diff --git a/documentation/18.11/_images/Definition_icon_2.png b/documentation/18.11/_images/Definition_icon_2.png new file mode 100644 index 00000000..7f7fadf8 Binary files /dev/null and b/documentation/18.11/_images/Definition_icon_2.png differ diff --git a/documentation/18.11/_images/Definition_icon_2.png.data b/documentation/18.11/_images/Definition_icon_2.png.data new file mode 100644 index 00000000..d9e07682 --- /dev/null +++ b/documentation/18.11/_images/Definition_icon_2.png.data @@ -0,0 +1,3 @@ +title=LogoDefinition +author=halw +path=content/logodefinition diff --git a/documentation/18.11/_images/LogoBeta.png b/documentation/18.11/_images/LogoBeta.png new file mode 100644 index 00000000..057d5bd1 Binary files /dev/null and b/documentation/18.11/_images/LogoBeta.png differ diff --git a/documentation/18.11/_images/LogoBeta.png.data b/documentation/18.11/_images/LogoBeta.png.data new file mode 100644 index 00000000..98777939 --- /dev/null +++ b/documentation/18.11/_images/LogoBeta.png.data @@ -0,0 +1,3 @@ +title=LogoBeta +author=halw +path=content/logobeta diff --git a/documentation/18.11/_images/LogoUpdateNeeded.png b/documentation/18.11/_images/LogoUpdateNeeded.png new file mode 100644 index 00000000..e9c8a89d Binary files /dev/null and b/documentation/18.11/_images/LogoUpdateNeeded.png differ diff --git a/documentation/18.11/_images/LogoUpdateNeeded.png.data b/documentation/18.11/_images/LogoUpdateNeeded.png.data new file mode 100644 index 00000000..6d1b689f --- /dev/null +++ b/documentation/18.11/_images/LogoUpdateNeeded.png.data @@ -0,0 +1,3 @@ +title=LogoUpdateNeeded +author=halw +path=content/logoupdateneeded diff --git a/documentation/18.11/_images/Review_icon_1.png b/documentation/18.11/_images/Review_icon_1.png new file mode 100644 index 00000000..b6ea96b4 Binary files /dev/null and b/documentation/18.11/_images/Review_icon_1.png differ diff --git a/documentation/18.11/_images/Review_icon_1.png.data b/documentation/18.11/_images/Review_icon_1.png.data new file mode 100644 index 00000000..4b06db70 --- /dev/null +++ b/documentation/18.11/_images/Review_icon_1.png.data @@ -0,0 +1,3 @@ +title=LogoReviewRequested +author=halw +path=content/logoreviewrequested diff --git a/documentation/18.11/_images/Rule_icon_4_2.png b/documentation/18.11/_images/Rule_icon_4_2.png new file mode 100644 index 00000000..e0402369 Binary files /dev/null and b/documentation/18.11/_images/Rule_icon_4_2.png differ diff --git a/documentation/18.11/_images/Rule_icon_4_2.png.data b/documentation/18.11/_images/Rule_icon_4_2.png.data new file mode 100644 index 00000000..89e76614 --- /dev/null +++ b/documentation/18.11/_images/Rule_icon_4_2.png.data @@ -0,0 +1,3 @@ +title=LogoRule +author=halw +path=content/logorule diff --git a/documentation/18.11/_images/tpl_Construction.png b/documentation/18.11/_images/tpl_Construction.png new file mode 100644 index 00000000..a3701d81 Binary files /dev/null and b/documentation/18.11/_images/tpl_Construction.png differ diff --git a/documentation/18.11/_images/tpl_Construction.png.data b/documentation/18.11/_images/tpl_Construction.png.data new file mode 100644 index 00000000..2c501459 --- /dev/null +++ b/documentation/18.11/_images/tpl_Construction.png.data @@ -0,0 +1,3 @@ +title=LogoConstruction +author=admin +path=content/logoconstruction diff --git a/documentation/18.11/_images/tpl_Information.png b/documentation/18.11/_images/tpl_Information.png new file mode 100644 index 00000000..86c67e02 Binary files /dev/null and b/documentation/18.11/_images/tpl_Information.png differ diff --git a/documentation/18.11/_images/tpl_Information.png.data b/documentation/18.11/_images/tpl_Information.png.data new file mode 100644 index 00000000..8e74a8f3 --- /dev/null +++ b/documentation/18.11/_images/tpl_Information.png.data @@ -0,0 +1,3 @@ +title=LogoInformation +author=admin +path=content/logoinformation diff --git a/documentation/18.11/_images/tpl_Recommended.png b/documentation/18.11/_images/tpl_Recommended.png new file mode 100644 index 00000000..a52b8d5b Binary files /dev/null and b/documentation/18.11/_images/tpl_Recommended.png differ diff --git a/documentation/18.11/_images/tpl_Recommended.png.data b/documentation/18.11/_images/tpl_Recommended.png.data new file mode 100644 index 00000000..78312ab9 --- /dev/null +++ b/documentation/18.11/_images/tpl_Recommended.png.data @@ -0,0 +1,3 @@ +title=LogoRecommended +author=admin +path=content/logorecommended diff --git a/documentation/18.11/_images/tpl_Warning.png b/documentation/18.11/_images/tpl_Warning.png new file mode 100644 index 00000000..67737269 Binary files /dev/null and b/documentation/18.11/_images/tpl_Warning.png differ diff --git a/documentation/18.11/_images/tpl_Warning.png.data b/documentation/18.11/_images/tpl_Warning.png.data new file mode 100644 index 00000000..2c804c09 --- /dev/null +++ b/documentation/18.11/_images/tpl_Warning.png.data @@ -0,0 +1,3 @@ +title=LogoWarning +author=admin +path=content/logowarning diff --git a/documentation/18.11/_others/community/index.wiki b/documentation/18.11/_others/community/index.wiki new file mode 100644 index 00000000..777cb81f --- /dev/null +++ b/documentation/18.11/_others/community/index.wiki @@ -0,0 +1,116 @@ +[[Property:title|Community]] +[[Property:description|Members of the Eiffel community can contribute to this documentation through this book]] +[[Property:weight|15]] +[[Property:uuid|75c75712-7c3e-2757-51b7-77b404471e2e]] +=You can become a contributor!= + +Eiffel is a community. Members of the Eiffel community can contribute to this documentation through this book. + +EiffelStudio documentation is available in a convenient Wiki format. This makes it possible to improve the documentation continuously and make sure it is always up to date. + +Community input is welcome. + +==Using the Comments pages== + +Each documentation page has an associated '''Comments''' page. Any viewer can add comments to a Comments page. These comments are periodically reviewed and appropriate content is "published," that is, made visible to the community. + +===Guidelines for Comments pages=== + +#The '''Comments''' pages are intended to be used to record and communicate issues concerning the documentation. Use Comments pages to post comments which report problems with the documentation or which suggest improvements to the documentation. +# '''Any material you add to this site becomes the property of Eiffel Software, and may be shared with the community.''' +# Comments pages should ''not'' be used for product support questions, product feature requests, or bug reports. ''Comments of this sort will be deleted.'' For help with products join the [http://groups.eiffel.com Eiffel Software User Group] and use the resources at the [http://community.eiffel.com Eiffel Community site]. + +===Comment lifecycle=== + +Although the procedure for how editors deal with comments is flexible, some general guidelines can be given: + +# For comments requesting action (e. g., fix a problem, add more information): +## For those actions which can be accomplished immediately: +### The comment will not be published. +### The requested action will be fixed. +### The original comment's subject line will be prepended with "FIXED". +## For those actions which cannot be accomplished quickly or require special handling: +### The comment will be published +### A response to the comment will be made via "reply", and +#### The original comment's subject line will be prepended with: +##### FIXED, if and when the request can be satisfied. +##### ANALYZED, otherwise, plus explanation of delaying or not acting on request. +## For actions affecting docs.eiffel.com plus the Eiffel distribution: +### Submit a problem report requesting feedback when problem is fixed so that docs.eiffel.com can be updated in kind. +# For comments not requesting action, but adding relevant information related to the page: +## The comment will be published. +## If appropriate: +### The content of the comment will be integrated into the page. +### The original comment's subject line prepended with FIXED. +# Periodically, an audit will remove older comments marked as FIXED and ANALYZED. + +==Contributors and Editors== + +If you are interested in a more active role in improving and developing EiffelStudio documentation, you can become: + +* A contributor: authorized to edit existing pages to any book, and to add pages to the "Community" book. +**"Community" book pages can be added to other books by an editor. + +* An editor: authorized to modify and add pages in any book. + +To become a contributor, you should be proficient in Eiffel technology and have good written English skills. To become an editor, you should already be a contributor and have contributed significant improvements or additions to the documentation. + +If you are interested in becoming a contributor, you can [[path:user/register|register]] for an account, and then please [[path:contact|contact us]] with a short description of your Eiffel experience and any other relevant background. + +===Guidelines for contributors=== + +# '''Entering log messages:''' When you change pages in the documentation, it can help sometimes if you can provide an explanation of your intent in the '''Log message''' box on the '''Edit''' page. This can eliminate confusion about why things have been changed. Of course, it is not necessary to provide a log message for every change. For fixing typographical errors or other simple changes, it generally would not be necessary, but putting a single lowercase '''"m"''' in the '''Log message''' field will convey the message that this was a minor update. If you are evolving new pages or a complex set of related changes to one or more pages, it should suffice to enter a single log message at the beginning of the series of edits. Use common sense here. +#* In cases in which a change is directly related to an external document or policy, it may be helpful to mention the impetus in the log message. For example, documentation changes made to satisfy Eiffel Software problem reports should reference the report in the log message. +# '''Renaming pages or moving pages to Trash:''' Before you rename a page or move it to the Trash, you should use the '''References''' tab to make certain that there are no current references to the page. If there are, make sure you resolve those references before renaming or moving the page. +# '''Replacing pages:''' If you need to replace a page completely, do so by replacing the '''content''' of the existing page, rather than moving the page to the Trash and creating a new page in its place. Replacing the content will leave the original page (and its UUID) in place, but with the new content. UUID's are used by the [[Eiffel Information System]] (EIS) to link EiffelStudio to documentation pages, and will be broken if the original page were to be deleted. +# '''Using templates:''' +## There are several "templates" available for use within the text of documentation pages. For example, "Note", "SeeAlso", "Rule", "Definition", "Caution". You can click on "List templates" in the left margin to see the list of available templates. +## While developing new pages or make significant changes to existing pages you may want to mark the tops of these pages temporarily with certain templates during the development process. The "top-of-the-page" templates most useful during page maintenance are Beta, ReviewRequested, UnderConstruction, and UpdateNeeded. The meanings of these are described below. + +==="Top-of-the-page" Documentation template meanings=== + +====Beta==== + +Looks like this: + +{{Beta}} + +Means this: + +:''Use this page with caution. This page is currently under development as a new page or a replacement for a previously existing page. It may contain information which describes capabilities not yet implemented. Avoid linking to this page. When this page comes out of beta, it is likely that the name and/or UUID of this page will change.'' + + +====ReviewRequested==== + +Looks like this: + +{{ReviewRequested}} + +Means this: + +:''The material on this page needs to be reviewed for completeness and accuracy. If you have knowledge of this material, please review this page. If you are a [[Community|contributor]], feel free to make any appropriate additions and/or corrections, then remove this template. If not, you can note improvements on the [[Community#Using the Comments pages|comments]] page.'' + + +====UnderConstruction==== + +Looks like this: + +{{UnderConstruction}} + +Means this: + +:''Use this page with caution. This page is currently under development. It is likely that the information on this page is still incomplete. '' + + +====UpdateNeeded==== + +Looks like this: + +{{UpdateNeeded}} + +Means this: + +:''Use this page with caution. This page has been identified as needing update. If you are a [[Community|contributor]], you can help by updating this page so that the information on it is current.'' + + + diff --git a/documentation/18.11/_others/draft/index.wiki b/documentation/18.11/_others/draft/index.wiki new file mode 100644 index 00000000..761f5714 --- /dev/null +++ b/documentation/18.11/_others/draft/index.wiki @@ -0,0 +1,5 @@ +[[Property:title|Draft]] +[[Property:weight|99]] +[[Property:uuid|c277e707-67a0-14a2-099e-5b861f2480ad]] + + diff --git a/documentation/18.11/_others/draft/multiple-inheritance.wiki b/documentation/18.11/_others/draft/multiple-inheritance.wiki new file mode 100644 index 00000000..bd7ff4a8 --- /dev/null +++ b/documentation/18.11/_others/draft/multiple-inheritance.wiki @@ -0,0 +1,49 @@ +[[Property:title|Multiple inheritance]] +[[Property:weight|0]] +[[Property:uuid|7f54afce-fd1d-fba7-7a55-f74604ea9846]] +

Multiple inheritance: definition

+ +Multiple inheritance is a mechanism for combining abstractions. It lets you define a class by extending or specializing two or more classes, not just one as in single inheritance. For example you might define a multi_function printer as the combination of a printer and a scanner. + +Multiple inheritance sometimes has the reputation of being complicated or even messy, but there is no such problem in Eiffel. "Name clashes", for example, are not a big deal: if classes A and B both have a feature with the same name f and class C inherits from both, you can either specify that they should be merged, or keep them separate through the rename mechanism. Details below. + +

Multiple inheritance basics

+ +Multiple inheritance happens as soon as you list more than one class in the inherit clause at the beginning of a class. For example: + + + class PRINTER feature + ... Here the features specific to printers ... + end + + class SCANNER feature + ... Here the features specific to scanners ... + end + + class MULTI_FUNCTION_PRINTER inherit + PRINTER + SCANNER + feature + ... Here the features specific to printer-scanners ... + end + + +As with single inheritance, the new class has access to the parent features, except that here they are features of two different parents. For example if PRINTER has feature and SCANNER has features scan and scanned, then the feature clause of SCANNER can include + + + scan_and_print + -- Scan a page and print it. + do + scan -- Leaves result of scan in `scanned' + print (scanned) + end + + + + + + + + + + diff --git a/documentation/18.11/_others/draft/test-page.wiki b/documentation/18.11/_others/draft/test-page.wiki new file mode 100644 index 00000000..a3f103ff --- /dev/null +++ b/documentation/18.11/_others/draft/test-page.wiki @@ -0,0 +1,5 @@ +[[Property:title|Test page]] +[[Property:weight|0]] +[[Property:uuid|6dc09e0f-b713-8c5b-799f-36a60264e8f8]] +Test page for Book "Draft" + diff --git a/documentation/18.11/_others/guide/_images/static_documentation_page_0.png b/documentation/18.11/_others/guide/_images/static_documentation_page_0.png new file mode 100644 index 00000000..e3f9218e Binary files /dev/null and b/documentation/18.11/_others/guide/_images/static_documentation_page_0.png differ diff --git a/documentation/18.11/_others/guide/_images/static_documentation_page_0.png.data b/documentation/18.11/_others/guide/_images/static_documentation_page_0.png.data new file mode 100644 index 00000000..1a8c9a7b --- /dev/null +++ b/documentation/18.11/_others/guide/_images/static_documentation_page_0.png.data @@ -0,0 +1,3 @@ +title=static documentation page +author=halw +path=content/static-documentation-page diff --git a/documentation/18.11/_others/guide/index.wiki b/documentation/18.11/_others/guide/index.wiki new file mode 100644 index 00000000..30c5a797 --- /dev/null +++ b/documentation/18.11/_others/guide/index.wiki @@ -0,0 +1,186 @@ +[[Property:title|Guide]] +[[Property:description|Central repository of information about Eiffel and the products and technologies of Eiffel Software]] +[[Property:link_title|Information Guide]] +[[Property:weight|10]] +[[Property:uuid|68b37685-64e9-f564-9258-29e709a55f44]] +'''Guide to Eiffel Information''' + +These pages are the central repository of information about Eiffel and the products and technologies of Eiffel Software. They cover the online documentation, but also link to many valuable resources outside the documentation set. + +If you are interested in [[Learning Eiffel|learning Eiffel, there is a list of resources]] dedicated to that purpose. + +The online documentation is organized into virtual books. Each book covers an important aspect of the world of Eiffel. For cases in which it is not always possible to use the online version of the documentation, all or selected parts of the documentation set can be [[Offline use of the Eiffel documentation|downloaded for offline use]]. + +* [[Guide]] -- Guide to Eiffel Information +* [[EiffelStudio]] -- The EiffelStudio Interactive Development Environment +* [[Solutions]] -- Eiffel Solutions, Technologies, and Class Libraries +* [[Platform specifics]] -- Specific support for particular platforms, e.g., Microsoft Windows +* [[Method|Method and Language]] -- The Eiffel Method and Language +* [[Why Eiffel?]] -- Why Eiffel? +* [[Papers]] -- Technical and position papers relating to Eiffel and the engineering of high quality software +* [[Examples]] -- Contributor supported examples of Eiffel solutions to common programming problems +* [[Community]] -- Community Contributions + +Sources of information on Eiffel include: + +==Books in the Eiffel Documentation== +---- + +===[[Guide]] -- Guide to Eiffel Information=== + +:You are reading this book now. + +===[[EiffelStudio]] -- The EiffelStudio Interactive Development Environment=== + +:Information about installing and using EiffelStudio + +===[[Solutions]] -- Eiffel Solutions, Technologies, and Class Libraries=== + +:Technologies available with Eiffel provide solutions to many ordinary development needs ... and some extraordinary needs too. This book addresses these requirements and the Eiffel technologies that satisfy them. + +===[[Platform specifics]] -- Support for particular operating systems=== + +:Although most Eiffel technology is completely platform-independent, Eiffel also provides important platform-specific solutions, described in this book. + +===[[Method|Method and Language]] -- The Eiffel Method and Language=== + +:Materials promoting the understanding of the Eiffel software development method and the Eiffel programming language. + +===[[Why Eiffel?]] -- Why Eiffel? === + +:A summary of the arguments for using Eiffel. + +===[[Papers]] -- Technical and position papers relating to Eiffel=== + +:This book is a place for white papers which provide background, foundation, or supplemental information about the the Eiffel method and language as well as the goal of engineering high quality software. + +===[[Examples]] -- Contributor supported examples of Eiffel solutions to common programming problems=== + +:Let's build a set of examples that can be shared on popular WWW program chrestomathies. + +===[[Community]] -- You can contribute to the documentation!=== + +:EiffelStudio documentation is available in a convenient Wiki format. This makes it possible to improve the documentation continuously and make sure it is always up to date. + + + +'''Community input''' is welcome. If you are interested in improving and developing EiffelStudio documentation, you can become a ''contributor'' or ''editor'': + +* Contributors can edit existing pages in any book and add pages to Community Contributions books. + +* Editors can modify and add pages in any book (including adding Community Contribution pages to an existing book). + +To become a contributor, you should be proficient in Eiffel technology and have good written English skills. To become an editor, you should already have made significant improvements or additions as a contributor. + +If you are interested in becoming a contributor, please send an email to info@eiffel.com with a short description of your Eiffel experience and any other relevant background. We look forward to your contributions! + + + +---- + +==Other sources of information on Eiffel== + +---- + + +===The [http://eiffel.com Eiffel.com] website=== + +Eiffel Software's website [http://eiffel.com Eiffel.com] contains an enormous amount of information about Eiffel. There are product descriptions, special pages for developers and their managers, case studies and testimonials, the latest Eiffel news, and much more. + + +---- + +===[http://eiffel.com/developers/presentations/ Web Presentations] on Eiffel.com=== + +Learn quickly about Eiffel and the things that help make it special, like Design by Contract and EiffelStudio. Learn how Eiffel fits in with and compares to other popular technologies. All this and more is available on the [http://eiffel.com/developers/presentations/ presentations page] on Eiffel.com. + + +---- + +===[http://eiffel.com/developers/learning_maps/ Learning Maps] on Eiffel.com=== + +Get an in-depth view of topics by navigating the [http://eiffel.com/developers/learning_maps/ Eiffel Learning Maps]. Learning maps represent knowledge as a network of interrelated concepts. Attached to the concepts you may find links to additional resources. These resources can be just about anything. You'll find plain text files, web pages, screen shots, and even Eiffel Learnlets. Learnlets are small units of learning in web presentation form that are designed to take no more than 30 minutes to view ... just right for your lunch break. + + +---- + +===The [http://www.eiffelroom.com/ EiffelRoom] Website=== + +[http://www.eiffelroom.com/ EiffelRoom] is an Eiffel community website on which Eiffel developers from across the globe come together and share their experiences ... and their products. You'll find how-to articles, tips and tricks, example code, whole libraries of EIffel classes, and specialized products. It is easy to contribute to EiffelRoom and start giving back to the community. + + +---- + +===The Eiffel Software User Group=== + +The Eiffel Software Users' Group is a focus group for those who use the products of Eiffel Software. Its primary communication vehicle is a [http://groups.eiffel.com/ collaborative discussion group]. The group mailing list is monitored by Eiffel Software developers and many highly experienced Eiffel programmers. So if you have questions or comments about Eiffel Software products, this is a good place to be. + + +---- + +===The EiffelWorld Newsletter=== + +A few times a year, we send out an email newsletter containing announcements of new versions of products, upcoming events, newly added technologies, website changes, editorials, and contributions from the community. To subscribe send a request to [mailto:info@eiffel.com info@eiffel.com]. + + +---- + +===[[Object-Oriented Software Construction, 2nd Edition]]=== + +There is no better place to gain an in-depth understanding of the Eiffel software development method than [[Object-Oriented Software Construction, 2nd Edition]], by Bertrand Meyer, published by Prentice Hall. It is the world's most complete guide to building great object-oriented software. + + +---- + +===Other [[Books about the Eiffel Method and Language|books about the Eiffel Method and Language]]=== + + +---- + +===The Standard: ''Eiffel: Analysis, Design, and Programming Language''=== + +Eiffel has been standardized under ISO and ECMA. The comprehensive description of the standard Eiffel programming language is presented in [http://www.ecma-international.org/publications/standards/Ecma-367.htm Standard ECMA-367]. + + + +---- + +===Contribute to Eiffel=== + +You can help Eiffel by contributing your time, expertise, and products. Here are some websites that you can visit to see what's up with the development of Eiffel Software products. + +====[http://dev.eiffel.com dev.eiffel.com]==== + +:This [http://dev.eiffel.com wiki site] is the hub of development activity for the EiffelStudio interactive development environment. Even if you do not plan to contribute, dev.eiffel.com is a valuable source of information concerning where EiffelStudio is going ... and, if you're curious, where it has been. + +====[http://eiffelstudio.origo.ethz.ch/ EiffelStudio on Origo]==== + +:[http://eiffelstudio.origo.ethz.ch/ EiffelStudio on Origo] contains blogs and forums focusing on Eiffel and EiffelStudio topics. + + + + + +---- + +==[[uuid:b8c10baa-4f50-adfe-a6f8-9cb56a8f1917|Glossary of Object Technology]]== + +---- + + +This is a relatively comprehensive glossary of terms used in Object-Oriented Analysis, Design, and programming, but are not specific to the Eiffel Language, since object-oriented principles can be applied to any programming language. It contains all the terms from the glossary in [[Object-Oriented Software Construction, 2nd Edition]], plus others used in this website, added for clarity and ease of reference. + +This glossary is useful all by itself, since a review of it can serve as a refresher (in case you have been away from Object Technology for a while). It is used in this website to assist the reader by providing easy links to technical terms that are used throughout the website. + +Additionally, it is possible to link to terms in this glossary from other websites by using links that look like this: + +:http://docs.eiffel.com/book/guide/glossary-object-technology#Attribute + +or a version that will survive the page being moved: + +:http://docs.eiffel.com/isedoc/uuid/b8c10baa-4f50-adfe-a6f8-9cb56a8f1917#Attribute + +Note that the anchor (the part after the "#") has to be spelled and capitalized exactly like the term on the page. (Use underscore characters to replace spaces.) + +---- + diff --git a/documentation/18.11/_others/guide/offline-use-eiffel-documentation.wiki b/documentation/18.11/_others/guide/offline-use-eiffel-documentation.wiki new file mode 100644 index 00000000..8dd50e01 --- /dev/null +++ b/documentation/18.11/_others/guide/offline-use-eiffel-documentation.wiki @@ -0,0 +1,30 @@ +[[Property:title|Offline use of the Eiffel Documentation]] +[[Property:link_title|Download Documentation]] +[[Property:weight|0]] +[[Property:uuid|e5f003f6-c732-c648-fd67-91f6642130f0]] +It is possible to download the books of the Eiffel online documentation for viewing offline with a web browser. + +To do this you use a [http://docs.eiffel.com/static/ web page] which has links to downloadable files that contain copies of the documentation in different forms and quantities. + + +[[Image:static documentation page|Downloadable documentation]] + + +The files are ".7z" files, meaning that they are compressed archives in [http://www.7-zip.org 7-zip] format. So, you can use any 7-zip compatible expander to unpack the files. + +You'll notice that the options for downloading come in three groups: + +# HTML: Multiple pages per book. +# HTML: One big page per book. +# WikiText+meta: raw files containing wikitext (backup) + +You should choose your files from one of the HTML options (the WikiText option is used for backup). + +It is possible also to download one documentation "book" at a time, or to download all books in one archive. + +The files are static copies of the content of the online documentation, as reflected by the dates shown on the web page. + + + + + diff --git a/documentation/18.11/_others/why-eiffel/index.wiki b/documentation/18.11/_others/why-eiffel/index.wiki new file mode 100644 index 00000000..e7653e7b --- /dev/null +++ b/documentation/18.11/_others/why-eiffel/index.wiki @@ -0,0 +1,11 @@ +[[Property:title|Why Eiffel?]] +[[Property:description|arguments for using Eiffel]] +[[Property:weight|11]] +[[Property:uuid|df007537-c0dd-2ea6-233b-764ad483eb65]] +This book collects arguments for using Eiffel. + +Even though we in the Eiffel community know that Eiffel is the most advanced object-oriented software development framework on this planet, that fact may not be so obvious to everyone else. Consequently, we felt that it would be helpful to provide some brief documents that spell out the reasons why the people who have chosen Eiffel have been so successful. + +You may find the information helpful if you are simply curious about Eiffel, if you are actively looking for a better development framework, or if you are busy trying to convince others to try Eiffel. + + diff --git a/documentation/18.11/_templates/Beta.tpl b/documentation/18.11/_templates/Beta.tpl new file mode 100644 index 00000000..e32b4e94 --- /dev/null +++ b/documentation/18.11/_templates/Beta.tpl @@ -0,0 +1 @@ +

[[Image:LogoBeta|24px]] '''Beta documentation:''' [[How to contribute to documentation#Beta|see definition]].

diff --git a/documentation/18.11/_templates/Beta.tpl.data b/documentation/18.11/_templates/Beta.tpl.data new file mode 100644 index 00000000..fd45de21 --- /dev/null +++ b/documentation/18.11/_templates/Beta.tpl.data @@ -0,0 +1,3 @@ +title=Beta +author=vwheeler +path=content/beta diff --git a/documentation/18.11/_templates/Caution.tpl b/documentation/18.11/_templates/Caution.tpl new file mode 100644 index 00000000..d716bdad --- /dev/null +++ b/documentation/18.11/_templates/Caution.tpl @@ -0,0 +1,2 @@ +

[[Image:LogoWarning|24px]] '''Caution:''' {{{1}}}

+ diff --git a/documentation/18.11/_templates/Caution.tpl.data b/documentation/18.11/_templates/Caution.tpl.data new file mode 100644 index 00000000..f41bf645 --- /dev/null +++ b/documentation/18.11/_templates/Caution.tpl.data @@ -0,0 +1,3 @@ +title=Caution +author=admin +path=content/caution-0 diff --git a/documentation/18.11/_templates/Info.tpl b/documentation/18.11/_templates/Info.tpl new file mode 100644 index 00000000..3c38d64f --- /dev/null +++ b/documentation/18.11/_templates/Info.tpl @@ -0,0 +1 @@ +

[[Image:LogoInformation|24px]] '''Info: '''{{{1}}}

diff --git a/documentation/18.11/_templates/Info.tpl.data b/documentation/18.11/_templates/Info.tpl.data new file mode 100644 index 00000000..dc6791fd --- /dev/null +++ b/documentation/18.11/_templates/Info.tpl.data @@ -0,0 +1,3 @@ +title=Info +author=admin +path=content/info diff --git a/documentation/18.11/_templates/Inline-Error.tpl b/documentation/18.11/_templates/Inline-Error.tpl new file mode 100644 index 00000000..64076adc --- /dev/null +++ b/documentation/18.11/_templates/Inline-Error.tpl @@ -0,0 +1 @@ +{{{1}}} diff --git a/documentation/18.11/_templates/Inline-Info.tpl b/documentation/18.11/_templates/Inline-Info.tpl new file mode 100644 index 00000000..a32c6bbd --- /dev/null +++ b/documentation/18.11/_templates/Inline-Info.tpl @@ -0,0 +1 @@ +{{{1}}} diff --git a/documentation/18.11/_templates/Inline-Success.tpl b/documentation/18.11/_templates/Inline-Success.tpl new file mode 100644 index 00000000..0351750e --- /dev/null +++ b/documentation/18.11/_templates/Inline-Success.tpl @@ -0,0 +1 @@ +{{{1}}} diff --git a/documentation/18.11/_templates/Inline-Warning.tpl b/documentation/18.11/_templates/Inline-Warning.tpl new file mode 100644 index 00000000..1a097523 --- /dev/null +++ b/documentation/18.11/_templates/Inline-Warning.tpl @@ -0,0 +1 @@ +{{{1}}} diff --git a/documentation/18.11/_templates/Key.tpl b/documentation/18.11/_templates/Key.tpl new file mode 100644 index 00000000..b0eece42 --- /dev/null +++ b/documentation/18.11/_templates/Key.tpl @@ -0,0 +1 @@ +{{{1}}} diff --git a/documentation/18.11/_templates/Key.tpl.data b/documentation/18.11/_templates/Key.tpl.data new file mode 100644 index 00000000..d26a2509 --- /dev/null +++ b/documentation/18.11/_templates/Key.tpl.data @@ -0,0 +1,3 @@ +title=Key +author=admin +path=content/key diff --git a/documentation/18.11/_templates/Note.tpl b/documentation/18.11/_templates/Note.tpl new file mode 100644 index 00000000..1b00b242 --- /dev/null +++ b/documentation/18.11/_templates/Note.tpl @@ -0,0 +1 @@ +

[[Image:LogoInformation|24px]] '''Note: '''{{{1}}}

diff --git a/documentation/18.11/_templates/Note.tpl.data b/documentation/18.11/_templates/Note.tpl.data new file mode 100644 index 00000000..855e9265 --- /dev/null +++ b/documentation/18.11/_templates/Note.tpl.data @@ -0,0 +1,3 @@ +title=Note +author=admin +path=content/note diff --git a/documentation/18.11/_templates/Recommended.tpl b/documentation/18.11/_templates/Recommended.tpl new file mode 100644 index 00000000..43521ac7 --- /dev/null +++ b/documentation/18.11/_templates/Recommended.tpl @@ -0,0 +1 @@ +

[[Image:LogoRecommended|24px]] '''Recommended: '''{{{1}}}

diff --git a/documentation/18.11/_templates/Recommended.tpl.data b/documentation/18.11/_templates/Recommended.tpl.data new file mode 100644 index 00000000..9b7bf199 --- /dev/null +++ b/documentation/18.11/_templates/Recommended.tpl.data @@ -0,0 +1,3 @@ +title=Recommended +author=admin +path=content/recommended diff --git a/documentation/18.11/_templates/ReviewRequested.tpl b/documentation/18.11/_templates/ReviewRequested.tpl new file mode 100644 index 00000000..c927b85c --- /dev/null +++ b/documentation/18.11/_templates/ReviewRequested.tpl @@ -0,0 +1 @@ +

[[Image:LogoReviewRequested|24px]] '''Review requested: ''' [[How to contribute to documentation#ReviewRequested|see definition]].

diff --git a/documentation/18.11/_templates/ReviewRequested.tpl.data b/documentation/18.11/_templates/ReviewRequested.tpl.data new file mode 100644 index 00000000..89fcc23e --- /dev/null +++ b/documentation/18.11/_templates/ReviewRequested.tpl.data @@ -0,0 +1,3 @@ +title=ReviewRequested +author=vwheeler +path=content/reviewrequested diff --git a/documentation/18.11/_templates/Rule.tpl b/documentation/18.11/_templates/Rule.tpl new file mode 100644 index 00000000..5a2ab11a --- /dev/null +++ b/documentation/18.11/_templates/Rule.tpl @@ -0,0 +1 @@ +

[[Image:LogoRule|24px]] '''Rule -- {{{name}}}:''' {{{text}}}

diff --git a/documentation/18.11/_templates/Rule.tpl.data b/documentation/18.11/_templates/Rule.tpl.data new file mode 100644 index 00000000..1eb02663 --- /dev/null +++ b/documentation/18.11/_templates/Rule.tpl.data @@ -0,0 +1,3 @@ +title=Rule +author=halw +path=content/rule diff --git a/documentation/18.11/_templates/Sample.tpl b/documentation/18.11/_templates/Sample.tpl new file mode 100644 index 00000000..cfb7647c --- /dev/null +++ b/documentation/18.11/_templates/Sample.tpl @@ -0,0 +1 @@ +

[[Image:LogoInformation|24px]] '''Sample:''' {{{1}}}

diff --git a/documentation/18.11/_templates/Sample.tpl.data b/documentation/18.11/_templates/Sample.tpl.data new file mode 100644 index 00000000..424705cd --- /dev/null +++ b/documentation/18.11/_templates/Sample.tpl.data @@ -0,0 +1,3 @@ +title=Sample +author=admin +path=content/sample diff --git a/documentation/18.11/_templates/SeeAlso.tpl b/documentation/18.11/_templates/SeeAlso.tpl new file mode 100644 index 00000000..5cae363f --- /dev/null +++ b/documentation/18.11/_templates/SeeAlso.tpl @@ -0,0 +1 @@ +

[[Image:LogoInformation|24px]] '''See Also:''' {{{1}}}

diff --git a/documentation/18.11/_templates/SeeAlso.tpl.data b/documentation/18.11/_templates/SeeAlso.tpl.data new file mode 100644 index 00000000..b6d7a6d1 --- /dev/null +++ b/documentation/18.11/_templates/SeeAlso.tpl.data @@ -0,0 +1,3 @@ +title=SeeAlso +author=admin +path=content/seealso diff --git a/documentation/18.11/_templates/Tip.tpl b/documentation/18.11/_templates/Tip.tpl new file mode 100644 index 00000000..fb97fb41 --- /dev/null +++ b/documentation/18.11/_templates/Tip.tpl @@ -0,0 +1 @@ +

[[Image:LogoInformation|24px]] '''Tip: '''{{{1}}}

diff --git a/documentation/18.11/_templates/Tip.tpl.data b/documentation/18.11/_templates/Tip.tpl.data new file mode 100644 index 00000000..b08eb551 --- /dev/null +++ b/documentation/18.11/_templates/Tip.tpl.data @@ -0,0 +1,3 @@ +title=Tip +author=admin +path=content/tip diff --git a/documentation/18.11/_templates/UnderConstruction.tpl b/documentation/18.11/_templates/UnderConstruction.tpl new file mode 100644 index 00000000..8690bef8 --- /dev/null +++ b/documentation/18.11/_templates/UnderConstruction.tpl @@ -0,0 +1 @@ +

[[Image:LogoConstruction|24px]] '''Under construction:''' [[How to contribute to documentation#UnderConstruction|see definition]].

diff --git a/documentation/18.11/_templates/UnderConstruction.tpl.data b/documentation/18.11/_templates/UnderConstruction.tpl.data new file mode 100644 index 00000000..03ee0be2 --- /dev/null +++ b/documentation/18.11/_templates/UnderConstruction.tpl.data @@ -0,0 +1,3 @@ +title=UnderConstruction +author=vwheeler +path=content/underconstruction diff --git a/documentation/18.11/_templates/UpdateNeeded.tpl b/documentation/18.11/_templates/UpdateNeeded.tpl new file mode 100644 index 00000000..67c6d834 --- /dev/null +++ b/documentation/18.11/_templates/UpdateNeeded.tpl @@ -0,0 +1 @@ +

[[Image:LogoUpdateNeeded|24px]] '''Update Needed:''' [[How to contribute to documentation#UpdateNeeded|see definition]].

diff --git a/documentation/18.11/_templates/UpdateNeeded.tpl.data b/documentation/18.11/_templates/UpdateNeeded.tpl.data new file mode 100644 index 00000000..ba14a901 --- /dev/null +++ b/documentation/18.11/_templates/UpdateNeeded.tpl.data @@ -0,0 +1,3 @@ +title=UpdateNeeded +author=vwheeler +path=content/updateneeded diff --git a/documentation/18.11/_templates/Warning.tpl b/documentation/18.11/_templates/Warning.tpl new file mode 100644 index 00000000..78c79dcd --- /dev/null +++ b/documentation/18.11/_templates/Warning.tpl @@ -0,0 +1 @@ +

[[Image:LogoWarning|24px]] '''Warning:''' {{{1}}}

diff --git a/documentation/18.11/_templates/Warning.tpl.data b/documentation/18.11/_templates/Warning.tpl.data new file mode 100644 index 00000000..fb2d9462 --- /dev/null +++ b/documentation/18.11/_templates/Warning.tpl.data @@ -0,0 +1,3 @@ +title=Warning +author=admin +path=content/warning diff --git a/documentation/18.11/_templates/definition.tpl b/documentation/18.11/_templates/definition.tpl new file mode 100644 index 00000000..b6ee693f --- /dev/null +++ b/documentation/18.11/_templates/definition.tpl @@ -0,0 +1 @@ +

[[Image:LogoDefinition|24px]] '''Definition -- {{{1}}}''': {{{2}}}

diff --git a/documentation/18.11/_templates/definition.tpl.data b/documentation/18.11/_templates/definition.tpl.data new file mode 100644 index 00000000..9990e7a0 --- /dev/null +++ b/documentation/18.11/_templates/definition.tpl.data @@ -0,0 +1,3 @@ +title=definition +author=halw +path=content/definition diff --git a/documentation/18.11/contribute/documentation.wiki b/documentation/18.11/contribute/documentation.wiki new file mode 100644 index 00000000..8ebcc5a1 --- /dev/null +++ b/documentation/18.11/contribute/documentation.wiki @@ -0,0 +1,44 @@ +[[Property:title|How to contribute to documentation]] +[[Property:link_title|To documentation]] +[[Property:weight|2]] +[[Property:uuid|A2DED192-B50A-4E59-B214-FDC3FEDC7A44]] + += Current documentation system = +* The documentation is written using wikitext syntax (similar to wikipedia). +* Each documentation page is stored in a wiki file on disk. +* Those files come from the subversion repository: [https://svn.eiffel.com/eiffel-org/trunk/documentation/trunk] . +* The outline of book are following the underlying directory structure, and each wiki file can have properties that hold metadata such as: + +[[Property:title|The page title]] +[[Property:link_title|short title]] +[[Property:weight|5]] + +** '''link_title''' is used to have a short title in menu, or various links. +** '''weight''' is used to order sibling pages (lower weight goes before, upper weight goes after). + += To contribute = +* First, you can post comment on any page (see comment form at the bottom of each page). +* As one would contribute to any source maintained on a subversion repository, one can contribute via the repository [https://svn.eiffel.com/eiffel-org/trunk/documentation/trunk/] and provide patch. +* Note there is also a git mirror at [https://github.com/eiffelsoftware/eiffel-org] so you can also contribute via github by sending pull request. + += Step by step with git = +* Go to [https://github.com/eiffelsoftware/eiffel-org] for the project, then git clone on your machine. +* create a git branch. +* add or edit the files locally. +* once you want to share your changes. +** git commit your changes. +** git push them to your github repository. +** then create a pull request so that the Eiffel.org documentation team can review and integrate the changes. +* See current pull requests at [https://github.com/EiffelSoftware/eiffel-org/pulls]. + += Step by step with subversion = +* svn checkout https://svn.eiffel.com/eiffel-org/trunk/documentation/trunk/. +* add or edit the files locally. +* once you want to share your changes. +** svn update. +** Send the patch via [https://codereview.appspot.com/]. (note: follow the instructions from codereview site, you will need to use a python script "upload.py" distributed by the codereview site). +* See current patches at [https://codereview.appspot.com/search?base=https://svn.eiffel.com/eiffel-org/trunk/documentation/trunk/]. + += Live editing on this site = +* If you are a trusted editor, you can edit the documentation directly. +* To be a trusted editor, please request it via the [https://www.eiffel.org/contact contact] page (do not forget to mention who you are and why you think you should be a trusted editor). diff --git a/documentation/18.11/contribute/editing_help.wiki b/documentation/18.11/contribute/editing_help.wiki new file mode 100644 index 00000000..dcf54b89 --- /dev/null +++ b/documentation/18.11/contribute/editing_help.wiki @@ -0,0 +1,123 @@ +[[Property:title|Help to edit documentation]] +[[Property:link_title|Editing help]] +[[Property:weight|3]] + += Wikitext syntax = +* Have a look at [https://en.wikipedia.org/wiki/Help:Wiki_markup Wikipedia markup] documentation. +* The current website does not support the full Wikipedia syntax, but still most of the needed cases. + +* To embed inline code: +** `` `foo.bar` `` +** `foo.bar` +** `foo.bar` + +* To embed block code: + +```xml + + class FOOBAR + +``` + +```xml + + class FOOBAR + +``` + + +```eiffel + class FOOBAR +``` + + +Note: if you do not specify the lang, it is defaulted to "eiffel" + + + += Templates = +== Top page templates == +Used to qualify the current page. + +=== ReviewRequested === +:{{ReviewRequested|This is a ReviewRequested message}} +{{ReviewRequested|This is a ReviewRequested message}} + +=== UnderConstruction === +:{{UnderConstruction|This is a UnderConstruction message}} +{{UnderConstruction|This is a UnderConstruction message}} + +=== UpdateNeeded === +:{{UpdateNeeded|This is a UpdateNeeded message}} +{{UpdateNeeded|This is a UpdateNeeded message}} + +=== Beta === +:{{Beta|This is a beta message}} +{{Beta|This is a beta message}} + + +== Block templates == +=== Caution === +:{{Caution|This is a caution message}} +{{Caution|This is a caution message}} + +=== Definition === +:{{Definition|abc|This is a Definition message}} +{{Definition|abc|This is a Definition message}} + +=== Info === +:{{Info|This is a Info message}} +{{Info|This is a Info message}} + + +=== Note === +:{{Note|This is a Note message}} +{{Note|This is a Note message}} + +=== Recommended === +:{{Recommended|This is a Recommended message}} +{{Recommended|This is a Recommended message}} + +=== Rule === +:{{Rule|name=abc|text=This is a Rule message}} +{{Rule|name=abc|text=This is a Rule message}} + +=== Sample === +:{{Sample|This is a Sample message}} +{{Sample|This is a Sample message}} + +=== SeeAlso === +:{{SeeAlso|This is a SeeAlso message}} +{{SeeAlso|This is a SeeAlso message}} + +=== Tip === +:{{Tip|This is a Tip message}} +{{Tip|This is a Tip message}} + +=== Warning === +:{{Warning|This is a Warning message}} +{{Warning|This is a Warning message}} + + +== Inline templates == + +=== Key === +:This is a {{Key|key message}} in the text. +This is a {{Key|key message}} in the text. + +=== Error === +:This is a {{Inline-Error|error message}} in the text. +This is a {{Inline-Error|error message}} in the text. + +=== Info === +:This is a {{Inline-Info|info message}} in the text. +This is a {{Inline-Info|info message}} in the text. + +=== Success === +:This is a {{Inline-Success|success message}} in the text. +This is a {{Inline-Success|success message}} in the text. + +=== Warning === +:This is a {{Inline-Warning|warning message}} in the text. +This is a {{Inline-Warning|warning message}} in the text. + diff --git a/documentation/18.11/contribute/index.wiki b/documentation/18.11/contribute/index.wiki new file mode 100644 index 00000000..afa682dc --- /dev/null +++ b/documentation/18.11/contribute/index.wiki @@ -0,0 +1,10 @@ +[[Property:title|How to contribute]] +[[Property:description|How to contribute]] +[[Property:link_title|Contribute]] +[[Property:weight|6]] +[[Property:uuid|56480505-4CD5-4C8A-AA3D-120FD573DFA9]] + += How to contribute to Eiffel ? = + +Check page [https://www.eiffel.org/contribute] . + diff --git a/documentation/18.11/eiffel/Coding_Standards/Eiffel-Code-Comments.wiki b/documentation/18.11/eiffel/Coding_Standards/Eiffel-Code-Comments.wiki new file mode 100644 index 00000000..2e33d9cc --- /dev/null +++ b/documentation/18.11/eiffel/Coding_Standards/Eiffel-Code-Comments.wiki @@ -0,0 +1,144 @@ +[[Property:uuid|146E241E-C367-4F16-9CCE-6F11E5F7860A]] +[[Property:weight|1]] +[[Property:title|Eiffel Code Comments]] + +==Comment Mark Up == +The Eiffel compiler and EiffelStudio's code browsing tools support a special, light-weight mark up in comments and strings for referencing classes and features. EiffelStudio's code browsing tools use this mark up to better facilitate code navigation and browsing. In addition, marked up comments and strings will be examined and altered when performing a class or feature ''rename'' refactoring. + +===Syntax=== +The syntax for marking up classes and features is very compact, to ensure retained legibility. You'll see no need for XML or other types of verbose mark up found in other languages, which can impede the comment's very nature as a quick reference. + +To mark up a class reference, surround the class name in an open ('''{''') and matching closing ('''}''') brace: + + +-- See {DEBUG_OUTPUT} for more information. + + +To mark up a feature reference, implemented in the same class or parent, surround the feature name in a single back quote (`) and a matching closing single quote ('): + + +-- See `debug_output' for more information. + + +In the case where a reference to a feature is not accessible to the containing class directly, use a combination of the class reference mark up and a feature name, ''sans'' quotation marks: + + +-- See {DEBUG_OUTPUT}.debug_output for more information. + + +The rules that apply for comments, as described above, can also be utilized in any manifest or verbatim string: + + +note + description: "Augments searching facilities of {STRING_8}" + + +==Precursor Comments== + +{{Version|6.2}} + +Precursor comments declarations are a new mechanism added to EiffelStudio 6.2 to replicate a parent feature declaration's comments in the redefined/effective feature. The purpose of the mechanism is to reduce comment duplication, ease comment maintenance and facilitate augmentation. + +For the purpose of demonstration, take the following deferred interface: + +deferred class + BASE + +feature -- Query + + test (a_arg: INTEGER): BOOLEAN + -- Comments for a feature. + -- + -- `a_arg': An integer value. + -- `Result': Could be True or False. + deferred + end + +end + + +And effective implementation of it: + + +class + TEST + +inherit + BASE + +feature -- Query + + test (a_arg: INTEGER): BOOLEAN + -- + do + end + +end + + +TEST instead of replicating the comment makes use of the precursor comment declaration (-- ), which supporting code browsing tool will expand to show the precursor feature's contracts. The declaration is optional but is only supported for existing code out there that do not have comments due to lax implementation. Even though optional, it is strongly recommended that you use -- comment declaration, as it indicates to any reader the feature is a redefinition or effective implementation of a parent feature declaration. + +=== Comment Augmentation === +The precursor comments declaration also supports augmentation. All a comment author has to do is to write additional comments before and/or after the precursor comment declaration. As a requirement, the precursor comment declaration must appear on a separate line for no other purpose except for clarity. Failure to do so will results in the rendering of the comments as they are declared in the feature, i.e. with -- as is. + + +test (a_arg: INTEGER): BOOLEAN + -- Comments before the original comments from {BASE}. + -- + -- + -- + -- Some additional comments. + do + end + + +Using the code browsing facilities of [[EiffelStudio]] the reader will be presented with an expanded comment, for the effective version of feature test, that now read + + +-- Comments before the original comments from {BASE}. +-- +-- Comments for a feature. +-- +-- `a_arg': An integer value. +-- `Result': Could be True or False. +-- +-- Some additional comments. + + +For clarity it is a good idea to separate the agumented comments from the precursor comment declaration. Using the same example above but removing the one line spacing above and below the precursor comment declaration would results in the following, less readable comment: + + +-- Comments before the original comments from {BASE}. +-- Comments for a feature. +-- +-- `a_arg': An integer value. +-- `Result': Could be True or False. +-- Some additional comments. + + +However, that said, it is pure discretion to use additional spacing or not. Some situation do not call for, other do and some might (when the original comment changes.) + +=== Multiple Redefinitions and Selection === +With Eiffel supporting multiple inheritance, a scenario will arise where two inherited redefine features are joined in a descendant. + +By default the precursor comment declaration is replaced by the first located inherited feature comment, which may cause documentation irregularities. Because precursor comments are not signification to compilation they are not checked during compilation, such as is the way with the use of Precursor, resulting a compile time error when not selecting the parent class to call into. This can cause documentation irregularities because there is no guarantee that they feature comments viewed one project will be the same in another. + +To facilitate correct documentation the precursor comment declaration can use an optional select clause, just like using Precursor in the Eiffel code. + + +f (a_arg: INTEGER): BOOLEAN + -- + do + end + + +This will have exactly the same effect as using -- when f is made effective/redefined from a single parent. However, when making effective/redefining from multiple parents then comments will come from the parent class declaration in BASE. + +Again, because precursor comments do not affect compilation they are not checked at compile time. Specifying an incorrect class will yield a warning message in [[EiffelStudio]]'s code browsing tools, to the effect: + + +-- Unable to retrieve the comments from redefinition of {CLASS_NAME}. + + +=== Library Documentation Generation === +Precursor comments are supported in all code browsing/documentation facilities, whether is be the integrated [[Contract Viewer]], the [[Feature Relation Tool]] or the Eiffel documentation generation facilities. Using -- will ensure the comments are brought up from a parent declaration. diff --git a/documentation/18.11/eiffel/Coding_Standards/Eiffel-Coding-Standard.wiki b/documentation/18.11/eiffel/Coding_Standards/Eiffel-Coding-Standard.wiki new file mode 100644 index 00000000..57287ca6 --- /dev/null +++ b/documentation/18.11/eiffel/Coding_Standards/Eiffel-Coding-Standard.wiki @@ -0,0 +1,93 @@ +[[Property:modification_date|Mon, 03 Dec 2018 10:00:43 GMT]] +[[Property:publication_date|Tue, 30 Oct 2018 14:56:21 GMT]] +[[Property:uuid|0CD0A1B2-42F8-48E0-B419-61B4DC076C1B]] +[[Property:weight|2]] +[[Property:title|Eiffel Coding Standard]] + +==Language consideration== +* Do not put a blank line between +:* '''create''' and creation instructions +:* '''inherit''' and parent clauses +* Do not use assertion clauses without tag names. + +A sample of proper formatting of code: +note + description: "Descr...." + date: "$date: $" + +class A + +inherit + B + rename + f as g + end + +create + make + +feature {NONE} -- Initialization + + make (a: INTEGER) + -- Initialize Current with `a`. + do + end + +invariant + a_positive: a > 0 + +end + +==Style== +* If instructions: +if expr1 then + ... +elseif expr2 then + ... +else + ... +end + +If expressions are very long, break them on conjunctions as in: +if + expr1 and then + expr2 +then + ... +end + +* Loop instructions: +from + ... +until + ... +loop + ... +end + +* Inspect instructions: +inspect expr +when val1 then .... +else + ... +end + +or + +inspect + expr +when val1 then + ... +else + ... +end + +* For punctuation, we always have +** a space before, and no after `(` +** no space before, and space after `)` `,` `:` or `;` + +require + a_tag: query (a, b, c) or other_query (c, d) +local + i: INTEGER; j: INTEGER + diff --git a/documentation/18.11/eiffel/Coding_Standards/Local-Declaration-Guidelines.wiki b/documentation/18.11/eiffel/Coding_Standards/Local-Declaration-Guidelines.wiki new file mode 100644 index 00000000..3449e534 --- /dev/null +++ b/documentation/18.11/eiffel/Coding_Standards/Local-Declaration-Guidelines.wiki @@ -0,0 +1,236 @@ +[[Property:uuid|FF8DA311-55E5-4314-8B0C-AADB4645E686]] +[[Property:weight|3]] +[[Property:title|Local Declaration Guidelines]] + +Local declaration style guidelines for contributing to the Eiffel Software code repository. + +== Feature Arguments == +Feature arguments should begin with the prefix ''a_'' and nothing more. The prefix ''a_'' represent a contraction of the word ''argument'' and does not represent the singular inflection - a ''noun'' - Therefore it is '''not''' valid to utilize ''an'' when the suffixed argument word begins with a vowel. The following is a correct usage: + + +perform (a_string: STRING; a_integer: STRING): CHARACTER + -- An example using routine argument variable names. + do + end + + +Here, the second argument ''a_integer'', is not considered ''A Integer'' but ''The Argument Integer'', hence the use if a_ instead of ''_an_''. + +=== Indexing Routine Argument Variable Names === +In rare cases there is a need to use the same name on a routine's arguments, which of course no useful language would allow. Instead a slight form of indexing needs to be applied. In this case the use of ''other'' embedded in the variable name would suffice for most cases. + + +compare_strings (a_string: READABLE_STRING_GENERAL; a_other_string: like a_string): INTEGER_8 + -- An example using 'other' to index the second routine argument name + do + ... + end + + +=== In-line Agent Routine Arguments === +When working with an in-line agent, to prevent conflicts with the enclosing routine's arguments, the prefix ''ia_'' should be used. The same rules regarding English language rules apply here as they do to routine arguments. The ''ia_'' prefix represents an ''In-line Argument''. + + +perform (a_string: STRING; a_integer: STRING) + -- An example using in-line agent argument variable names. + do + process (agent (ia_string: STRING; ia_integer: INTEGER) + do + ... + end (a_string, a_integer)) + end + + +==== Nested In-line Agent Routine Arguments ==== +Although rare, a nested in-line agents need exists. When dealing with nested in-line agent routine argument names the prefix should contain the nested index, with the container in-line agent using either a ''1'' or no index in the prefix names. First/Top-level in-line agents (those that are not nested) can use the aforementioned ''ia_'' prefix or use ''i1a_'', the former being preferred. A second-level (first nested level) in-line agent should use the prefix ''i2a_'', third-level ''i3a_'' and so forth. + + +perform (a_string: STRING; a_integer: STRING) + -- An example using in-line agent argument variable names. + do + process (agent (ia_string: STRING; ia_integer: INTEGER) + do + -- An example of an nested, in-line agent + process (agent (i2a_string: STRING; i2a_integer: INTEGER) + do + .... + end (ia_string.as_lower, ia_integer) + end (a_string, a_integer)) + end + + +== Local Declarations == +Routine local declaration should also be prefixed to prevent potential conflicts between routine arguments or class attributes. The prefix ''l_'' is typically used for variable moniker names longer than two character. There are other exceptions, these are discussed below. + +=== Well Known Variable Names === +Indexing/counter variables, as used in iteration loops, should not use a local prefix and should be terse. The variable ''i'' should be use to indicate it is an index variable. Additional index variables should follow alphabetically from ''i'' onwards. + +Generally, paired with an indexing/counter variable, a stopping condition count or number-of-items variable is also used. There are two conventions used for this, generally used interchangeably; A count will use the same rules for local declarations and be called ''l_count'', a number-of-items variable will use a well-known contracted variable name 'nb''. + + +perform (a_array: ARRAY [INTEGER]) + -- An example using index and number-of-items local variable names. + local + i, nb: INTEGER + do + from + i := a_array.lower + nb := a_array.upper + until + i > nb + loop + ... + i := i + 1 + end + end + + +The case will commonly arise when multiple counters/number-of-items variables need to be used. In such cases the counter/number-of-items variable should be suffixed with the associated indexing/counter variable name. This is akin to [http://en.wikipedia.org/wiki/BASIC BASIC]'s NEXT x instruction: + + +perform (a_array: ARRAY [ARRAY [INTEGER]]) + -- An example using multiple index and number-of-items local variable names. + local + l_sub_array: ARRAY [INTEGER] + i, nb_i: INTEGER + j, nb_j: INTEGER + do + from + i := a_array.lower + nb_i := a_array.upper + until + i > nb_i + loop + l_item := a_array[i] + if l_item /= Void then + from + j := l_item.lower + nb_j := l_item.upper + until + j > nb_j + loop + ... + j := j + 1 + end + end + i := i + 1 + end + end + + +==== Other Well-Known Names ==== + +There are a number of other well know and simpler to use local variable names: + +* ''c'' for any type of character. +* ''e'' for any type of exception (descendant of EXCEPTION). +* ''s'' for any type of string (descendant of READABLE_STRING_GENERAL). +* ''uc'' for a Unicode character. +* ''us'' for a Unicode string (descendant of READABLE_STRING_32). +* ''nb'' for a number or count of elements. + +==== Rescue Clauses ==== + +When adding a rescue clause with a retry a state variable, typically used to determine if a retry has been performed, there is no need to use a local declaration prefix. In fact, it's recommended there is no prefix. Instead just use a variable named ''retried'': + + +perform + -- An example using a rescue/retry local variable name. + local + retried: BOOLEAN + do + if not retried then + ... + end + rescue + retried := True + retry + end + + +=== Object Tests === +Object test locals obey the same rules and other standard local declarations, that it, prefixing a variable moniker with ''l_''. However, due to the current scoping rules of object-tests, where no object test local may be reused, extraneous guidelines need to be defined. + + +close + -- An example using object-test scoped local variable names. + do + if attached {DISPOSABLE_I} Current as l_disposable then + l_disposable.dispose + end + end + + +==== In Contracts ==== +Object tests may need to be defined in contracts, especially when projects/libraries are configured to use Void-Safe compilation checks. To prevent variable name conflicts from arising a secondary prefix should be used to define an object-test local. Again using ''l_'' but this time prefixed with the first character of the enclosing assertion clause. Such rules would dictated the following prefixes to be used in object-tests, for assertion clauses: +* ''rl_'' for require +* ''el_'' for ensure +* ''cl_'' for check +* ''ll_'' for loop +* ''il_'' for loop invariant +* ''vl_'' for loop variant + + +close + -- An example using object-test scoped local variable names in contracts. + require + is_interface_usable: attached {USABLE_I} Current as rl_usable implies rl_usable.is_interface_usable + do + ... + ensure + not_is_interface_usable: attached {USABLE_I} Current as el_usable implies not el_usable.is_interface_usable + end + + +No prefix, other than ''l_'' is needed for class invariants because no conflicts in variable name reuse exist in an invariant scope. + +=== In-line Agents === +There is no real preferred convention for local declaration inside in-line agents and the ''l_'' prefix should be used if possible. However, for clarity this cannot always be such the case. When such as scenario arises the use of ''il_'' (in-line local) is preferred. It is recommended that all locals utilize the same prefix and '''not''' mix ''l_'' and il_''! + + +l_action := agent (ia_string: READABLE_STRING_GENERAL) + local + il_i, il_count: INTEGER + do + .... + end + + +Notice that even well-known local declaration names are prefixed, this is to avoid conflicts with the containing routine or in-line agent as well as providing consistency in the naming of local variables. + +With nested in-line agents use the same name index injection guideline, placing the nested index after the initial ''i'' prefix. For a second level in-line agent, this would be ''i2l_''. + +== Indexing Variable Names == +There will be times when variable names clash with one another and there is no choice but to apply the last-stop effort to naturally indexed variable names to suit. This last-stop effort is really a last-stop. Other attempts should be made to create unique variable names before applying natural indexing. + +Natural indexing concerns itself with suffixing variables with a sequential natural index. The only exception is the first local declaration which may or may not have the primary index suffix ''_1''. To better illustrate, the following code examples are both valid uses of natural indexing: + + +perform + -- An example of using natural sequential indexes to avoid variable name clashes. + local + l_item_1: ITEM + l_item_2: ITEM + l_item_3: ITEM + do + ... + end + + +or + + +perform + -- An example with the first index elided, which is also valid. + local + l_item: ITEM + l_item_2: ITEM + l_item_3: ITEM + do + ... + end + + +If local declaration have to be indexed when first writing the code then it is far better to be explicit and use a natural sequential index for all similar local declaration (the former example). The latter example is valid and would exist when modifying existing code. There is no hard or fast rule here, each is valid as long as the indexes are sequential. + +The examples apply to all variable declaration, not just local declarations. diff --git a/documentation/18.11/eiffel/Coding_Standards/Style-Guidelines.wiki b/documentation/18.11/eiffel/Coding_Standards/Style-Guidelines.wiki new file mode 100644 index 00000000..a123ebc1 --- /dev/null +++ b/documentation/18.11/eiffel/Coding_Standards/Style-Guidelines.wiki @@ -0,0 +1,766 @@ +[[Property:uuid|46FFB0ED-CE10-4CA5-8F10-5E1D0AB6EE46]] +[[Property:weight|4]] +[[Property:title|Style Guidelines]] + +Style Guidelines that EiffelStudio developers should use and are not intended or suggestions for developing code with the Eiffel language. The guidelines are to promote consistency in API design, making EiffelStudio's code base more readable to all. + +==Status of this page== +[I am starting this page by copy-pasting from existing references. It will be edited and cleaned up later on.[[User:Bertrand Meyer|Bertrand Meyer]] 12:35, 22 May 2008 (PDT) + +=From ''Object-Oriented Software Construction''= + +Implementing the object-oriented method requires paying attention to many details of style, which a less ambitious approach might consider trifles. + +==COSMETICS MATTERS!== +Although the rules appearing hereafter are not as fundamental as the principles of object-oriented software construction covered in earlier chapters, it would be foolish to dismiss them as just “cosmetics”. Good software is good in the large and in the small, in its high-level architecture and in its low-level details. True, quality in the details does not guarantee quality of the whole; but sloppiness in the details usually indicates that something more serious is wrong too. (If you cannot get the cosmetics right, why should your customers believe that you can master the truly difficult aspects?) A serious engineering process requires doing everything right: the grandiose and the mundane. + +So you should not neglect the relevance of such seemingly humble details as text layout and choice of names. True, it may seem surprising to move on, without lowering our level of attention, from the mathematical notion of sufficient completeness in formal specifications (in the chapter on abstract data types) to whether a semicolon should be preceded by a space (in the present chapter). The explanation is simply that both issues deserve our care, in the same way that when you write quality O-O software both the design and the realization will require your attention. + +We can take a cue from the notion of style in its literary sense. Although the first determinant of good writing is the author’s basic ability to tell a story and devise a coherent structure, no text is successful until everything works: every paragraph, every sentence and every word. + +===Applying the rules in practice=== +Some of the rules of this chapter can be checked or, better yet, enforced from the start by software tools. Tools will not do everything, however, and there is no substitute for care in writing every piece of the software. + +There is often a temptation to postpone the application of the rules, writing things casually at first and thinking “I will clean up everything later on; I do not even know how much of this will eventually be discarded”. This is not the recommended way. Once you get used to the rules, they do not add any significant delay to the initial writing of the software; even without special tools, it is always more costly to fix the text later than to write it properly from the start. And given the pressure on software developers, there is ever a risk that you will forget or not find the time to clean things up. Then someone who is asked later to take up your work will waste more time than it would have cost you to write the proper header comments, devise the right feature names, apply the proper layout. That someone may be you. + +===Terseness and explicitness=== +Software styles have oscillated between the terse and the verbose. In programming languages, the two extremes are perhaps APL and Cobol. The contrast between the Fortran-C-C++ line and the Algol-Pascal-Ada tradition — not just the languages themselves, but the styles they have bred — is almost as stark. + +What matters for us is clarity and, more generally, quality. Extreme forms of terseness and verbosity can both work against these goals. Cryptic C programs are unfortunately not limited to the famous “obfuscated C” and “Obfuscated C++” contests; but the almost equally famous DIVIDE DAYS BY 7 GIVING WEEKS of Cobol is a waste of everyone’s attention. + +The style that follows from this chapter’s rules is a particular mix of Algol-like explicitness (although not, it is hoped, verbosity) and telegram-style terseness. It never begrudges keystrokes, even lines, when they truly help make the software readable; for example, you will find rules that enjoin using clear identifiers based on full words, not abbreviations, as it is foolish to save a few letters by calling a feature disp (ambiguous) rather than display (clear and precise), or a class ACCNT (unpronounceable) rather than ACCOUNT. There is no tax on keystrokes. But at the same time when it comes to eliminating waste and unneeded redundancies the rules below are as pitiless as the recommendations of a General Accounting Office Special Commission on Improving Government. They limit header comments to indispensable words, getting rid of all the non-essential “the” and other such amenities; they proscribe over-qualification of feature names (as in account_balance in a class ACCOUNT, where balance is perfectly sufficient); against dominant mores, they permit the grouping of related components of a complex construct on a single line, as in from i := 1 invariant i <= n until i = n loop; and so on. + +This combination of terseness and explicitness is what you should seek in your own texts. Do not waste space, as exaggerated size will in the end mean exaggerated complexity; but do not hesitate to use space when it is necessary to enhance clarity. + +Also remember, if like many people you are concerned about how much smaller the text of an object-oriented implementation will be than the text of a comparable C, Pascal, Ada or Fortran program, that the only interesting answer will appear at the level of a significant system or subsystem. If you express a basic algorithm — at the level of Quicksort, say, or Euclid’s algorithm — in C and in the notation of this book, expect the O-O version to be at least as large. In many cases, if you apply the principles thoroughly, it will be larger, since it will include assertions and more type information. Yet in ISE’s experience of looking at medium-scale systems we have sometimes found (without being able to give a general law, as the circumstances vary considerably) the object-oriented solution to be several times smaller. Why? This is not due to terseness at the “micro” level but to systemwide application of the architectural techniques of the O-O method: + +Genericity is one of the key factors. We have found C programs that repeated essentially the same C code many times to handle different types. With a generic class — or for that matter a generic Ada package — you immediately get rid of that redundancy. It is disturbing in this respect to see that Java, a recent O-O language based on C, does not support genericity. + +Inheritance is also fundamental in gathering commonalities and removing duplications. + +Dynamic binding replaces many complex decision structures by much shorter calls. + +Assertions and the associated idea of Design by Contract avoid redundant error checking, a principal source of bloat. + +The exception mechanism gets rid of some error code. + +If you are concerned with source size, make sure to concentrate on these architectural aspects. You should also be terse in expressing algorithms, but never skimp on keystrokes at the expense of clarity. + +===The role of convention=== +Most rules define a single permissible form, with no variants. The few exceptions include font use, which is governed by external considerations (what looks good in a book may not be visible on overhead transparencies), and semicolons, for which there exist two opposite schools with equally forceful arguments (although we will have a few universal rules anyway). In all other cases, in line with the introductory methodology chapter’s exhortations against wishy-washiness, the rules leave about as much room to doubt as a past due reminder from the Internal Revenue Service. + +The rules are rooted in a careful analysis of what works and what works less well, resulting from many years of observation; some of the rationale will appear in the discussion. Even so, some rules may appear arbitrary at first, and indeed in a few cases the decision is a matter of taste, so that reasonable persons working from the same assumptions may disagree. If you object to one of the recommended conventions, you should define your own, provided you explain it in detail and document it explicitly; but do think carefully before making such a decision, so obvious are the advantages of abiding by a universal set of rules that have been systematically applied to thousands of classes over more than ten years, and that many people know and understand. + +As noted in an earlier chapter (in the more general context of design principles), many of the style rules were originally developed for libraries, and then found their way into ordinary software development. In object technology, of course, all software is developed under the assumption that even if it is not reusable yet it might eventually be made reusable, so it is natural to apply the same style rules right from the start. + +===Self-practice=== +Like the design rules of the preceding chapters, the style rules which follow have been carefully applied to the many examples of this book. The reasons are obvious: one should practice what one preaches; and, more fundamentally, the rules do support clarity of thought and expression, which can only be good for a detailed presentation of the object-oriented method. + +The only exceptions are a few occasional departures from the rules on software text layout. These rules do not hesitate to spread texts over many lines, for example by requiring that every assertion clause have its own label. Lines are not a scarce resource on computer screens; it has been observed that with the computer age we are reversing the direction of the next-to-last revolution in written communication, the switch from papyrus rolls to page-structured books. But this text is definitely a book, structured into pages, and a constant application of the layout-related rules would have made it even bigger than it is. + +The cases of self-dispensation affect only two or three layout-related rules, and will be noted in their presentation below. Any exception only occurs after the first few examples of a construct in the book have applied the rules scrupulously. + +Such exceptions are only justified for a paper presentation. Actual software texts should apply the rules literally. + +===Discipline and creativity=== +It would be a mistake to protest against the rules of this chapter (and others) on the grounds that they limit developer creativity. A consistent style favors rather than hampers creativity by channeling it to where it matters. A large part of the effort of producing software is spent reading existing software and making others read what is being written. Individual vagaries benefit no one; common conventions help everyone. + +Some of the software engineering literature of the nineteen-seventies propounded the idea of “egoless programming”: developing software so that it does not reflect anything of its authors’ personality, thereby making developers interchangeable. Applied to system design, this goal is clearly undesirable, even if some managers may sometimes long for it (as in this extract of a programming management book quoted by Barry Boehm: “ºthe programmer[‘s] creative instincts should be totally dulled to insure uniform and understandable programming”, to which Boehm comments: “Given what we know about programmers and their growth motivation, such advice is a clear recipe for disaster”). + +What quality software requires is egoful design with egoless expression. + +More than style standards, what would seem to require justification is the current situation of software development, with its almost total lack of style standards. In no other discipline that demands to be called “engineering” is there such room for such broad personal variations of whim and fancy. To become more professional, software development needs to regulate itself. + +==CHOOSING THE RIGHT NAMES== +The first aspect that we need to regulate is the choice of names. Feature names, in particular, will be strictly controlled for everyone’s benefit. + +===General rules=== +What matters most is the names of classes and features which will be used extensively by the authors of classes that rely on yours. + +For feature and class names, use full words, not abbreviations, unless the abbreviations are widely accepted in the application domain. In a class PART describing parts in an inventory control system, call number, not num, the feature (query) giving the part number. Typing is cheap; software maintenance is expensive. An abbreviation such as usa in a Geographical Information System or copter in a flight control system, having gained an independent status as a word of its own, is of course acceptable. In addition, a few standard abbreviations have gained recognition over the years, such as PART for PARTIAL in class names such as PART_COMPARABLE describing objects equipped with a partial order relation. + +In choosing names, aim for clarity. Do not hesitate to use several words connected by underscores, as in ANNUAL_RATE, a class name, or yearly_premium, a feature name. + +Although modern languages do not place any limit on the length of identifiers, and treat all letters as significant, name length should remain reasonable. Here the rule is not the same for classes and for features. Class names are input only occasionally (in class headers, type declarations, inheritance clauses and a few other cases) and should describe an abstraction as completely as possible, so PRODUCT_QUANTITY_INDEX_EVALUATOR may be fine. For features, there is seldom a need for more than two or possibly three underscore-connected words. In particular, do not overqualify feature names. If a feature name appears too long, it is usually because it is overqualified: + +===Composite Feature Name rule=== +Do not include in a feature name the name of the underlying data abstraction (which should serve as the class name). + + +The feature giving the part number in class PART should be called just number, not part_number. Such over-qualification is a typical beginner’s mistake; the resulting names obscure rather than illuminate the text. Remember that every use of the feature will unambiguously indicate the class, as in part1 l number where part1 must have been declared with a certain type, PART or a descendant. + +For composite names, it is better to avoid the style, popularized by Smalltalk and also used in such libraries as the X Window System, of joining several words together and starting the internal ones with an upper-case letter, as in yearlyPremium. Instead, separate components with underscores, as in yearly_ premium. The use of internal upper-case letters is ugly; it conflicts with the conventions of ordinary language; and it leads to cryptic names, hence to possible errors (compare aLongAndRatherUnreadableIdentifier with an_even_longer_but_ perfectly_clear_choice_of_name). + +Sometimes, every instance of a certain class contains a field representing an instance of another class. This suggests using the class name also as attribute name. You may for example have defined a class RATE and, in class ACCOUNT, need one attribute of type RATE, for which it seems natural to use the name rate — in lower case, according to the rules on letter case stated below. Although you should try to find a more specific name, you may, if this fails, just declare the feature as rate: RATE. The rules on identifier choice explicitly permit assigning the same name to a feature and a class. Avoid the style of prefixing the name with the, as in the_rate, which only adds noise. + +===Local entities and routine arguments=== +The emphasis on clear, spelled-out names applies to features and classes. Local entities and arguments of a routine only have a local scope, so they do not need to be as evocative. Names that carry too much meaning might almost decrease the software’s readability by giving undue weight to ancillary elements. So it is appropriate to declare local entities (here in routines of TWO_WAY_LIST in the Base libraries) as + +move (i: INTEGER) + -- Move cursor i positions, or after if i is too large. + local + c: CURSOR; counter: INTEGER; p: like FIRST_ELEMENT + +remove + -- Remove current item; move cursor to right neighbor (of after if none). + local + succ, pred, removed: like first_element + + +If succ and pred had been features they would have been called successor and predecessor. It is also common to use the names new for a local entity representing a new object to be created by a routine, and other for an argument representing an object of the same type as the current one, as in the declaration for clone in GENERAL: + +frozen clone (other: GENERAL): like other + + +===Letter case=== +Letter case is not significant in our notation, as it is too dangerous to let two almost identical identifiers denote different things. But strongly recommended guidelines help make class texts consistent and readable: + +Class names appear in all upper case: POINT, LINKED_LIST, PRICING_MODEL. Formal generic parameters too, usually with just one letter: G. + +Names of non-constant attributes, routines other than once functions, local entities and routine arguments appear in all lower case: balance, deposit, succ, i. + +Constant attributes have their first letter in upper case and the rest in lower case: Pi: INTEGER is 3.1415926524; Welcome_message: STRING is "Welcome!". This applies to unique values, which are constant integers. + +The same convention applies to once functions, the equivalent of constants for non-basic types: Error_window, Io. Our first example, the complex number i, remained in lower case for compatibility with mathematical conventions. + +This takes care of developer-chosen names. For reserved words, we distinguish two categories. Keywords such as do and class play a strictly syntactic role; they are written in lower case, and will appear in boldface (see below) in printed texts. A few reserved words are not keywords because they carry an associated semantics; written with an initial upper case since they are similar to constants, they include Current, Result, Precursor, True and False. + +===Grammatical categories=== +Precise rules also govern the grammatical category of the words from which identifiers are derived. In some languages, these rules can be applied without any hesitation; in English, as noted in an earlier chapter, they will leave more flexibility. + +The rule for class names has already been given: you should always use a noun, as in ACCOUNT, possibly qualified as in LONG_TERM_SAVINGS_ACCOUNT, except for the case of deferred classes describing a structural property, which may use an adjective as in NUMERIC or REDEEMABLE. + +Routine names should faithfully reflect the Command-Query separation principle: + +Procedures (commands) should be verbs in the infinitive or imperative, possibly with complements: make, move, deposit, set_color. + +Attributes and functions (queries) should never be imperative or infinitive verbs; never call a query get_value, but just value. Non-boolean query names should be nouns, such as number, possibly qualified as in last_month_balance. Boolean queries should use adjectives, as in full. In English, because of possible confusions between adjectives and verbs (empty, for example, could mean “is this empty?” or “empty this!”), a frequent convention for boolean queries is the is_ form, as in is_empty. + +===Standard names=== +You will have noted, throughout this book, the recurrence of a few basic names, such as put and item. They are an important part of the method. + +Many classes will need features representing operations of a few basic kinds: insert an element into a structure, replace the value of an element, access a designated elementº Rather than devising specific names for the variants of these operations in every class, it is preferable to apply a standard terminology throughout. + +Here are the principal standard names. We can start with creation procedures, for which the recommended is make for the most common creation procedure of a class. Non-vanilla creation procedures may be called make_some_qualification, for example make_polar and make_cartesian for a POINT or COMPLEX class. + +====For commands the most common names are:==== + +*extend: Add an element. +*replace: Replace an element. +*force: Like put but may work in more cases; for example put for arrays has a precondition to require the index to be within bounds, but force has no precondition and will resize the array if necessary. +*remove: Remove an (unspecified) element. +*prune: Remove a specific element. +*wipe_out: Remove all elements. + +====For non-boolean queries (attributes or functions):==== +*item: The basic query for accessing an element: in ARRAY, the element at a given index; in STACK classes, the stack top; in QUEUE classes, the oldest element; and so on. +*infix "@": A synonym for item in a few cases, notably ARRAY. +: -- Note: no longer necessary; use bracket alias instead. Still present in existing libraries. +*count: Number of usable elements in a structure. +*capacity: Physical size allocated to a bounded structure, measured in number of potential elements. The invariant should include 0 <= count and count <= capacity. + +====For boolean queries:==== +*is_empty: Is the structure devoid of elements? +*is_full: Is there no more room in the representation to add elements? (Normally the same as count = capacity.) +*has: Is a certain element present? (The basic membership test.) +*is_extendible: Can an element be added? (May serve as a precondition to extend.) +*is_prunable: Can an element be removed? (May serve as a precondition to remove and prune.) +*is_readable: Is there an accessible element? (May serve as precondition to item and remove.) +*is_writable: Is it possible to change an element? (May variously serve as precondition to extend, replace, put etc.) + +::Note: the variants without `is_' are also widely used, e.g. `prunable', but the `is_' form is now recommended. + +A few name choices which may seem strange at first are justified by considerations of clarity and consistency. For example prune goes with prunable and extend with extendible; delete and add might seem more natural, but then s l deletable and s l addable would carry the wrong connotation, since the question is not whether s can be deleted or added but whether we can add elements to it or delete elements from it. The verbs prune and extend, with the associated queries, convey the intended meaning. + +===The benefits of consistent naming=== +The set of names sketched above is one of the elements that most visibly contribute to the distinctive style of software construction developed from the principles of this book. + +Is the concern for consistency going too far? One could fear that confusion could result from routines that bear the same name but internally do something different. For example item for a stack will return the top element, and for an array will return an element corresponding to the index specified by the client. + +With a systematic approach to O-O software construction, using static typing and Design by Contract, this fear is not justified. To learn about a feature, a client author can rely on four kinds of property, all present in the short form of the enclosing class: +*Its name. +*Its signature (number and type of arguments if a routine, type of result if a query). +*Its precondition and postcondition if any. +*Its header comment. + +A routine also has a body, but that is not part of what client authors are supposed to use. + +Three of these elements will differ for the variants of a basic operation. For example in the short form of class STACK you may find the feature + +put (x: G) + -- Push x on top. + require + writable: not full + ensure + not_empty: not empty + pushed: item = x + +whereas its namesake will appear in ARRAY as + +put (x: G; i: INTEGER) + -- Replace by x the entry of index i + require + not_too_small: i >= lower + not_too_large: i <= upper + ensure + replaced: item (i) = x + + +The signatures are different (one variant takes an index, the other does not); the preconditions are different; the postconditions are different; and the header comments are different. Using the same name put, far from creating confusion, draws the reader’s attention to the common role of these routines: both provide the basic element change mechanism. + +This consistency has turned out to be one of the most attractive aspects of the method and in particular of the libraries. New users take to it quickly; then, when exploring a new class which follows the standard style, they feel immediately at home and can zero in on the features that they need. + +==USING CONSTANTS== +Many algorithms will rely on constants. As was noted in an early chapter of this book, constants are widely known for the detestable practice of changing their values; we should prepare ourselves against the consequences of such fickleness. + +===Manifest and symbolic constants=== +The basic rule is that uses of constants should not explicitly rely on the value: + +====Symbolic Constant principle==== +Do not use a manifest constant, other than the zero elements of basic operations, in any construct other than a symbolic constant declaration. + + +In this principle, a manifest constant is a constant given explicitly by its value, as in 50 (integer constant) or "Cannot find file" (string constant). The principle bars using instructions of the form + +population_array l make (1, 50) + +or + +print ("Cannot find file") -- See mitigating comment below about this case + + +Instead, you should declare the corresponding constant attributes, and then, in the bodies of the routines that need the values, denote them through the attribute names: + +US_state_count: INTEGER = 50 +File_not_found: STRING = "Cannot find file" + + + +population_array l make (1, state_count) + + + +print (file_not_found) + + +The advantage is obvious: if a new state is added, or the message needs to be changed, you have only have to update one easy-to-locate declaration. + +The use of 1 together with state_count in the first instruction is not a violation of the principle, since its prohibition applies to manifest constants “other than zero elements of basic operations”. These zero elements, which you may use in manifest form, include the integers 0 and 1 (zero elements of addition and multiplication), the real number 0.0, the null character written '%0', the empty string " ". Using a symbolic constant One every time you need to refer to the lower bound of an array (1 using the default convention) would lead to an unsustainable style — pedantic, and in fact less readable because of its verbosity. Sometimes, Freud is supposed to have said, a cigar is just a cigar; sometimes One is just 1. + +Some other times 1 is just a system parameter that happens to have the value one today but could become 4,652 later — its role as addition’s zero element being irrelevant. Then it should be declared as a symbolic constant, as in Processor_count: INTEGER is 1 in a system that supports multiple processors and is initially applied to one processor. + +The Symbolic Constant principle may be judged too harsh in the case of simple manifest strings used just once, such as "Cannot find file" above. Some readers may want to add this case to the exception already stated in the principle (replacing the qualification by “other than manifest string constants used only once in the same class, and zero elements of basic operations”). This book has indeed employed a few manifest constants in simple examples. Such a relaxation of the rule is acceptable, but in the long run it is probably preferable to stick to the rule as originally given even if the result for string constants looks a little pedantic at times. One of the principal uses of string constants, after all, is for messages to be output to users; when a successful system initially written for the home market undergoes internationalization, it will be that much less translation work if all the user-visible message strings (at least any of them that actually appear in the software text) have been put in symbolic constant declarations. + +====Where to put constant declarations==== +If you need more than a handful of local constant attributes in a class, you have probably uncovered a data abstraction — a certain concept characterized by a number of numeric or character parameters. + +It is desirable, then, to group the constant declarations into a class, which can serve as ancestor to any class needing the constants (although some O-O designers prefer to use the client relation in this case). An example in the Base libraries is the class ASCII, which declares constant attributes for the different characters in the ASCII character set and associated properties. + +==HEADER COMMENTS AND NOTE CLAUSES== +Although the formal elements of a class text should give as much as possible of the information about a class, they must be accompanied by informal explanations. Header comments of routines and feature clause answer this need together with the note clause of each class. + + '''Terminology''': in earlier Eiffel versions the keyword indexing was used instead of note, + and "note clauses" were called "indexing clauses" + +===Routine header comments: an exercise in corporate downsizing=== + +Like those New York street signs that read “Don’t even think of parking here!”, the sign at the entrance of your software department should warn “Don’t even think of writing a routine without a header comment”. The header comment, coming just after the is for a routine, expresses its purpose concisely; it will be kept by the short and flat-short forms: + +distance_to_origin: REAL + -- Distance to point (0, 0) + local + origin: POINT + do + create origin + Result := distance (origin) + end + +Note the indentation: one step further than the start of the routine body, so that the comment stands out. + +Header comments should be informative, clear, and terse. They have a whole style of their own, which we can learn by looking at an initially imperfect example and improve it step by step. In a class CIRCLE we might start with + + +tangent_from (p: POINT): LINE + -- Return the tangent line to the current circle going through the point p, + -- if the point is outside of the current circle. + require + outside_circle: not has (p) + + +There are many things wrong here. First, the comment for a query, as here, should not start with “Return theº” or “Compute theº”, or in general use a verbal form; this would go against the Command-Query Separation principle. Simply name what the query returns, typically using a qualified noun for a non-boolean query (we will see below what to use for a boolean query and a command). Here we get: + + + -- The tangent line to the current circle going through the point p, + -- if the point p is outside of the current circle + + +Since the comment is not a sentence but simply a qualified noun, the final period disappears. Next we can get rid of the auxiliary words, especially the, where they are not required for understandability. Telegram-like style is desirable for comments. (Remember that readers in search of literary frills can always choose Proust novels instead.) + + --Tangent line to current circle from point p, + -- if point p is outside current circle + + +The next mistake is to have included, in the second line, the condition for the routine’s applicability; the precondition, not has (p), which will be retained in the short form where it appears just after the header comment, expresses this condition clearly and unambiguously. There is no need to paraphrase it: this could lead to confusion, if the informal phrasing seems to contradict the formal precondition, or even to errors (a common oversight is a precondition of the form x >= 0 with a comment stating “applicable only to positive x”, rather than “non-negative”); and there is always a risk that during the software’s evolution the precondition will be updated but not the comment. Our example becomes: + + -- Tangent line to current circle from point p. + + +Yet another mistake is to have used the words line to refer to the result and point to refer to the argument: this information is immediately obvious from the declared types, LINE and POINT. With a typed notation we can rely on the formal type declarations — which again will appear in the short form — to express such properties; repeating them in the informal text brings nothing. So: + + -- Tangent to current circle from p. + + +The mistakes of repeating type information and of duplicating the precondition’s requirements point to the same general rule: in writing header comments, assume the reader is competent in the fundamentals of the technology; do not include information that is obvious from the immediately adjacent short form text. This does not mean, of course, that you should never specify a type; the earlier example, -- Distance to point (0,0), could be ambiguous without the word point. + +When you need to refer to the current object represented by a class, use phrasing such as current circle, current number and so on as above, rather than referring explicitly to the entity Current. In many cases, however, you can avoid mentioning the current object altogether, since it is clear to everyone who can read a class text that features apply to the current object. Here, for example, we just need + + -- Tangent from p. + + +At this stage — three words, starting from twenty-two, an 87% reduction that would make the toughest Wall Street exponent of corporate downsizing jealous — it seems hard to get terser and we can leave our comment alone. + +A few more general guidelines. We have noted the uselessness of “Return the ” in queries; other noise words and phrases to be avoided in routines of all kinds include “This routine computes”, “This routine returns”; just say what the routine does, not that it does it. Instead of + + -- This routine records the last outgoing call. + +write + + -- Record outgoing call. + +As illustrated by this example, header comments for commands (procedures) should be in the imperative or infinitive (the same in English), in the style of marching orders. They should end with a period. For boolean-valued queries, the comment should always be in the form of a question, terminated by a question mark: + +has (v: G): BOOLEAN is + -- Does v appear in list? + + +A convention governs the use of software entities — attributes, arguments — appearing in comments. In typeset texts such as the above they will appear in italics (more on font conventions below); in the source text they should always appear between an opening quote (“backquote”) and a closing quote; the original text for the example is then: + + + -- Does ‘v’ appear in list? + +Tools such as the short class abstracter will recognize this convention when generating typeset output. Note that the two quotes should be different: ‘v’, not ’v’. + +Be consistent. If a function of a class has the comment Length of string, a routine of the same class should not say Update width of string if it affects the same property. + +All these guidelines apply to routines. Because an exported attribute should be externally indistinguishable from argumentless functions — remember the Uniform Access principle — it should also have a comment, which will appear on the line following the attribute’s declaration, with the same indentation as for functions: + + +count: INTEGER + -- Number of students in course + +For secret attributes a comment is desirable too but the rule is less strict. + +===Feature clause header comments=== +As you will remember, a class may have any number of feature clauses: + +note + + + +class LINKED_LIST [G] + inherit + + + +creation + + + +feature -- Initialization + make + + + +feature -- Access + item: G + + + +feature -- Status report + before: BOOLEAN + + + +feature -- Status setting + + + +feature -- Element change + put_left (v: G) + + + +feature -- Removal + remove + + + +feature {NONE} -- Implementation + first_element: LINKABLE [G]. + + + +end -- class LINKED_LIST + +One of the purposes of having several feature clauses is to allow different features to have different export privileges; in this example everything is generally available except the secret features in the last clause. But another consequence of this convention is that you could, and should, group features by categories. A comment on the same line as the keyword feature should characterize the category. Such comments are, like header comments of routines, recognized an preserved by documentation tools such as short. + +Eighteen categories and the corresponding comments have been standardized for the Base libraries, so that every feature (out of about 2000 in all) belongs to one of them. The example above illustrates some of the most important categories. Status report corresponds to options (set by features in the Status setting category, not included in the example). Secret and selectively exported features appear in the Implementation category. These standard categories always appear in the same order, which the tools know (through a user-editable list) and will preserve or reinstate in their output. Within each category, the tools list the features alphabetically for ease of retrieval. + +The categories cover a wide range of application domains, although for special areas you may need to add your own categories. + +===Note clauses=== +Similar to header comments but slightly more formal are note clauses, appearing at the beginning of a class: + +note + description: "Sequential lists, in chained representation" + names: "Sequence", "List" + contents: GENERIC + representation: chained + date: "$Date: 96/10/20 12:21:03 $" + revision: "$Revision: 2.4$" + +class LINKED_LIST [G] + inherit + + +Note clauses proceed from the same Self-Documentation principle that has led to built-in assertions and header comments: include as much as possible of the documentation in the software itself. For properties that do not directly appear in the formal text, you may include note entries, all of the form + + +note_term: note_value, note_value, + +where the note_term is an identifier and each note_value is some basic element such as a string, an integer and so on. Entries can indicate alternative names under which potential client authors might search for the class (names), contents type (contents), implementation choices (representation), revision control information, author information, and anything else that may facilitate understanding the class and retrieving it through keyword-based search tools — tools that support reuse and enable software developers to find their way through a potentially rich set of reusable components. + +Both the note terms and the note values are free-form, but the possible choices should be standardized for each project. A set of standard choices has been used throughout the Base libraries; the above example illustrates six of the most common entry kinds. Every class must have a description entry, introducing as index_value a string describing the role of the class, always expressed in terms of the instances (as Sequential listsº, not “this class describes sequential lists”, or “sequential list”, or “the notion of sequential list” etc.). Most significant class texts in this book — but not short examples illustrating a specific point — include the description entry. + +===Non-header comments=== +The preceding rules on comments applied to standardized comments, appearing at specific places — feature declarations and beginning of feature clauses — and playing a special role for class documentation. + +As in all forms of software development, there is also a need for comments within routine bodies, to provide further explanations + +Another use of comments, although frequent in the practice of software development, does not figure much in software engineering and programming methodology textbooks. I am referring here to the technique of transforming some part of the code into comments, either because it does not work, or because it is not ready yet. This practice is clearly a substitute for better tools and techniques of configuration management. It has enriched the language with a new verb form, comment out, whose potential, surprisingly enough, has not yet been picked up by hip journalists, even though the non-technical applications seem attractive and indeed endless: “The last elections have enabled Congress to comment out the President”, “Letterman was commented out of the Academy Awards”, and so on. + +Every comment should be of a level of abstraction higher than the code it documents. A famous counter-example is -- Increase i by 1 commenting the instruction i := i + 1. Although not always that extreme, the practice of writing comments that paraphrase the code instead of summarizing its effect is still common. + +Low-level languages cry for ample commenting. It is a good rule of thumb, for example, that for each line of C there should be a comment line; not a negative reflection on C, but a consequence that in modern software development the role of C is to encapsulate machine-oriented and operating-system-level operations, which are tricky by nature and require a heavy explanatory apparatus. In the O-O part, non-header comments will appear much more sparsely; they remain useful when you need to explain some delicate operation or foresee possible confusion. In its constant effort to favor prevention over cure, the method decreases the need for comments through a modular style that yields small, understandable routines, and through its assertion mechanisms: preconditions and postconditions of routines, to express their semantics formally; class invariants; check instructions to express properties expected to hold at certain stages; the systematic naming conventions introduced earlier in this chapter. More generally, the secret of clear, understandable software is not adding comments after the fact but devising coherent and stable system structures right from the start. + +==TEXT LAYOUT AND PRESENTATION== +The next set of rules affects how we should physically write our software texts on paper — real, or simulated on a screen. More than any others, they prompt cries of “Cosmetics!”; but such cosmetics should be as important to software developers as Christian Dior’s are to his customers. They play no little role in determining how quickly and accurately your software will be understood by its readers — maintainers, reusers, customers. + +===Layout === +The recommended layout of texts results from the general form of the syntax of our notation, which is roughly what is known as an “operator grammar”, meaning that a class text is a sequence of symbols alternating between “operators” and “operands”. An operator is a fixed language symbol, such as a keyword (do etc.) or a separator (semicolon, comma º); an operand is a programmer-chosen symbol (identifier or constant). + +Based on this property, the textual layout of the notation follows the comb-like structure introduced by Ada; the idea is that a syntactically meaningful part of a class, such as an instruction or an expression, should either: + +Fit on a line together with a preceding and succeeding operators. + +Be indented just by itself on one or more lines — organized so as to observe the same rules recursively. + +Each branch of the comb is a sequence of alternating operators and operands; it should normally begin and end with an operator. In the space between two branches you find either a single operand or, recursively, a similar comb-like structure. + +As an example, depending on the size of its constituents a, b and c, you may spread out a conditional instruction as + +if c then a else b end + +or + +if + c +then + a +else + b +end + +or + +if c then + a +else b end + +You would not, however, use a line containing just if c or c end, since they include an operand together with something else, and are missing an ending operator in the first case and a starting operator in the second. + +Similarly, you may start a class, after the note clause, with + +class C inherit -- [1] + +or + +class C feature -- [2] + +or + +class -- [3] + C +feature + +but not + +class C -- [4] +feature + +because the first line would violate the rule. Forms [1] and [2] are used in this book for small illustrative classes; since most practical classes have one or more labeled feature clauses, they should in the absence of an inherit clause use form [3] (rather than [2]): + +class + C +feature -- Initialization + + + +feature -- Access + + etc. + +===Height and width=== +Like most modern languages, our notation does not attach any particular significance to line separations except to terminate comments, so that you can include two or more instructions (or two or more declarations) on a single line, separated by semicolons: + + +count := count + 1; forth + + +This style is for some reason not very popular (and many tools for estimating software size still measure lines rather than syntactical units); most developers seem to prefer having one instruction per line. It is indeed not desirable to pack texts very tightly; but in some cases a group of two or three short, closely related instructions can be more readable if they all appear on one line. + +In this area it is best to defer to your judgment and good taste. If you do apply intra-line grouping, make sure that it remains moderate, and consistent with the logical relations between instructions. The Semicolon Style principle seen later in this chapter requires any same-line instructions to be separated by a semicolon. + +For obvious reasons of space, this book makes a fair use of intra-line grouping, consistent with these guidelines. It also avoids splitting multi-line instructions into more lines than necessary; on this point one can recommend the book’s style for general use: there is really no reason to split from i:= 1 invariant i <= n until i = n loop or if a = b then. Whatever your personal taste, do observe the Comb structure. + +===Indenting details=== +The comb structure uses indentation, achieved through tab characters (not spaces, which are messy, error-prone, and not reader-parameterizable). + +Here are the indentation levels for the basic kinds of construct, illustrated by the example on the facing page: + +*Level 0: the keywords introducing the primitive clauses of a class. This includes note (beginning of a note clause), class (beginning of the class body), feature (beginning of a feature clause, except if on the same line as class), invariant (beginning of an invariant clause, not yet seen) and the final end of a class. +*Level 1: beginning of a feature declaration; note entries; invariant clauses. +*Level 2: the keywords starting the successive clauses of a routine. This includes require, local, do, once, ensure, rescue, end. +*Level 3: the header comment for a routine or (for consistency) attribute; declarations of local entities in a routine; first-level instructions of a routine. + +Within a routine body there may be further indentation due to the nesting of control structures. For example the earlier if a then º instruction contains two branches, each of them indented. These branches could themselves contain loops or conditional instructions, leading to further nesting (although the style of object-oriented software construction developed in this book leads to simple routines, seldom reaching high levels of nesting). + +A check instruction is indented, together with the justifying comment that normally follows it, one level to the right of the instruction that it guards. + +note + description: "Example for formating" +class EXAMPLE inherit + MY_PARENT + redefine f1, f2 end + MY_OTHER_PARENT + rename + g1 as old_g1, g2 as old_g2 + redefine + g1 + select + g2 + end +creation + make +feature -- Initialization + make + -- Do something. + require + some_condition: correct (x) + local + my_entity: MY_TYPE + do + if a then + b; c + else + other_routine + check max2 > max1 + x ^ 2 end + -- Because of the postcondition of other_routine. + new_value := old_value / (max2 – max1) + end + end +feature -- Access + my_attribute: SOME_TYPE + -- Explanation of its role (aligned with comment for make) + + ... Other feature declarations and feature clauses ... + +invariant + upper_bound: x <= y +end -- class EXAMPLE + +Note the trailer comment after the end of the class, a systematic convention. + +===Spaces=== +White space contributes as much to the effect produced by a software text as silence to the effect of a musical piece. + +The general rule, for simplicity and ease of remembering, is to follow as closely as possible the practice of standard written language. By default we will assume this language to be English, although it may be appropriate to adapt the conventions to the slightly different rules of other languages. + +Here are some of the consequences. You will use a space: + +Before an opening parenthesis, but not after: +f (x) (not f (x), the C style, or f ( x)). + +After a closing parenthesis unless the next character is a punctuation sign such as a period or semicolon; but not before. Hence: +proc1 (x); x := f1 (x) + f2 (y) + +After a comma but not before: \ +g (x, y, z). + +After the two dash signs that start a comment: -- A comment. + +Similarly, the default rule for semicolons is to use a space after but not before: + +p1; p2 (x); p3 (y, z) + + +Here, however, some people prefer, even for English-based software texts, the French style of including a space both before and after, which makes the semicolon stand out and emphasizes the symmetry between the components before and after it: + +p1 ; p2 (x) ; p3 (y, z) + + +Choose either style, but then use it consistently. (This book uses the English style.) English and French styles have the same difference for colons as for semicolons; since, however, the software notation only uses colons for declarations, in which the two parts — the entity being declared and its type — do not play a symmetric role, it seems preferable to stick to the English style, as in your_entity: YOUR_TYPE. + +Spaces should appear before and after arithmetic operators, as in a + b. (For space reasons, this book has omitted the spaces in a few cases, all of the form n+1.) + +For periods the notation departs from the conventions of ordinary written language since it uses periods for a special construct, as originally introduced by Simula. As you know, a l r means: apply feature r to the object attached to a. In this case there is a space neither before nor after the period. To avoid any confusion, this book makes the period bigger, as illustrated: l rather than just . + +There is another use of the period: as decimal point in real numbers, such as 3.14. Here, to avoid any confusion, the period is not made any bigger. + +Some European languages use a comma rather than a period as the separator between integral and fractional parts of numbers. Here the conflict is irreconcilable, as in English the comma serves to separate parts of big numbers, as in “300,000 dollars”, where other languages would use a space. The committee discussions for Algol 60 almost collapsed when some continental members refused to bow to the majority’s choice of the period; the stalemate was resolved when someone suggested distinguishing between a reference language, fixed, and representation languages, parameterizable. (In retrospect, not such a great idea, at least not if you ever have to compile the same program in two different countries!) Today, few people would make this a point of contention, as the spread of digital watches and calculators built for world markets have accustomed almost everyone to alternate between competing conventions. + +===Precedence and parentheses=== +The precedence conventions of the notation conform to tradition and to the “Principle of Least Surprise” to avoid errors and ambiguities. + +Do not hesitate, however, to add parentheses for clarity; for example you may write (a = (b + c)) implies (u /= v) even though the meaning of that expression would be the same if all parentheses were removed. The examples in this book have systematically over-parenthesized expressions, in particular assertions, risking heaviness to avert uncertainty. + +===The War of the Semicolons=== +Two clans inhabit the computing world, and the hatred between them is as ferocious as it is ancient. The Separatists, following Algol 60 and Pascal, fight for the recognition of the semicolon as a separator between instructions; the Terminatists, rallied behind the contrasting flags of PL/I, C and Ada, want to put a semicolon behind every instruction. + +Each side’s arguments are endlessly relayed by its propaganda machine. The Terminatists worship uniformity: if every instruction is terminated by the same marker, no one ever has to ask the question “do I need a semicolon here?” (the answer in Terminatist languages is always yes, and anyone who forgets a semicolon is immediately beheaded for high treason). They do not want to have to add or remove a semicolon because an instruction has been moved from one syntactical location to another, for example if it has been brought into a conditional instruction or taken out of it. + +The Separatists praise the elegance of their convention and its compatibility with mathematical practices. They see do instruction1; instruction2; instruction3 end as the natural counterpart of f (argument1, argument2, argument3). Who in his right mind, they ask, would prefer f (argument1, argument2, argument3,) with a superfluous final comma? They contend, furthermore, that the Terminatists are just a front for the Compilists, a cruel people whose only goal is to make life easy for compiler writers, even if that means making it hard for application developers. + +The Separatists constantly have to fight against innuendo, for example the contention that Separatist languages will prevent you from including extra semicolons. Again and again they must repeat the truth: that every Separatist language worthy of the name, beginning with the venerated Patriarch of the tribe, Algol 60, has supported the notion of empty instruction, permitting all of + +a; b; c +a; b; c; +; a ;; b ;;; c; + +to be equally valid, and to mean exactly the same thing, as they only differ by the extra empty instructions of the last two variants, which any decent compiler will discard anyway. They like to point out how much more tolerant this convention makes them: whereas their fanatical neighbors will use any missing semicolon as an excuse for renewed attacks, the Separatists will gladly accept as many extra semicolons as a Terminatist transfuge may still, out of habit, drop into an outwardly Separatist text. + +Modern propaganda needs science and statistics, so the Terminatists have their own experimental study, cited everywhere (in particular as the justification for the Terminatist convention of the Ada language): a 1975 measurement of the errors made by two groups of 25 programmers each, using languages that, among other distinguishing traits, treated semicolons differently. The results show the Separatist style causing almost ten times as many errors! Starting to feel the heat of incessant enemy broadcasts, the Separatist leadership turned for help to the author of the present book, who remembered a long-forgotten principle: quoting is good, but reading is better. So he fearlessly went back to the original article and discovered that the Separatist language used in the comparison — a mini-language meant only for “teaching students the concepts of asynchronous processes” — treats an extra semicolon after the final instruction of a compound, as in begin a; b; end, as an error! No real Separatist language, as noted above, has ever had such a rule, which would be absurd in any circumstance (as an extra semicolon is obviously harmless), and is even more so in the context of the article’s experiment since some of the subjects apparently had Terminatist experience from PL/I and so would have been naturally prone to add a few semicolons here and there. It then seems likely, although the article gives no data on this point, that many of the semicolon errors were a result of such normally harmless additions — enough to disqualify the experiment, once and for all, as a meaningful basis for defending Terminatism over Separatism. + +On some of the other issues it studies, the article is not marred by such flaws in its test languages, so that it still makes good reading for people interested in language design. + +All this shows, however, that it is dangerous to take sides in such a sensitive debate, especially for someone who takes pride in having friends in both camps. The solution adopted by the notation of this book is radical: + +====Semicolon Syntax rule==== +Semicolons, as markers to delimit instructions, declarations or assertion clauses, are optional in almost all the positions where they may appear in the notation of this book. + + +“Almost” because of a few rare cases, not encountered in this book, in which omitting the semicolon would cause a syntactical ambiguity. + +The Semicolon Syntax rule means you can choose your style: + +*Terminatist: every instruction, declaration or assertion clause ends with a semicolon. +*Separatist: semicolons appear between successive elements but not, for example, after the last declaration of a feature or local clause. +*Moderately Separatist: like the Separatist style, but not worrying about extra semicolons that may appear as a result of habit or of elements being moved from one context to another. +*Discardist: no semicolons at all (except as per the Semicolon Style principle below). + +This is one of the areas where it is preferable to let each user of the notation follow his own inclination, as the choice cannot cause serious damage. But do stick, at least across a class and preferably across an entire library or application, to the style that you have chosen (although this will not mean much for the Moderately Separatist style, which is by definition lax), and observe the following principle: + +====Semicolon Style principle==== +If you elect to include semicolons as terminators (Terminatist style), do so for all applicable elements. + +If you elect to forego semicolons, use them only when syntactically unavoidable, or to separate elements that appear on the same line. + + +The second clause governs elements that appear two or more to a line, as in + +found := found + 1; forth + + +which should always include the semicolon; omitting it would make the line quite confusing. + +Just for once, this discussion has no advice here, letting you decide which of the four styles you prefer. Since the earliest version of the notation required semicolons — in other words, it had not yet been tuned to support the Semicolon Syntax rule — the first edition of this book used a Separatist style. For the present one I dabbled into a few experiments; after polling a sizable group of co-workers and experienced users of the notation, I found (apart from a handful of Terminatists) an almost equal number of Discardists and Separatists. Some of the Discardists were very forceful, in particular a university professor who said that the main reason his students loved the notation is that they do not need semicolons — a comment which any future language designer, with or without grandiose plans, should find instructive or at least sobering. + +You should defer to your own taste as long as it is consistent and respects the Semicolon Style principle. (As to this book: for a while I stuck to the original Separatist style, more out of habit than of real commitment; then, hearing the approach of the third millenium and its call to start a new life free of antique superstitions, I removed all the semicolons over a single night of utter debauchery.) + +===Assertions=== +You should label assertion clauses to make the text more readable: + +require + not_too_small: index >= lower + + +This convention also helps produce useful information during testing and debugging since, as you will remember, the assertion label will be included in the run-time message produced if you have enabled monitoring of assertions and one of them gets violated. + +This convention will spread an assertion across as many lines as it has clauses. As a consequence, it is one of the rules to which the present book has made a few exceptions, again in the interest of saving space. When collapsing several clauses on one line, you should actually remove the labels for readability: + +require + index >= lower; index <= upper + +In normal circumstances, that is to say for software texts rather than a printed textbook, better stick to the official rule and have one labeled clause per line. + +==FONTS== +In typeset software texts, the following conventions, used throughout this book and related publications, are recommended. + +===Basic font rules=== + +Print software elements (class names, feature names, entitiesº) in italics to distinguish them from non-software text elements. This facilitates their inclusion in sentences of the non-software text, such as “We can see that the feature number is a query, not an attribute”. (The word number denotes the name of the feature; you do not want to mislead your reader into believing that you are talking about the number of features!) + +Keywords, such as class, feature, invariant and the like, appear in boldface. + +This was also the convention of the first edition of this book. At some stage it seemed preferable to use boldface italics which blends more nicely with italics. What was esthetically pleasing, however, turned out to hamper quality; some readers complained that the keywords did not stand out clearly enough, hence the return to the original convention. This is a regrettable case of fickleness. [M 1994a] and a handful of books by other authors show the intermediate convention. + +Keywords play a purely syntactic role: they have no semantics of their own but delimit those elements, such as feature and class names, that do carry a semantic value. As noted earlier in this chapter, there are also a few non-keyword reserved words, such as Current and Result, which have a denotation of their own — expressions or entities. They are written in non-bold italics, with an initial upper-case letter. + +Following the tradition of mathematics, symbols — colons and semicolons : ;, brackets [ ], parentheses ( ), braces { }, question and exclamation marks ? ! and so on — should always appear in roman (straight), even when they separate text in italics. Like keywords, they are purely syntactic elements. + +Comments appear in roman. This avoids any ambiguity when a feature name — which, according to the principles seen earlier, will normally be a word from ordinary language — or an argument name appears in a comment; the feature name will be in italics and hence will stand out. For example: + +accelerate (s: SPEED; t: REAL) + -- Bring speed to s in at most t seconds. + + +set_number (n: INTEGER) + -- Make n the new value of number. + + +In the software text itself, where no font variations are possible, such occurrences of formal elements in comments should follow a specific convention already mentioned earlier: they will appear preceded by a back quote ‘ and followed by a normal quote ’ , as in + + -- Make ‘n’ the new value of ‘number’. + +(Remember that you must use two different quote characters for opening and closing.) Tools that process class texts and can produce typeset output, such as short and flat, know this convention and so can make sure the quoted elements are printed in italics. + +===Other font conventions=== +The preceding font conventions work well for a book, an article or a Web page. Some contexts, however, may call for different approaches. In particular, elements in plain italics, and sometimes even bold italics, are not always readable when projected on a projection screen, especially if what you are projecting is the output of a laptop computer with a relatively small display. + +In such cases I have come to using the following conventions: + +Use non-italics boldface for everything, as this projects best. + +Choose a wide enough font, such as Bookman (for which boldface may be called “demibold”). + +Instead of italics versus roman versus bold, use color to distinguish the various elements: keywords in black; comments in red; the rest (entities, feature names, expressionsº) in blue. More colors can be used to highlight special elements. + +These conventions seem to work well, although there is always room for improvement, and new media will undoubtedly prompt new conventions. + +===Color=== +The particularly attentive reader may by now have come to notice another convention used by this book: for added clarity, all formal elements — software texts or text extracts, but also mathematical elements — appear in color. This technique, which of course cannot be presented as a general requirement, enhances the effect of the rules seen so far on font usage. + +==BIBLIOGRAPHICAL NOTES== +*[Waldén 1995] is the source of the idea of showing by example that even a longer separated_by_underscores identifier is easier to read than an internalUpperCase identifier. +*[Gannon 1975] is an experimental study of the effect of various language design choices on error rates. +*The rules on standard feature names were first presented in [M 1990b] and are developed in detail in [M 1994a]. +*I received important comments from Richard Wiener on students’ appreciation of the optionality of semicolons, and from Kim Waldén on the respective merits of bold italics and plain bold. + +==EXERCISES== +===Header comment style=== +Rewrite the following header comments in the proper style: + +reorder (s: SUPPLIER; t: TIME) + -- Reorders the current part from supplier s, to be delivered + -- on time t; this routine will only work if t is a time in the future. + require + not_in_past: t >= Now + + +next_reorder_date: TIME + -- Yields the next time at which the current part is scheduled + -- to be reordered. + + +===Semicolon ambiguity=== +Can you think of a case in which omitting a semicolon between two instructions or assertions could cause syntactic ambiguity, or at least confuse a simple-minded parser? (Hint: a feature call can have as its target a parenthesized expression, as in (vector1 + vector2) l count.) diff --git a/documentation/18.11/eiffel/Coding_Standards/index.wiki b/documentation/18.11/eiffel/Coding_Standards/index.wiki new file mode 100644 index 00000000..e9efed5a --- /dev/null +++ b/documentation/18.11/eiffel/Coding_Standards/index.wiki @@ -0,0 +1,4 @@ +[[Property:uuid|9396770A-E53B-4629-84A9-CB2A6680AAAD]] +[[Property:weight|5]] +[[Property:title|Coding Standards]] +Below are the coding and style guidelines followed at Eiffel Software to write the Eiffel and C code of EiffelStudio. \ No newline at end of file diff --git a/documentation/18.11/eiffel/Examples/example-command-line-arguments.wiki b/documentation/18.11/eiffel/Examples/example-command-line-arguments.wiki new file mode 100644 index 00000000..fdf0637c --- /dev/null +++ b/documentation/18.11/eiffel/Examples/example-command-line-arguments.wiki @@ -0,0 +1,68 @@ +[[Property:modification_date|Thu, 22 Nov 2018 19:50:45 GMT]] +[[Property:publication_date|Thu, 22 Nov 2018 19:50:45 GMT]] +[[Property:title|Example: Command line arguments]] +[[Property:weight|0]] +[[Property:uuid|ba852d83-3c02-4d38-088a-60b76fe5c63f]] +==Description== + +Retrieve the list of command-line arguments given to the program. +Example command line: + +myprogram -c "alpha beta" -h "gamma" + + +==Notes== + +This class inherits functionality for dealing with command line arguments from class ARGUMENTS. It uses the feature separate_character_option_value to return the values by option name for each of the two arguments. ARGUMENTS provides a rich set of features for command line argument processing. + +The simple version in [[#Solution|Solution]] below is as submitted to Rosetta Code to illustrate class ARGUMENTS, but it should be noted that separate_character_option_value is of a detached type and will return a void reference if no value is found for a specified character option. Therefore, a safer version of the use of separate_character_option_value would include object test on the result: + + + if attached separate_character_option_value ('c') as l_val then + print ("Command line argument value for option 'c' is: ") + print (l_val + "%N") + end + if attached separate_character_option_value ('h') as l_val then + print ("Command line argument value for option 'h' is: ") + print (l_val + "%N") + end + + +==Source== + +Problem description from [http://rosettacode.org/wiki/Command-line_arguments Rosetta Code] + +==Solution== + + +class + APPLICATION +inherit + ARGUMENTS +create + make +feature {NONE} -- Initialization + make + -- Print values for arguments with options 'c' and 'h'. + do + print ("Command line argument value for option 'c' is: ") + print (separate_character_option_value ('c') + "%N") + print ("Command line argument value for option 'h' is: ") + print (separate_character_option_value ('h') + "%N") + io.read_line -- Keep console window open + end +end + + + +==Output (for command line arguments: -c "alpha beta" -h "gamma")== + + +Command line argument value for option 'c' is: alpha beta +Command line argument value for option 'h' is: gamma + + + +{{SeeAlso|[[Execution_profiles|How to run with arguments]]}} + + diff --git a/documentation/18.11/eiffel/Examples/example-environment-variables.wiki b/documentation/18.11/eiffel/Examples/example-environment-variables.wiki new file mode 100644 index 00000000..2f214bfb --- /dev/null +++ b/documentation/18.11/eiffel/Examples/example-environment-variables.wiki @@ -0,0 +1,41 @@ +[[Property:title|Example: Environment variables]] +[[Property:weight|0]] +[[Property:uuid|60c39a34-0794-4c1f-a150-7431afa3e693]] +==Description== + +Using features from the class EXECUTION_ENVIRONMENT to create and retrieve an environment variable. + +==Notes== + +The make procedure of the class APPLICATION below uses the features put and get, inherited from the class EXECUTION_ENVIRONMENT, to create the environment variable MY_VARIABLE with value "Hello World!", and then to retrieve the value by key and print it. + +==Solution== + + +class + APPLICATION + +inherit + EXECUTION_ENVIRONMENT + +create + make + +feature {NONE} -- Initialization + make + -- Create and retrieve an environment variable. + do + put ("Hello World!", "MY_VARIABLE") + print (get ("MY_VARIABLE")) + end +end + + + +==Output== + + +Hello World! + + + diff --git a/documentation/18.11/eiffel/Examples/example-file-io.wiki b/documentation/18.11/eiffel/Examples/example-file-io.wiki new file mode 100644 index 00000000..abaafd16 --- /dev/null +++ b/documentation/18.11/eiffel/Examples/example-file-io.wiki @@ -0,0 +1,52 @@ +[[Property:title|Example: File IO]] +[[Property:weight|0]] +[[Property:uuid|b26aa8e3-5963-94ae-b523-642c8b79637b]] +==Description== + +Create a file "output.txt" containing the contents of "input.txt". + + +==Source== + +Problem description from [http://rosettacode.org/wiki/File_IO Rosetta Code: File IO] + +==Solution== + + +class + APPLICATION + +create + make + +feature {NONE} -- Initialization + + make + -- Run application. + do + create input_file.make_open_read ("input.txt") + create output_file.make_open_write ("output.txt") + + from + input_file.read_character + until + input_file.exhausted + loop + output_file.put (input_file.last_character) + input_file.read_character + end + + input_file.close + output_file.close + end + +feature -- Access + + input_file: PLAIN_TEXT_FILE + output_file: PLAIN_TEXT_FILE + +end + + + + diff --git a/documentation/18.11/eiffel/Examples/example-polymorphism.wiki b/documentation/18.11/eiffel/Examples/example-polymorphism.wiki new file mode 100644 index 00000000..3896a8a2 --- /dev/null +++ b/documentation/18.11/eiffel/Examples/example-polymorphism.wiki @@ -0,0 +1,218 @@ +[[Property:title|Example: Polymorphism]] +[[Property:weight|0]] +[[Property:uuid|e4a9db32-c087-21b7-f0d6-4685f0ce249d]] +==Description== + +Create a class POINT and its heir CIRCLE to demonstrate polymorphic attachment and dynamic binding. + + +==Source== + +Problem description from [http://rosettacode.org/wiki/Polymorphism Rosetta Code: Polymorphism] + +Solution varies from Rosetta Code description (e. g., feature out is redefined in this solution, versus feature print.) + +==Solution== + + +class + POINT +inherit + ANY + redefine + out + end +create + make, make_origin + +feature -- Initialization + + make (a_x, a_y: INTEGER) + -- Create with values `a_x' and `a_y' + do + set_x (a_x) + set_y (a_y) + ensure + x_set: x = a_x + y_set: y = a_y + end + + make_origin + -- Create at origin + do + ensure + x_set: x = 0 + y_set: y = 0 + end + +feature -- Access + + x: INTEGER assign set_x + -- Horizontal axis coordinate + + y: INTEGER assign set_y + -- Vertical axis coordinate + +feature -- Element change + + set_x (a_x: INTEGER) + -- Set `x' coordinate to `a_x' + do + x := a_x + ensure + x_set: x = a_x + end + + set_y (a_y: INTEGER) + -- Set `y' coordinate to `a_y' + do + y := a_y + ensure + y_set: y = a_y + end + +feature -- Output + + out: STRING + -- Display as string + do + Result := "Point: x = " + x.out + " y = " + y.out + end +end + + + + +class + CIRCLE + +inherit + POINT + rename + make as point_make + redefine + make_origin, + out + end +create + make, make_origin, make_from_point + +feature -- Initialization + + make (a_x, a_y, a_r: INTEGER) + -- Create with values `a_x' and `a_y' and `a_r' + require + non_negative_radius_argument: a_r >= 0 + do + point_make (a_x, a_y) + set_r (a_r) + ensure + x_set: x = a_x + y_set: y = a_y + r_set: r = a_r + end + + make_origin + -- Create at origin with zero radius + do + Precursor + ensure then + r_set: r = 0 + end + + make_from_point (a_p: POINT; a_r: INTEGER) + -- Initialize from `a_r' with radius `a_r'. + require + non_negative_radius_argument: a_r >= 0 + do + set_x (a_p.x) + set_y (a_p.y) + set_r (a_r) + ensure + x_set: x = a_p.x + y_set: y = a_p.y + r_set: r = a_r + end + +feature -- Access + + r: INTEGER assign set_r + -- Radius + +feature -- Element change + + set_r (a_r: INTEGER) + -- Set radius (`r') to `a_r' + require + non_negative_radius_argument: a_r >= 0 + do + r := a_r + ensure + r_set: r = a_r + end + +feature -- Output + + out: STRING + -- Display as string + do + Result := "Circle: x = " + x.out + " y = " + y.out + " r = " + r.out + end + +invariant + + non_negative_radius: r >= 0 + +end + + + + +class + APPLICATION + +create + make + +feature {NONE} -- Initialization + + make + -- Run application. + local + my_point: POINT + my_circle: CIRCLE + do + create my_point.make_origin + print (my_point.out + "%N") + + create {CIRCLE} my_point.make_origin + print (my_point.out + "%N") + + create my_point.make (10, 15) + print (my_point.out + "%N") + + create {CIRCLE} my_point.make (20, 25, 5) + print (my_point.out + "%N") + + create my_circle.make (30, 35, 10) + print (my_circle.out + "%N") + + create my_circle.make_from_point (my_point, 35) + print (my_circle.out + "%N") + end + +end + + + +==Output== + + +Point: x = 0 y = 0 +Circle: x = 0 y = 0 r = 0 +Point: x = 10 y = 15 +Circle: x = 20 y = 25 r = 5 +Circle: x = 30 y = 35 r = 10 +Circle: x = 20 y = 25 r = 35 + + diff --git a/documentation/18.11/eiffel/Examples/example-reverse-string.wiki b/documentation/18.11/eiffel/Examples/example-reverse-string.wiki new file mode 100644 index 00000000..cd29c929 --- /dev/null +++ b/documentation/18.11/eiffel/Examples/example-reverse-string.wiki @@ -0,0 +1,41 @@ +[[Property:title|Example: Reverse a string]] +[[Property:weight|0]] +[[Property:uuid|d888d308-6bb7-edd5-ee25-92d04b5658d3]] +==Description== + +Reverse the order of the characters in a give string of characters. + + +==Source== + +Problem description from [http://rosettacode.org/wiki/Reverse_a_string Rosetta Code] + + +==Solution== + + +class + APPLICATION +create + make +feature + make + -- Demonstrate string reversal. + do + my_string := "Hello World!" + my_string.mirror + print (my_string) + end + my_string: STRING + -- Used for reversal +end + + + +==Output== + + +!dlroW olleH + + + diff --git a/documentation/18.11/eiffel/Examples/example-self-initializing-attributes-and-assigner-commands.wiki b/documentation/18.11/eiffel/Examples/example-self-initializing-attributes-and-assigner-commands.wiki new file mode 100644 index 00000000..38f0a2ab --- /dev/null +++ b/documentation/18.11/eiffel/Examples/example-self-initializing-attributes-and-assigner-commands.wiki @@ -0,0 +1,84 @@ +[[Property:title|Example: Self-initializing attributes and assigner commands]] +[[Property:weight|0]] +[[Property:uuid|dbc107a4-42cd-606a-71b2-e0b70ac5482e]] +==Description== + +Example of using a [[Void-safety: Background, definition, and tools#Self-initializing attributes|self-initializing attribute]] and an [[ET: The Dynamic Structure: Execution Model#Assigner commands|assigner command]]. + +==Notes== + +The concepts of [[Void-safety: Background, definition, and tools#Self-initializing attributes|self-initializing attributes]] and [[ET: The Dynamic Structure: Execution Model#Assigner commands|assigner commands]] are independent of one another. However, this example shows how each works in a small amount of code. + +The example consists of two classes: a root class, and class PERSON. The PERSON class has a self-initializing attribute of type STRING named mood. If mood is accessed before it is explicitly initialized, then the self-initializing code after the keyword attribute will be executed, setting the default mood to "Happy". + +The attribute mood also has an assigner command, the procedure set_mood, designated as such by the assign keyword. This allows clients of class PERSON to appear to assign directly to mood. However, the assigner command set_mood will always get executed, and its precondition will be in force during such an apparent assignment. + +The root class APPLICATION creates an instance of PERSON and prints the value of mood, getting the self-iniitalized value. Then it assigns to mood. When it prints again, it gets the updated value. + +==Source== + +Adapted from an example given on the Eiffel Software Users Group. + +==Solution== + +A root class: + + +class + APPLICATION + +create + make + +feature {NONE} -- Initialization + + make + -- Print and set mood of `my_person'. + do + create my_person + print ("Mood: " + my_person.mood + "%N") + my_person.mood := "Ecstatic" + print ("Mood: " + my_person.mood + "%N") + end + +feature -- Access + + my_person: PERSON + +end + + + +Class PERSON: + + +class + PERSON + +feature -- Access + + mood: STRING assign set_mood + attribute + Result := "Happy" + end + +feature -- Element change + + set_mood (a_string: STRING) + require + single_token: a_string.occurrences (' ') = 0 + do + mood := a_string + ensure + mood_set: mood = a_string + end +end + + +==Output== + + +Mood: Happy +Mood: Ecstatic + + diff --git a/documentation/18.11/eiffel/Examples/example-sieve-eratosthenes.wiki b/documentation/18.11/eiffel/Examples/example-sieve-eratosthenes.wiki new file mode 100644 index 00000000..f5b891f5 --- /dev/null +++ b/documentation/18.11/eiffel/Examples/example-sieve-eratosthenes.wiki @@ -0,0 +1,64 @@ +[[Property:title|Example: Sieve of Eratosthenes]] +[[Property:weight|0]] +[[Property:uuid|e825c874-4266-b5ee-501c-221e6940dacd]] +==Description== + +Deliver prime numbers up to a specified integer limit. Compute prime numbers using sieve of Eratosthenes. + +==Notes== + +This example uses the ''iteration'' (across) form of the Eiffel loop construct to traverse a list, an array, and an integer interval. + +==Source== + +Problem description from [http://rosettacode.org/wiki/Sieve_of_Eratosthenes Rosetta Code] + + +==Solution== + + +class + APPLICATION + +create + make + +feature + make + -- Run application. + do + across primes_through (100) as ic loop print (ic.item.out + " ") end + end + + primes_through (a_limit: INTEGER): LINKED_LIST [INTEGER] + -- Prime numbers through `a_limit' + require + valid_upper_limit: a_limit >= 2 + local + l_tab: ARRAY [BOOLEAN] + do + create Result.make + create l_tab.make_filled (True, 2, a_limit) + across + l_tab as ic + loop + if ic.item then + Result.extend (ic.target_index) + across ((ic.target_index * ic.target_index) |..| l_tab.upper).new_cursor.with_step (ic.target_index) as id + loop + l_tab [id.item] := False + end + end + end + end +end + + + +==Output== + + +2 3 5 7 11 13 17 19 23 29 31 37 41 43 47 53 59 61 67 71 73 79 83 89 97 + + + diff --git a/documentation/18.11/eiffel/Examples/example-sleep.wiki b/documentation/18.11/eiffel/Examples/example-sleep.wiki new file mode 100644 index 00000000..c3003c3b --- /dev/null +++ b/documentation/18.11/eiffel/Examples/example-sleep.wiki @@ -0,0 +1,54 @@ +[[Property:title|Example: Sleep]] +[[Property:weight|0]] +[[Property:uuid|a846db1c-2096-43a9-bb8b-a233c9e21421]] +==Description== + +Write a program that does the following in this order: +# Input an amount of time to sleep in whatever units are most natural for your language (milliseconds, seconds, ticks, etc.). This unit should be noted in comments or in a description. +# Print "Sleeping..." +# Sleep the main thread for the given amount of time. +# Print "Awake!" +# End. + +==Notes== + +The feature sleep is defined in the library class EXECUTION_ENVIRONMENT. So the demonstration class APPLICATION inherits from EXECUTION_ENVIRONMENT in order to make sleep available. + +sleep takes an argument which declares the number of nanoseconds to suspend the thread's execution. + +==Source== + +Problem description from [http://rosettacode.org/wiki/Sleep Rosetta Code] + +==Solution== + + +class + APPLICATION +inherit + EXECUTION_ENVIRONMENT +create + make +feature -- Initialization + make + -- Sleep for a given number of nanoseconds. + do + print ("Enter a number of nanoseconds: ") + io.read_integer_64 + print ("Sleeping...%N") + sleep (io.last_integer_64) + print ("Awake!%N") + end +end + + + +==Output (sleeping 10 seconds)== + + +Enter a number of nanoseconds: 10000000000 +Sleeping... +Awake! + + + diff --git a/documentation/18.11/eiffel/Examples/index.wiki b/documentation/18.11/eiffel/Examples/index.wiki new file mode 100644 index 00000000..35c8fbb5 --- /dev/null +++ b/documentation/18.11/eiffel/Examples/index.wiki @@ -0,0 +1,10 @@ +[[Property:title|Examples]] +[[Property:description|how common programming problems can be solved using Eiffel]] +[[Property:weight|6]] +[[Property:uuid|1a59e03b-8bf0-8426-43b4-577761e40790]] +Here you will find examples of how common programming problems can be solved using Eiffel. + +A set of examples is also included with the EiffelStudio distribution kit. + + + diff --git a/documentation/18.11/eiffel/Examples/introduction-examples-book.wiki b/documentation/18.11/eiffel/Examples/introduction-examples-book.wiki new file mode 100644 index 00000000..755605a5 --- /dev/null +++ b/documentation/18.11/eiffel/Examples/introduction-examples-book.wiki @@ -0,0 +1,26 @@ +[[Property:modification_date|Mon, 10 Sep 2018 09:10:34 GMT]] +[[Property:publication_date|Mon, 10 Sep 2018 09:10:34 GMT]] +[[Property:title|Introduction to the Examples Book]] +[[Property:weight|-1]] +[[Property:uuid|044fa742-f3ca-9f5b-01cc-7194ee172b08]] + +EiffelStudio comes with a rich set of examples that you can use to learn how to use the many Eiffel facilities and libraries. You should look first to the examples distributed with EiffelStudio as your primary source of samples of Eiffel in use. + +The examples in this book are somewhat different in nature and serve a different purpose. + +Although some of the examples included here are provided by Eiffel Software, the intent is that the majority of the entries will be contributed by people like you who use Eiffel daily to solve real problems. + +The inspiration for this book is the many ''program chrestomathies'' on the World-Wide Web. In natural language, a chrestomathy is a set of literary passages explicitly selected for the purpose of helping learn a language. A program chrestomathy is a set of problems for which solutions are represented in various programming languages with the aim of allowing programmers to compare language capabilities and programming techniques. + +Program chrestomathies vary widely. At one end of the spectrum [http://99-bottles-of-beer.net/ 99 Bottles of Beer] has collected solutions in over one thousand programming languages, all targeted to a single problem: generate and print the complete lyrics of the song ''99 Bottles of Beer on the Wall''. There are several "Hello world!" chrestomathies. Other sites host multiple programming problems, all with solutions in many languages. One large multi-problem site is [http://rosettacode.org/wiki/Main_Page Rosetta Code]. In fact, Rosetta Code maintains a [http://rosettacode.org/wiki/Help:Similar_Sites list of links to many of the Web's other programming chrestomathy projects]. + +Eiffel has a presence on many of these sites. Still, the more examples, the better. + +The purpose of the examples in this book, then, is two-fold. First, we get a set of Eiffel examples in the Eiffel online documentation with solutions to a different set of problems than the examples distributed with EiffelStudio. Second, examples from this set can be migrated to Rosetta Code or one of the other chrestomathies to improve Eiffel's presence on those sites. (The caveat to contributors is clear: '''Contribute only work that you have the authority to release, and only if you are willing to have your work shared on one or more of the program chrestomathies.''' By submitting content to this Examples book, you agree to release that content under terms no more restrictive than the GNU Free Documentation License.) + +Sites like Rosetta Code and [http://en.literateprograms.org/LiteratePrograms:Welcome Literate Programs] offer a wide variety of programming problems or tasks for comparison of languages and techniques. Rosetta Code provides an index to the [http://rosettacode.org/wiki/Reports:Tasks_not_implemented_in_Eiffel tasks not yet implemented in Eiffel]. + +This book should include, but not necessarily be limited to, certain of the problems used as challenges by program chrestomathies. + + + diff --git a/documentation/18.11/eiffel/Language_reference/index.wiki b/documentation/18.11/eiffel/Language_reference/index.wiki new file mode 100644 index 00000000..a0aabc78 --- /dev/null +++ b/documentation/18.11/eiffel/Language_reference/index.wiki @@ -0,0 +1,6 @@ +[[Property:title|Language reference]] +[[Property:link_title|Language]] +[[Property:weight|3]] +[[Property:uuid|17412f30-0451-4b2b-bdec-578ca2e619a6]] + + diff --git a/documentation/18.11/eiffel/Language_reference/quick-reference-eiffel-programming-language/Expressions/Conditional-expression.wiki b/documentation/18.11/eiffel/Language_reference/quick-reference-eiffel-programming-language/Expressions/Conditional-expression.wiki new file mode 100644 index 00000000..a096da5e --- /dev/null +++ b/documentation/18.11/eiffel/Language_reference/quick-reference-eiffel-programming-language/Expressions/Conditional-expression.wiki @@ -0,0 +1,30 @@ +[[Property:uuid|C652AC71-8BAD-4387-A46C-21C9F5C3A68F]] +[[Property:weight|0]] +[[Property:title|Conditional expression]] +[[Property:link_title|Conditional]] + +[[Eiffel%20Programming%20Language%20Syntax#Conditionals|Conditional expressions]] compute a value using different expressions depending on one or more conditions. If all expressions have the same type, the conditional expression as a whole has this type as well: + + + if time < noon then + "Good morning" + elseif time < evening then + "Good afternoon" + else + "Good evening" + end + + +has type `STRING`. + +If the types of the expressions are different, the [[Types#Common ancestor types|common ancestor type]] is used as a type of the whole expression. + + + if time < noon then + "Good morning" + else + Void + end + + +has type `detachable STRING`. \ No newline at end of file diff --git a/documentation/18.11/eiffel/Language_reference/quick-reference-eiffel-programming-language/Expressions/Manifest-array.wiki b/documentation/18.11/eiffel/Language_reference/quick-reference-eiffel-programming-language/Expressions/Manifest-array.wiki new file mode 100644 index 00000000..1d652ce3 --- /dev/null +++ b/documentation/18.11/eiffel/Language_reference/quick-reference-eiffel-programming-language/Expressions/Manifest-array.wiki @@ -0,0 +1,85 @@ +[[Property:uuid|3C1A6DEF-A6F1-4E64-A0BE-C07BDB382C93]] +[[Property:weight|0]] +[[Property:title|Manifest array]] + +A manifest array is an expression denoting an array by simply listing its elements, as in `<<1, 4, 9, 16, 25>>`. The lower index is always `1` and the upper index is the number of items, `5` in this example. + +The type of a manifest array is always `ARRAY [T]` where `T` is a type to which all the elements conform, `INTEGER` in the previous example. In case of a possible ambiguity you can make the type explicit, as in `{ARRAY [COMPARABLE]} <<7, "Eiffel">>`, where both `INTEGER`, the type of `7`, and `STRING`, the type of `"Eiffel"`, conform to `COMPARABLE`. + +== What are manifest arrays good for? == + +Use a manifest array to initialize an element by simply listing its initial elements. For example, with the declaration + +```eiffel +squares: ARRAY [INTEGER] +``` + +you can initialize `squares` through + +```eiffel +squares := <<1, 4, 9, 16, 25>> +``` + +This is simpler than the alternative, which would be to create the array explicitly and give a value to every element in turn: +```eiffel + -- Arguments to `make_filled` are: default value, lower bound, upper bound. +create squares.make_filled (0, 1, 5) +squares [1] := 1 +squares [2] := 4 +squares [3] := 9 +squares [4] := 16 +squares [5] := 25 +``` + +The first form, with the manifest array, is shorter, but the effect is the same. + +Manifest arrays are normal arrays, not restricted in any way. You can for example add elements to them, as in + +```eiffel + -- Arguments to `force` are: value, position. +squares.force (36, 6) +``` + +which will resize the array to bounds 1 and 6. + +== Type of a manifest array: the implicit case == + +If you do not explicitly specify an array type, the type of the manifest array is as follows: + +* For an empty manifest array `<<>>`: `ARRAY [NONE]`. (In the following cases we assume the array is not empty.) + +* If all elements are of the same exact type `T`: `ARRAY [T]`. + +* If the types of all elements all conform to a type `T`: `ARRAY [T]`. Note that in this case `T` is unique since two different types cannot conform to each other. (The preceding case, all types identical, is a special case of this one, since a type conforms to itself.) + +* Otherwise: `ARRAY [ANY]`. + +As an example of the third case (conformance of all elements to one of them), assume `POLYGON` and `CIRCLE` both conform to `FIGURE`. Then the manifest array `<>`, with `a_polygon` of type `POLYGON` and so on, is `ARRAY [FIGURE]`. + +== Type of a manifest array: the explicit case == + +With the preceding rule, the type of `<<7, "Eiffel">>` is the most general possible one, `ARRAY [ANY]`, since `INTEGER` and `STRING` do not conform to each other (either way). If you are not happy with this default type, you can make the array type explicit by writing it in braces: + +```eiffel +{ARRAY [COMPARABLE]} <<7, "Eiffel">> +``` + +The rule in such a case is that in `{ARRAY [T]} <>` the types of all elements must conform to `T`. + +As another example, with + +```eiffel +figures: ARRAY [FIGURE] +``` + +you cannot assign `<>` to `figures` since the type of the manifest array is `ARRAY [ANY]`. To make this assignment possible, use an explicit type: + +```eiffel +figures := {ARRAY [FIGURE]} <> +``` + +You can also use this form to give an explicit type to an empty array, which would otherwise be of type `ARRAY [NONE]`. For example, with `figures` declared as above: + +```eiffel +figures := {ARRAY [FIGURE]} <<>> +``` diff --git a/documentation/18.11/eiffel/Language_reference/quick-reference-eiffel-programming-language/Expressions/index.wiki b/documentation/18.11/eiffel/Language_reference/quick-reference-eiffel-programming-language/Expressions/index.wiki new file mode 100644 index 00000000..be9b0720 --- /dev/null +++ b/documentation/18.11/eiffel/Language_reference/quick-reference-eiffel-programming-language/Expressions/index.wiki @@ -0,0 +1,5 @@ +[[Property:uuid|F904B70B-4C34-459B-A146-E10C7EC30136]] +[[Property:weight|0]] +[[Property:title|Expressions]] + +[[Eiffel%20programming%20language%20syntax#Expressions|Expressions]] are used to compute a value at run-time and have an associated type at compile-time. \ No newline at end of file diff --git a/documentation/18.11/eiffel/Language_reference/quick-reference-eiffel-programming-language/Types.wiki b/documentation/18.11/eiffel/Language_reference/quick-reference-eiffel-programming-language/Types.wiki new file mode 100644 index 00000000..55b45e17 --- /dev/null +++ b/documentation/18.11/eiffel/Language_reference/quick-reference-eiffel-programming-language/Types.wiki @@ -0,0 +1,44 @@ +[[Property:uuid|88764AFC-7DC5-4547-8B8C-4C0A489B0620]] +[[Property:weight|0]] +[[Property:title|Types]] + +== Common ancestor type == + +A '''common ancestor type''' is a type computed for a list of types using the following algorithm: + +# Add `NONE` to the list of types (to make sure the list is never empty). +# If there is a separate type in the list, add a mark `separate` in front of all non-separate types in the list. +# If there is a detachable type in the list, add a mark `detachable` in front of all attached types in the list. +# If there is a type in the list to which all other types conform, it is the common ancestor type. +# Otherwise, add `ANY` to the list and repeat steps starting from step #2. + + +Here are some examples: +{| +! Type list +! Common ancestor type +|- +| (empty) +| NONE +|- +| BOOLEAN +| BOOLEAN +|- +| BOOLEAN, BOOLEAN +| BOOLEAN +|- +| INTEGER_32, REAL_64, COMPARABLE +| COMPARABLE +|- +| INTEGER_32, REAL_64 +| ANY +|- +| INTEGER_32, detachable COMPARABLE +| detachable COMPARABLE +|- +| INTEGER_32, separate COMPARABLE +| separate COMPARABLE +|- +| detachable STRING, separate COMPARABLE +| detachable separate COMPARABLE +|} \ No newline at end of file diff --git a/documentation/18.11/eiffel/Language_reference/quick-reference-eiffel-programming-language/eiffel-programming-language-reserved-words.wiki b/documentation/18.11/eiffel/Language_reference/quick-reference-eiffel-programming-language/eiffel-programming-language-reserved-words.wiki new file mode 100644 index 00000000..44d0df03 --- /dev/null +++ b/documentation/18.11/eiffel/Language_reference/quick-reference-eiffel-programming-language/eiffel-programming-language-reserved-words.wiki @@ -0,0 +1,508 @@ +[[Property:title|Eiffel programming language reserved words]] +[[Property:link_title|Reserved words]] +[[Property:weight|1]] +[[Property:uuid|047ce062-45de-f25c-f356-ee8ec0fc2d1d]] +In the Eiffel programming language, there are certain words that are considered "reserved". These words have specific meanings recognized by the compiler. As such, it is invalid to attempt to use a reserved word as an ordinary language identifier. + +The reserved words listed in the ISO/ECMA standard are shown below with a brief explanation of their meanings. Links are given where appropriate to the syntax definitions and to descriptions in the online documentation. Occasionally, references to the June 2006 standard document are used and are recognizable as clause numbers in parentheses, i.e., three integers separated by dots, for example: (8.14.1) + + +{{info|The list below includes all the Eiffel reserved words. Some of these words are considered ''language keywords'' while others are not. The distinction is that language keywords are reserved words that are used only as syntactical markers, and have no inherent semantic value. Examples are the keywords do and end. Non-keyword reserved words are those that do carry semantic value, such as True and Current.}} + + +{{note|The set of reserved words supported by the Eiffel Software implementation may vary somewhat from those specified in the current standard. See the [[Differences between standard ECMA-367 and Eiffel Software implementation|"differences" chapter of the online documentation]] for information on these variances.}} + + +==Reserved words== + +===across=== + +Introduces an [[ET: Instructions#Loop|iteration]]. + +===agent=== + +Used to specify an [[ET: Agents|agent]]. + +:[[Eiffel programming language syntax#Agents|Syntax.]] + + +===alias=== + +Used to identify an alternative or alias feature name. + +:[[Eiffel programming language syntax#Feature names|Syntax.]] + +[[ET: The Dynamic Structure: Execution Model#Infix and prefix notations|Usage for infix/prefix notations.]] + +[[ET: The Static Picture: System Organization#External software|Usage in interfaces to external software.]] + +:[[Eiffel programming language syntax#External routines|Syntax.]] + + +===all=== + +Used in [[ET: Inheritance#Changing the export status|export adaptation]] to indicate that a chosen export status applies to all features inherited from a given parent. + +:[[Eiffel programming language syntax#Export adaptation|Syntax.]] + + +===and=== + +The logical conjunction [[Eiffel programming language syntax#Operators|operator]]. Strict when used alone, nonstrict when used with [[#then|then]]. + + +===as=== + +Used when [[ET: Inheritance#Multiple inheritance and renaming|renaming]] features in descendant classes. + +:[[Eiffel programming language syntax#Rename clauses|Syntax.]] + + +===assign=== + +Used to designate [[ET: The Dynamic Structure: Execution Model#Abstraction|assigner commands]]. + +:[[Eiffel programming language syntax#Assigner marks|Syntax.]] + + +===attribute=== + +Introduces an attribute body, as in [[Void-safety: Background, definition, and tools#Self-initializing attributes|self-initializing attributes]]. + +:[[Eiffel programming language syntax#Attribute bodies|Syntax.]] + + +===check=== + +Identifies a [[ET: Other Mechanisms#Check|check instruction]]. + +:[[Eiffel programming language syntax#Check instructions|Syntax.]] + + +===class=== + +Used in a class header in the declaration of a [[ET: The Dynamic Structure: Execution Model#A simple class|class]]. + +:[[Eiffel programming language syntax#Class headers|Class header syntax.]] + + +===convert=== + +Used in converter clauses. + +:[[Eiffel programming language syntax#Converter clauses|Syntax.]] + +Used in feature names for operator aliases, supporting mixed type expressions causing a conversion of the target (8.5.14). + +:[[Eiffel programming language syntax#Feature names|Syntax.]] + + +===create=== + +In the creators part of a class, introduces those procedures which can be used to [[ET: The Dynamic Structure: Execution Model#Creating and initializing objects|initialize instances]]. + +:[[Eiffel programming language syntax#Creators parts|Syntax.]] + +Introduces a [[ET: The Dynamic Structure: Execution Model#Creating and initializing objects|creation instruction]]. + +:[[Eiffel programming language syntax#Creation instructions|Syntax.]] + +Introduces a creation expression (8.20.18) + +:[[Eiffel programming language syntax#Creation expressions|Syntax.]] + +In [[ET: Inheritance#Constrained genericity|constrained genericity]], introduces a list of names of features which can be used as creation procedures with a generic class for a particular formal generic parameter. (8.12.10) + +:[[Eiffel programming language syntax#Generic constraints|Syntax.]] + + +===Current=== + +A predefined entity indicating the current object. + +:[[Eiffel programming language syntax#Entities and variables|Entity syntax.]] + +:[[Eiffel programming language syntax#Types|Anchored types syntax.]] + + +===debug=== + +Introduces a [[ET: Other Mechanisms#Debug|debug instruction]]. + +:[[Eiffel programming language syntax#Debug Instructions|Syntax.]] + + +===deferred=== + +Used in class header to indicate a [[ET: Inheritance#Deferred features and classes|deferred class]]. + +:[[Eiffel programming language syntax#Class headers|Syntax.]] + +Used in routine body to indicate a [[ET: Inheritance#Deferred features and classes|deferred feature]]. + +:[[Eiffel programming language syntax#Routine bodies|Syntax.]] + + +===do=== + +Introduces a sequence of instructions as a routine body, as shown in the [[ET: Hello World|Hello World]] example. + +:[[Eiffel programming language syntax#Routine bodies|Syntax.]] + + +===else=== + +Used in [[ET: Other Mechanisms#Conditional|conditional]] and [[ET: Other Mechanisms#Multi-branch|multi-branch]] instructions to introduce a sequence of instructions to be executed in the case that no specified conditions are met. + +:[[Eiffel programming language syntax#Conditionals|Conditional syntax.]] + +:[[Eiffel programming language syntax#Multi-branch instructions|Multi-branch syntax.]] + +Used as part of the double reserved word or else, the semi-strict disjunction operator. + +:[[Eiffel programming language syntax#Operators|Syntax.]] + +Used after the reserved word [[#require|require]] as a precondition extension, allowing the weakening of an inherited precondition (8.10.3). + +:[[Eiffel programming language syntax#Assertions|Syntax.]] + + +===elseif=== + +Used in [[ET: Other Mechanisms#Conditional|conditional]] instructions to effect a "multi-branch" choice instruction. + +:[[Eiffel programming language syntax#Conditionals|Syntax.]] + + +===end=== + +Serves to terminate several Eiffel programming language constructs. + +:Syntax for: +::[[Eiffel programming language syntax#Class declarations|Class declarations]] +::[[Eiffel programming language syntax#Feature bodies|Feature bodies]] +::[[Eiffel programming language syntax#Inheritance parts|Inheritance parts]] +::[[Eiffel programming language syntax#Check instructions|Check instructions]] +::[[Eiffel programming language syntax#Generic constraints|Generic constraints: renaming and constraint creators]] +::[[Eiffel programming language syntax#Conditionals|Conditional instructions]] +::[[Eiffel programming language syntax#Multi-branch instructions|Multi-branch instructions]] +::[[Eiffel programming language syntax#Loops|Loops]] +::[[Eiffel programming language syntax#Debug instructions|Debug instructions]] + + +===ensure=== + +Introduces a [[ET: Design by Contract (tm), Assertions and Exceptions#Expressing assertions|postcondition]]. + +When followed by the reserved word [[#then|then]] denotes a postcondition extension, allowing the strengthening of an inherited postcondition (8.10.3). + +:[[Eiffel programming language syntax#Assertions|Syntax.]] + + +===expanded=== + +Used in a class header to indicate that a class is [[ET: The Dynamic Structure: Execution Model#Type categories|expanded]]. + +:[[Eiffel programming language syntax#Class headers|Syntax.]] + + +===export=== + +Used to [[ET: Inheritance#Changing the export status|change the export status]] (availability to clients) of inherited features. + +:[[Eiffel programming language syntax#Export adaptation|Syntax.]] + + +===external=== + +Denotes an [[ET: The Static Picture: System Organization#External software|external routine]]. External routines are commonly defined to interface with [[C externals|C external routines]] and [[C++ Externals|C++ external routines]]. + +:[[Eiffel programming language syntax#External routines|Syntax]] + + +===False=== + +Boolean manifest constant. + +:[[Eiffel programming language syntax#Manifest constants|Syntax.]] + + +===feature=== + +Introduces a [[ET: Hello World|feature clause]]. + +:[[Eiffel programming language syntax#Feature parts|Syntax.]] + + +===from=== + +Used in [[ET: Other Mechanisms#Loop|loop]] initialization. + +:[[Eiffel programming language syntax#Loops|Syntax.]] + + +===frozen=== + +Used in a class header to mark a class explicitly as frozen. A frozen class prohibits it from serving as a "conforming parent" to other classes. (8.4.5). + +:[[Eiffel programming language syntax#Class headers|Syntax.]] + +Used in a feature declaration to mark a feature as frozen. A frozen feature cannot be redefined by heir classes. + +:[[Eiffel programming language syntax#New feature lists|Syntax.]] + +Used with a formal generic parameter to indicate that conformance of generic derivations of the class require identical actual generic parameters. (8.12.3) + +:[[Eiffel programming language syntax#Formal generic parameters|Syntax.]] + + +===if=== + +Introduces a [[ET: Other Mechanisms#Conditional|conditional]]. + +:[[Eiffel programming language syntax#Conditionals|Syntax.]] + + +===implies=== + +The semi-strict logical implication [[Eiffel programming language syntax#Operators|operator]]. + + +===inherit=== + +Used in an [[ET: Inheritance|inherit]] clause. + +:[[Eiffel programming language syntax#Inheritance parts|Syntax.]] + + +===inspect=== + +Introduces a [[ET: Other Mechanisms#Multi-branch|multi-branch]] instruction. + +:[[Eiffel programming language syntax#Multi-branch instructions|Syntax.]] + + +===invariant=== + +Used to introduce an invariant assertion as a [[ET: Design by Contract (tm), Assertions and Exceptions#Class invariants|class invariant]] or [[ET: Instructions#Loop|loop invariant]]. + +:[[Eiffel programming language syntax#Assertions|Assertions syntax.]] + +:[[Eiffel programming language syntax#Class declarations|Syntax of class declaration including class invariant.]] + +:[[Eiffel programming language syntax#Loops|Syntax of loop including loop invariant.]] + + +===like=== + +Used in the declaration of an [[ET: Inheritance#Covariance and anchored declarations|anchored]] entity. + +:[[Eiffel programming language syntax#Types|Syntax.]] + + +===local=== + +Introduces the [[ET: The Dynamic Structure: Execution Model#Entities|local variable]] declarations in a feature body. + +:[[Eiffel programming language syntax#Feature bodies|Feature bodies syntax.]] + +:[[Eiffel programming language syntax#Local variables|Local variable declarations syntax.]] + + +===loop=== + +Introduces a [[ET: Other Mechanisms#Loop|loop]] body. + +:[[Eiffel programming language syntax#Loops|Syntax.]] + + +===not=== + +The logical negation [[Eiffel programming language syntax#Operators|operator]]. + + +===note=== + +Used to begin a Notes part, in a [[Eiffel programming language syntax#Class declarations|class declaration]], a [[Eiffel programming language syntax#Feature declarations|feature declaration]], or a [[Eiffel programming language syntax#Check instructions|check instruction]]. + +:[[Eiffel programming language syntax#Notes|Syntax.]] + + +===obsolete=== + +Used to mark [[ET: Other Mechanisms#Obsolete features and classes|obsolete features and classes]]. + +:[[Eiffel programming language syntax#Feature declarations|Feature declarations syntax.]] + +:[[Eiffel programming language syntax#Class declarations|Class declarations declarations syntax.]] + +:[[Eiffel programming language syntax#Obsolete marks|Obsolete mark syntax.]] + + +===old=== + +Introduces an ''old expression''. Old expressions are valid only in the [[ET: Design by Contract (tm), Assertions and Exceptions#Postconditions|postconditions]] of routines. + +:[[Eiffel programming language syntax#Old postcondition expressions|Syntax.]] + + +===once=== + +Used to introduce [[ET: Other Mechanisms#Once routines and shared objects|once routines]] and once string expressions. + +:[[Eiffel programming language syntax#Routine bodies|Once routine syntax.]] + +:[[Eiffel programming language syntax#Expressions|Once string syntax.]] + + +===only=== + +Used in an ''only postcondition clause''. (8.9.11) + +:[[Eiffel programming language syntax#"Old" postcondition expressions|Syntax.]] + + +===or=== + +The logical disjunction [[Eiffel programming language syntax#Operators|operator]]. Strict when used alone, nonstrict when used with [[#else|else]]. + + +===Precursor=== + +Allows a redefined routine to access the routine it redefines, i.e, its [[ET: Inheritance#Redefinition|precursor]]. + +:[[Eiffel programming language syntax#Precursor|Syntax.]] + + +===redefine=== + +Used in an [[Eiffel programming language syntax#Inheritance parts|inheritance part]] of a [[Eiffel programming language syntax#Class declarations|class declaration]] to list those inherited features which, in the heir class, will receive new implementations, specifications, or both, i.e, those features being [[ET: Inheritance#Redefinition|redefined]]. + +:[[Eiffel programming language syntax#Redefinition|Redefine syntax.]] + + +===rename=== + +Used in an [[Eiffel programming language syntax#Inheritance parts|inheritance part]] of a [[Eiffel programming language syntax#Class declarations|class declaration]] to [[ET: Inheritance#Multiple inheritance and renaming|provide alternative names]] for inherited features in an heir class. + +Used to rename features in a [[Eiffel programming language syntax#Generic constraints|generic constraint]]. (8.12.8). + +:[[Eiffel programming language syntax#Rename clauses|Syntax.]] + + +===require=== + +Introduces a [[ET: Design by Contract (tm), Assertions and Exceptions#Expressing assertions|precondition]]. + +When followed by the reserved word [[#else|else]] denotes a precondition extension, allowing the weakening of an inherited precondition (8.10.3). + +:[[Eiffel programming language syntax#Assertions|Syntax.]] + + + +===rescue=== + +Introduces a [[ET: Design by Contract (tm), Assertions and Exceptions#Exception handling|rescue clause]] in a [[Eiffel programming language syntax#Feature bodies|feature body]]. + +:[[Eiffel programming language syntax#Rescue clauses|Syntax.]] + + +===Result=== + +A predefined [[ET: The Dynamic Structure: Execution Model#Entities|entity]] used to represent the final result of a function. + +:[[Eiffel programming language syntax#Entities and variables|Syntax.]] + + +===retry=== + +An [[Eiffel programming language syntax#Instructions|instruction]] valid only in [[Eiffel programming language syntax#Rescue clauses|rescue clauses]] and used to [[ET: Design by Contract (tm), Assertions and Exceptions#Exception handling|re-execute the routine]] in which it appears. + +:[[Eiffel programming language syntax#Rescue clauses|Syntax.]] + + +===select=== + +Used in an [[Eiffel programming language syntax#Inheritance parts|inheritance part]] of a [[Eiffel programming language syntax#Class declarations|class declaration]] to resolve possible ambiguities related to polymorphism and dynamic binding in the presence of [[ET: Inheritance#Repeated inheritance and selection|repeated inheritance]]. + +:[[Eiffel programming language syntax#Select clauses|Syntax.]] + + +===separate=== + +Reserved for future use. + +{{Note|Used in EiffelStudio implementations version 6.8 and later to support [[Concurrent programming with SCOOP]].}} + + +===then=== + +Used in [[ET: Other Mechanisms#Conditional|conditional]] and [[ET: Other Mechanisms#Multi-branch|multi-branch]] instructions to introduce a sequence of instructions to be executed in the case that a condition is met. + +:[[Eiffel programming language syntax#Conditionals|Conditional syntax.]] + +:[[Eiffel programming language syntax#Multi-branch instructions|Multi-branch syntax.]] + +Used as part of the double reserved word and then, the semi-strict conjunction operator. + +:[[Eiffel programming language syntax#Operators|Syntax.]] + +Used after the reserved word [[#ensure|ensure]] as a postcondition extension, allowing the strengthening of an inherited postcondition (8.10.3). + +:[[Eiffel programming language syntax#Assertions|Syntax.]] + + +===True=== + +Boolean manifest constant. + +:[[Eiffel programming language syntax#Manifest constants|Syntax.]] + + +===TUPLE=== + +Denotes a [[ET: Other Mechanisms#Tuple types|TUPLE type]]. + +:[[Eiffel programming language syntax#Tuple types|Syntax.]] + + +===undefine=== + +Used in an [[Eiffel programming language syntax#Inheritance parts|inheritance part]] of a [[Eiffel programming language syntax#Class declarations|class declaration]] to [[ET: Inheritance#Joining and uneffecting|uneffect]] an inherited feature. + +:[[Eiffel programming language syntax#Undefine clauses|Syntax.]] + + +===until=== + +Used in [[ET: Other Mechanisms#Loop|loop]] initialization. + +:[[Eiffel programming language syntax#Loops|Syntax.]] + + +===variant=== + +Introduces a [[ET: Instructions#Loop|loop variant]]. + +:[[Eiffel programming language syntax#Variants|Syntax.]] + + +===Void=== + +A predefined entity name representing a [[ET: The Dynamic Structure: Execution Model#Basic operations|void (a.k.a., null) reference]]. + + +===when=== + +Used in a [[ET: Other Mechanisms#Multi-branch|multi-branch instruction]] to introduce cases. + +:[[Eiffel programming language syntax#Multi-branch instructions|Syntax.]] + + +===xor=== + +The exclusive disjunction [[Eiffel programming language syntax#Operators|operator]]. + + + + diff --git a/documentation/18.11/eiffel/Language_reference/quick-reference-eiffel-programming-language/eiffel-programming-language-syntax.wiki b/documentation/18.11/eiffel/Language_reference/quick-reference-eiffel-programming-language/eiffel-programming-language-syntax.wiki new file mode 100644 index 00000000..c338bf68 --- /dev/null +++ b/documentation/18.11/eiffel/Language_reference/quick-reference-eiffel-programming-language/eiffel-programming-language-syntax.wiki @@ -0,0 +1,778 @@ +[[Property:title|Eiffel programming language syntax]] +[[Property:link_title|Syntax]] +[[Property:weight|0]] +[[Property:uuid|4CB56AD5-1586-41F6-9E81-085F47E992DC]] +The syntax specification shown here is a less complete and less formal version of that which is in the Eiffel ISO/ECMA standard document. The format is BNF-E. The Language Specification section of the standard document includes an overview of BNF-E. + +There are a few parts of the syntax that are either non-production or non-representable in BNF-E. Some of these have been omitted from the following specification. These omitted parts of the syntax definition add to the precision of the specification, but knowledge of them is not always vital for developers. + +In the BNF-E representation, generally non-terminals which are defined in the same group of productions in which they are used are not linked. However when a non-terminal is defined outside a group in which it is used, it is linked to the group in which it is defined. + +__TOC__ + +The following section contains those non-production elements of the specification that are used later in the BNF-E specification. + +==Eiffel non-production elements== + +===Identifiers=== + +An '''identifier''' is a sequence of one or more alphanumeric [[#Characters|characters]] of which the first is a letter. + +The definition is augmented by the rule that Identifiers are not valid if they are the same as one of the language's reserved words. + +===Characters=== + +Characters are either: + +* All 32-bit, corresponding to Unicode and to the Eiffel type CHARACTER_32. +* All 8-bit, corresponding to 8-bit extended ASCII and to the Eiffel type CHARACTER_8 + +===Reals=== + +A real -- specimen of Real -- is made of the following elements, in the order given: + +* An optional decimal [[#Integers|Integer]], giving the integral part. +* A required "." (dot). +* An optional decimal [[#Integers|Integer]], giving the fractional part. +* An optional exponent, which is the letter ''e'' or ''E'' followed by an optional [[#Manifest constants|Sign]] and a decimal [[#Integers|Integer]]. + +No intervening character (blank or otherwise) is permitted between these elements. The integral and fractional parts may not both be absent. + +===Strings=== + +A string -- specimen of construct String -- is a sequence of zero or more manifest characters. + +===Simple strings=== + +A simple string -- specimen of Simple_string -- is a [[#Strings|String]] consisting of at most one line (that is to say, containing no embedded new-line manifest character), possibly containing [[#Special characters|codes for special characters]]. + +===Special characters=== + +{| border="2" +|+ Special Characters and Their Codes +|- +! Character +! Code +! Mnemonic name +|- +| @ || %A || At-sign +|- +| BS || %B || Backspace +|- +| ^ || %C || Circumflex +|- +| $ || %D || Dollar +|- +| FF || %F || Form feed +|- +| \ || %H || Backslash +|- +| ~ || %L || Tilde +|- +| NL (LF) || %N || Newline +|- +| `` ` `` || %Q || Backquote +|- +| CR || %R || Carriage return +|- +| # || %S || Sharp +|- +| HT || %T || Horizontal tab +|- +| NUL || %U || Null +|- +| | || %V || Vertical bar +|- +| % || %% || Percent +|- +| ' || %' || Single quote +|- +| " || %" || Double quote +|- +| [ || %( || Opening bracket +|- +| ] || %) || Closing bracket +|- +| { || %< || Opening brace +|- +| } || %> || Closing brace +|} + +* %/123/ represents the character with decimal code 123 . + +===Line wrapping parts=== + +A sequence of characters consisting of the following, in order: +* % (percent character) +* Zero or more blanks or tabs +* New line (Line feed) +* Zero or more blanks or tabs +* % (percent character) + +Line wrapping parts are used as separators between one [[#Simple strings|Simple_string]] and the next in a [[#Manifest strings|Basic_manifest_string]] so that the string can be split across lines. + + + +==Eiffel BNF-E Syntax== + + +===Class names === +Class_name ::= [[#Identfiers|Identifier]] + +===Class declarations === +Class_declaration ::= [[[#Notes|Notes]]] +[[#Class headers|Class_header]] [[[#Formal generic parameters|Formal_generics]]] + +[[[#Obsolete marks|Obsolete]]] + +[[[#Inheritance parts|Inheritance]]] + +[[[#Creators parts|Creators]]] + +[[[#Converter clauses|Converters]]] + +[[[#Feature parts|Features]]] + +[[[#Notes|Notes]]] + +[[[#Assertions|Invariant]]] + +[[[#Notes|Notes]]] + +end + +===Notes === +Notes ::= note Note_list + +Note_list ::= {Note_entry ";" ...}* + +Note_entry ::= Note_name Note_values + +Note_name ::= [[#Identifiers|Identifier]] ":" + +Note_values ::= {Note_item ","...}+ + +Note_item ::= [[#Identifiers|Identifier]] | [[#Manifest constants|Manifest_constant]] + +===Class headers === +Class_header ::= [Header_mark] class [[#Class names|Class_name]] + +Header_mark ::= deferred | expanded | frozen + +===Obsolete marks === +Obsolete ::= obsolete Message + +Message ::= [[#Manifest strings|Manifest_string]] + +===Feature parts === +Features ::= Feature_clause+ + +Feature_clause ::= feature [[[#Clients|Clients]]] [[[#Feature parts|Header_comment]]] Feature_declaration_list + +Feature_declaration_list ::= {[[#Feature declarations|Feature_declaration]] ";" ...}* + +Header_comment ::= [[#Comments|Comment]] + +===Feature declarations === +Feature_declaration ::= [[#New feature lists|New_feature_list]] Declaration_body + +Declaration_body ::= [[[#Formal argument and entity declarations|Formal_arguments]]] [Query_mark] [Feature_value] + +Query_mark ::= Type_mark [[[#Assigner marks|Assigner_mark]]] + +Type_mark ::= ":" [[#Types|Type]] + +Feature_value ::= [Explicit_value] +[[[#Obsolete parts|Obsolete]]] +[[[#Feature parts|Header_comment]]] +[[[#Feature bodies|Attribute_or_routine]]] + +Explicit_value ::= "=" [[#Manifest constants|Manifest_constant]] + + +===New feature lists === +New_feature_list ::= {New_feature "," ...}+ + +New_feature ::= [frozen] [[#Feature names|Extended_feature_name]] + + +===Feature bodies === +Attribute_or_routine ::= [[[#Assertions|Precondition]]] +[[[#Local variable declarations|Local_declarations]]] +Feature_body +[[[#Assertions|Postcondition]]] +[[[#Rescue clauses|Rescue]]] +end + +Feature_body ::= [[#Routine bodies|Deferred]] | [[#Routine bodies|Effective_routine]] | [[#Attribute bodies|Attribute]] + + +===Feature names === +Extended_feature_name ::= Feature_name [Alias] + +Feature_name ::= [[#Identfiers|Identifier]] + +Alias ::= alias '"' Alias_name '"' [convert] + +Alias_name ::= [[#Operators|Operator]] | Bracket + +Bracket ::= "[ ]" + + +===Operators === +Operator ::= Unary | Binary + +Unary ::= not | "+" | "-" | Free_unary + +Binary ::= "+" | "-" | "*" | "/" | "//" | "\\" | "^" | ".." | "<" | ">" | "<=" | ">=" | and | or | xor | and then | or else | implies | Free_binary + +{{note| Free_unary and Free_binary are free operators that are distinct from (respectively) the ''standard'' unary and binary operators (one- or two-character symbols) explicitly listed in the Unary and Binary productions. See ''Definition: Free operator'' in the standard for more precision.}} + + +===Assigner marks === +Assigner_mark ::= assign [[#Feature names|Feature_name]] + + +===Inheritance parts === +Inheritance ::= Inherit_clause+ + +Inherit_clause ::= inherit [Non_conformance] Parent_list + +Non_conformance ::= "{" NONE "}" + +Parent_list ::= {Parent ";" ...}+ + +Parent ::= [[#Types|Class_type]] [Feature_adaptation] + +Feature_adaptation ::= [[[#Undefine clauses|Undefine]]] +[[[#Redefinition|Redefine]]] +[[[#Rename clauses|Rename]]] +[[[#Export adaptation|New_exports]]] +[[[#Select clauses|Select]]] +end + + + +===Rename clauses === +Rename ::= rename Rename_list + +Rename_list ::= {Rename_pair "," ...}+ + +Rename_pair ::= [[#Feature names|Feature_name]] as [[#Feature names|Extended_feature_name]] + + +===Clients === +Clients ::= "{" Class_list "}" + +Class_list ::= {[[#Class names|Class_name]] "," ...}+ + + + +===Export adaptation === +New_exports ::= export New_export_list + +New_export_list ::= {New_export_item ";" ...}+ + +New_export_item ::= [[#Clients|Clients]] [[[#Feature parts|Header_comment]]] Feature_set + +Feature_set ::= Feature_list | all + +Feature_list ::= {[[#Feature names|Feature_name]] "," ...}+ + + + +===Formal argument and entity declarations === +Formal_arguments ::= "(" [[#Formal argument and entity declarations|Entity_declaration_list]] ")" + +Entity_declaration_list ::= {Entity_declaration_group ";" ...}+ + +Entity_declaration_group ::= Identifier_list [[#Feature declarations|Type_mark]] + +Identifier_list ::= {[[#Identfiers|Identifier]] "," ...}+ + + +===Routine bodies === +Deferred ::= deferred + +Effective_routine ::= Internal | [[#External routines|External]] + +Internal ::= Routine_mark [[#Instructions|Compound]] + +Routine_mark ::= do | Once + +Once ::= once [ "("Key_list ")" ] + +Key_list ::= {[[#Manifest strings|Manifest_string]] "," ...}+ + + +===Local variable declarations === +Local_declarations ::= local [[[#Formal argument and entity declarations|Entity_declaration_list]]] + + +===Instructions === +Compound ::= {Instruction ";" ...}* + +Instruction ::= [[#Creation instructions|Creation_instruction]] | [[#Feature calls|Call]] | [[#Assignments|Assignment]] | [[#Assigner calls|Assigner_call]] | [[#Conditionals|Conditional]] | [[#Multi-branch instructions|Multi_branch]] +| [[#Loops|Loop]] | [[#Debug instructions|Debug]] | [[#Precursor|Precursor]] | [[#Check instructions|Check]] | [[#Rescue clauses|Retry]] + + +===Assertions === +Precondition ::= require [else] Assertion + +Postcondition ::= ensure [then] Assertion [[[#"Only" postcondition clauses|Only]]] + +Invariant ::= invariant Assertion + +Assertion ::= {Assertion_clause ";" ...}* + +Assertion_clause ::= [Tag_mark] Unlabeled_assertion_clause + +Unlabeled_assertion_clause ::= [[#Expressions|Boolean_expression]] | [[#Comments|Comment]] + +Tag_mark ::= Tag ":" + +Tag ::= [[#Identfiers|Identifier]] + + +==="Old" postcondition expressions === +Old ::= old [[#Expressions|Expression]] + + +==="Only" postcondition clauses === +Only ::= only [[[#Export adaptation|Feature_list]]] + + +===Check instructions === +Check ::= check [[#Assertions|Assertion]] [[[#Notes|Notes]]] end + + +===Variants === +Variant ::= variant [[[#Assertions|Tag_mark]]] [[#Expressions|Expression]] + + +===Precursor === +Precursor ::= Precursor [Parent_qualification] [[[#Actual arguments|Actuals]]] + +Parent_qualification ::= "{" [[#Class names|Class_name]] "}" + + +===Redefinition === +Redefine ::= redefine [[#Export adaptation|Feature_list]] + + +===Undefine clauses === +Undefine ::= undefine [[#Export adaptation|Feature_list]] + + +===Types === +Type ::= Class_or_tuple_type | [[#Formal generic parameters|Formal_generic_name]] | Anchored + +Class_or_tuple_type ::= Class_type | [[#Tuple types|Tuple_type]] + +Class_type ::= [Attachment_mark] [[#Class names|Class_name]] [[[#Actual generic parameters|Actual_generics]]] + +Attachment_mark ::= "?" | "!" + +Anchored ::= [Attachment_mark] like Anchor + +Anchor ::= [[#Feature names|Feature_name]] | Current + + +===Actual generic parameters === +Actual_generics ::= "[" Type_list "]" + +Type_list ::= {[[#Types|Type]] "," ...}+ + + +===Formal generic parameters === +Formal_generics ::= "[" Formal_generic_list "]" + +Formal_generic_list ::= {Formal_generic ","...}+ + +Formal_generic ::= [frozen] Formal_generic_name [[[#Generic constraints|Constraint]]] + +Formal_generic_name ::= [?] [[#Identfiers|Identifier]] + + +===Generic constraints === +Constraint ::= "->" Constraining_types [Constraint_creators] + +Constraining_types ::= Single_constraint | Multiple_constraint + +Single_constraint ::= [[#Types|Type]] [Renaming] + +Renaming ::= [[#Rename clauses|Rename]] end + +Multiple_constraint ::= "{" Constraint_list "}" + +Constraint_list ::= {Single_constraint "," ...}+ + +Constraint_creators ::= create [[#Export adaptation|Feature_list]] end + + +===Manifest arrays === +Manifest_array ::= [Manifest_array_type] << Expression_list >> + +Manifest_array_type ::= { [[#Types|Type]] } + +Expression_list ::= {[[#Expressions|Expression]] , ...}* + + +===Tuple types === +Tuple_type ::= TUPLE [Tuple_parameter_list] + +Tuple_parameter_list ::= "[" Tuple_parameters "]" + +Tuple_parameters ::= [[#Actual generic parameters|Type_list]] | [[#Formal argument and entity declarations|Entity_declaration_list]] + + +===Manifest tuples === +Manifest_tuple ::= "[" [[#Manifest arrays|Expression_list]] "]" + + +===Converter clauses === +Converters ::= convert Converter_list + +Converter_list ::= {Converter ","...}+ + +Converter ::= Conversion_procedure | Conversion_query + +Conversion_procedure ::= [[#Feature names|Feature_name]] "(" "{" [[#Actual generic parameters|Type_list]] "}" ")" + +Conversion_query ::= [[#Feature names|Feature_name]] ":" "{" [[#Actual generic parameters|Type_list]] "}" + + +===Select clauses === +Select ::= select [[#Export adaptation|Feature_list]] + + +===Conditionals === +Conditional ::= if Then_part_list [Else_part] end + +Then_part_list ::= {Then_part elseif ...}+ + +Then_part ::= [[#Expressions|Boolean_expression]] then [[#Instructions|Compound]] + +Else_part ::= else [[#Instructions|Compound]] + + +Conditional_expression ::= if Then_part_expression_list else [[#Expressions|Expression]] end + +Then_part_expression_list ::= {Then_part_expression elseif ...}+ + +Then_part_expression ::= [[#Expressions|Boolean_expression]] then [[#Expressions|Expression]] + + +===Multi-branch instructions === +Multi_branch ::= inspect [[#Expressions|Expression]] [When_part_list] [Else_part] end + +When_part_list ::= When_part+ + +When_part ::= when Choices then [[#Instructions|Compound]] + +Choices ::= {Choice "," ...}+ + +Choice ::= [[#Constants|Constant]] | [[#Manifest constants|Manifest_type]] | Constant_interval | Type_interval + +Constant_interval ::= [[#Constants|Constant]] ".." [[#Constants|Constant]] + +Type_interval ::= [[#Manifest constants|Manifest_type]] ".." [[#Manifest constants|Manifest_type]] + + +===Loops === +Loop ::=
+      [Iteration]
+      [Initialization]
+      [[[#Assertions|Invariant]]]
+      [Exit_condition]
+      Loop_body
+      [[[#Variants|Variant]]]
+      end + +Iteration ::= across [[#Expressions|Expression]] as [[#Identfiers|Identifier]] + +Initialization ::= from [[#Instructions|Compound]] + +Exit_condition ::= until [[#Expressions|Boolean_expression]] + +Loop_body ::=
+      loop [[#Instructions|Compound]] |
+      all [[#Expressions|Boolean_expression]] |
+      some [[#Expressions|Boolean_expression]] + + +===Debug instructions === +Debug ::= debug [ "("[[#Routine_bodies|Key_list]] ")" ] [[#Instructions|Compound]] end + + +===Attribute bodies === +Attribute ::= attribute [[#Instructions|Compound]] + + +===Entities and variables === +Entity ::= Variable | Read_only + +Variable ::= Variable_attribute | Local + +Variable_attribute ::= [[#Feature names|Feature_name]] + +Local ::= [[#Identfiers|Identifier]] | Result + +Read_only ::= Formal | Constant_attribute | Current + +Formal ::= [[#Identfiers|Identifier]] + +Constant_attribute ::= [[#Feature names|Feature_name]] + + +===Creators parts === +Creators ::= Creation_clause+ + +Creation_clause ::= create [[[#Clients|Clients]]] [[[#Feature parts|Header_comment]]] Creation_procedure_list + +Creation_procedure_list ::= {Creation_procedure ","...}+ + +Creation_procedure ::= [[#Feature names|Feature_name]] + + +===Creation instructions === +Creation_instruction ::= create [Explicit_creation_type] Creation_call + +Explicit_creation_type ::= "{" [[#Types|Type]] "}" + +Creation_call ::= [[#Entities and variables|Variable]] [Explicit_creation_call] + +Explicit_creation_call ::= "." [[#Feature calls|Unqualified_call]] + + +===Creation expressions === +Creation_expression ::= create [[#Creation instructions|Explicit_creation_type]] [[[#Creation instructions|Explicit_creation_call]]] + + +===Equality expressions === +Equality ::= [[#Expressions|Expression]] Comparison [[#Expressions|Expression]] + +Comparison ::= "=" | "/=" | "~" | "/~" + + +===Assignments === +Assignment ::= [[#Entities and variables|Variable]] ":=" [[#Expressions|Expression]] + + +===Assigner calls === +Assigner_call ::= [[#Expressions|Expression]] ":=" [[#Expressions|Expression]] + + +===Feature calls === +Call ::= Object_call | Non_object_call + +Object_call ::= [Target "."] Unqualified_call + +Unqualified_call ::= [[#Feature names|Feature_name]] [[[#Actual arguments|Actuals]]] + +Target ::= [[#Entities and variables|Local]] | [[#Entities and variables|Read_only]] | Call | Parenthesized_target + +Parenthesized_target ::= ( [[#Expressions|Expression]] ) + +Non_object_call ::= "{" [[#Types|Type]] "}" "." Unqualified_call + + +===Actual arguments === +Actuals ::= "(" Actual_list ")" + +Actual_list ::= {[[#Expressions|Expression]] "," ...}+ + + +===Object test === +Object_test ::= "{" [[#Identfiers|Identifier]] ":" [[#Types|Type]] "}" [[#Expressions|Expression]] + + +===Rescue clauses === +Rescue ::= rescue [[#Instructions|Compound]] + +Retry ::= retry + + +===Agents === +Agent ::= Call_agent | Inline_agent + +Call_agent ::= agent [[#Call agent bodies|Call_agent_body]] + +Inline_agent ::= agent [[[#Formal argument and entity declarations|Formal_arguments]]] [[[#Feature declarations|Type_mark]]] [[[#Feature bodies|Attribute_or_routine]]] [[[#Call agent bodies|Agent_actuals]]] + + +===Call agent bodies === +Call_agent_body ::= Agent_qualified | Agent_unqualified + +Agent_qualified ::= Agent_target ". " Agent_unqualified + +Agent_unqualified ::= [[#Feature names|Feature_name]] [Agent_actuals] + +Agent_target ::= Entity | Parenthesized | [[#Manifest constants|Manifest_type]] + +Agent_actuals ::= "(" Agent_actual_list ")" + +Agent_actual_list ::= {Agent_actual "," ...}+ + +Agent_actual ::= [[#Expressions|Expression]] | Placeholder + +Placeholder ::= [[[#Manifest constants|Manifest_type]]] "?" + + +===Expressions === +Expression ::= Basic_expression | Special_expression + +Basic_expression ::= [[#Entities and variables|Read_only]] | [[#Entities and variables|Local]] | [[#Feature calls|Call]] | [[#Precursor|Precursor]] | [[#Equality expressions|Equality]] | Parenthesized | [[#"Old" postcondition expressions|Old]] | +[[#Operator expressions|Operator_expression]] | [[#Bracket expressions|Bracket_expression]] | [[#Creation expression|Creation_expression]] | [[#Conditionals|Conditional_expression]] + +Special_expression ::= [[#Manifest constants|Manifest_constant]] | [[#Manifest arrays|Manifest_array]] | [[#Manifest tuples|Manifest_tuple]] | [[#Agents|Agent]] | [[#Object test|Object_test]] | Once_string | +Address + +Parenthesized ::= "(" Expression ")" + +Address ::= "$" [[#Entities and variables|Variable]] + +Once_string ::= once [[#Manifest strings|Manifest_string]] + +Boolean_expression ::= Basic_expression | [[#Manifest constants|Boolean_constant]] | [[#Object test|Object_test]] + + +===Operator expressions === +Operator_expression ::= Unary_expression | Binary_expression + +Unary_expression ::= Unary Expression + +Binary_expression ::= [[#Expressions|Expression]] [[#Operators|Binary]] [[#Expressions|Expression]] + + +===Bracket expressions === +Bracket_expression ::= Bracket_target "[" [[#Actual arguments|Actuals]] "]" + +Bracket_target ::= [[#Feature calls|Target]] | [[#Expressions|Once_string]] | [[#Manifest constants|Manifest_constant]] | [[#Manifest tuples|Manifest_tuple]] + + +===Constants === +Constant ::= [[#Manifest constants|Manifest_constant]] | Constant_attribute + +Constant_attribute ::= [[#Feature names|Feature_name]] + + +===Manifest constants === +Manifest_constant ::= [Manifest_type] Manifest_value + +Manifest_type ::= "{" [[#Types|Type]] "}" + +Manifest_value ::= Boolean_constant | +Character_constant | +Integer_constant | +Real_constant | +[[#Manifest strings|Manifest_string]] | +Manifest_type + +Sign ::= "+" | "-" + +Integer_constant ::= [Sign] [[#Integers|Integer]] + +Character_constant ::= " ' " [[#Characters|Character]] " ' " + +Boolean_constant ::= True | False + +Real_constant ::= [Sign] [[#Reals|Real]] + + +===Manifest strings === +Manifest_string ::= Basic_manifest_string | Verbatim_string + +Basic_manifest_string ::= ' " ' String_content ' " ' + +String_content ::= {[[#Simple strings|Simple_string]] [[#Line wrapping parts|Line_wrapping_part]] ...}+ + +Verbatim_string ::= Verbatim_string_opener Line_sequence Verbatim_string_closer + +Verbatim_string_opener ::= ' " ' [[[#Simple strings|Simple_string]]] Open_bracket + +Verbatim_string_closer ::= Close_bracket [[[#Simple strings|Simple_string]]] ' " ' + +Open_bracket ::= "[" | "{" + +Close_bracket ::= "]" | "}"Verbatim_string ::= Verbatim_string_opener Line_sequence Verbatim_string_closer + +Verbatim_string_opener ::= ' " ' [[[#Simple strings|Simple_string]]] Open_bracket + +Verbatim_string_closer ::= Close_bracket [[[#Simple strings|Simple_string]]] ' " ' + +Open_bracket ::= "[" | "{" + +Close_bracket ::= "]" | "}" + + +===External routines === +External ::= external External_language [External_name] + +External_language ::= Unregistered_language | [[#Registered languages|Registered_language]] + +Unregistered_language ::= [[#Manifest strings|Manifest_string]] + +External_name ::= alias [[#Manifest strings|Manifest_string]] +{{note|If the `inline` keyword is used in the Registered_language part, then External_name part is the inline code on the specified language.}} + + +===Registered languages === +Registered_language ::= [[#C externals|C_external]] | [[#C++ externals|C++_external]] | [[#DLL externals|DLL_external]] + + +===External signatures === +External_signature ::= signature [External_argument_types] [: External_type] + +External_argument_types ::= "(" External_type_list ")" + +External_type_list ::= {External_type "," ...}* + +External_type ::= [[#Simple strings|Simple_string]] + + +===External file use === +External_file_use ::= use External_file_list + +External_file_list ::= {External_file "," ... }+ + +External_file ::= External_user_file | External_system_file + +External_user_file ::= ' " ' [[#Simple strings|Simple_string]] ' " ' + +External_system_file ::= "<" [[#Simple strings|Simple_string]] ">" + +===C externals === +C_external ::= ' " ' C [inline] [ [[#External signatures |External_signature]] ] [ [[#External file use |External_file_use]] ] ' " ' + + +===C++ externals === +C++_external ::= ' " ' C++ inline [ [[#External signatures |External_signature]] ] [ [[#External file use |External_file_use]] ] ' " ' + + +===DLL externals === +DLL_external ::= ' " ' dll [windows] DLL_identifier [DLL_index] [[ [[#External signatures |External_signature]] ] [ [[#External file use |External_file_use]] ] ' " ' + +DLL_identifier ::= [[#Simple strings|Simple_string]] + +DLL_index ::= [[#Integers|Integer]] + + +===Comments === +Comment ::= "- -" {[[#Simple strings|Simple_string]] Comment_break ...}* + +Comment_break ::= New_line [Blanks_or_tabs] "- -" + +===Integers === +Integer ::= [Integer_base] Digit_sequence + +Integer_base ::= "0" Integer_base_letter + +Integer_base_letter ::= "b" | "c" | "x" | "B" | "C" | "X" + +Digit_sequence ::= Digit+ + +Digit ::= "0" | "1" | "2" | "3" | "4" | "5" | "6" | "7" | "8" | "9" | +"a" | "b" | "c" | "d" | "e" | "f" | +"A" | "B" | "C" | "D" | "E" | "F" | "_" + diff --git a/documentation/18.11/eiffel/Language_reference/quick-reference-eiffel-programming-language/index.wiki b/documentation/18.11/eiffel/Language_reference/quick-reference-eiffel-programming-language/index.wiki new file mode 100644 index 00000000..c8dc25c1 --- /dev/null +++ b/documentation/18.11/eiffel/Language_reference/quick-reference-eiffel-programming-language/index.wiki @@ -0,0 +1,16 @@ +[[Property:title|Quick reference to the Eiffel programming language]] +[[Property:link_title|Quick Reference]] +[[Property:weight|4]] +[[Property:uuid|4f61365d-59f6-a394-678b-144bad8ec12f]] +The Quick Reference to the Eiffel programming language provides an informal guide to the syntax and reserved words of the language. The Eiffel programming language is described in detail in the '''ISO/ECMA''' standard document, available [http://www.ecma-international.org/publications/standards/Ecma-367.htm online]. + +Sometimes there are differences between the language as defined by the standard and that which is implemented by Eiffel Software. These differences are documented in the online documentation. + +So, the final authority on Eiffel as implemented by Eiffel Software is the content of the standard document, amended by those variances cited in the [[Differences between standard ECMA-367 and Eiffel Software implementation|"differences" chapter of the online documentation]]. + +This reference is based on the June 2006 ISO/ECMA standard document. + + + + + diff --git a/documentation/18.11/eiffel/Language_reference/void-safe-programming-eiffel/converting-existing-software-void-safety/changes-eiffel-libraries-support-void-safety.wiki b/documentation/18.11/eiffel/Language_reference/void-safe-programming-eiffel/converting-existing-software-void-safety/changes-eiffel-libraries-support-void-safety.wiki new file mode 100644 index 00000000..7e1fe6c4 --- /dev/null +++ b/documentation/18.11/eiffel/Language_reference/void-safe-programming-eiffel/converting-existing-software-void-safety/changes-eiffel-libraries-support-void-safety.wiki @@ -0,0 +1,88 @@ +[[Property:title|Void-safe changes to Eiffel libraries]] +[[Property:weight|0]] +[[Property:uuid|dc993c0e-fbec-dc5a-82c8-fbfd9fa9bc3a]] +==Overview== + +During the adoption of void-safety, the software libraries provided by Eiffel Software have been converted to be void-safe. The bulk of the changes made to these libraries will have little or no adverse effect on your existing software as you go through the process of void-safe conversion. However, there are a few changes to the library that we consider "breaking" changes, that is, important changes that might cause problems in existing systems that use certain library classes. + + +{{note|Many of these changes were in effect in the ''experimental'' mode of versions 6.4 and 6.5. With the release of version 6.6, the ''experimental'' mode of previous versions became the ''default'' mode and, consequently may have caused these changes to become more apparent to some users. A ''compatibility'' mode is available to ease transition. The ''compatibility'' mode is accessible using the -compat command line option or through the EiffelStudio choices provided through the Microsoft Windows ''Start'' button. }} + + +==Important changes to library classes== + + +===Class ARRAY=== + +====New preconditions==== + +Some additional preconditions are in force in ARRAY in void-safe mode. + +In void-unsafe mode, the behavior is equivalent to that of previous versions. + +====Feature make_from_special==== + +The signature of this routine has changed. + +Current signature: make_from_special (a: SPECIAL [G]) + +Previous signature: make_from_special (a: SPECIAL [G]; min_index, max_index: INTEGER) + +Using the current version will create an array with a range from 1 to the number of elements in the argument `a`. + +====Feature auto_resize==== + +This implementation (private) feature has been removed. + + +===Class ARRAYED_LIST=== + +====Relationship to ARRAY==== + +Previously ARRAYED_LIST conformed to ARRAY. This is no longer the case. The feature {ARRAYED_LIST}.to_array can be used to produce an instance of ARRAY from an instance of ARRAYED_LIST. + +====Features count and area==== + +Previously these two queries, count and area, were attributes. They are now functions. + + +===Class HASH_TABLE=== + +The internal implementation has changed in ways that cause the order of traversal to differ from previous versions. + + +===Classes SPECIAL and TO_SPECIAL=== + +====Feature {SPECIAL}.make==== + +This void-unsafe feature has been removed. + +In its place, the creation procedures {SPECIAL}.make_filled and {SPECIAL}.make_empty can be used. + +{SPECIAL}.make_filled is available in both ''default'' and ''compatible'' modes. Use this creation procedure if you want code that is compatible with both modes. + +{SPECIAL}.make_empty is available in ''default'' mode only. + +====Feature {TO_SPECIAL}.make_area==== + +In order to reflect the above change to class SPECIAL, the make_area feature of TO_SPECIAL has been removed in favor of {TO_SPECIAL}.make_filled_area and {TO_SPECIAL}.make_empty_area. + +The availability of {TO_SPECIAL}.make_filled_area and {TO_SPECIAL}.make_empty_area corresponds to that noted above for the creation features of SPECIAL: + +{TO_SPECIAL}.make_filled_area is available in both ''default'' and ''compatible'' modes. Use make_filled_area for code that needs to compile in both modes. + +{TO_SPECIAL}.make_empty_area is available only in ''default'' mode. + +====Relationship of feature {SPECIAL}.count to {SPECIAL}.capacity==== + +In previous versions, for a particular instance of SPECIAL the queries count and capacity yielded the same value. + +This is no longer always true. If an instance of SPECIAL is created with, for example, make_empty (10), although the capacity will be 10, the count will be zero. + +However creating a SPECIAL using make_filled will produce an instance in which count and capacity are equal upon creation. So the behavior is similar to that of previous versions. Also, make_filled is available in both ''default'' and ''compatible'' modes. + +If your code depends upon count and capacity having the same value, then you can use make_filled for creation. And then if you need resizing, use the "_with_default" versions of the "resized" features, specifically resized_area_with_default and aliased_resized_area_with_default. + + + + diff --git a/documentation/18.11/eiffel/Language_reference/void-safe-programming-eiffel/converting-existing-software-void-safety/index.wiki b/documentation/18.11/eiffel/Language_reference/void-safe-programming-eiffel/converting-existing-software-void-safety/index.wiki new file mode 100644 index 00000000..f754eaf0 --- /dev/null +++ b/documentation/18.11/eiffel/Language_reference/void-safe-programming-eiffel/converting-existing-software-void-safety/index.wiki @@ -0,0 +1,335 @@ +[[Property:title|Converting existing software to void-safety]] +[[Property:weight|6]] +[[Property:uuid|eb901272-d405-2277-005d-e37275b9baa4]] +If you have been using Eiffel for a while, you may be maintaining systems which were developed before Eiffel became void-safe. If that's the case, then you will probably want to make those systems void-safe. + +In this section we will use the experience of converting a set of simple (but not too simple) legacy Eiffel classes to show the types of issues that you may encounter, and how to deal with them. + +So in the discussion below, you will see references to these classes: + + +{| border="1" +|- +! Class name +! Description +|- +| APPLICATION +| Simple root class containing declarations of types NVP and NVP_LIST +|- +| NVP +| Class modeling name/value pairs of type STRING +|- +| NVP_LIST +| Class modeling a list of NVP's with specialized behavior; heir of TWO_WAY_LIST [NVP] +|} + + +It's not important that you know much about the details of these classes. We will, however, look at certain parts of the classes in enough detail to resolve the conversion issues. + + +=Conversion considerations= + +==To redesign or not to redesign== + +During the process of conversion of classes to void-safety, the compiler will point out problems which you will have to fix. Some of these will be straightforward, while others may be tricky. It is natural, or sometimes mandatory, at times to consider changing elements of the design of your software. + +Also, as you sift through your existing software during the void-safe conversion, you may not get very far before you see things that you wish had been done differently. This occurs often during reviews of existing systems, not just because of the introduction of void-safety. + +In the discussions that follow you will see these redesign opportunities arise, and the decisions that were made for these cases. + +==Be aware of changes to Eiffel libraries== + +The libraries distributed with EiffelStudio have been converted to support void-safety. Mostly the changes made will cause no problems for existing software. However a few changes have been identified as "breaking" changes. You may or may not encounter the effects of these changes, but you should be aware of how they could effect your software and what options you have for adapting to them. Breaking changes are described in the [[EiffelStudio release notes]] and in the page dedicated to [[Void-safe changes to Eiffel libraries]]. + +=Conversion process= + +==Enable full class checking== + +First make sure your project will compile correctly under the configuration of EiffelStudio that you intend to use to convert to void-safe. + +Then set the project setting '''Full Class Checking''' to '''True'''. Do a ''[[Clean compile|clean compile]]'' of your system. + +Full class checking will analyze your classes to make sure that in cases of inheritance, features of the parent classes are rechecked for validity in the heirs. + +Here's an example of the kind of error you might expect when compiling with full class checking: + + +[[Image:VGCC error]] + + +The situation here is that the feature split has been inherited (from class TWO_WAY_LIST [G]) by our class NVP_LIST. Feature split includes code to create and attach feature sublist which is typed attached like Current which in this case means attached NVP_LIST. To do this creation, split uses a creation procedure make_sublist. + +Now here's the rub: NVP_LIST has not named make_sublist as a creation procedure: + +create + make, make_from_string, make_from_file_named + +If we go to the create part of NVP_LIST and add make_sublist to its list of creation procedures, this will fix the problem: + +create + make, make_from_string, make_from_file_named, make_sublist + + +So, fix any problems that arise out of turning on full class checking. + +==Enable other project settings== + +The second step in conversion of existing software is to change the values of the other void-safe related project settings and use the void-safe configurations for any delivered libraries and precompilations. + +In the project settings for the target in which you are working, set '''Void safety''' to '''Complete''', '''Transitional''' , '''Initialization''' or '''Conformance'''. + +{{note|Remember that during a transitional period starting with v6.4, there will be multiple versions of the configuration files for Eiffel libraries and precompiles. For example, base.ecf (void-unsafe) and base-safe.ecf (void-safe). Starting with v16.11 there is only one configuration file for libraries (e.g., base.ecf) that works with both void-safe and void-unsafe client software, but if you are using a precompile, there could be different versions for void-safe and void-unsafe precompiles.}} + +If necessary, remove Eiffel libraries and any precompiled library that your project uses and re-add them with their void-safe configuration files. Because you've set your target to void-safety, when you click '''Add Library''', you should see only void-safe configurations by default. +You will see a check box on the dialog that you can uncheck if you want to see all available library configurations: + + +[[Image:VoidSafeAddLibraryDialog]] + + +Now do a [[Clean compile|clean compile]]. + +If you've replaced a precompiled library that you have not already built, EiffelStudio will offer to build it for you on the fly: + + +[[Image:VoidSafePrecompileOffer]] + + +Now you should see error messages representing any situation in your project in which the compiler determines that it cannot guarantee void-safety. + +This is what our legacy system produced: + + +[[Image:VoidSafeErrorList]] + + +==Fix the issues== + +Next you fix the problems that the compiler discovered. The compiler errors concerning void-safety typically will be of three varieties. + +# VEVI: violations of the '''Variable initialization rule'''. An attached variable is not '''properly set'''. +# VUTA: violations of the '''Target rule'''. The target of a feature call is not attached. +# VJAR (and other related codes): violations of attached status considered in conformance. The attachment status of the source of an assignment (or an argument to a feature call) is not compatible with that of the target of the assignment (or the formal argument). + +Let's look at some specific cases and how fixing them unfolds. + +===Variables not properly set=== + +[[Image:VoidSafeVEVI1]] + + +There are two VEVI errors like this in class APPLICATION of our legacy system. They are probably the most obvious and easiest cases to handle. + + +feature {NONE} -- Initialization + + make + -- Run application. + do + ... + end + +feature -- Access + + my_nvp: NVP + -- NVP for testing + + my_nvp_list: NVP_LIST + -- NVP_LIST for testing + + +Here attribute declarations for my_nvp and my_nvp_list are made. These are assumed to be attached because of the project setting. But the create routine make fails to create objects and attach them. So by adding those creations, as shown below, the compiler is satisfied. + + + make + -- Run application. + do + create my_nvp.make ("SomeName", "SomeValue") + create my_nvp_list.make + ... + end + + + +In a second case, there is also an Initialization rule violation (VEVI), this time on Result, in this routine: + + + at_first (nm: STRING): NVP + -- The first found NVP with name matching nm. + -- Or Void if not found + require + nm_valid: nm /= Void and then not nm.is_empty + local + tc: CURSOR + do + tc := cursor + start + name_search (nm) + if not exhausted then + Result := item + end + go_to (tc) + ensure + index_unchanged: index = old index + end + + +Here we cannot just ensure that Result is always attached, because, as indicated by the header comment, Result is allowed to be void by design. + +So the least impact to this routine will be to declare its type as detachable: + + + at_first (nm: STRING): detachable NVP + -- The first found NVP with name matching nm. + -- Or Void if not found + + + +The same change is made in other routines that can return void by design, particularly including a routine called value_at_first, which gets our attention next. + +The case of at_first offered us an opportunity to redesign (or not). We might have been able to leave at_first attached. After all, in void-safe software, the fewer detachables, the better. Maybe we could devise a way, possibly through preconditions and other queries, that would guarantee that at_first attempts to execute only when it can return a value. + +But at_first is an exported query, so a consequence of such a change in the class design is that it would affect the class interface in such a way that existing clients would have to be modified to comply. In other words, it would be a "breaking" change. + + +===Source of assignment does not conform to target=== + +The change to at_first satisfies the VEVI issue in at_first, but it introduces a previously unseen conformance issue (VJAR) in the routine value_at_first: + + +[[Image:VoidSafeVJAR1]] + + +value_at_first looks like this: + + + value_at_first (nm: STRING): detachable STRING + -- Value from first found NVP with name matching nm + -- Or Void of not found + require + nm_valid: nm /= Void and then not nm.is_empty + local + tn: NVP + do + tn := at_first (nm) + if tn /= Void then + Result := tn.value + end + end + + +The problem is that the local variable tn is declared as attached, but we know that now the result of at_first is detachable, making this assignment invalid: + + tn := at_first (nm) + + +Here the '''attached syntax''' can fix the problem and streamline the routine: + + + value_at_first (nm: STRING): detachable STRING + -- Value from first found NVP with name matching nm + -- Or Void of not found + require + nm_valid: nm /= Void and then not nm.is_empty + do + if attached at_first (nm) as tn then + Result := tn.value + end + end + + +In this version tn need not be declared as a local variable. Remember that the attached syntax provides a fresh local variable, if the expression is not void. + +===Both VEVI and VJAR errors=== + +A design issue in class NVP_LIST causes both conformance and initialization compiler errors. In the original design, an instance of the class NVP_LIST could traverse its contents NVP-by-NVP with inherited functionality. Additionally, NVP_LIST has immediate functionality allowing an instance to traverse its contents in two different ways returning "sublists" based on recurring patterns of the name attributes of a sequence of name/value pairs. + +These two traversal methods are referred to as "sequencing" and "segmenting". It's not important that you understand the details of what these traversals do. But it is important to know that a valid instance of NVP_LIST can either be in the process of sequencing or in the process of segmenting, or neither. It is invalid to be both sequencing ''and'' segmenting. + +Two class attributes are maintained to store the recurring patterns of values of {NVP}.name that guide traversal: + + +feature {NONE} -- Implementation + + sequence_array: ARRAY [STRING] + -- The current array of names being used for + -- sequence traversal + + segment_array: ARRAY [STRING] + -- The current array of names being used to determine + -- the termination of list segments + + +In the original class design, each of these attributes would be void unless their corresponding traversal was active. So the class contains the following clauses in its invariant: + + + not_sequencing_and_segmenting: not (segment_readable and sequence_readable) + sequence_traversal_convention: (sequence_array = Void) = (not sequence_readable) + segment_traversal_convention: (segment_array = Void) = (not segment_readable) + + +Of course by default these attributes are considered to be attached. So, because they are not initialized during creation, we see initialization errors. Because elements of the class intentionally set them to Void, we see conformance errors. + +Here we have another opportunity to redesign (or not). We could mark the two arrays as detachable, recompile and fix any problems this causes (in fact, it causes eight errors: six Target rule violations, and two conformance issues). + +However, because these attributes are not exported, we may be able to leave them attached and make changes to the implementation design without making breaking changes to the interface. + +Those exported features which take arguments of the type ARRAY [STRING] which will serve as sequencing or segmenting control also require that the array contain at least one element. For example, the contract for feature segment_start contains these preconditions: + + + segment_start (nms: ARRAY [STRING_8]) + -- Place segment cursor on the first occurrence of a seqment of list which + -- begins at the current cursor position and + -- terminates in a sequence with names equivalent to and ordered the same as `nms'. + -- If no such sequence exists, then ensure exhausted + require + nms_valid: nms /= Void and then (nms.count > 0) + not_sequencing: not sequence_readable + + +Because the restriction always exists that a valid sequence_array or segment_array must contain at least one element, it is possible to redesign the implementation of the class such that an empty sequence_array and segment_array could serve the same purpose as a Void one does in the original design. + +So the invariant clauses that we saw above would now become: + + + not_sequencing_and_segmenting: not (segment_readable and sequence_readable) + sequence_traversal_convention: (sequence_array.is_empty) = (not sequence_readable) + segment_traversal_convention: (segment_array.is_empty) = (not segment_readable) + + +We already have compiler errors (VJAR's) that point us to those places in which we have code that sets either sequence_array or segment_array to Void. Like this: + + + segment_array := Void + + +These instances need to be changed to attach an empty array, maybe like this: + + + create segment_array.make (1, 0) + + +Additionally, some postconditions which reference the implementation features sequence_array and/or segment_array would have to be changed. Looking at the postcondition clauses for segment_start we see that segment_array is expected (or not) to be Void: + + + ensure + started: (not exhausted) implies (segment_readable and (segment_array /= Void) and (last_segment_element_index > 0)) + not_started: exhausted implies ((not segment_readable) and (segment_array = Void) and (last_segment_element_index = 0)) + + +To support the "empty array" design, segment_start's postcondition clauses would be: + + + ensure + started: (not exhausted) implies (segment_readable and (not segment_array.is_empty) and (last_segment_element_index > 0)) + not_started: exhausted implies ((not segment_readable) and (segment_array.is_empty) and (last_segment_element_index = 0)) + + + + +{{SeeAlso|
[[Converting EiffelVision 2 Systems to Void-Safety]]
[[Void-safe changes to Eiffel libraries]]}} + + + + + diff --git a/documentation/18.11/eiffel/Language_reference/void-safe-programming-eiffel/converting-existing-software-void-safety/mixing-void-safe-and-void-unsafe-software.wiki b/documentation/18.11/eiffel/Language_reference/void-safe-programming-eiffel/converting-existing-software-void-safety/mixing-void-safe-and-void-unsafe-software.wiki new file mode 100644 index 00000000..ca8c2a76 --- /dev/null +++ b/documentation/18.11/eiffel/Language_reference/void-safe-programming-eiffel/converting-existing-software-void-safety/mixing-void-safe-and-void-unsafe-software.wiki @@ -0,0 +1,28 @@ +[[Property:title|Mixing void-safe and void-unsafe software]] +[[Property:weight|3]] +[[Property:uuid|3446f214-3c77-ef41-98eb-92942298630c]] +{{underconstruction}} + + +=Introduction= + +Eiffel Software recommends that any new development efforts be implemented using Eiffel's void-safe approach, thus eliminating one more common type of runtime failure. It is also recommended that existing software be converted to void-safety at the earliest opportunity. + +Under some circumstances it is possible and even helpful to mix void-safe and void-unsafe libraries. During conversion to void-safety, for example, it can be helpful to compile and test a void-unsafe system with void-safe versions of the libraries it depends upon. + +=Rule for mixing void-safety modes= + +The rule for using void-safe and void-unsafe software together is fairly simple. + + +{{Rule|name=Mixing void-safe and void-unsafe software|text=
+1) A class that is void-unsafe may depend upon other classes (as suppliers or ancestors) which are either void-safe or void-unsafe.
+2) A class that is void-safe may depend only upon other classes that are void-safe.}} + + +This means that if the root class of a system is void-safe, then every other class in the system must also be void-safe. + +However, if you are converting a system to void-safety, it's likely that your root class and the classes in the closely related clusters will be void-unsafe. The rule allows you to mix the void-safe versions of the Eiffel Software library classes from the EiffelStudio distribution with your void-unsafe system during conversion. + + + diff --git a/documentation/18.11/eiffel/Language_reference/void-safe-programming-eiffel/creating-new-void-safe-project.wiki b/documentation/18.11/eiffel/Language_reference/void-safe-programming-eiffel/creating-new-void-safe-project.wiki new file mode 100644 index 00000000..e0cf753b --- /dev/null +++ b/documentation/18.11/eiffel/Language_reference/void-safe-programming-eiffel/creating-new-void-safe-project.wiki @@ -0,0 +1,390 @@ +[[Property:link_title|New void-safe project]] +[[Property:title|Creating a new void-safe project]] +[[Property:weight|2]] +[[Property:uuid|92cea2e9-b094-6380-2c5d-1cd1eb3038b4]] + +{{TOC|limit=2}} + +Now that we've been introduced to the Eiffel void-safe facilities, let's look at what it takes to set up a new void-safe software project. Here we'll look at the void-safety related project settings and how the can be used. Then we'll look deeper into the use of some of the void-safe tools. + +==Project settings for void-safe projects== + +There are two project settings that are related to void-safety. These settings can be set with great granularity throughout your project to allow you maximum flexibility, particularly when including classes or libraries that are void-unsafe or that have been converted to void-safety, but must do double duty in the void-safe and void-unsafe worlds. + +===The ''"Void-safe"'' setting=== + +The '''Void-safe''' setting determines whether and how the Eiffel compiler checks your project against the void-safe related validity rules. + +This is the essential void-safe project setting. It can assume one of the following values: +# '''No''': No checking against any of the void-safety validity rules. Attachment marks '''attached''' and '''detachable''' are simply ignored. +# '''Conformance''': The attachment marks are not ignored for type conformance checks (with respect to VJAR/VBAR and related validity rules). +# '''Initialization''': Validity rules are selectively checked. The initialization rule (VEVI) and the target rule (VUTA) are checked only for attached entities and attached call targets -- i.e., detachable cases are not checked. +# '''Transitional''': It is an obsolete level which is for users who have already migrated their code to void-safety using an old version of the compiler which did not implement all the void-safety validity rules (especially with agent initialization). +# '''Complete''': Complete checking against all void-safety validity rules. + +So, for a new void-safe project, you would want to set this option first to '''Conformance''', then '''Initialization''' and finally to '''Complete'''. This will let you migrate your code progressively without much changes at each steps. + + +===The ''"Full class checking"'' setting=== + +This setting instructs the compiler to recheck inherited features in descendant classes. This setting is True and cannot be changed for projects with some void-safety level enabled. + + +==Void-safe libraries== + +As of EiffelStudio version 13.11, all libraries distributed with EiffelStudio are void-safe except the EiffelCOM library. + +{{note|During a period of transition, there are different Eiffel configuration files (.ecf's) for void-unsafe and void-safe projects (for example, base.ecf and base-safe.ecf). If you have set the '''Void-safe''' setting to check for void-safety, then when you add a library to your project in EiffelStudio, you will see only the void-safe configurations by default. Starting with version 16.11 there is only one version of each of the configuration files for each library. The single configuration files serve both void-unsafe and void-safe projects.}} + +===Using generic classes=== + +Void-safety affects generic classes. Fortunately, from the viewpoint of those writing clients to the generic classes in the EiffelBase library, not much has changed. Still, you should understand the interplay between void-safety and [[ET: Genericity and Arrays|genericity]]. + +Consider a generic class like LIST [G]. The formal generic parameter G represents an arbitrary type. In a generic derivation of LIST [G], say LIST [STRING], the formal generic type is replaced by an actual generic type, in this case STRING. + +Remember that unconstrained genericity, LIST [G], for example, is really a case of [[ET: Inheritance#Constrained genericity|constrained genericity]] in which the generic parameter is constrained to ANY, that is, it could be written LIST [G -> ANY]. + +With the advent of void-safe Eiffel, the unconstrained generic class name LIST [G] now equates to LIST [G -> detachable ANY]. Because any type, say T, (synonymous with attached T in void-safe Eiffel) conforms to detachable T, this change facilitates the production of generic classes, but has little effect on writers of clients to those classes. + +This change works for all the generic classes in EiffelBase ... except for one: ARRAY. Arrays are a special case because we often create arrays with a pre-allocated number of elements. In the case of expanded types, there's not a problem. For example, in this code + + my_array: ARRAY [INTEGER] + ... + create my_array.make (1, 100) + +we create my_array with one hundred INTEGER elements. INTEGER is an expanded type, and each element is initialized by applying the default initialization rule for INTEGER, i.e, the integer representation of zero. + +However, if my_array had been declared of a type with reference semantics, say STRING (meaning, of course, attached STRING, the default rule would not work well, because the default initialization for references types is Void which would not be allowed in an array of elements of any attached type. + +The solution to this challenge is fairly simple. For arrays of elements of detachable or expanded types, there is no different behavior. When dealing with arrays of elements of attached types, we must be careful. + +Creating an array using ARRAY's creation procedure make may still be safe in some cases. Specifically, make can be used with arrays of elements of attached types if the arguments have values such that an empty array will be created, that is, when + + min_index = max_index + 1 + + +In all other situations involving arrays of elements of attached types, make may not be used to do the creation. Rather, you should use the creation procedure make_filled which takes three arguments. The first is an object of the type of the array, and the second and third are the minimum and maximum indexes, respectively. When the array is created, each of the elements will be initialized with a reference to the object of the first argument. + +So, a call using make_filled would look like this: + + my_array: ARRAY [STRING] + ... + create my_array.make_filled (" ", 1, 100) + +Upon creation, each element of the array will reference the same object; an object of type STRING composed of one space character. + + +==Using the ''attribute'' keyword carefully== + +The keyword attribute should be used with some care. You might be tempted to think that it would be convenient or add an extra element of safety to use [[Void-safety: Background, definition, and tools#Self-initializing attributes|self-initializing attributes]] widely. And in a way, you would be correct. But you should also understand that there is a price to pay for using self-initializing attributes and stable attributes. It is that upon every access, an evaluation of the state of the attribute must be made. So, as a general rule, you should avoid using self-initializing attributes only for the purpose of lazy initialization. + + +==More about the ''attached syntax''== + +The complete attached syntax is: + + attached {SOME_TYPE} exp as l_exp + +In this section, we will see more ways in which to use this versatile language facility. + +===As a CAP-like construct which yields a local variable=== + +In the introduction to the attached syntax, we used an example which showed how the attached syntax is directly relevant to void-safety. That is, the code: + + if x /= Void then +-- ... Any other instructions here that do not assign to x + x.f (a) + end + + +is a CAP for x ... but that's only true if x is a local variable or a formal argument to the routine that contains the code. + +So to access a detachable attribute safely, we could declare a local variable, make an assignment, and test for Void as above. Something like this: + + my_detachable_attribute: detachable MY_TYPE + + ... + some_routine + local + x: like my_detachable_attribute + do + x := my_detachable_attribute + if x /= Void then +-- ... Any other instructions here that do not assign to x + x.f (a) + end + ... + +The attached syntax can both check the attached status of a detachable attribute and also provide a new local variable. So the routine becomes: + + some_routine + do + if attached my_detachable_attribute as x then +-- ... Any other instructions here that do not assign to x + x.f (a) + end + ... + + +===As a test for attachment=== + +In its simplest form, the attached syntax can be used to test attached status only: + + if attached x then + do_something + else + do_something_different + end + + +So in this simple form, attached x can be used instead of x /= Void. The two are semantically equivalent, and which one you choose is a matter of personal preference. + + +===As a tool for "once per object"=== + +There is a code pattern for functions that exists in some Eiffel software to effect "once-per-object / lazy evaluation". + +{{note|As of EiffelStudio version 6.6, the use of this code pattern effecting "once per object" is no longer necessary. V6.6 includes explicit support for once routines which can be adjusted by a [[ET: Once routines and shared objects#Adjusting once semantics with "once keys"|once key]] to specify once per object.}} + +This "once-per-object" code pattern employs a cached value for some object which is not exported. When it is applied, the "once-per-object" function checks the attachment status of the cached value. If the cached value is void, then it is created and assigned to Result. If the cached value was found already to exist, then it is just assigned to Result. + +Here's an example of this pattern used to produce some descriptive text of an instance of its class: + + +feature -- Access + + descriptive_text: STRING + local + l_result: like descriptive_text_cache + do + l_result := descriptive_text_cache + if l_result = Void then + create Result.make_empty + -- ... Build Result with appropriate + -- descriptive text for Current. + descriptive_text_cache := Result + else + Result := l_result + end + ensure + result_attached: Result /= Void + result_not_empty: not Result.is_empty + result_consistent: Result = descriptive_text + end + +feature {NONE} -- Implementation + + descriptive_text_cache: like descriptive_text + + +This example will not compile in a void-safe project (class types are attached by default). The problem is that the attribute descriptive_text_cache is of an attached type, therefore will be flagged by the compiler as not properly set (VEVI). Of course, it will be ... that's the whole idea here: not to initialize descriptive_text_cache until it's actually used. So it sounds like descriptive_text_cache should be declared detachable. That is: + + descriptive_text_cache: detachable like descriptive_text + +This change will make this routine compile in a void-safe project. But you should notice that there is a ripple-down effect due to the change. Within the routine, l_result is typed like descriptive_text_cache, so it also will be detachable. Therefore we might expect trouble, because later in the routine we have: + + Result := l_result + +Because we know Result is attached and l_result is detachable, we might expect a compiler error in which the source of an assignment does not conform to its target (VJAR). + +But we don't get such an error. The reason is two-fold. First, l_result is a local variable whose use can be protected by a CAP. Second, the CAP in this case is the check to ensure that l_result is not void. We only make the assignment to Result if l_result is not void. So the compiler can prove that l_result cannot be void at the point at which the assignment occurs ... therefore, no error. + +Because the '''attached syntax''' can test attached status and provide a local variable, it can be used to remove some unnecessary code from this routine. The version of the routine that follows shows the attached syntax being used to test the attached status of descriptive_text_cache and yield the local variable l_result in the case that descriptive_text_cache is indeed attached. + + descriptive_text: STRING + do + if attached descriptive_text_cache as l_result then + Result := l_result + else + create Result.make_empty + -- ... Build Result with appropriate + -- descriptive text for Current. + descriptive_text_cache := Result + end + ensure + result_attached: Result /= Void + result_not_empty: not Result.is_empty + result_consistent: Result = descriptive_text + end + +feature {NONE} -- Implementation + + descriptive_text_cache: like descriptive_text + + + + +===As a replacement for assignment attempt=== + +The assignment attempt ( ?= ) has traditionally been used to deal with external objects (e.g., persistent objects from files and databases) and to narrow the type of an object in order to use more specific features. The latter is a process known by names such as "down casting" in some technological circles. A classic example is doing specific processing on some elements of a polymorphic data structure. Let's look at an example. Suppose we have a LIST of items of type POLYGON: + + my_polygons: LIST [POLYGON] + +POLYGONs could be of many specific types, and one of those could be RECTANGLE. Suppose too that we want to print the measurements of the diagonals of all the RECTANGLEs in the list. Class RECTANGLE might have a query diagonal returning such a measurement, but POLYGON would not, for the reason that the concept of diagonal is not meaningful for all POLYGONs, e.g., TRIANGLEs. + +As we traverse the list we would use assignment attempt to try to attach each POLYGON to a variable typed as RECTANGLE. If successful, we can print the result of the application of diagonal. + + l_my_rectangle: RECTANGLE + + ... + from + my_polygons.start + until + my_polygons.exhausted + loop + l_my_rectangle ?= my_polygons.item + if l_my_rectangle /= Void then + print (l_my_rectangle.diagonal) + print ("%N") + end + my_polygons.forth + end + +The '''attached syntax''' allows us to check both attached status and type, and provides us with a fresh local variable when appropriate: + + from + my_polygons.start + until + my_polygons.exhausted + loop + if attached {RECTANGLE} my_polygons.item as l_my_rectangle then + print (l_my_rectangle.diagonal) + print ("%N") + end + my_polygons.forth + end + +As with the other examples of the '''attached syntax''', it is no longer necessary to make a declaration for the local variable, in this case l_my_rectangle. + + +==More about CAPs== + +===Use of check instructions=== + +In void-safe mode, the compiler will accept code that it can prove will only apply features to attached references at runtime ... and you help this process along by using the tools of void-safety, like attached types and CAPs. On the other hand, the compiler will reject code that it cannot guarantee is void-safe. Sometimes this may cause you a problem. There may be subtle situations in which you feel quite certain that a section of code will be free of void calls at runtime, but the compiler doesn't see it the same way, and rejects your code. In cases like this, you can usually satisfy the compiler by using check instructions. + +Technically speaking, check instructions are not CAPs. But they are useful in cases in which an entity is always expected to be attached at a certain point in the code. In the following example, the attribute my_detachable_any is detachable. But at the particular point at which it is the source of the assignment to l_result, it is expected always to be attached. If it is not attached at the time of the assignment, and therefore l_result becomes void, then an exception should occur. The check instruction provides this behavior. + +The following sample shows the check instruction at work. There are reasons why this is not the best use use of check in this case, and we will discuss that next. + + + -- A not-so-good example of using check. + + my_detachable_any: detachable ANY + ... + my_attached_any: ANY + local + l_result: like my_detachable_any + do + l_result := my_detachable_any + check + attached l_result + end + Result := l_result + end + + +Here the assertion in the check guarantees that l_result is attached at the time of its assignment to Result. If my_detachable_any is ever not attached to an object, then an exception will be raised. + +So what's wrong with the sample above? It would be fine in ''workbench'' code, but what happens if the code is in ''finalized'' mode, in which assertions are typically discarded? + +The answer is that the check in the sample above would no longer be effective, and the resulting executable would no longer be void-safe. + +The solution to this problem is found in a different form of the check instruction. Consider the same example, but this time using check ... then ... end: + + + -- A better way of using check. + + my_detachable_any: detachable ANY + ... + my_attached_any: ANY + do + check attached my_detachable_any as l_result then + Result := l_result + end + end + + +Here, in the improved version of the example, the check ... then ... end is used along with the attached syntax. This streamlines the code a bit by eliminating the need to declare a separate local entity, while achieving the same effect as the previous example. If my_detachable_any is attached at runtime, then the temporary variable l_result is created and attached to the same object. Then the body of the check ... then ... end is executed. If my_detachable_any is not attached, an exception occurs. + +Another important benefit, one that solves the problem with the original example, comes from the way in which check ... then ... end is handled by the compiler. The check ... then ... end form '''is always monitored, even if assertion checking is turned off at all levels''', as is usually done in finalized code. + +===Choosing CAPs versus the Attached Syntax=== + +The attached syntax is convenient because it can check attached status and deliver a new local variable at the same time. But there are cases in which you might choose instead to define a local variable and use a CAP. Suppose you had code acting on several similar and detachable expressions, and you use the attached syntax in each case: + + foobar + do + if attached dictionary_entry ("abc") as l_abc then + l_abc.do_something + end + if attached dictionary_entry ("def") as l_def then + l_def.do_something + end + if attached dictionary_entry ("ghi") as l_ghi then + l_ghi.do_something + end + end + +This routine causes three local variables to be allocated for the duration of routine foobar, one each for l_abc, l_def, and l_ghi. And it is no better to do this: + + foobar + do + if attached dictionary_entry ("abc") as l_entry then + l_entry.do_something + end + if attached dictionary_entry ("def") as l_entry then + l_entry.do_something + end + if attached dictionary_entry ("ghi") as l_entry then + l_entry.do_something + end + end + +Even though the names are the same, still three separate local variables are allocated for foobar. + +In cases like this, you could effect a minor performance improvement by declaring one local variable and reusing it. In the following code, only one local variable is used and access to it is protected by the CAP if l_entry /= Void then. + + foobar + local + l_entry: like dictionary_entry + do + l_entry := dictionary_entry ("abc") + if l_entry /= Void then + l_entry.do_something + end + l_entry := dictionary_entry ("def") + if l_entry /= Void then + l_entry.do_something + end + l_entry := dictionary_entry ("ghi") + if l_entry /= Void then + l_entry.do_something + end + end + + +==Stable attributes== + +Remember that stable attributes are actually detachable attributes, with the difference that they can never be the target of an assignment in which the source is Void or anything that could have a value of Void. + +Stable attributes are useful in situations in which there are valid object life scenarios in which some particular attribute will never need an object attached, or will only need an object attached late in the scenario. So in this case, the attribute is used only under certain runtime conditions. Declaring these attributes as stable eliminates the need to make attachments during object creation. Yet once needed, that is, once the attribute is attached, it will always be attached. + +Also, you should remember that unlike other attributes, you can access stable attributes directly in a CAP: + + my_stable_attribute: detachable SOME_TYPE + note + option: stable + attribute + end + + ... + + if my_stable_attribute /= Void then + my_stable_attribute.do_something + end + + ... + + +{{SeeAlso| [[Void-safety: Background, definition, and tools#Types as "attached" or "detachable"|Types as "attached" or "detachable"]].}} \ No newline at end of file diff --git a/documentation/18.11/eiffel/Language_reference/void-safe-programming-eiffel/index.wiki b/documentation/18.11/eiffel/Language_reference/void-safe-programming-eiffel/index.wiki new file mode 100644 index 00000000..d819899f --- /dev/null +++ b/documentation/18.11/eiffel/Language_reference/void-safe-programming-eiffel/index.wiki @@ -0,0 +1,23 @@ +[[Property:link_title|Void-safe programming]] +[[Property:title|Void-safe programming in Eiffel]] +[[Property:weight|10]] +[[Property:uuid|a03568e8-eb79-70d7-04a3-6fd3ed7ac2b3]] +=Void-safe software development using Eiffel: introduction= + +When you develop software in Eiffel, you can be assured (at compile time) that your system will not attempt (at run time) to apply a feature to a void reference -- or, in the terminology of other languages such as C, "dereference a null pointer". + +Throughout the history of Eiffel, new capabilities -- agents, the SCOOP concurrency mechanism and many others -- have added considerable expressive power to the languag,e while causing minimum impact on existing software. Void-safe Eiffel is such an innovation, which instead of adding new mechanisms ''removes'' a major source of instability in programs, present in all other major languages: null-pointer dereferencing. To say that Eiffel is void-safe means that such catastrophic yet common errors simply will not occur. + +There is in fact no need to speak of "void-safe Eiffel". The language is just Eiffel... and it is void-safe, just as it is statically typed. We still occasionally refer to "Void-safe Eiffel" simply because until 2005 or so Eiffel was not void-safe (it had to start somewhere), and you may still encounter older documentation that talks about "calls on void targets" (null-pointer dereferences). But in today's Eiffel such an event is impossible. + +The rest of this chapter explains void safety: + +# How is void-safety defined? +# What are the specific elements of the mechanism? +# How do these relate to Eiffel before void-safety? +# What do I need to know to produce standard Eiffel software? +# What do I need to know to convert my existing systems to be standard? + + + + diff --git a/documentation/18.11/eiffel/Language_reference/void-safe-programming-eiffel/void-safety-background-definition-and-tools.wiki b/documentation/18.11/eiffel/Language_reference/void-safe-programming-eiffel/void-safety-background-definition-and-tools.wiki new file mode 100644 index 00000000..4245f60c --- /dev/null +++ b/documentation/18.11/eiffel/Language_reference/void-safe-programming-eiffel/void-safety-background-definition-and-tools.wiki @@ -0,0 +1,287 @@ +[[Property:link_title|Background and tools]] +[[Property:title|Void-safety: Background, definition, and tools]] +[[Property:weight|0]] +[[Property:uuid|689f62b2-5675-5ab6-cd47-d891cf3d484d]] +=Background= + +The primary focus of Eiffel is on software quality. Void-safety, like static typing, is another facility for improving software quality. Void-safe software is protected from run time errors caused by calls to void references, and therefore will be more reliable than software in which calls to void targets can occur. The analogy to static typing is a useful one. In fact, void-safe capability could be seen as an extension to the type system, or a step beyond static typing, because the mechanism for ensuring void-safety is integrated into the type system. + +==Static typing== + +You know that static typing eliminates a whole class of software failures. This is done by making an assurance at compile time about a feature call of the form: + + x.f (a) + +Such a feature call is judged acceptable at compile time only if the type of x has a feature f and that any arguments, represented here by a, number the same as the formal arguments of f, and are compatible with the types of those formal arguments. + + +In statically typed languages like Eiffel, the compiler guarantees that you cannot, at run time, have a situation in which feature f is not applicable to the object attached to x. If you've ever been a Smalltalk programmer, you are certainly familiar with this most common of errors that manifests itself as "Message not understood." It happens because Smalltalk is not statically typed. + +==Void-unsafe software== + +Static typing will ensure that there is some feature f that can be applied at run time to x in the example above. But it does not assure us that, in the case in which x is a reference, that there will always be an object attached to x at any time x.f (a) is executed. + +This problem is not unique to Eiffel. Other environments that allow or mandate reference semantics also allow the possibility of void-unsafe run time errors. If you've worked in Java or .NET you may have seen the NullReferenceException. Sometimes you might have experienced this rather poetic sounding message: "Object reference not set to an instance of an object". In Eiffel you would see "Feature call on void target". All these are the hallmarks of run time errors resulting from void-unsafe software. + +{{note|If you need a review of difference between reference types and expanded types in Eiffel, see [[ET: The Dynamic Structure: Execution Model|the chapter of the Eiffel Tutorial dedicated to the Eiffel execution model]]. }} + +Of course this is not an issue with instances of expanded types, because these instances are indeed "expanded" within their parent objects. But we could not imagine a world with expanded types only. References are important for performance reasons and for modeling purposes. For example, consider that a car has an engine and a manufacturer. When we model cars in software, it might be appropriate for engines to be expanded types, as each car has one engine. But certainly the same is not true for manufacturer. Many cars can share, through a reference, a single manufacturer. + +So, references are necessary, but we want them to be trouble free. + +==Void-safe software== + +Void-safe software, then, is software in which the compiler can give assurance, through a static analysis of the code, that at run time whenever a feature is applied to a reference, that the reference in question will have an object attached. This means that the feature call + + x.f (a) + +is valid only if we are assured that x will be attached to an object when the call executes. + + +{{info|This validity rule is called the '''Target rule''', validity code VUTA, and is the primary rule for void-safety. In the following discussion, you will see that other validity rules are involved, too. You can see the formal definition of all validity rules in the [http://www.ecma-international.org/publications/standards/Ecma-367.htm ISO/ECMA standard document] available online. }} + + +Once we have committed ourselves to this validity rule, we must have a strategy for complying with the rule. + +=Elements of the void-safe strategy= + +Here are the tools of void-safe trade. They will each be addressed in more detail throughout the documentation that follows. As you look at these elements it helps to try to think about things from the compiler's viewpoint ... after all, it is the compiler that we expect to give us the guarantee that our code is indeed void-safe. + +First let's look at a couple of approaches that won't work. + +It might occur to us that we could enforce compliance with the target rule by simply eliminating the concept of void references. But this would not be practical. Void is a valuable abstraction that is useful in many situations, such as providing void links in structures. So, we must keep void ... but we want to keep it under control. + +Another thought might be that we could just have the compiler do all the work for us. But would be impossibly time consuming for the compiler to investigate every conceivable execution path available to a system to make certain that every possible feature call was made on an attached reference. + +So, all of this boils down to the fact that we have to take some actions that help the compiler along. That's what the following are about. + +==Certified Attachment Patterns (CAPs)== + +We know that in the context of certain code patterns, it is clear that it would be impossible for a reference to be void. These patterns are identified and we call them CAPs, short for Certified Attachment Patterns. Here is a very straightforward example expressed in a syntax that should be familiar to all Eiffel developers: + + if x /= Void then +-- ... Any other instructions here that do not assign to x + x.f (a) + end + +Here a check is made to ensure x is not void. Then as long as no assignments to x are made in the interim, a feature f can be applied to x with the certainty that x will be attached at the time ... and importantly, this can be determined at compile time. So, we say that this code pattern is a CAP for x. + + +It is important to understand that in this example (and with other CAPs), x is allowed to be a local variable or formal argument only. That is, x may not be an attribute or general expression (with one exception which we will see [[#Stable attributes|below]]). Direct access to class attribute references cannot be allowed via a CAP due to the fact that they could be set to void by a routine call in some execution path invoked by the intervening instructions or possibly even different process thread. In a later [[Void-safety: Background, definition, and tools#Types as "attached" or "detachable"|section]], we well see that this is not quite such a limitations as it may appear at this point. + + +{{note|You will find more useful information about CAPs in [[Creating a new void-safe project#More about CAPs|More about CAPs]]. Learn how certain code patterns are determined to be CAPs in [[What makes a Certified Attachment Pattern]]. }} + + +==The ''attached syntax'' (object test)== + +For the purposes of void-safety, the '''attached syntax''' does double duty for us. It allows us to make certain that a reference is attached, and it provides us a safe way to access objects that are attached to class attributes. + +We noted earlier that this code + + if x /= Void then +-- ... Any other instructions here that do not assign to x + x.f (a) + end + +creates a CAP for feature calls on x, but only if x is a local variable or a formal argument. + +By using the '''attached syntax''', we can perform an '''object test''' on a variable. That is, the attached syntax is a BOOLEAN expression which provides an answer to the question "Is x attached to an object?" At the same time, if indeed x is attached to an object, the attached syntax will deliver to us a fresh local variable, also attached to x's object, on which we can make feature calls. + + if attached x as l_x then + l_x.f (a) + end + +In the example above, x is tested to make certain that it is attached. If so, the new local l_x becomes attached to the same object as x. And so the object can be used safely even if x is a class attribute. So, the attached syntax, is really another CAP, because it provides a clearly verifiable place for the application of features to targets that are guaranteed not to be void. + + +{{note|The attached syntax has other syntax variations as well as other uses. These will be discussed [[Creating a new void-safe project#More about the attached syntax|later]]. }} + + +One way to make sure we comply with the target rule would be always use a CAP or the attached syntax every time we want to apply a feature to a referenced object. That might work, but it falls among the impractical approaches to the problem ... it would break a very high percentage of existing Eiffel code, not to mention cluttering things up quite a bit. + +==Types as "attached" or "detachable"== + +Rather than trying to protect every feature call, Eiffel allows us to declare any variable as being of an '''attached type'''. This is an important extension to the Eiffel type system. + +In Eiffel prior to the introduction of void-safe facilities, any reference variable could be set to Void. So, all variables were considered '"detachable"'. + +The current standard Eiffel supports a mixture of '''attached''' and '''detachable''' types. When a variable is declared of an attached type, as in the following example, then the compiler will prevent it from being set to Void or set to anything that can be set to Void. + + + my_attached_string: attached STRING + + +It is easy to imagine that the more declarations are of attached types, the easier it will be to guarantee that a call to a void target cannot take place at run time. In fact, if every declaration was guaranteed to be of an attached type, then that would be all that was needed to satisfy the Target rule. + +However, it wouldn't be workable to have only attached types, because sometimes it's important to allow references to have a value of Void. + +When it is necessary to allow Void as a value, a declaration can use the ''detachable mark'' as in the following. + + my_detachable_string: detachable STRING + + + +This doesn't mean that on every declaration you must put either an ''attached mark'' or a ''detachable mark''. Declarations that are unmarked are allowed. If a declaration contains neither '''attached''' nor '''detachable''', then it is assumed to be '''attached'''. + +In Eiffel then, all declarations will have types that are either '''attached''' or '''detachable'''. As a result, we need only use CAPs and the attached syntax with detachable types. So the important thing to remember is that ''direct access to class attributes of detachable types is never void-safe.'' + +===Attachment and conformance=== + +The distinction between attached and detachable types results in a small but important addition to the rules of conformance. Because variables declared as attached types can never be void, then it is important not to allow any assignment of a detachable source to an attached target. However, assigning an attached source to a detachable target is permissible. The following code shows both cases (as described earlier, class types are attached by default). + + my_attached_string: STRING + my_detachable_string: detachable STRING + + ... + + my_attached_string := my_detachable_string -- Invalid + my_detachable_string := my_attached_string -- Valid + + + +==Initialization rule== + +If we have attached types, then we can assume variables declared of these types, once attached, will always be attached. But how do they get attached in the first place? That's what the initialization rule is all about. + +The rule says that at any place in which a variable is accessed, it must be '''properly set'''. A variable's being properly set has a precise, but not particularly simple definition in the Eiffel standard. + + +{{info|You can find the formal definition of the '''Variable initialization rule''', validity code VEVI, and its related concepts such as '''properly set''' variables in the [http://www.ecma-international.org/publications/standards/Ecma-367.htm ISO/ECMA standard document]. }} + + +Still, it's not too hard to understand the basics of initializing variables of attached types: + +* For the initialization of attributes of a class, we can apply a rule similar to that of the initial evaluation of class invariants ... that is, everything must be in order upon completion of a creation procedure. If a class attribute is of an attached type, then each of the class's creation procedures is responsible for making sure that the attribute is attached to an object upon its completion. + +* A local variable is considered properly set if it is initialized at some point '''preceding''' its use in any execution path in which it is used. So immediately after its create instruction, the local variable would be considered properly set. But if the create occurred in the then part of an if instruction, the local variable would not be properly set in the else part of that same if instruction: + + + my_routine + -- Illustrate properly set local variable + local + l_my_string: STRING + do + if my_condition then + create l_my_string.make_empty +-- ... l_my_string is properly set here + else +-- ... l_my_string is not properly set here + end + end + + +* A variable is considered properly set if it is '''self-initializing'''. What it means to be self-initializing is explained below. + +==Self-initializing attributes== + +A self-initializing attribute is guaranteed to have a value when accessed at run time. Declarations of self-initializing attributes are characterized by the use of the code that follows the attribute keyword. The code is executed to initialize the attribute in the case that the attribute is accessed prior to being initialized in any other way. + +So, self-initializing attributes are ordinary attributes, with the restriction that they are of both ''attached'' types and ''reference'' types (i.e., not expanded types or constants). Self-initializing attributes still can be, and typically will be initialized in the traditional ways. The difference is that the code in the attribute part serves as a kind of safety net guaranteeing that a self-initializing attribute will never be void, even if it is accessed prior to being initialized by one of the traditional means. + + + value: STRING + attribute + create Result.make_empty + end + + +In the example above, the attribute value will be attached to an object of type STRING, in fact, the empty string, if no other initialization occurs before the first access of value. + +==Rule for conformance== + +You will remember that the Eiffel type system dictates that an assignment instruction: + + x := y + +is valid only if the type of y is '''compatible''' with the type of x. Compatibility, in turn, means either '''conversion''' or '''conformance'''. + +The fact that all types are either '''attached''' or '''detachable''' adds another dimension to rule for conformance: +*If x is of an attached type, then y must be of an attached type. +This prevents us from circumventing attached status at run time. If x is of a detachable type, then y could be either a detachable or attached type. + +The same goes for routine calls. In a call: + + z.r (y) + +where x is the formal argument for r, then if x is of an attached type, then y must be of an attached type. + +==Stable attributes== + +Stable attributes are really stable ''detachable'' attributes, as adding the concept of stability is meaningful only for detachable attributes. Declaring a detachable attribute as stable, means that it behaves like a detachable attribute except that its assignment rules mimic those of attached attributes. In other words, a stable attribute does not need to be attached during object creation the way that attributes declared as attached must. But like attached type attributes, stable attributes can never be the target of an assignment in which the source is Void or a detachable type. + + my_test: detachable TEST + note + option: stable + attribute + end + + +This means that even though stable attributes do not need to be initialized like attributes of attached types, once they are attached to an object, they can never be void again. + +Stable attributes are also interesting in that they are the only exception to the rule given above in the [[Void-safety: Background, definition, and tools#Certified Attachment Patterns (CAPs)|CAPs section]] that stated that direct access to attributes cannot be protected by a CAP. A stable attribute can be used under the protection of a CAP. This is because once a stable attribute has an object attached, it can never again be set to Void. So there's no worry about having the attribute's state going unexpectedly from attached to non-attached because of the actions of other routines or threads. + +==Rule for generic parameters== + +Generic classes provide another question. A generic class like + +class + C [G] + ... + +allows us to create a type by providing a specific actual generic parameter for the formal parameter G. + +So, two valid derivations are: + + my_integer_derivation: C [INTEGER] + +and + + my_employee_derivation: C [EMPLOYEE] + + +If class C contains a declaration: + + x: G + +What do we know about the void-safety of x ? + +In the case of the INTEGER derivation above, we know x is safe because INTEGER is an expanded type. But often types like EMPLOYEE will be reference types which could be void at run time. + +'''For a class like C [G], G is considered detachable'''. As a result, because of the [[Void-safety: Background, definition, and tools#Rule for conformance|rule for conformance]], any class will work for an actual generic parameter. That means that both of the following are valid generic derivations: + + + my_detachable_string_derivation: C [detachable STRING] + + my_attached_string_derivation: C [attached STRING] + + +If C contains a declaration x: G, the application of features to x must include verification of attachment (CAPs, attached syntax, etc). + +Constrained genericity can be used to create generic classes in which the generic parameter represents an attached type. If class C had been defined as: + +class C [G -> attached ANY] + ... + +then x in this class G represents an attached type. Consequently, the actual generic type in any derivation must be attached ... and feature calls on x are safe. + +==Rule for ARRAYs== + +The rule for generic parameters applies to all generic types ... except ARRAYs. In the typical creation of an ARRAY, we would provide a minimum and maximum index. + + my_array: ARRAY [STRING] + + ... + + create my_array.make (1, 100) + +During creation, an area to store the appropriate number of entries is also created. And depending upon the actual generic parameter, these entries are either objects for expanded types or references for reference types. + +In the case of an actual generic parameter of an attached reference type, all the elements must be attached to instances of type during the creation of the ARRAY. The make procedure would not do this. Creation of an ARRAY in which the actual generic parameter is attached must be done using the make_filled creation procedure. + + create my_array.make_filled ("", 1, 100) + +The first argument is an object of the actual generic type, in this case an empty STRING. Every entry in the newly created ARRAY will be initialized to reference this object. + + +For more detail on void-safe use of arrays and other generic classes, see the section: [[Creating a new void-safe project#Using generic classes|Using generic classes]]. diff --git a/documentation/18.11/eiffel/Language_reference/void-safe-programming-eiffel/what-makes-certified-attachment-pattern.wiki b/documentation/18.11/eiffel/Language_reference/void-safe-programming-eiffel/what-makes-certified-attachment-pattern.wiki new file mode 100644 index 00000000..74d20a44 --- /dev/null +++ b/documentation/18.11/eiffel/Language_reference/void-safe-programming-eiffel/what-makes-certified-attachment-pattern.wiki @@ -0,0 +1,182 @@ +[[Property:title|What makes a Certified Attachment Pattern]] +[[Property:weight|8]] +[[Property:uuid|1a20197d-5a88-59c3-9a04-512399125661]] + +==A little background on CAPs== + +Certified Attachment Patterns (CAPs) were described in the section on [[Void-safety: Background, definition, and tools#Certified attachment patterns (CAPs)|void-safety tools]]. To review, a CAP is a code pattern for a certain expression, say exp of a detachable type that ensures that exp will never have a void run-time value within the covered scope. + +A simple example is the familiar test for void reference: + + if l_x /= Void then + l_x.do_something -- Valid for formal arguments, local variables, and stable attributes + end + +We know that after the explicit check to make sure l_x is not Void, that the feature application l_x.do_something is void-safe. +Of course, you should remember from previous discussions that l_x must be a local variable, a formal argument, or a [[Void-safety: Background, definition, and tools#Stable attributes|stable attribute]]. + +When void-safety was first envisioned for Eiffel, it was intended that individual CAPs would be proven or certified and documented. This would produce a "catalog" of CAPs. + +What happened instead is that the members of the Eiffel standard committee have been able to produce and publish as part of the [http://www.ecma-international.org/publications/standards/Ecma-367.htm standard] a definition of the nature of a CAP from which a determination can be made as to whether a particular code pattern is or is not a CAP. + +The definition in the standard document is not easily readable by most developers. So, in this documentation, you will see various examples of CAPs and the rationale behind them. + + +==The standard CAP definition== + +The Eiffel standard (2nd edition, June 2006) defines a CAP as follows: +---- +'''''A Certified Attachment Pattern (or CAP) for an expression exp whose type is detachable is an occurrence of exp in one of the following contexts: ''''' + + +'''''1. exp is an Object-Test Local and the occurrence is in its scope. ''''' + +'''''2. exp is a read-only entity and the occurrence is in the scope of a void test involving exp.''''' +---- + +The terminology used in the definition is precise. For example, terms like "read-only entity" and "scope of a void test" have specific meanings that are supported by their own definitions in the standard. + +Still, the standard does contain informative text that gives us a guideline that a CAP is a scheme to ensure that a particular expression of a detachable type will never have void run-time value in the scope covered by the CAP. + +The discussion here will follow that guideline, and, as such, will be less formal (and consequently less precise) than that in the standard, and is intended to be a practical guide. Of course, the [http://www.ecma-international.org/publications/standards/Ecma-367.htm standard document] is available for download if you wish to investigate the specifics. + + +==CAP-able expressions== + +In the first context in the definition above, the expression exp can be an '''Object-Test Local'''. An Object-Test Local is the identifier specified for a fresh local entity in an '''object test'''. Remember, object tests are coded using the [[Void-safety: Background, definition, and tools#The attached syntax (object test)|attached syntax]]. + + attached x as l_x + +In the object test expression above, the identifier '''l_x''' is an Object-Test Local. + +In the second context, the expression can be a '''read-only entity'''. Read-only entities are: +# Constant attributes +# Formal arguments +# Object-Test Locals +# Current + +Additionally, the Eiffel Software compiler allows for [[Void-safety: Background, definition, and tools#Stable attributes|stable attributes]] and local variables to be protected by a CAP. + +===Stable attributes=== + +Stable attributes are the only class attributes which are CAP-able. This is because stable attributes, once attached at run-time, can never have a void value again. So, you use stable attributes safely by using them under the protection of a CAP. Consider this stable attribute: + + my_stable_string: detachable STRING + note + option: stable + attribute + end + +The detachable attribute my_stable_string, because it is stable, is not required to be initialized during the creation of instances of the class in which it is a feature. That means that for each instance, my_stable_string can be initialized later during the instance's life-cycle or not at all. But because it is detachable, my_stable_string cannot be accessed in any context in which it cannot be determined that it is currently attached. For ordinary attributes, this means either using an object test and accessing the object through an object test local, or using using a local variable under the protection of a CAP. + +Stable attributes however, can be used directly in a CAP, as shown below: + + + if my_stable_string /= Void then + my_stable_string.append ("abc") -- Valid + ... + + +So using stable attributes can reduce the need to initialize rarely used attributes, and the need to code object tests. + +===Local variables=== + +Local variables can be used in a CAP as long as they are not the target of an assignment whose source is Void or some expression which could possibly be void. + +So, for a local variable l_string, the following is valid: + + local + l_string: detachable STRING + do + if l_string /= Void then + l_string.append ("abc") -- Valid + ... + + +But, if l_string had been a target of an assignment in which the source could possibly have been void, then it could no longer be guaranteed that l_string is not void. So, assuming that my_detachable_string is an attribute declared as type detachable STRING, the second application of append in this example would be invalid: + + + local + l_string: detachable STRING + do + if l_string /= Void then + l_string.append ("abc") -- Valid + l_string := my_detachable_string + l_string.append ("xyz") -- Invalid: my_detachable_string might have been void + ... + + +==Common CAPs== + +We've already seen the simple test for void as a CAP: + + local + l_str: detachable STRING + + ... + + if l_str /= Void then + l_str.append ("xyz") -- Valid + end + + +Additionally, a creation instruction can serve as a CAP. After the execution of a creation instruction, the target of the creation instruction will be attached: + + local + l_str: detachable STRING + do + create l_str.make_empty + l_str.append ("xyz") -- Valid + ... + + + +==Less obvious cases== + +There are some situations that constitute CAPs that we might not think of immediately. + +For example, the case of the non-strict boolean operator and then: + + if x /= Void and not x.is_empty then -- Invalid + ... + + if x /= Void and then not x.is_empty then -- Valid + ... + +Assuming that x is CAP-able, the first line of code is invalid because the expression x.is_empty could always be evaluated even in the case in which x is void. + +In the second line of code, the non-strict boolean is used, guaranteeing that x.is_empty will not be evaluated in cases in which x is void. Therefore, x.is_empty falls within the scope of the void test on x. + +In contracts, multiple assertion clauses are treated as if they were separated by and then. This allows preconditions like the one in the following example: + +my_routine (l_str: detachable STRING) + require + l_str /= Void + not l_str.is_empty -- Valid + ... + + +Another not-so-obvious CAP is related to the use of the logical implication: + + local + l_str: detachable STRING + do + if l_str /= Void implies some_expression then + ... + else + l_str.append ("xyz") -- Valid + end + + + +==The bottom line on CAPs== + +In summary, CAPs provide void-safe protection for certain types of detachable expressions. + +Possibly the characteristic of CAPs which is most important to developers is whether or not a particular CAP is supported by the compiler. In other words, from the developers viewpoint, the only opinion that matters in the argument of whether a particular pattern constitutes a CAP is that of the compiler. + +If the compiler can provide assurance that a certain code pattern guarantees void-safe protection, then the developer will have that pattern available as a CAP. Likewise, even if a pattern can be shown logically to be a CAP, but for some reason it is not supported by the compiler, then that pattern will not available as a CAP and the compiler will not allow its use. + + + + diff --git a/documentation/18.11/eiffel/Overview/common-myths-and-misconceptions-about-eiffel.wiki b/documentation/18.11/eiffel/Overview/common-myths-and-misconceptions-about-eiffel.wiki new file mode 100644 index 00000000..cc114aed --- /dev/null +++ b/documentation/18.11/eiffel/Overview/common-myths-and-misconceptions-about-eiffel.wiki @@ -0,0 +1,80 @@ +[[Property:title|Common myths and misconceptions about Eiffel]] +[[Property:link_title|]] +[[Property:weight|4]] +[[Property:uuid|056c0ab0-8e44-571f-f126-0b1850980754]] +Often, when we speak about Eiffel to prospective users, we hear them repeat misinformation about the method, the language, or the tools. Most of the time, the stories are familiar to us … and untrue. Here are a few of the myths that we hear most often, as recounted and debunked by the series entitled [http://eiffel.com/developers/presentations/ "Where Eiffel Fits"]. + + +==Eiffel is an "academic" language only: ''Whoa, wrong! Twice!''== + +Recently, I was offered the opportunity to speak to a local technology group about Eiffel for Microsoft .Net. The leader of this group is part of a small commercially-oriented software development company. Concerning Eiffel, he said, “All I know about Eiffel is that it’s an academic language.” + +We hear that one a lot … and it’s wrong … in two unrelated ways. + +First, as you should know by now, Eiffel is a framework for software development. It has a full-lifecycle development method. The Eiffel method is supported by a notation we call the Eiffel programming language. The notation just happens to be designed such that when it contains sufficient detail, it can be compiled into a running software system. Additionally, the method and language are supported by a set of tools including an interactive development and compiler. So to refer to Eiffel only as a "language" is to do injustice to the complete framework of which the language is only one part. + +Secondly, I’m not sure what “academic language” means exactly, but if it means only used in an academic setting, or not fit for practical work, then this could not be farther from the truth. It is true that Bertrand Meyer who developed the original Eiffel concepts has academic background and is well-respected in the academic community. It’s also true that many of those Eiffel ideas evolved from work that was done by other academic computer scientists and mathematicians. And it’s true that many colleges and universities use Eiffel to teach the best practices of software development. + +But Eiffel is also used successfully in many commercial and government endeavors. If you have any doubts, pay a visit to [https://www.eiffel.com/company/customers/testimonials/ eiffel.com] and check out the success stories and customers testimonials. + + +==Eiffel is not for doing "real" work: ''That's a joke, right?''== + +Occasionally we’ve heard people say that Eiffel is only suitable for building “toy” systems. + +This is similar to the "academic language" argument and is just as false. + +In actuality, we see Eiffel being used often in situations in which other technologies fail. If anything it is the other commonly used technologies that tend to break down under stress. + +We see Eiffel being used instead of other technologies for systems in which scalability and reliability are essential. + +One of our customers is an organization that has developed a payroll system using Eiffel that every week pays over two hundred thousand employees in twenty thousand different institutions … the people in this organization would assure you that Eiffel is indeed industrial grade. + + +==Not many people are using Eiffel: ''You wouldn't want to share an elevator with them all!''== + +The answer to this one depends a bit upon your frame of reference. Some time ago Microsoft estimated that there were twenty million Visual Basic programmers world wide. + +If this is true, then relatively speaking, we have to admit that Eiffel’s market share ''is'' considerably smaller than that of Visual Basic. + +Despite that, it’s not correct to say that not many people use Eiffel. Eiffel licenses world wide number in the tens of thousands. If you use Eiffel, you are not alone. These license-holders have formed a lasting worldwide quorum. Many world-class organizations are committed now, and will continue to be committed to the Eiffel framework. There is support through your maintenance contract with Eiffel Software. Help and information are available online in the form of the [https://www.eiffel.com/company/customers/ Eiffel Software users’ list] and websites like [http://community.eiffel.com/room/ EiffelRoom]. + +Eiffel Software's dual licensing model gives developers the opportunity to learn Eiffel without a great initial financial commitment. + +So, don’t worry about it, plenty of people use Eiffel … and those numbers are increasing constantly. + + +==If we use Eiffel, we may not be able to find qualified programmers: ''Gimme a break.''== + +Through the years some potential Eiffel users have expressed to us a concern that if they embrace Eiffel, that they may not be able to find a sufficient number of qualified developers. + +This is of course incorrect. + +First, almost all Eiffel people were proficient in some other technology before they became Eiffel people. It turns out that this really works to your advantage. You see, Eiffel people want to stay Eiffel people. So an Eiffel programmer on the job market will be searching for an Eiffel position first, and would probably rather have a root canal than to go back to working in his or her previous technology. + +Additionally, it is important also to understand that Eiffel developers are easy to create. Because Eiffel is simple, clean, and elegant, it doesn’t take long to get people going with it. I teach a five-day course that contains fifteen programming exercises. Each time I’ve taught the course, almost every student has finished every exercise. Students leave with a good foundation for how to begin saving time and money for their organization by constructing quality software with Eiffel. These people can be fluent in Eiffel in as little as a couple of months. This can be contrasted with the other extreme ... a well-known Microsoft Windows expert told me a couple of years ago that he estimates it to take 5 to 7 years to become truly fluent in C++/COM programming on Windows. Programmers who are proficient in other technologies often experience Eiffel as a breath of fresh air. + + +==Eiffel might not be around in five/eight/ten (choose one) years: ''Better recalibrate your crystal ball, Nostradamus!''== + +I think the first time I heard this one, it was about 1989. + +And of course, I’ve heard it many times in the years since. + +And of course, it’s not true. + +Eiffel is more complete and functionally superior in most ways to every other commercially viable software development technology … and there are enough people around who recognize this (that quorum of users I mentioned earlier) to ensure that Eiffel will be around for a long time to come. + +It’s possible that twenty-five years from now, there will be a significantly better software engineering idea … but certainly there hasn’t been anything that’s come close since Eiffel’s original design in 1985. In most areas, other technologies are playing “catch-up” to Eiffel. + +Besides, Eiffel constantly implements refinements and new capabilities with minimal impact on existing software. [[Void-safe programming in Eiffel|Void-safe programming]] is an excellent example of this. + +You can get a feel for this issue by watching [http://channel9.msdn.com/posts/Charles/Emmanuel-Stapf-Eiffel-and-Contract-Oriented-Programming/ this video on Microsoft Developers Network Channel9]. Here you'll see Emmanuel Stapf, an engineer at Eiffel Software, speak with Mads Torgersen, one of Microsoft's C# language designers. You'll hear how Eiffel stays fresh and continues to set a technological standard worthy of the aspirations of other technologies. + +So, don’t worry about it. Eiffel will be here. + + + + + + diff --git a/documentation/18.11/eiffel/Overview/eiffel-two-minute-fact-sheet.wiki b/documentation/18.11/eiffel/Overview/eiffel-two-minute-fact-sheet.wiki new file mode 100644 index 00000000..ecd37799 --- /dev/null +++ b/documentation/18.11/eiffel/Overview/eiffel-two-minute-fact-sheet.wiki @@ -0,0 +1,97 @@ +[[Property:title|Two-Minute fact sheet]] +[[Property:weight|0]] +[[Property:uuid|f672bfb8-ddea-beb1-eaa6-e374a6a6bc92]] +If you are both curious about Eiffel and in a hurry, take a couple of minutes to read these facts about Eiffel. If anything here seems too good to be true, please suspend your disbelief. Press on to the more detailed documentation for the rationale, and our success stories for the evidence behind these facts. + +===Eiffel is the most comprehensive approach to the construction of successful object-oriented software.=== + +Software produced with Eiffel is typically: + +*Cheaper -- You spend less on development, debugging, maintenance +*Better -- You get the bugs before they get you +*Shorter time-to-market -- You release quality products ahead of your competitors +*Easier -- In every way: understanding, maintenance, reuse, and extension + +===Systems developed using Eiffel can be made portable across major industry platforms.=== + +*Windows NT/2000/XP/Vista including CLS compliance on Microsoft .NET +*Major Unix versions +*Macintosh OS X +*Linux +*OpenVMS + +===Eiffel is the only approach that covers analysis, design, implementation and maintenance in a single framework.=== + +Eiffel consists of: + +====The Eiffel Method==== + +*Is Based on a small number of powerful ideas from computer science and software engineering +**An example of these is Design by Contract +***Defines a software system as a set of components interacting through precisely specified contracts +***Contracts are active and enforceable throughout the life-cycle +***Design by Contract promotes: +****Precise software specification +****Software reliability +****Safe, effective software reuse +*Uses a "single-product" model +**All life-cycle phases are supported by a single notation +***No need to switch, say, from "analysis language" to "design language" +**Products of all phases are recorded in a single document with multiple views + +====The Eiffel Programming Language==== + +*Exists to express the products of the Eiffel Method +*Supports features not always available in competing technologies +**Contracts and contract monitoring +**Exception handling based on software specification (versus ad hoc try/catch) +**Void-safety: calls on void (null) references are eliminated at compile time +**Inheritance +***Includes multiple and repeated inheritance +***Safe and fully controllable +**Genericity (generic classes), including constrained genericity +**Platform independent concurrency ([[Concurrent programming with SCOOP|SCOOP]]) +*Widely recognized as simultaneously the simplest and most complete implementation of object-oriented concepts +*Is clean, elegant, readable, easy to learn + + +====EiffelStudio and the Eiffel Libraries==== + +*'''EiffelStudio''' +**Runs on all major platforms (of course, it's built with Eiffel) +**Features lightning-fast compilation (Melting Ice Technology) +**Generates lightning-fast executables +***Final compilation generates standard C (MSIL in the case of .NET) +***Speed of executables rivals native C +**Provides multiple views of your product +***Views for different life-cycle phases and developer roles +***Graphical views +**Features automated generation of HTML and XML documentation + +*'''The Eiffel Libraries''' +**Contain rich, time-tested, multi-platform components +**Include facilities for +***GUI building and graphics +***Web +***Networking +***Fundamental algorithms and data structures +***Object persistence and database access +***Multi-threading +***Lexical analysis and parsing +***Interfacing with other technologies + +===Eiffel has a proven track record of successful projects=== + +*Some of the largest successful object-oriented projects ever built, including systems target to: +**Finance and securities +**Education +**Trading +**Manufacturing +**Telecommunications +**Government and national defense +**Science + +For a more detailed overview see [[Invitation to Eiffel (I2E)|An Invitation to Eiffel]] . + + + diff --git a/documentation/18.11/eiffel/Overview/index.wiki b/documentation/18.11/eiffel/Overview/index.wiki new file mode 100644 index 00000000..98bdaaab --- /dev/null +++ b/documentation/18.11/eiffel/Overview/index.wiki @@ -0,0 +1,5 @@ +[[Property:title|Eiffel Overview]] +[[Property:link_title|Overview]] +[[Property:weight|1]] +[[Property:uuid|f65e67ed-0990-4638-b8f8-0fc85c28f0d8]] + diff --git a/documentation/18.11/eiffel/Overview/learning-eiffel.wiki b/documentation/18.11/eiffel/Overview/learning-eiffel.wiki new file mode 100644 index 00000000..53305820 --- /dev/null +++ b/documentation/18.11/eiffel/Overview/learning-eiffel.wiki @@ -0,0 +1,54 @@ +[[Property:title|Learning Eiffel]] +[[Property:weight|3]] +[[Property:uuid|a30e29fe-841d-4634-ded2-88ae1754e5fd]] +If you are new to Eiffel and are interested in learning the technology, you might consider some of the following resources. Remember that Eiffel, unlike other programming languages, is not just a programming language. Instead, it is a full life-cycle framework for software development. As a consequence, learning Eiffel implies learning the Eiffel Method and the Eiffel programming Language. Additionally, the Eiffel development environment EiffelStudio is specifically designed to support the method and language. So having an understanding of the method and language helps you to appreciate the capabilities and behavior of EiffelStudio. + + +=Online presentations= + +Your first stop in getting acquainted with Eiffel might be the collection of [http://eiffel.com/developers/presentations/ online presentations] on the [http://eiffel.com eiffel.com] website. These presentations each usually take less than an hour to view, and give an introduction to Eiffel concepts including Design by Contract, the EiffelStudio development environment, and includes several presentations that describe selected Eiffel features in relation to those of other other development tools. + +=Online documentation set= + +The [http://docs.eiffel.com docs.eiffel.com] site contains the online documentation for the Eiffel method, tools, and language. Within the documentation set are tutorials to help you learn about the Eiffel programming language and tools. + +==The Eiffel Tutorial== + +A [[An Eiffel Tutorial (ET)|tutorial]] that covers the Eiffel Method and much of the Eiffel programming language. + +==The EiffelStudio Guided Tour== + +This [[Introducing EiffelStudio]] page is good way to get a feel for what EiffelStudio can do. + +=Academic materials available online= + +Many colleges and universities use Eiffel to teach "best practices" in software engineering. Often the materials used in courses are available on the worldwide web. For example, the teaching materials for courses at the Swiss Federal Institute of Technology in Zurich are available at [http://se.ethz.ch/teaching/index.html this web address]. + +If you search the web, you can find similar materials at other academic institutions. + +=Learning maps= + +For certain specific areas of learning, the eiffel.com website includes conceptual [http://eiffel.com/developers/learning_maps/ learning maps]. These are graphical maps that link concepts with their relationships. Each concept can have multiple learning resources attached to it. One of the most prevalent types of resources is the "Learnlet", a short online presentation (less than 30 minutes) covering a specific concept. + +=Books= + +To find information about the most up-to-date books about Eiffel, look [[Books about the Eiffel Method and Language|here]]. + +=Examples and sample code= + +Throughout the documentation site, there are many code snippets designed to illustrate certain language features or design principles. For example, the code snippet [[ET: Inheritance#Redefinition|here]] shows the mechanics of redefining an inherited feature. + +In the EiffelStudio distribution you will find a subdirectory "examples" which contains many examples of using Eiffel, primarily with the Eiffel class libraries. + +A third source of examples is the [[Examples]] book in the documentation pages. + +=Eiffel Programming Language Syntax= + +The documentation site includes a summary of the [[Quick reference to the Eiffel programming language|syntax of Eiffel]] the language. This summary is intended to reflect the state of the current official [[ECMA Standard 367|ISO/ECMA Eiffel standard document]]. + +However, usually you will find that there are differences in the syntax supported by EiffelStudio's compiler and that defined in the current standard. The differences between the standard and the EiffelStudio implementation are summarized in the [[EiffelStudio release notes]] and in a [[Differences between standard ECMA-367 and Eiffel Software implementation|documentation page]] that is specific to that purpose. + + + + + diff --git a/documentation/18.11/eiffel/Overview/why-your-next-project-should-use-eiffel.wiki b/documentation/18.11/eiffel/Overview/why-your-next-project-should-use-eiffel.wiki new file mode 100644 index 00000000..753efc42 --- /dev/null +++ b/documentation/18.11/eiffel/Overview/why-your-next-project-should-use-eiffel.wiki @@ -0,0 +1,185 @@ +[[Property:title|Your next project in Eiffel]] +[[Property:weight|1]] +[[Property:uuid|038CDA4A-9ACA-46F6-AC10-06942FAE4529]] +(After an article in the special Eiffel issue of the ''Journal of Object-Oriented Programming'', May 1996.) + + +Over its ten-year life Eiffel has evolved into one of the most usable software development environments available today. Other articles discuss its theoretical contributions. This one addresses a more mundane subject: how practical software projects can benefit, today, from the power of Eiffel. In so doing it will largely rely on published assessments from both Eiffel users and book authors. In fact a quotation from one of the best-known books in the object-oriented field -- ''Object-Oriented Modeling and Design'' by James Rumbaugh and his colleagues, the text that introduced the OMT O-O analysis method -- provides a good start: + +
+''Eiffel is arguably the best commercial object-oriented language available today. [Jim Rumbaugh et al. in Object-Oriented Modeling and Design, Prentice Hall 1988]. '' +
+ + +==What is Eiffel?== + +First we should define what the word "Eiffel" means. If you are thinking "a programming language" you are not wrong (and the preceding quotation shows that you are in good company). The programming language is indeed the most visible part, but it is only a reflection of something broader: a comprehensive approach to the production of quality software. As Richard Wiener wrote: + +
+''Eiffel is more than a language; it is a framework for thinking about, designing and implementing object-oriented software. [Richard Wiener in Software Development using Eiffel: There is life other than C++, Prentice Hall, 1995.] '' +
+ +The Eiffel approach includes a method (a "methodology", as it is sometimes called) based on a number of pervasive ideas such as Design by Contract, seamlessness, reversibility, rigorous architectural rules, systematic use of single and multiple inheritance, static type checking and several others. Besides a method and a language Eiffel also means powerful graphical development environments, such as EiffelStudio, available across a wide number of industry-standard platforms and supporting analysis and design as well as implementation, maintenance and evolution. + +The language itself, indeed (which Wiener calls an elegant and powerful language for object-oriented problem solving") is not just a programming language but extends to the phases of system construction that both precede and follow implementation. This is sometimes hard to accept if you have been raised in the view that software development must involve a sequence of separate steps; that one should initially use an analysis method and then at some point switch to a programming language, with perhaps a design method in-between. This view is detrimental to the software process and to the quality of the resulting product, as it does not support the inevitable back-and-forth hesitations that characterize real software development. + +Wisdom sometimes blooms late in the season. However careful you may have been at the analysis stage, some great ideas will hit you - or your implementers - past the point at which you thought you had all the specifications right. Why renounce the benefit of such belated but valuable ideas? Eiffel and the associated Business Object Notation approach to analysis and design accommodate them naturally, by providing a single conceptual framework from the beginning to the end of the process. + +Here Eiffel does not have much competition. The most bright-eyed Smalltalk or C++ enthusiast would not seriously claim that one can do design, let alone analysis, in his language of choice. And users of any of the popular O-O analysis notations know that at some stage they must stop working on their model and move on to the implementation in some programming language. Eiffel is unique in helping you for all of these tasks, without ever introducing the impedance mismatches that characterize other approaches. + +As a reviewer wrote: + +
+''As a design language, Eiffel continues to be a better model for object- oriented programming than Ada. It is even better than the new Ada 9X standard. [Richard Riehle in HP Professional, October 1994, A Tour of Eiffel.] '' +
+ +==The commercial and political context== + +The next few sections give a glimpse of the technical contributions of Eiffel, or more precisely of what other people have written about them. But of course the best technology in the world requires infrastructure and support to succeed. + +Eiffel has plenty of these. It has been around for more than a decade. Eiffel is available from several commercial and open-source providers. The number of licenses sold is in the tens of thousands. Reusable library classes are in the thousands. + +The platforms covered range from Unix (all of Unix, the famous and the arcane) and Linux to OpenVMS, OS/2, Windows 3. 1, Windows NT, Windows 95/98. + +Particularly impressive is the growth of Eiffel usage in education. Eiffel is quickly becoming the language of choice for teaching modern software technology, including, increasingly, introductory programming. A dozen of excellent textbooks are now available from Prentice Hall, Addison-Wesley, Macmillan and others, with about as many announced just for the coming months. + +It is not just the professors who like the approach. Here is just one typical comment on student reaction, from an institution (Rochester Institute of Technology) having adopted Eiffel as its first-year introductory language on a massive scale: + +
+''We were pleased to discover many of our more skeptical students turning around and admitting that Eiffel was a "fun" language in which to work. [Jim Heliotis in the Proceedings of OOPSLA 95, Experiences teaching objects: A new curriculum for computer science students.] '' +
+ +A Computer World article confirmed the need for Eiffel in training the high-powered software professionals of tomorrow. Quoting Amy Cody-Quinn from Management Recruiters International, the journalist writes + +
+''There is a big problem with people who say they know C++ - but they don't really know how to do objects. If they have Eiffel on their resume, then we know they really have the proper understanding of what they are doing. [Leslie Goff in ComputerWorld, Object Edge, December 18, 1995.] '' +
+ +But it would be a mistake to think of Eiffel as an academic tool. A little-known fact is that some of the biggest object-oriented projects ever undertaken (at least the successful ones - other O-O languages have had their share of large-scale failures) are being done in Eiffel. The hot areas at the moment are banking and the financial industry (in particular some very large derivative trading and investment management systems), telecommunications, health care. These are all areas in which all that counts in the end is quality and time to market, so that projects need to select the best technology available. Quoting from an article by Philippe Stephan, the system architect of such a project (Rainbow, a major derivative trading system built with ISE Eiffel): + +
+''We evaluated three major object-oriented languages for the project - Smalltalk, C++ and Eiffel - and chose Eiffel. [...] Rainbow currently comprises over 400,000 lines of code, for about 3000 classes. [Current figures are way over these mid-1995 counts. ] The developers feel very productive. This was confirmed when Rainbow's financial backers brought in object professionals to audit the project. The auditors evaluated the project during July 1994 and were impressed with the productivity of the Rainbow development group. [Philippe Stephan in Object Magazine, July-August 1995, Building financial software with object technology.] '' +
+ +The development group in question is remarkable for being made only for a third of software professionals. The others are professionals from other disciplines (such as trading and financial analysis), who, Stephan writes, + +
+''can express business concepts in Eiffel because they can focus on design and implementation, rather than struggling with memory management problems and debugging. '' +
+ +The result has received lavish praise from such publications as ComputerWorld and analysts: + +
+''Industry experts briefed on Rainbow said they were impressed with the results. CALFP is "progressive" in [...] committing the organization's mission-critical systems development efforts to this architecture, said Richard Crone, senior manager of financial services at KPMG Peat Marwick in Los Angeles. "What's unique here is that [CALFP is] delivering this system end-to-end using object-oriented technologies", said Henry Morris, a research analyst at International Data Corporation (IDC) in Framingham, Mass. [Thomas Hoffmann in ComputerWorld, May 8, 1995, Object- Oriented financial package tames transactions.]'' +
+ +Along with these Eiffel mega-projects, you will also find myriad smaller endeavors. Many consultants, in particular, have found for themselves the key competitive advantage that they can gain from Eiffel's excellence. In ensuring this spread of Eiffel throughout the industry, the benefit of cheap yet complete environments such as EiffelStudio for Linux has been immeasurable. + +Also crucial to the development of Eiffel has been the neutral status of its definition, now controlled by a consortium of vendors and users, NICE (the Nonprofit International Consortium for Eiffel). NICE has already produced a library standard and expects to produce soon the language standard that should shortly thereafter enjoy a smooth ride through ANSI and other international standards bodies. + +The pace of Eiffel history has been accelerating in the past few months. This has been picked up by many journalists. As Dan Wilder wrote: + +
+''With an open specification for both the language and the kernel libraries, and support from multiple vendors, Eiffel now stands poised to take off. [Dan Wilder in Linux Journal, June 1995, Introduction to Eiffel.] '' +
+ + +==The criteria== + +Eiffel - the method, the language, the environment - is based on a small set of goals, addressing the crucial needs of software quality and productivity. Quoting from an article in ''Byte'' magazine: + +
+''Developers who want an object-oriented language that adheres to the keystone principles of software engineering need look no further than Eiffel. [Peter Varhol in Byte Magazine, February 1996.] '' +
+ +or, as Steve Bilow wrote in a review of Eiffel Software's Melting Ice compiling technology (which he calls "an outstanding marriage between portability and development speed"): + +
+''Eiffel was designed precisely for the purpose of enabling software developers to deliver high quality, reliable, efficient, reusable code. [Steve Bilow in The X Journal, The Eiffel alternative, July-August 1995.]'' +
+ +==Reliability== + +The first goal is reliability. No other approach available today has made the effort to give developers all the tools that they need to produce bug-free software - software that will run without bugs the first time around. Crucial in this effort is the presence of static typing ( ''real'' static typing, not "a little bit typed" as in those languages that still keep C-like type conversions); assertions and the whole mechanism of Design by Contract, on which more than one Eiffel developer has said "this has changed my life" by enabling him or her to specify precisely what the software should do, and to track at run time that it does it; disciplined exception handling; automatic garbage collection, which eliminates a source of horrendous bugs in C++-based environments (and a large part of the code, tedious and error-prone); a clean approach to inheritance; the use of dynamic binding as the default policy, meaning the guarantee that all calls will use the right version of each operation; and the simplicity of the language design, which enables Eiffel developers to know '''all''' of Eiffel and feel in control. + +The role of assertions and Design by Contract is particularly important here. According to the ''Journal of Object-Oriented Programming'': + +
+''The contribution of Eiffel is significant: it shows how invariants, preconditions, and postconditions can be incorporated into a practical developer's view of a class. Wider use of Eiffel [...] will encourage a greater use of simple but powerful mathematics during development. [Richard Mitchell et al. in Journal of Object-Oriented Programming, July-August 1995, As-a: a relationship to support code reuse.] '' +
+ +==Reusability== + +The second goal is reusability. This has become a catchword, but Eiffel is the only approach that has taken this requirement and its consequences all the way to the end. Quoting Roland Racko: + +
+''Everything about [Eiffel] is single-mindedly, unambiguously, gloriously focused on reusability - right down to the choice of reserved words and punctuation and right up to the compile time environment. [Roland Racko in Software Development, December 1994, In praise of Eiffel.] '' +
+ +Eiffel benefits here from being a simple ("but not simplistic", writes Racko) and consistent design, not a transposition from older, unrelated technology. Beyond the language and the environment facilities (such as precompilation), the crucial help to reusability is of course the presence of thousands of high-quality library ''classes'', such as, in EiffelBase (a "Linnaean approach to the reconstruction of software fundamentals"), EiffelNet for client-server communication, EiffelStore for relational and O-O database manipulations, EiffelLex and EiffelParse for lexical analysis and parsing, EiffelMath for object-oriented numerical computation, EiffelVision for portable graphics, WEL (the Windows Eiffel Library) for Windows-specific graphics, EiffelWeb to process forms from the Web, and many others. Not even mentioning quality, the result is probably the biggest repository of object-oriented components available elsewhere. The care that has been applied to the production of these libraries also has considerable pedagogical benefits: the way people learn Eiffel is by learning the libraries - first to use them, then to adapt them if necessary, then to write their own software. + +Part of the single-mindedness mentioned by acko is the emphasis on abstraction. In contrast with, say, Smalltalk, you do not read the source code of a class when you want to use it. This may be fine for a couple dozen classes, but not for a large, powerful library. Eiffel introduces the notion of '''short form''': an abstract version of the class, keeping only the interface information including assertions. This is an ideal tool for documenting classes but also for discussing designs and presenting them to outsiders - managers or customers - who need to know what is going on without getting bogged down in the details. + +Let me mention just one of the unique reusability-supporting features of Eiffel, without which it is, in my experience, impossible to have a long-term reuse effort. Racko again: + +
+''The language's designer [...] recognized that no reusable library is ever perfect and, thus, that libraries are always in flux. So he built a kind of version-control system into the language. Specifically, there are language elements to demarcate obsolete code that is, however, still being supported. When these elements are referenced by someone unaware of such code's obsolescence, the compiler will issue a warning at compile time about the impending doom that awaits persons who continue the referencing. '' +
+ +It is this kind of detail that can make or break the success of reuse in a company. + +==Extendibility== + +Next comes extendibility. With Eiffel, modifying software is part of the normal process. As Philippe Stephan writes of the external audit of his project: + +
+''The auditors rated the responsiveness of the development team as very high. '' +
+ +Chief among the method's support for extendibility is the careful design of the inheritance mechanism. Unlike Smalltalk, which is fatally limited by the absence of multiple inheritance, the Eiffel approach fundamentally relies on multiple inheritance to combine various abstractions into one. As Dan Wilder notes: + +
+''Most object-oriented languages do not attempt multiple-inheritance. The literature is full of elaborate explanations why. This is sad. Eiffel demonstrates that multiple inheritance need not be difficult or complex, and it can also yield some quite practical results. '' +
+ +The approach also enforces a strict form of information hiding, which means that a module (a '''client''' in Eiffel Design by Contract terminology) that uses another's facilities (its '''supplier''') is protected against many of the changes that can be made later on to these facilities. This is essential in preserving the coherent evolution of a large system - and the sanity of its developers. + +==Efficiency== + +Performance is almost as much an obsession in Eiffel as reusability. The software field is still, and will remain for a long time, largely driven by performance considerations. (Do not believe anyone who says that speed does not matter. If we get faster computers, it is to do things faster and especially to do more things - not to use more CPU cycles to run the same old applications at the same old visible speed. ) + +There is no reason whatsoever to leave the mantle of efficiency to the proponents of machine-oriented languages such as C/C++, or to follow the path of Smalltalk which sacrifices performance to object orientation. With Eiffel you can have the best of both worlds. Thanks to a performance-obsessed language design and ten years of research and competition on compiling algorithms, the speed of Eiffel-generated code (in such modes as what is known as "finalization" in Eiffel Software's implementation) is as good as that of hand-produced C code, or better. + +Software producers should stand up to their ideas. That is what we do at Eiffel Software: apart from the run-time engine (a few thousand lines of C), all of our software - thousands of classes, hundreds of thousands of lines - is written in Eiffel, and it runs fast. Typical of the situation is a recent incident with the EiffelLex library: it still had a few C elements, remnants of an earlier design. We rewrote them in Eiffel - for a 30% performance gain. + +Why these gains? The answer is simple. The /C++ approach of doing everything by hand, under tight programmer control, works well for small programs. Similarly, a good secretary has no equivalent for keeping one person's records. But in the same way that no humans can match the performance of a computer for managing, say, the records of a bank or a city, no programmer can beat a sophisticated Eiffel compiler for optimizing a large program. Against the automatic application of inlining, static binding, memory management and other optimizations, the human does not stand a chance. + +To have one's cake and eat it also means not to have to choose between run-time and compilation-time performance. For programmers used to the contrast between a Smalltalk-like style of rapid turnaround and the interminable edit-compile-link cycle of most compiled environment, the following comments by Dan Wilder (in a separate article) will be a shock: + +
+''EiffelStudio uses "melting ice technology", which allows incremental changes to run in an interpreted mode. Only modified classes are recompiled. Changing one class and clicking the Melt button caused only a few seconds of compilation. [...] My test application took 20 seconds to compile from scratch in "melt" mode. [Dan Wilder in Linux Journal, September 1995, Two Eiffel implementations.] '' +
+ +Steve Bilow provides further explanations: + +
+''Based on the observation that software development is an iterative process which is usually focused on constructing systems from code modifications, the folks at Eiffel Software have developed something that they call "Melting Ice Technology". Essentially, this means that when you make a [change] and you want to try it out, you simply "melt" it into the system. You don't need to regenerate a bunch of C code, so your changes are integrated into the system proportionally to the amount of code changed. Even in C and C++, `make` still has to relink. '' +
+ +What this also indicates in passing is the technology choice made by Eiffel Software's implementation and all current implementations: using C as the portable implementation vehicle. By going through C, the compilers gain efficiency and portability. This also makes Eiffel one of the most open environments around; in contrast to the self-centered view that predominates in Smalltalk, Eiffel software is born with a sociable attitude, ready to interface with all kinds of other software written in C or other languages. This, needless to say, is a key to the success of realistic applications. + +==With us, everything is the face== + +A good way to think about Eiffel - the seamlessness of it, the insistence on getting everything right, the conviction that software should be beautiful in and out, specification and implementation - is this little anecdote stolen from Roman Jakobson's Essays on ''General Linguistics'': + +
+''In a far-away country, a missionary was scolding the natives. "You should not go around naked, showing your body like this!". One day a young girl spoke back, pointing at him: "But you, Father, you are also showing a part of your body!". "But of course", the missionary said in a dignified tone; "That is my face". The girl replied: "So you see, Father, it is really the same thing. Only, with us, everything is the face". '' +
+ +So it is with Eiffel too. Everything is the face. + +Hundreds of thousands of people have now been exposed to Eiffel through books, through courses, through hearing about other people's successes, and most importantly (for the most fortunate among them) through using it to complete a project on time, within budget, and to the satisfaction of their customers. Shouldn't your next project use Eiffel too? + + + + diff --git a/documentation/18.11/eiffel/Technical_papers/books-about-eiffel-method-and-language/ecma-standard-367.wiki b/documentation/18.11/eiffel/Technical_papers/books-about-eiffel-method-and-language/ecma-standard-367.wiki new file mode 100644 index 00000000..3c34bf99 --- /dev/null +++ b/documentation/18.11/eiffel/Technical_papers/books-about-eiffel-method-and-language/ecma-standard-367.wiki @@ -0,0 +1,16 @@ +[[Property:title|ECMA Standard 367]] +[[Property:weight|1]] +[[Property:uuid|b49b0949-85fa-31da-555e-003b09f6213e]] +[[Image:ECMA-367 cover small|ECMA-367]] + + +==ECMA Standard 367 -- Eiffel: Analysis, Design, and Programming Language== + +ECMA International + +Standard Eiffel syntax, validity, and semantics are described in this document, which is available [http://www.ecma-international.org/publications/standards/Ecma-367.htm online]. + +ECMA-367 is a specification for the Eiffel programming language. Therefore, it can be useful as a reference, but it is definitely not a tutorial. That said, the document does contain occasional informative text and a general description chapter which can help readers understand the specification. + + + diff --git a/documentation/18.11/eiffel/Technical_papers/books-about-eiffel-method-and-language/eiffel-language.wiki b/documentation/18.11/eiffel/Technical_papers/books-about-eiffel-method-and-language/eiffel-language.wiki new file mode 100644 index 00000000..cb8c1edb --- /dev/null +++ b/documentation/18.11/eiffel/Technical_papers/books-about-eiffel-method-and-language/eiffel-language.wiki @@ -0,0 +1,26 @@ +[[Property:title|Eiffel: The Language]] +[[Property:weight|2]] +[[Property:uuid|dae5a248-29f5-02b2-d01f-371394aa75e9]] +[[Image:ETL]] + + +=='''''Eiffel: The Language''''' by Bertrand Meyer.== + +Prentice Hall Object-Oriented Series. + +594 pp. + +Soft cover. + +ISBN 0-13-247925-7 + + +''Eiffel: The Language'' is one of the foundation volumes of Eiffel technology. It was originally published in 1992, and reprinted later with updates and corrections. + +Because the language specification has changed since the last reprinting to incorporate new quality and productivity constructs, hardcopies of ''Eiffel: The Language'', although still available, will represent the bulk of Eiffel correctly, but will not reflect the latest important changes. + +Currently ''Standard Eiffel'', the successor to ''Eiffel: The Language'', is a work-in-progress and is available in its current state online (See ''Standard Eiffel'', on [http://se.ethz.ch/~meyer/publications/#PSTE this page]). + +The most current state of Eiffel syntax, validity, and semantics is described in the ISO/ECMA [http://www.ecma-international.org/publications/standards/Ecma-367.htm standard document], also available online. + + diff --git a/documentation/18.11/eiffel/Technical_papers/books-about-eiffel-method-and-language/index.wiki b/documentation/18.11/eiffel/Technical_papers/books-about-eiffel-method-and-language/index.wiki new file mode 100644 index 00000000..c7ccb2ad --- /dev/null +++ b/documentation/18.11/eiffel/Technical_papers/books-about-eiffel-method-and-language/index.wiki @@ -0,0 +1,6 @@ +[[Property:title|Books about the Eiffel Method and Language]] +[[Property:link_title|Books]] +[[Property:weight|5]] +[[Property:uuid|721967da-6621-33f0-198f-9fc8ee26d37f]] + + diff --git a/documentation/18.11/eiffel/Technical_papers/books-about-eiffel-method-and-language/object-oriented-software-construction-2nd-edition.wiki b/documentation/18.11/eiffel/Technical_papers/books-about-eiffel-method-and-language/object-oriented-software-construction-2nd-edition.wiki new file mode 100644 index 00000000..de7d125b --- /dev/null +++ b/documentation/18.11/eiffel/Technical_papers/books-about-eiffel-method-and-language/object-oriented-software-construction-2nd-edition.wiki @@ -0,0 +1,39 @@ +[[Property:title|Object-Oriented Software Construction, 2nd Edition]] +[[Property:link_title|OOSC2]] +[[Property:weight|0]] +[[Property:uuid|496983ef-b86e-772e-16b9-39b37ef80e37]] +[[Image:OOSC2 small|OOSC2]] + + +=='''''Object-Oriented Software Construction, 2nd Edition''''' by Bertrand Meyer.== + +Prentice Hall Professional Technical Reference. + +1254 + xxviii pp. + +Soft cover. + +ISBN 0-13-629155-4 + + +Click to [http://www.amazon.com/Object-Oriented-Software-Construction-Book-CD-ROM/dp/0136291554 buy from Amazon]. + + +This Jolt Award winner takes the reader through the clear, logical, and comprehensive formation of a method for object-oriented software development ... the Eiffel method. During this journey, the author evolves a notation capable of expressing the products of each phase of development, from analysis through implementation. This notation is the Eiffel programming language. + + +==Praise for '''''Object-Oriented Software Construction, 2nd Edition'''''== + +Roger Smith, on the Dr. Dobbs Journal website, writes: + +:"In my unbiased opinion [...] it is destined to become the comprehensive and definitive reference for most methodological and technical questions raised by object technology. Its width and breadth of scope is impressive, from object-oriented techniques like Design by Contract and inheritance, to methodology issues like patterns and class design, to advanced issues like concurrency and persistence." + + +In ''Unix Review'', Stan Kelly-Bootle calls this book "The ultimate O-O guide." + + +Ian Graham, in ''Journal of Object-Oriented Programming'' calls it "Epoch-making". + + + + diff --git a/documentation/18.11/eiffel/Technical_papers/books-about-eiffel-method-and-language/touch-class-learning-program-well-objects-and-contracts.wiki b/documentation/18.11/eiffel/Technical_papers/books-about-eiffel-method-and-language/touch-class-learning-program-well-objects-and-contracts.wiki new file mode 100644 index 00000000..b5299fa1 --- /dev/null +++ b/documentation/18.11/eiffel/Technical_papers/books-about-eiffel-method-and-language/touch-class-learning-program-well-objects-and-contracts.wiki @@ -0,0 +1,36 @@ +[[Property:link_title|Touch of Class]] +[[Property:title|Touch of Class: Learning to Program Well with Objects and Contracts]] +[[Property:weight|-1]] +[[Property:uuid|3b4afd2f-6433-c619-f9a4-602c430c6902]] +[[Image:Touch of Class cover small]] + + + +=='''''Touch of Class: Learning to Program Well with Objects and Contracts''''' by Bertrand Meyer== + +Springer-Verlag, 2009 + +876 + lxiv pp. + +ISBN-13: 978-3540921448 + +Full color printing; many color illustrations and photographs + + +Click to [http://www.amazon.com/Touch-Class-Learning-Program-Contracts/dp/3540921443 buy from Amazon]. + + +Is this really a book about Eiffel? Perhaps in some senses it is not. It is a book about exactly what the subtitle indicates: ''Learning to Program Well with Objects and Contracts.'' (Primary emphasis should fall on the word "''Well''".) + +Still, the Eiffel method and language are used in this journey as tools, the best tools known, to help those seeking excellence in software development become prepared to meet the types of challenges a career in software will present. In the rapidly changing software world, this is a tall order. As the preface (for instructors) states: + +:'' It is not enough to present immediately applicable technology, for which in our globalized industry a cheaper programmer will always be available somewhere ... [Software professionals] must master software development as a professional endeavor, and by this distinguish themselves from the masses of occasional or amateur programmers.'' + + +''Touch of Class'' imparts its message using techniques which have accumulated through decades of study of technical learning and have been applied for several years in courses at ETH Zurich. These techniques include the extensive study and reuse of libraries of high-quality software components, employment of the Eiffel object-oriented method and Design by Contract, an introduction to formal methods and a ubiquitous awareness for software engineering concerns. + +A unique and refreshing aspect of ''Touch of Class'' is seen throughout the volume. Credit is given for ideas which form the foundation of modern software thinking, and in the process, those pioneers upon whose shoulders all software professionals stand, are made human and personal by photographs and historical vignettes. + + + + diff --git a/documentation/18.11/eiffel/Technical_papers/eiffel-expression-language.wiki b/documentation/18.11/eiffel/Technical_papers/eiffel-expression-language.wiki new file mode 100644 index 00000000..1e50a8ca --- /dev/null +++ b/documentation/18.11/eiffel/Technical_papers/eiffel-expression-language.wiki @@ -0,0 +1,20 @@ +[[Property:title|Eiffel as an expression language]] +[[Property:weight|0]] +[[Property:uuid|61e93102-c558-42e7-7784-0b60b9257b5d]] +A functional-programming style, or more generally a style involving more expressions and fewer instructions, is possible in Eiffel. In particular, the agent mechanism embeds a full functional-programming mechanism in the object-oriented framework of the language. + +To make the notations simpler, a number of extensions have been proposed. They involve no fundamental new language mechanisms, but provide new, more concise notations for existing mechanisms. Examples are: +*Conditional expressions +*Implicit tuple, a rule allowing the omission of brackets for an actual argument when it is a tuple and the last argument, e.g. f (a, b, c) as an abbreviation for f ([a, b, c]) (an example involving just one argument). Tuples already provided the equivalent of a variable-argument ("varargs") facility, but it is made simpler to use with this convention. +*Parenthesis alias, making it possible to write just f (x, y) when f is an agent (closure, lambda expression, delegate etc. in other terminologies), i.e. treating f as if it were a function; the notation is simply an abbreviation for f.item ([x, y]) (this example also takes advantage of implicit tuples). It has many other applications since a "parenthesis alias" can be defined for a feature of any class. +*Avoiding explicit assignments to '''Result'''. +*Type inference (to avoid explicitly specifying the type when it can be deduced from the context). This is a facility for the programmer, useful in particular for local variables, but does not affect the type system: Eiffel remains strongly typed, it is just that you can be lazy about writing the type when there is no ambiguity. +*In the same vein, omitting the entire list of generic parameters when it can be inferred. + +see [[file:expression_language.pdf|document as pdf]]. + + + + + + diff --git a/documentation/18.11/eiffel/Technical_papers/index.wiki b/documentation/18.11/eiffel/Technical_papers/index.wiki new file mode 100644 index 00000000..8d29e16c --- /dev/null +++ b/documentation/18.11/eiffel/Technical_papers/index.wiki @@ -0,0 +1,9 @@ +[[Property:title|Technical papers about Eiffel]] +[[Property:description|Background, foundation, or supplemental information about uncovered topics]] +[[Property:link_title|Papers]] +[[Property:weight|4]] +[[Property:uuid|d2b880d6-d1dc-9811-32b8-ed718ad4d4be]] +Occasionally papers are produced providing background, foundation, or supplemental information about the topics covered by the Eiffel documentation. Although the material in these papers might be of interest to many Eiffel users, they might not be suitable in their current form for inclusion in the mainstream documentation books. + +You will find a collection of these papers in this book. + diff --git a/documentation/18.11/eiffel/Technical_papers/void-safety-how-eiffel-removes-null-pointer-dereferencing.wiki b/documentation/18.11/eiffel/Technical_papers/void-safety-how-eiffel-removes-null-pointer-dereferencing.wiki new file mode 100644 index 00000000..6f98ef4a --- /dev/null +++ b/documentation/18.11/eiffel/Technical_papers/void-safety-how-eiffel-removes-null-pointer-dereferencing.wiki @@ -0,0 +1,25 @@ +[[Property:title|Void-safety: how Eiffel removes null-pointer dereferencing]] +[[Property:weight|0]] +[[Property:uuid|d9380464-4312-b76e-9bfd-e57df0f59b4a]] +This white paper (see [[file:void-safe-eiffel.pdf|document as pdf]]) presents the Eiffel void-safety mechanism, fully implemented in EiffelStudio 6.4. + +In almost every program running today there is a ticking time bomb: the risk of a "void call". A void call is possible in programs written in almost any programming language; its effect is usually to crash the program. Many unexplained program failures and other abnormal behaviors result from void calls. + +While extensive testing can decrease the likelihood of a void call, it cannot remove the possibility. The solution has to come from the programming language. + +Professor C.A.R. Hoare from Microsoft Research, winner of the Turing Award and the Kyoto Prize, calls the presence of void calls in modern programming languages the "billion-dollar mistake": + +:"The invention of the null reference in 1965" [the source of void calls] "has led to innumerable errors, vulnerabilities, and system crashes, which have probably caused a billion dollars of pain and damage in the last forty years." + +(Citation at: [http://www.infoq.com/presentations/Null-References-The-Billion-Dollar-Mistake-Tony-Hoare] ) + + +The Eiffel solution relies on a combination of language mechanisms: + +*"Certified Attachment Patterns" are code schemes that the EiffelStudio compiler guarantees to be void-safe. +*"Attached types" are types that are guaranteed to have non-void values. +*The "Object Test" instruction lets programmers treat void values in a special way. + + +The White Paper (see the link below) describes the theoretical and practical challenges of ensuring void-safety and presents the Eiffel mechanism. + diff --git a/documentation/18.11/eiffel/Tutorials/Mini-HowTo/Getting-a-STRING-from-a-NUMERIC-object.wiki b/documentation/18.11/eiffel/Tutorials/Mini-HowTo/Getting-a-STRING-from-a-NUMERIC-object.wiki new file mode 100644 index 00000000..39f91d94 --- /dev/null +++ b/documentation/18.11/eiffel/Tutorials/Mini-HowTo/Getting-a-STRING-from-a-NUMERIC-object.wiki @@ -0,0 +1,17 @@ +[[Property:modification_date|Mon, 10 Sep 2018 09:09:25 GMT]] +[[Property:publication_date|Mon, 10 Sep 2018 09:09:25 GMT]] +[[Property:uuid|B74D374E-895C-4F22-B95F-656BD78ECD03]] +[[Property:weight|1000]] +[[Property:title|Getting a STRING from a NUMERIC object]] +[[Property:link_title|NUMERIC to STRING]] +Every class has the `out` method that can be used to get a text version of the object. For a lot of classes, this method returns internal information that is not really useful for the end user. But for every `NUMERIC` class, the `out` method returns a text representation of the number that the `NUMERIC` object represents. + + + print_integer (a_integer: INTEGER) + -- Print the value of `a_integer`. + do + print (a_integer.out + "%N") + end + + +Note that for more advanced conversion, you can also use a conversion class like `FORMAT_DOUBLE`. \ No newline at end of file diff --git a/documentation/18.11/eiffel/Tutorials/Mini-HowTo/Iterate-on-a-LIST-and-removing-object.wiki b/documentation/18.11/eiffel/Tutorials/Mini-HowTo/Iterate-on-a-LIST-and-removing-object.wiki new file mode 100644 index 00000000..52e4097a --- /dev/null +++ b/documentation/18.11/eiffel/Tutorials/Mini-HowTo/Iterate-on-a-LIST-and-removing-object.wiki @@ -0,0 +1,28 @@ +[[Property:modification_date|Mon, 10 Sep 2018 09:06:41 GMT]] +[[Property:publication_date|Fri, 07 Sep 2018 12:13:00 GMT]] +[[Property:uuid|78393BBA-9B1E-4523-9881-3D83CEB6A952]] +[[Property:weight|3000]] +[[Property:title|Removing object while iterating on a LIST]] +If you already have the object that you want to remove from the `LIST` you can easily use `prune` and `prune_all`. But if you want to remove objects while iterating on that `LIST`, depending on criteria on the objects contained in the `LIST`, here is what you can do. + +First of all, if you think about removing an object while iterating, I do not recommend using an `across` loop. If you iterate on the list using a `from until loop end`, just remember to use the `LIST.forth` only when you do not use `LIST.remove`. + +For example, let's say we have class `MY_CLASS` with an attribute `has_stopped` and that I want to remove every object of a `LIST` that has this attribute set to `True`. Here is what the code will look like. + + + removing_stopped (a_list: LIST [MY_CLASS]) + -- Removing every closed element of `a_list` + do + from + a_list.start + until + a_list.exhausted + loop + if a_list.item.has_stopped then + a_list.remove + else + a_list.forth + end + end + end + \ No newline at end of file diff --git a/documentation/18.11/eiffel/Tutorials/Mini-HowTo/Iterating-on-a-LIST.wiki b/documentation/18.11/eiffel/Tutorials/Mini-HowTo/Iterating-on-a-LIST.wiki new file mode 100644 index 00000000..d4306b77 --- /dev/null +++ b/documentation/18.11/eiffel/Tutorials/Mini-HowTo/Iterating-on-a-LIST.wiki @@ -0,0 +1,64 @@ +[[Property:modification_date|Thu, 06 Sep 2018 15:21:39 GMT]] +[[Property:publication_date|Thu, 06 Sep 2018 15:17:57 GMT]] +[[Property:uuid|96077603-DD2D-4D8C-A486-AF4BD066613A]] +[[Property:weight|2000]] +[[Property:title|Iterating on a LIST]] +There are three Eiffel mechanisms to iterate on every element of a `LIST`. + +=== the `across` loop === +The `across` can be used on every `ITERABLE` object (including `LIST` objects). + + + print_elements (a_list: LIST[INTEGER]) + -- Print every elements on `a_list` + do + across a_list as ic loop + print (ic.item.out + "%N") + end + end + + +Note that the temporary variable (`ic` in the example) represent an iterator of the `ITERABLE` object, and not directly an element like in many other languages (like the `for` structure in Python for example). + +=== the `from until` loop syntax=== +This syntax offer more possibilities than the `across` loop, but is riskier. + + + print_elements (a_list:LIST[INTEGER]) + -- Print every elements on `a_list` + do + from + a_list.start + until + a_list.exhausted + loop + print (a_list.item.out + "%N") + a_list.forth + end + end + + +=== Using Eiffel agents and `{LIST}.do_all, ....` === +It is possible to use agents in conjunction with the `LIST` features `do_all`, `do_if`, `there_exists`, and `for_all` which are inherited from the class `LINEAR`. + + list_traversal_agents + -- Example of traversing a list with do_all + local + a_list: LINKED_LIST [STRING] + do + -- Insert some elements in a_list + create a_list.make + a_list.extend ("The Moon Is Full") + a_list.extend ("Master charge") + a_list.extend ("Black cat bone") + a_list.do_all (agent {STRING}.append (" - Albert Collins")) + a_list.do_all (agent print_element) + end + + print_element (a_element: STRING) + -- Print `a_element` to standard output + do + io.put_string (a_element) + io.put_new_line + end + diff --git a/documentation/18.11/eiffel/Tutorials/Mini-HowTo/Managing-CTRL-C-on-console.wiki b/documentation/18.11/eiffel/Tutorials/Mini-HowTo/Managing-CTRL-C-on-console.wiki new file mode 100644 index 00000000..bd2f1204 --- /dev/null +++ b/documentation/18.11/eiffel/Tutorials/Mini-HowTo/Managing-CTRL-C-on-console.wiki @@ -0,0 +1,50 @@ +[[Property:uuid|5CA34C5D-30F1-4D6F-9FE4-B555E541EA8C]] +[[Property:weight|4000]] +[[Property:title|Managing CTRL+C in console application]] +Normally, if the user use the CTRL+C keys, the Eiffel application detect it as an error and throw an exception of type OPERATING_SYSTEM_SIGNAL_FAILURE. + +To manage the CTRL+C keys, you can use a rescue clause to detect the exception and a retry mecanism to cancel the exception handeling done by the Eiffel runtime. + +To detect the exception, you can inherit from the EXCEPTIONS class and use an attachment test on Exception_manager.last_exception. + + +note + description: "Show how to quit an application using CTRL+C (without trace)." + author: "Louis Marchand" + date: "Wed, 25 Apr 2018 23:12:33 +0000" + revision: "0.1" + +class + APPLICATION + +inherit + EXCEPTIONS + +create + make + +feature {NONE} -- Initialization + + make + -- Launch `Current'. + local + l_ctrl_c:BOOLEAN + do + if not l_ctrl_c then + from until False loop + io.standard_default.put_string ("Press CTRL+C%N") + io.input.read_line + end + else + io.standard_default.put_string ("%NClosing...%N") + end + rescue + if attached {OPERATING_SYSTEM_SIGNAL_FAILURE} + Exception_manager.last_exception then + l_ctrl_c := True + retry + end + end + +end + \ No newline at end of file diff --git a/documentation/18.11/eiffel/Tutorials/Mini-HowTo/index.wiki b/documentation/18.11/eiffel/Tutorials/Mini-HowTo/index.wiki new file mode 100644 index 00000000..4473fb5c --- /dev/null +++ b/documentation/18.11/eiffel/Tutorials/Mini-HowTo/index.wiki @@ -0,0 +1,10 @@ +[[Property:modification_date|Mon, 10 Sep 2018 09:04:15 GMT]] +[[Property:publication_date|Mon, 10 Sep 2018 09:04:15 GMT]] +[[Property:link_title|Mini How-tos]] +[[Property:uuid|B2E4622A-2495-47DD-9C02-B9940A026EC1]] +[[Property:weight|0]] +[[Property:title|Mini How-tos]] +In this section, you will find little how-tos that you can use to learn some very specific mechanics in Eiffel. Those how-tos are small by design and can be used to show very fundamental, or more advanced, mechanisms for beginners. + + + diff --git a/documentation/18.11/eiffel/Tutorials/eiffel-tutorial-et/et-agents.wiki b/documentation/18.11/eiffel/Tutorials/eiffel-tutorial-et/et-agents.wiki new file mode 100644 index 00000000..03dc9616 --- /dev/null +++ b/documentation/18.11/eiffel/Tutorials/eiffel-tutorial-et/et-agents.wiki @@ -0,0 +1,250 @@ +[[Property:title|ET: Agents]] +[[Property:weight|-3]] +[[Property:uuid|ba49a80d-5ddf-8b30-4943-528974fd0ddd]] +Our last mechanism, agents, adds one final level of expressive power to the framework describe so far. Agents apply object-oriented concepts to the modeling of operations. + +==Objects for operations== + +Operations are not objects; in fact, object technology starts from the decision to separate these two aspects, and to choose object types, rather than the operations, as the basis for modular organization of a system, attaching each operation to the resulting modules -- the classes. + +In a number of applications, however, we may need objects that represent operations, so that we can include them in object structures that some other piece of the software will later traverse to uncover the operations and, usually, execute them. Such "operation wrapper" objects, called agents, are useful in a number of application areas such as:
+* GUI (Graphical User Interface) programming, where we may associate an agent with a certain event of the interface, such as a mouse click at a certain place on the screen, to prescribe that if the event occurs -- a user clicks there -- it must cause execution of the agent's associated operation. +* Iteration on data structures, where we may define a general-purpose routine that can apply an arbitrary operation to all the elements of a structure such as a list; to specify a particular operation to iterate, we will pass to the iteration mechanism an agent representing that operation. +* Numerical computation, where we may define a routine that computes the integral of any applicable function on any applicable interval; to represent that function and pass its representation to the integration routine, we will use an agent. + + +Operations in Eiffel are expressed as routines, and indeed every agent will have an associated routine. Remember, however, that the fundamental distinction between objects and operations remains: an agent is an object, and it is not a routine; it represents a routine. As further evidence that this is a proper data abstraction, note that the procedure call, available on all agents to call the associated routine, is only one of the features of agents. Other features may denote properties such as the class to which the routine belongs, its precondition and postcondition, the result of the last call for a function, the number of arguments. + +==Building an agent== + +In the simplest form, also one of the most common, you obtain an agent just by writing + + agent r + + +where r is the name of a routine of the enclosing class. This is an expression, which you may assign to a writable entity, or pass as argument to a routine. Here for example is how you will specify event handling in the style of the EiffelVision 2 GUI library: + + your_icon.click_actions.extend (agent your_routine) + + +This adds to the end of your_icon.click_actions -- the list of agents associated with the "click" event for your_icon, denoting an icon in the application's user interface -- an agent representing your_routine. Then when a user clicks on the associated icon at execution, the EiffelVision 2 mechanisms will call the procedure call on every agent of the list, which for this agent will execute your_routine. This is a simple way to associate elements of your application, more precisely its "business model" (the processing that you have defined, directly connected to the application's business domain), with elements of its GUI. + +Similarly although in a completely different area, you may request the integration of a function your_function over the interval 0..1 through a call such as + + your_integrator.integral (agent your_function, 0, 1) + + +In the third example area cited above, you may call an iterator of EiffelBase through + + your_list.do_all (agent your_proc) + + +with your_list of a type such as LIST [YOUR_TYPE]. This will apply your_proc to every element of the list in turn. + +The agent mechanism is type-checked like the rest of Eiffel; so the last example is valid if and only if your_proc is a procedure with one argument of type YOUR_TYPE. + +==Operations on agents== + +An agent agent r built from a procedure r is of type PROCEDURE [T, ARGS] where T represents the class to which r belongs and ARGS the type of its arguments. If r is a function of result type RES, the type is FUNCTION [T, ARGS, RES]. Classes PROCEDURE and FUNCTION are from the Kernel Library of EiffelBase, both inheriting from ROUTINE [T, ARGS]. + +Among the features of ROUTINE and its descendants the most important are call, already noted, which calls the associated routine, and item, appearing only in FUNCTION and yielding the result of the associated function, which it obtains by calling call. + +As an example of using these mechanisms, here is how the function integral could look like in our INTEGRATOR example class. The details of the integration algorithm (straight forward, and making no claims to numerical sophistication) do not matter, but you see the place were we evaluate the mathematical function associated with f, by calling item on f: + + integral (f: FUNCTION [TUPLE [REAL], REAL]; low, high: REAL): REAL + -- Integral of `f' over the interval [`low', `high'] + require + meaningful_interval: low <= high + local + x: REAL + do + from + x := low + invariant + x >= low + x <= high + step + -- Result approximates the integral over + -- the interval [low, low.max (x - step)] + until + x > high + loop + Result := Result + step * f.item ([x]) -- Here item is applied to f + x := x + step + end + end + + +Function integral takes three arguments: the agent f representing the function to be integrated, and the two interval bounds. When we need to evaluate that function for the value x, in the line + + Result := Result + step * f.item ([x]) + + +we don't directly pass x to item; instead, we pass a one-element tuple [x], using the syntax for manifest tuples introduced in [[ET: Other Mechanisms#Tuple_types|"Tuple types"]] . You will always use tuples for the argument to call and item, because these features must be applicable to any routine, and so cannot rely on a fixed number of arguments. Instead they take a single tuple intended to contain all the arguments. This property is reflected in the type of the second actual generic parameter to f, corresponding to ARGS (the formal generic parameter of FUNCTION): here it's TUPLE [REAL] to require an argument such as [x], where x is of type REAL. + +Similarly, consider the agent that the call seen above: + + your_icon.click_actions.extend (agent your_routine) + + +added to an EiffelVision list. When the EiffelVision mechanism detects a mouse click event, it will apply to each element item of the list of agents, your_icon.click_actions, an instruction such as + + item.call ([x, y]) + + +where x and y are the coordinates of the mouse clicking position. If item denotes the list element agent your_routine, inserted by the above call to extend, the effect will be the same as that of calling + + your_routine (x, y) + + +assuming that your_routine indeed takes arguments of the appropriate type, here INTEGER representing a coordinate in pixels. (Otherwise type checking would have rejected the call to extend.) + +==Open and closed arguments== + +In the examples so far, execution of the agent's associated routine, through item or call, passed exactly the arguments that a direct call to the routine would expect. You can have more flexibility. In particular, you may build an agent from a routine with more arguments than expected in the final call, and you may set the values of some arguments at the time you define the agent. + +Assume for example that a cartographical application lets a user record the location of a city by clicking on the corresponding position on the map. The application may do this through a procedure + + record_city (cn: STRING; pop: INTEGER; x, y: INTEGER) + -- Record that the city of name `cn' is at coordinates + -- `x' and `y' with population `pop'. + + +Then you can associate it with the GUI through a call such as + + map.click_actions.extend (agent record_city (name, population, ?, ?)) + + +assuming that the information on the name and the population has already been determined. What the agent denotes is the same as agent your_routine as given before, where your_routine would be a fictitious two-argument routine obtained from record_city -- a four-argument routine -- by setting the first two arguments once and for all to the values given, name and population. + +In the agent agent record_city (name, population, ?, ?), we say that these first two arguments, with their set values, are '''closed'''; the last two are '''open'''. The question mark syntax introduced by this example may only appear in agent expressions; it denotes open arguments. This means, by the way, that you may view the basic form used in the preceding examples, agent your_routine, as an abbreviation -- assuming your_routine has two arguments -- for agent your_routine (?, ?). It is indeed permitted, to define an agent with all arguments open, to omit the argument list altogether; no ambiguity may result. + +For type checking, agent record_city (name, population, ?, ?) and agent your_routine (?, ?) are acceptable in exactly the same situations, since both represent routines with two arguments. The type of both is + + PROCEDURE [TUPLE [INTEGER, INTEGER]] + + +where the tuple type specifies the open operands. + +A completely closed agent, such as agent your_routine (25, 32) or agent record_city (name, population, 25, 32), has the type TUPLE, with no parameters; you will call it with call ([ ]), using an empty tuple as argument. + +The freedom to start from a routine with an arbitrary number of arguments, and choose which ones you want to close and which ones to leave open, provides a good part of the attraction of the agent mechanism. It means in particular that in GUI applications you can limit to the strict minimum the "glue" code (sometimes called the controller in the so-called MVC, Model-View Controller, scheme of GUI design) between the user interface and "business model" parts of a system. A routine such as record_city is a typical example of an element of the business model, uninfluenced -- as it should be -- by considerations of user interface design. Yet by passing it in the form of an agent with partially open and partially closed arguments, you may be able to use it directly in the GUI, as shown above, without any "controller" code. + +As another example of the mechanism's versatility, we saw above an integral function that could integrate a function of one variable over an interval, as in + + your_integrator.integral (agent your_function (0, 1)) + + +Now assume that function3 takes three arguments. To integrate function3 with two arguments fixed, you don't need a new integral function; just use the same integral as before, judiciously selecting what to close and what to leave open: + + your_integrator.integral (agent function3 (3.5, ?, 6.0), 0, 1) + + +==Open targets== + +All the agent examples seen so far were based on routines of the enclosing class. This is not required. Feature calls, as you remember, were either unqualified, as in f (x, y), or qualified, as in a.g (x, y). Agents, too, have a qualified variant as in + + agent a.g + + +which is closed on its target a and open on the arguments. Variants such as agent a.g (x, y), all closed, and agent a.g (?, y), open on one argument, are all valid. + +You may also want to make the target open. The question mark syntax could not work here, since it wouldn't tell us the class to which feature g belongs, known in the preceding examples from the type of a. As in creation expressions, we must list the type explicitly; the convention is the same: write the types in braces, as in + + agent {SOME_TYPE}.g + agent {SOME_TYPE}.g (?, ?) + agent {SOME_TYPE}.g (?, y) + + +The first two of these examples are open on the target and both operands; they mean the same. The third is closed on one argument, open on the other and on the target. + +These possibilities give even more flexibility to the mechanism because they mean that an operation that needs agents with certain arguments open doesn't care whether they come from an argument or an operand of the original routine. This is particularly useful for iterators and means that if you have two lists + + your_account_list: LIST [ACCOUNT] + your_integer_list: LIST [INTEGER] + + +you may write both + + your_account_list.do_all (agent {ACCOUNT}.deposit_one_grand) + your_integer_list.do_all (agent add_to_total) + + +even though the two procedures used in the agents have quite different forms. We are assuming here that the first one, a feature of class ACCOUNT, is something like + + deposit_one_grand + -- Deposit one thousand into `Current'. + do + deposit (1000) + end + + +The procedure deposit_one_grand takes no arguments. In the do_all example above, its target is open. The target will be, in turn, each instance of ACCOUNT in your_account_list. + +In contrast, the other routine, assumed to be a feature of the calling class, does take an argument x: + + add_to_total (x: INTEGER) + -- Add `x' to the value of `total'. + do + total := total + x + end + + +Here, total is assumed to be an integer attribute of the enclosing class. In the do_all example, each instance of your_integer_list will fill the argument x left open in add_to_total. + +Without the versatility of playing with open and closed arguments for both the original arguments and target, you would have to write separate iteration mechanisms for these two cases. Here you can use a single iteration routine of LIST and similar classes of EiffelBase, do_all, for both purposes:
+* Depositing money on every account in a list of accounts. +* Adding all the integers in a list of integers. + + +==Inline agents== + +In the agent discussion above, it has been assumed that there already exists some routine that we wish to represent with an agent. However, sometimes the only usage of such a routine could be as an agent ... that is, the routine does not make sense as a feature of the class in question. In these cases, we can use '''inline agents'''. With an inline agent we write the routine within the agent declaration. + +If we consider the use of agents instead of class features in the two do_all examples in the previous section, the agents would be coded as follows: + + + your_account_list.do_all + (agent (a: ACCOUNT) + do + a.deposit (1000) + end) + + +and + + + your_integer_list.do_all + (agent (i: INTEGER) + do + total := total + i + end) + + +The syntax of the inline agent corresponds to the syntax of a routine. Immediately following the agent keyword are the formal arguments and in the case of functions the type for Result. Inline agents can have local entities, preconditions, and postconditions, just like any routine. + +Inline agents do not have access to the local entities of the routine in which they are coded. So, if it is necessary to use the routine's local variables, they must be passed as arguments to the inline agent. + +Here's an example of an inline agent which is a function. It is used in the context of a check to see if every element of your_integer_list is positive: + + + your_integer_list.for_all + (agent (i: INTEGER): BOOLEAN + do + Result := (i > 0) + ensure + definition: Result = (i > 0) + end) + + +Inline agents are interesting also as an implementation of the notion of [http://en.wikipedia.org/wiki/Closure_(computer_science) closures] in computer science. + + +Agents provide a welcome complement to the other mechanisms of Eiffel. They do not conflict with them but, when appropriate -- as in the examples sketched in this section -- provide clear and expressive programming schemes, superior to the alternatives. + +Compatibility note: earlier versions of the agent classes (ROUTINE, PROCEDURE, FUNCTION, PREDICATE) had an extra initial generic parameter, for which ANY was generally used. The compiler has been engineered to accept the old style in most cases. + + +{{SeeAlso|[[Event Programming with Agents]] }} + + + diff --git a/documentation/18.11/eiffel/Tutorials/eiffel-tutorial-et/et-design-contract-tm-assertions-and-exceptions.wiki b/documentation/18.11/eiffel/Tutorials/eiffel-tutorial-et/et-design-contract-tm-assertions-and-exceptions.wiki new file mode 100644 index 00000000..d9edb63f --- /dev/null +++ b/documentation/18.11/eiffel/Tutorials/eiffel-tutorial-et/et-design-contract-tm-assertions-and-exceptions.wiki @@ -0,0 +1,337 @@ +[[Property:title|ET: Design by Contract (tm), Assertions and Exceptions]] +[[Property:weight|-8]] +[[Property:uuid|2ef367c9-34d9-d45e-a722-163b39581405]] +Eiffel directly implements the ideas of Design by Contract™ , which enhance software reliability and provide a sound basis for software specification, documentation and testing, as well as exception handling and the proper use of inheritance. + +==Design by Contract™ basics== + +A system -- a software system in particular, but the ideas are more general -- is made of a number of cooperating components. Design by Contract™ states that their cooperation should be based on precise specifications -- contracts -- describing each party's expectations and guarantees. + +An Eiffel contract is similar to a real-life contract between two people or two companies, which it is convenient to express in the form of tables listing the expectations and guarantees. Here for example is how we could sketch the contract between a homeowner and the telephone company: + + +{| border="1" +|- +| style="width=10%" |provide telephone service +| style="width=35%" |'''OBLIGATIONS''' +| style="width=35%" |'''BENEFITS''' +|- +| '''Client''' +| (Satisfy precondition:)
+Pay bill. +| (From postcondition:)
+Receive telephone service from Supplier. +|- +| '''Supplier''' +| (Satisfy precondition:)
+Provide telephone service. +| (From postcondition:)
+No need to provide anything if bill not paid. +|} + + +Note how the obligation for each of the parties maps onto a benefit for the other. This will be a general pattern. + +The client's obligation, which protects the supplier, is called a '''precondition'''. It states what the client must satisfy before requesting a certain service. The client's benefit, which describes what the supplier must do (assuming the precondition was satisfied), is called a '''postcondition'''. + +In addition to preconditions and postconditions, contract clauses include '''class invariants''', which apply to a class as a whole. More precisely a class invariant must be ensured by every creation procedure (or by the default initialization if there is no creation procedure), and maintained by every exported routine of the class. + +==Expressing assertions== + +Eiffel provides syntax for expressing preconditions (require), postconditions (ensure) and class invariants (invariant), as well as other assertion constructs studied later (see "[[ET: Instructions|Instructions]]" ): loop invariants and variants, check instructions. + +Here is a partial update of class ACCOUNT with more assertions: + +note + description: "Simple bank accounts" + +class + ACCOUNT + +feature -- Access + + balance: INTEGER + -- Current balance + + deposit_count: INTEGER + -- Number of deposits made since opening + do + ... As before ... + end + +feature -- Element change + + deposit (sum: INTEGER) + -- Add `sum' to account. + require + non_negative: sum >= 0 + do + ... As before ... + ensure + one_more_deposit: deposit_count = old deposit_count + 1 + updated: balance = old balance + sum + end + +feature {NONE} -- Implementation + + all_deposits: DEPOSIT_LIST + -- List of deposits since account's opening. + +invariant + consistent_balance: (all_deposits /= Void) implies + (balance = all_deposits . total) + zero_if_no_deposits: (all_deposits = Void) implies + (balance = 0) + +end -- class ACCOUNT + + +Each assertion is made of one or more subclauses, each of them a boolean expression (with the additional possibility of the old construct). The effect of including more than one sub clause, as in the postcondition of deposit and in the invariant, is the same as connecting them through an and. Each clause may be preceded by a label, such as consistent_balance in the invariant, and a colon; the label is optional and does not affect the assertion's semantics, except for error reporting as explained in the next section, but including it systematically is part of the recommended style. The value of the boolean expression a implies b is true except if a is true and b false. + +Because assertions benefit from the full power of boolean expressions, they may include function calls. This makes it possible to express sophisticated consistency conditions, such as " the graph contains no cycle", which would not be otherwise expressible through simple expressions, or even through first-order predicate calculus, but which are easy to implement as Eiffel functions returning boolean results. + +===Preconditions=== + +The precondition of a routine expresses conditions that the routine is imposing on its clients. Here a call to deposit is correct if and only if the value of the argument is non-negative. The routine does not guarantee anything for a call that does not satisfy the precondition. It is in fact part of the Eiffel method that a routine body should '''never''' test for the precondition, since it is the client's responsibility to ensure it. (An apparent paradox of Design by Contract™, which is reflected in the bottom-right entries of the preceding and following contract tables, and should not be a paradox any more at the end of this discussion, is that one can get more reliable software by having fewer explicit checks in the software text.) + +===Postconditions=== + +The postcondition of a routine expresses what the routine guaranteed to its clients for calls satisfying the precondition. The notation old expression, valid in postconditions ( ensure clauses) only, denotes the value that expression had on entry to the routine. + +The precondition and postcondition state the terms of the contract between the routine and its clients, similar to the earlier example of a human contract: + + +{| border="1" +|- +| style="width=10%" |deposit +| style="width=35%"| '''OBLIGATIONS''' +| style="width=35%" | '''BENEFITS''' +|- +| '''Client''' +| (Satisfy precondition:)
+Use a non-negative argument. +| (From postcondition:)
+Get deposits list and balance updated. +|- +| '''Supplier''' +| (Satisfy precondition:)
+Update deposits list and balance. +| (From postcondition:)
+No need to handle negative arguments. +|} + +===Class invariants=== + +The class invariant, as noted, applies to all features. It must be satisfied on exit by any creation procedure, and is implicitly added to both the precondition and postcondition of every exported routine. In this respect it is both good news and bad news for the routine implementer: good news because it guarantees that the object will initially be in a stable state, averting the need in the example to check that the total of all_deposits is compatible with the balance; bad news because, in addition to its official contract as expressed by its specific postcondition, every routine must take care of restoring the invariant on exit. + +A requirement on meaningful contracts is that they should be in good faith: satisfiable by an honest partner. This implies a consistency rule: if a routine is exported to a client (either generally or selectively), any feature appearing in its precondition must also be available to that client. Otherwise -- for example if the precondition included require n > 0, where n is a secret attribute -- the supplier would be making demands that a good-faith client cannot possibly check for. + +Note in this respect that guaranteeing a precondition does not necessarily mean, for the client, testing for it. Assuming n is exported, a call may test for the precondition + + if x.n > 0 then + x.r + end + + +possibly with an else part. But if the context of the call, in the client's code, implies that n is positive -- perhaps because some preceding call set it to the sum of two squares -- then there is no need for an if or similar construct. + +{{note|In such a case, a check instruction as introduced later ( "[[ET: Instructions|Instructions]]" ) is recommended if the reason for omitting the test is non-trivial. }} + +==Using contracts for built-in reliability== + +What are contracts good for? Their first use is purely methodological. By applying a discipline of expressing, as precisely as possible, the logical assumptions behind software elements, you can write software whose reliability is built-in: software that is developed hand-in-hand with the rationale for its correctness. + +This simple observation -- usually not clear to people until they have practiced Design by Contract™ thoroughly on a large-scale project -- brings as much change to software practices and quality as the rest of object technology. + +==Run-time assertion monitoring== + +Contracts in Eiffel are not just wishful thinking. They can be monitored at run time under the control of compilation options. + +It should be clear from the preceding discussion that contracts are not a mechanism to test for special conditions, for example erroneous user input. For that purpose, the usual control structures ( if deposit_sum > 0 then ...) are available, complemented in applicable cases by the exception handling mechanism reviewed next. An assertion is instead a '''correctness condition''' governing the relationship between two software modules (not a software module and a human, or a software module and an external device). If sum is negative on entry to deposit, violating the precondition, the culprit is some other software element, whose author was not careful enough to observe the terms of the deal. Bluntly: + +{{rule|name=Assertion Violation|text=A run-time assertion violation is the manifestation of a bug. }} + +To be more precise:
+* A precondition violation signals a bug in the client, which did not observe its part of the deal. +* A postcondition (or invariant) violation signals a bug in the supplier -- the routine -- which did not do its job. + +That violations indicate bugs explains why it is legitimate to enable or disable assertion monitoring through mere compilation options: for a correct system -- one without bugs -- assertions will always hold, so the compilation option makes no difference to the semantics of the system. + +But of course for an incorrect system the best way to find out where the bug is -- or just that there is a bug -- is often to monitor the assertions during development and testing. Hence the presence of the compilation options, which EiffelStudio lets you set separately for each class, with defaults at the system and cluster levels:
+* no : assertions have no run-time effect. +* require : monitor preconditions only, on routine entry. +* ensure : preconditions on entry, postconditions on exit. +* invariant : same as ensure, plus class invariant on both entry and exit for qualified calls. +* all : same as invariant, plus check instructions, loop invariants and loop variants. + + +An assertion violation, if detected at run time under one of these options other than the first, will cause an exception ( [[ET: Design by Contract (tm), Assertions and Exceptions#exception_handling|"Exception handling"]] ). Unless the software has an explicit "retry" plan as explained in the discussion of exceptions, the violation will produce an exception trace and cause termination (or, in EiffelStudio, a return to the environment's browsing and debugging facilities at the point of failure). If present, the label of the violated sub clause will be displayed, to help identify the problem. + +The default is require. This is particularly interesting in connection with the Eiffel method's insistence on reuse: with libraries such as EiffelBase, richly equipped with preconditions expressing terms of use, an error in the '''client software''' will often lead, for example through an incorrect argument, to violating one of these preconditions. A somewhat paradoxical consequence is that even an application developer who does not apply the method too well (out of carelessness, haste, indifference or ignorance) will still benefit from the presence of contracts in someone else's library code. + +During development and testing, assertion monitoring should be turned on at the highest possible level. Combined with static typing and the immediate feedback of compilation techniques such as the Melting Ice Technology, this permits the development process mentioned in the section [[ET: The Software Process in Eiffel#Quality_and_functionality|"Quality and functionality"]], where errors are exterminated at birth. No one who has not practiced the method in a real project can imagine how many mistakes are found in this way; surprisingly often, a violation will turn out to affect an assertion that was just included for goodness' sake, the developer being convinced that it could never "possibly" fail to be satisfied. + +By providing a precise reference (the description of what the software is supposed to do) against which to assess the reality (what the software actually does), Design by Contract™ profoundly transforms the activities of debugging, testing and quality assurance. + +When releasing the final version of a system, it is usually appropriate to turn off assertion monitoring, or bring it down to the require level. The exact policy depends on the circumstances; it is a trade off between efficiency considerations, the potential cost of mistakes, and how much the developers and quality assurance team trust the product. When developing the software, however, you should always assume -- to avoid loosening your guard -- that in the end monitoring will be turned off. + +==The contract form of a class== + +Another application of assertions governs documentation. Environment mechanisms, such as clicking the Form Contract icon in Eiffelstudio, will produce, from a class text, an abstracted version which only includes the information relevant for client authors. Here is the contract form of class ACCOUNT in the latest version given: + +note + description: "Simple bank accounts" + +class interface + ACCOUNT + +feature -- Access + + balance: INTEGER + -- Current balance + + deposit_count: INTEGER + -- Number of deposits made since opening + +feature -- Element change + + deposit (sum: INTEGER) + -- Add `sum' to account. + require + non_negative: sum >= 0 + ensure + one_more_deposit: deposit_count = old deposit_count + 1 + updated: balance = old balance + sum + +invariant + consistent_balance: balance = all_deposits.total + +end -- class interface ACCOUNT + + +The words class interface are used instead of just class to avoid any confusion with actual Eiffel text, since this is documentation, not executable software. (It is in fact possible to generate a compilable variant of the Contract Form in the form of a deferred class, a notion defined later.) + +Compared to the full text, the Contract Form of a class (also called its "short form") retains all its interface properties, relevant to client authors:
+* Names and signatures (argument and result type information) for exported features. +* Header comments of these features, which carry informal descriptions of their purpose. (Hence the importance, mentioned in "[[ET: Hello World|Hello World]]", of always including such comments and writing them carefully.) +* Preconditions and postconditions of these features (at least the subclauses involving only exported features). +* Class invariant (same observation). + + +The following elements, however, are not in the Contract Form: any information about non-exported features; all the routine bodies (do clauses, or the external and once variants seen in [[ET: The Static Picture: System Organization#External_software|"External software"]] above and [[ET: Other Mechanisms#Once_routines_and_shared_objects|"Once routines and shared objects"]] below); assertion subclauses involving non-exported features; and some keywords not useful in the documentation. + +In accordance with the Uniform Access principle (described in [[ET: The Dynamic Structure: Execution Model|"Objects, fields, values, and references"]] ), the Contract Form does not distinguish between attributes and argument-less queries. In the above example, balance could be one or the other, as it makes no difference to clients, except possibly for performance. + +The Contract Form is the fundamental tool for using supplier classes in the Eiffel method. It enables client authors to reuse software elements without having to read their source code. This is a crucial requirement in large-scale industrial developments. + +The Contract Form satisfies two key requirements of good software documentation:
+* It is truly abstract, free from the implementation details of what it describes and concentrating instead on its functionality. +* Rather than being developed separately -- an unrealistic requirement, hard to impose on developers initially and becoming impossible in practice if we expect the documentation to remain up to date as the software evolves -- the documentation is extracted from the software itself. It is not a separate product but a different view of the same product. This prolongs the '''Single Product''' principle that lies at the basis of Eiffel's seamless development model (shown in [[ET: The Software Process in Eiffel|The Software Process in Eiffel]] ). + + +The Contract Form is only one of the relevant views. EiffelStudio, for example, generates graphical representations of system structures, to show classes and their relations -- client, inheritance -- according to the conventions of BON (the Business Object Notation). In accordance with the principles of seamlessness and reversibility, EiffelStudio lets you both work on the text, producing the graphics on the fly, or work on the graphics, updating the text on the fly; you can alternate as you wish between these two modes. The resulting process is quite different from more traditional approaches based on separate tools: an analysis and CASE workbench, often based on UML, to deal with an initial "bubble-and-arrow" description; and a separate programming environment, to deal with implementation aspects only. In Eiffel the environment provides consistent, seamless support from beginning to end. + +The Contract Form -- or its variant the Flat-Contract Form, which takes account of inheritance ( [[ET: Inheritance#Flat_and_Flat-Contract_Forms|"Flat and Flat-Contract Forms"]] ) are the standard form of library documentation, used extensively, for example, in the book [http://www.eiffel.com/services/training/books.html Reusable Software] (see bibliography). Assertions play a central role in such documentation by expressing the terms of the contract. As demonstrated a contrario by the widely publicized $500-million crash of the Ariane-5 rocket launcher in June of 1996, due to the incorrect reuse of a software module from the Ariane-4 project, '''reuse without a contract documentation''' is the path to disaster. Non-reuse would, in fact, be preferable. + +==Exception handling== + +Another application of Design by Contract™ governs the handling of unexpected cases. The vagueness of many discussions of this topic follows from the lack of a precise definition of terms such as "exception". With Design by Contract™ we are in a position to be specific:
+* Any routine has a contract to achieve. +* Its body defines a strategy to achieve it -- a sequence of operations, or some other control structure involving operations. Some of these operations are calls to routines, with their own contracts; but even an atomic operation, such as the computation of an arithmetic operation, has an implicit contract, stating that the result will be representable. +* Any one of these operations may fail, that is to say be unable to meet its contract; for example an arithmetic operation may produce an overflow (a non-representable result). +* The failure of an operation is an '''exception''' for the routine that needed the operation. +* As a result the routine may fail too -- causing an exception in its own caller. + + + +Note the precise definitions of the two key concepts, failure and exception. Although failure is the more basic one -- since it is defined for atomic, non-routine operations -- the definitions are mutually recursive, since an exception may cause a failure of the recipient routine, and a routine's failure causes an exception in its own caller. + +Why state that an exception "may" cause a failure? It is indeed possible to "rescue" a routine from failure in the case of an exception, by equipping it with a clause labeled rescue, as in: + + read_next_character (f: FILE) + -- Make next character available in last_character. + -- If impossible, set failed to True. + require + readable: file.readable + local + impossible: BOOLEAN + do + if impossible then + failed := True + else + last_character := low_level_read_function (f) + end + rescue + impossible := True + retry + end + + +This example includes the only two constructs needed for exception handling: rescue and retry. A retry instruction is only permitted in a rescue clause; its effect is to start again the execution of the routine, without repeating the initialization of local entities (such as impossible in the example, which was initialized to False on first entry). Features failed and last_character are assumed to be attributes of the enclosing class. + +This example is typical of the use of exceptions: as a last resort, for situations that should not occur. The routine has a precondition, file.readable, which ascertains that the file exists and is accessible for reading characters. So clients should check that everything is fine before calling the routine. Although this check is almost always a guarantee of success, a rare combination of circumstances could cause a change of file status (because a user or some other system is manipulating the file) between the check for readable and the call to low_level_read_function. If we assume this latter function will fail if the file is not readable, we must catch the exception. + +A variant would be + + local + attempts: INTEGER + do + if attempts < Max_attempts then + last_character := low_level_read_function (f) + else + failed := True + end + rescue + attempts := attempts + 1 + retry + end + + +which would try again up to Max_attempts times before giving up. + +The above routine, in either variant, never fails: it always fulfills its contract, which states that it should either read a character or set failed to record its inability to do so. In contrast, consider the new variant + + local + attempts: INTEGER + do + last_character := low_level_read_function (f) + rescue + attempts := attempts + 1 + if attempts < Max_attempts then + retry + end + end + + +with no more role for failed. In this case, after Max_attempts unsuccessful attempts, the routine will execute its rescue clause to the end, with no retry (the if having no else clause). This is how a routine '''fails'''. It will, as noted, pass on the exception to its caller. + +Such a rescue clause should, before terminating, restore the invariant of the class so that the caller and possible subsequent retryattempts from higher up find the objects in a consistent state. As a result, the rule for an absent rescue clause -- the case for the vast majority of routines in most systems -- is that it is equivalent to + + rescue + default_rescue + + +where procedure default_rescue comes from ANY, where it is defined to do nothing; in a system built for robustness, classes subject to non-explicitly-rescued exceptions should redefine default_rescue (perhaps using a creation procedure, which is bound by the same formal requirement) so that it will always restore the invariant. + +Behind Eiffel's exception handling scheme lies the principle -- at first an apparent platitude, but violated by many existing mechanisms -- that a routine should '''either succeed or fail'''. This is in turn a consequence of Design by Contract™ principles: succeeding means being able to fulfill the contract, possibly after one or more retry; failure is the other case, which must always trigger an exception in the caller. Otherwise it would be possible for a routine to miss its contract and yet return to its caller in a seemingly normal state. That is the worst possible way to handle an exception. + +Concretely, exceptions may result from the following events:
+* A routine failure ( rescue clause executed to the end with no retry), as just seen. +* Assertion violation, if for a system that runs with assertion monitoring on. +* Attempt to call a feature on a void reference: x.f (...), the fundamental computational mechanism, can only work if x is attached to an object, and will cause an exception otherwise. +* Developer exception, as seen next. +* Operating system signal:arithmetic overfolow; no memory available for a requested creation or twin -- even after garbage collection has rummaged everything to find some space. (But no C/C++-like "wrong pointer address", which cannot occur thanks to the statically typed nature of Eiffel.) + + +It is sometimes useful, when handling exceptions in rescue clauses, to ascertain the exact nature of the exception that got the execution there. For this it is suffices to inherit from the Kernel Library class EXCEPTIONS, which provides queries such as exception, giving the code for the last exception, and symbolic names ( [[ET: Other Mechanisms#Constant_attributes|"Constant attributes"]] ) for all such codes, such as No_more_memory. You can then process different exceptions differently by testing exception against various possibilities. The method strongly suggests, however, that exception handling code should remain simple; a complicated algorithm in a rescue clause is usually a sign that the mechanism is being misused. Class EXCEPTIONS also provides various facilities for fine-tuning the exception facilities, such as a procedure raise that will explicitly trigger a "developer exception" with a code that can then be detected and processed. Exception handling helps produce Eiffel software that is not just correct but robust, by planning for cases that should not normally arise, but might out of Murphy's law, and ensuring they do not affect the software's basic safety and simplicity. + +==Other applications of Design by Contract™== + +The Design by Contract™ ideas pervade the Eiffel method. In addition to the applications just mentioned, they have two particularly important consequences:
+* They make it possible to use Eiffel for analysis and design. At a high level of abstraction, it is necessary to be precise too. With the exception of BON, object-oriented analysis and design methods tend to favor abstraction over precision. Thanks to assertions, it is possible to express precise properties of a system ("At what speed should the alarm start sounding?") without making any commitment to implementation. The discussion of deferred classes ( [[ET: Inheritance#Applications_of_deferred_classes|"Applications of deferred classes"]] ) will show how to write a purely descriptive, non-software model in Eiffel, using contracts to describe the essential properties of a system without any computer or software aspect. +* Assertions also serve to control the power of inheritance-related mechanisms -- redeclaration, polymorphism, dynamic binding -- and channel them to correct uses by assigning the proper semantic limits. See [[ET: Inheritance#Inheritance_and_contracts|"Inheritance and contracts"]] . + + + + + diff --git a/documentation/18.11/eiffel/Tutorials/eiffel-tutorial-et/et-dynamic-structure-execution-model.wiki b/documentation/18.11/eiffel/Tutorials/eiffel-tutorial-et/et-dynamic-structure-execution-model.wiki new file mode 100644 index 00000000..11f574a0 --- /dev/null +++ b/documentation/18.11/eiffel/Tutorials/eiffel-tutorial-et/et-dynamic-structure-execution-model.wiki @@ -0,0 +1,697 @@ +[[Property:title|ET: The Dynamic Structure: Execution Model]] +[[Property:weight|-10]] +[[Property:uuid|1f3f2707-9129-4dca-76c7-157143d7ae74]] +A system with a certain static structure describes a set of possible executions. The run-time model governs the structure of the data (objects) created during such executions. + +The properties of the run-time model are not just of interest to implementers; they also involve concepts directly relevant to the needs of system modelers and analysts at the most abstract levels. + +==Objects, fields, values, and references== + +A class was defined as the static description of a type of run-time data structures. The data structures described by a ca class are called '''instances''' of the class, which in turn is called their '''generating class''' (or just "generator"). An instance of ACCOUNT is a data structure representing a bank account; an instance of LINKED_LIST is a data structure representing a linked list. + +An '''object''', as may be created during the execution of a system, is an instance of some class of the system. + +Classes and objects belong to different worlds: a class is an element of the software text; an object is a data structure created during execution. Although is possible to define a class whose instances represent classes, this does not eliminate the distinction between a static, compile-time notion, class, and a dynamic, run-time notion, object. + +An object is either an atomic object (integer, real, boolean, double) or a composite object made of a number of '''fields''', represented by adjacent rectangles on the conventional run-time diagrams: + + +[[Image:tutorial-5]] + + +Each field is a '''value'''. A value can be either an object or an object reference:
+* When a field is an object, it will in most cases be an atomic object, as on the figure where the first field from the top is an integer and the third a character. But a field can also be a composite object, in which case it is called a '''subobject'''. +* A '''reference''' is either void or uniquely identifies an object, to which it is said to be '''attached'''. In the preceding figure the second field from the top is a reference -- attached in this case, as represented by the arrow, to the enclosing object itself. The bottom field is a void reference. + + +==Features== + + +[[Image:tutorial-6]] + + +A feature, as noted, is an operation available on instances of a class. A feature can be either an '''attribute''' or a '''routine'''. This classification, which you can follow by starting from the right on the figure above, is based on implementation considerations: +* An attribute is a feature implemented through memory: it describes a field that will be found in all instances of the class. For example class ACCOUNT may have an attribute balance; then all instances of the class will have a corresponding field containing each account's current balance. +* A routine describes a computation applicable to all instances of the class. ACCOUNT may have a routine withdraw . +* Routines are further classified into '''functions''', which will return a result, and '''procedures''', which will not. Routine withdraw will be a procedure; an example of function may be highest_deposit, which returns the highest deposit made so far to the account. + +If we instead take the viewpoint of the '''clients''' of a class (the classes relying on its feature), you can see the relevant classification by starting from the left on the figure: +* '''Commands''' have no result, and may modify an object. They may only be procedures. +* '''Queries''' have a result: they return information about an object. You may implement a query as either an attribute (by reserving space for the corresponding information in each instance of the class, a memory-based solution) or a function (a computation-based solution). An attribute is only possible for a query without argument, such as balance; a query with arguments, such as balance_on (d) , returning the balance at date d, can only be a function. + +From the outside, there is no difference between a query implemented as an attribute and one implemented as a function: to obtain the balance of an account a, you will always write a.balance. In the implementation suggested above, a is an attribute, so that the notation denotes an access to the corresponding object field. But it is also possible to implement a as a function, whose algorithm will explore the lists of deposits and withdrawals and compute their accumulated value. To the clients of the class, and in the official class documentation as produced by the environment tools, the difference is not visible. + +This principle of '''Uniform Access''' is central to Eiffel's goals of extendibility, reusability and maintainability: you can change the implementation without affecting clients; and you can reuse a class without having to know the details of its features' implementations. Most object-oriented languages force clients to use a different notation for a function call and an attribute access. This violates Uniform Access and is an impediment to software evolution, turning internal representation changes into interface changes that may disrupt large parts of a system. + +==A simple class== + +The following simple class text illustrates the preceding concepts + +note + description: "Simple bank accounts" + +class + ACCOUNT + +feature -- Access + + balance: INTEGER + -- Current balance + + deposit_count: INTEGER + -- Number of deposits made since opening + do + if all_deposits /= Void then + Result := all_deposits.count + end + end + +feature -- Element change + + deposit (sum: INTEGER) + -- Add `sum' to account. + do + if all_deposits = Void then + create all_deposits + end + + all_deposits.extend (sum) + balance := balance + sum + end + +feature {NONE} -- Implementation + + all_deposits: DEPOSIT_LIST + -- List of deposits since account's opening. + +invariant + consistent_balance: + (all_deposits /= Void) implies (balance = all_deposits.total) + zero_if_no_deposits: + (all_deposits = Void) implies (balance = 0) + +end -- class ACCOUNT + + +(The {NONE} qualifier and the invariant clause, used here to make the example closer to a real class, will be explained shortly. DEPOSIT_LIST refers to another class, which can be written separately using library classes.) + +It's easy to deduce, from a feature's syntactic appearance, the category to which it belongs. Here: +* Only deposit and deposit_count, which include a do ... clause, are routines. +* balance and all_deposits, which are simply declared with a type, are attributes. Note that even for attributes it is recommended to have a header comment. +* Routine deposit_count is declared as returning a result (of type INTEGER); so it is a function. +* Routine deposit has no such result and hence is a procedure. + +==Creating and initializing objects== + +Classes, as noted, are a static notion. Objects appear at run time; they are created explicitly. Here is the basic instruction to create an object of type ACCOUNT and attach it to x: + + create x + + +assuming that x has been declared of type ACCOUNT. Such an instruction must be in a routine of some class -- the only place where instructions can appear -- and its effect at run time will be threefold: create a new object of type ACCOUNT; initialize its fields to default values; and attach the value of x to it. Here the object will have two fields corresponding to the two attributes of the generating class: an integer for balance, which will be initialized to 0, and a reference for all_deposits, which will be initialized to a void reference: + + +[[Image:tutorial-7]] + + +The language specifies default initialization values for all possible types: +{| +|- +| +'''Type''' + +|   +| +'''Default value''' + +|- +| +INTEGER, REAL, DOUBLE + +|     +| +Zero + +|- +| +BOOLEAN + +|   +| +False + +|- +| +CHARACTER + +|   +| +Null + +|- +| +Reference types (such as ACCOUNT and DEPOSIT_LIST) + +|   +| +Void reference + +|- +| +Composite expanded types (see next) + +|   +| +Same rules, applied recursively to all fields + +|} + +It is possible to override the initialization values by providing -- as in the earlier example of class HELLO -- one or more creation procedures. For example we might change ACCOUNT to make sure that every account is created with an initial deposit: + +note + description : "Simple bank accounts, initialized with a first deposit" + +class + ACCOUNT1 + +create + make + +feature -- Initialization + + make (sum: INTEGER) + -- Initialize account with `sum' . + do + deposit (sum) + end + + -- The rest of the class as for ACCOUNT + +end -- class ACCOUNT1 + + +A create clause may list zero or more (here just one) procedures of the class. + +{{info|Note the use of the same keyword, create , for both a creation clause, as here, and creation instructions such as create x . }} + +In this case the original form of creation instruction, create x , is not valid any more for creating an instance of ACCOUNT1; you must use the form + + create x.make (2000) + +known as a creation call. Such a creation call will have the same effect as the original form -- creation, initialization, attachment to -- x followed by the effect of calling the selected creation procedure, which here will call deposit with the given argument. + +Note that in this example all that make does is to call deposit. So an alternative to introducing a new procedure make would have been simply to introduce a creation clause of the form create deposit , elevating deposit to the status of creation procedure. Then a creation call would be of the form create x.deposit (2000) . + +{{info|Some variants of the basic creation instruction will be reviewed later: instruction with an explicit type; creation expressions. See [[ET: Other Mechanisms#Creation_variants|"Creation variants"]] . }} + +==Entities== + +The example assumed x declared of type ACCOUNT (or ACCOUNT1). Such an x is an example of '''entity''', a notion generalizing the well-known concept of variable. An entity is a name that appears in a class text to represent possible run-time values (a value being, as defined earlier, an object or a reference). An entity is one of the following:
+* An attribute of the enclosing class, such as balance and all_deposits. +* A formal argument of a routine, such as sum for deposit and make. +* A local entity declared for the internal needs of a routine. +* The special entity Result in a function. + + +The third case, local entities, arises when a routine needs some auxiliary values for its computation. Here is an example of the syntax: + + deposit (sum: INTEGER) + -- Add sum to account. + local + new: AMOUNT + do + create new.make (sum) + all_deposits.extend (new) + balance := balance + sum + end + + +This example is a variant of deposit for which we assume that the elements of a DEPOSIT_LIST such as all_deposits are no longer just integers, but objects, instances of a new class, AMOUNT. Such an object will contain an integer value, but possibly other information as well. So for the purpose of procedure deposit we create an instance of AMOUNT and insert it, using procedure extend, into the list all_deposits. The object is identified through the local entity new, which is only needed within each execution of the routine (as opposed to an attribute, which yields an object field that will remain in existence for as long as the object). + +The last case of entity, Result, serves to denote, within the body of a function, the final result to be returned by that function. This was illustrated by the function deposit_count, which read + + deposit_count: INTEGER + -- Number of deposits made since opening (provisional version) + do + if all_deposits /= Void then + Result := all_deposits.count + end + end + + +The value returned by any call will be the value of the expression all_deposits.count (to be explained in detail shortly) for that call, unless all_deposits is a Void reference ( /= means "not equal"). + +The default initialization rules seen earlier for attributes (see the table above) also serve to initialize local entities and Result on routine entry. So in the last example, if all_deposits is void (as in the case on initialization with the class as given so far), Result keeps its default value of 0, which will be returned as the result of the function. + +==Calls== + +Apart from object creation, the basic computational mechanism, in the object-oriented style of computation represented by Eiffel, is feature call. In its basic form, it appears as + + target.feature (argument1, ...) + + +where target is an entity or more generally an expression, feature is a feature name, and there may be zero or more argument expressions. In the absence of any argument the part in parentheses should be removed. + +We have already seen such calls. If the feature denotes a procedure, the call is an instruction, as in + + all_deposits.extend (new) + + +If feature denotes a query (function or attribute), the call is an expression, as in the right-hand side of + + Result := all_deposits.count + + +Following the principle of Uniform Access (mentioned earlier in the section ''Objects, fields, values, and references''), this form is the same for calls to attributes and to functions without arguments. In this example, feature count from class DEPOSIT_LIST may indeed be implemented in either of these two ways: we can keep a count field in each list, updating it for each insertion and removal; or we can compute count, whenever requested, by traversing the list and counting the number of items. + +In the case of a routine with arguments -- procedure or function -- the routine will be declared, in its class, as + + some_feature (formal_1: TYPE_1; ...) + do + ... + end + + +meaning that, at the time of each call, the value of each formal will be set to the corresponding actual (formal_1 to argument_1 and so on). + +In the routine body, it is not permitted to change the value of a formal argument, although it is possible to change the value of an attached object through a procedure call such as formal_1.some_procedure ( ... ) . + +==Infix and prefix notations== + +Basic types such as INTEGER are, as noted, full-status citizens of Eiffel's type system, and so are declared as classes (part of the Kernel Library). INTEGER, for example, is characterized by the features describing integer operations: plus, minus, times, division, less than, and so on. + +With the dot notation seen so far, this would imply that simple arithmetic operations would have to be written with a syntax such as + + i.plus (j) + +instead of the usual + + i + j + +This would be awkward. Infix and prefix notations solve the problem, reconciling the object-oriented view of computation with common notational practices of mathematics. The addition function is declared in class INTEGER as + + plus alias "+" (other: INTEGER): INTEGER + do + ... + end + + +Such a feature has all the properties and prerogatives of both normal "identifier-dot" notation and infix notation. This allowing invoking plus using either notation: i.plus (j) or i + j . A feature such as plus allowing infix notation must be a function, and take exactly one argument. + +Prefix notation is allowed as well. A function can be declared as opposite alias "-" , with no argument, permitting calls of the form -3 rather than (3).opposite . + +Predefined library classes covering basic types such as INTEGER, CHARACTER, BOOLEAN, REAL, DOUBLE are known to the Eiffel compiler, so that a call of the form j + i, although conceptually equivalent to a routine call, can be processed just as efficiently as the corresponding arithmetic expression in an ordinary programming language. This brings the best of both worlds: conceptual simplicity, enabling Eiffel developers, when they want to, to think of integers and the like as objects; and efficiency as good as in lower-level approaches. + +Infix and prefix notations are available to any class, not just the basic types' predefined classes. For example a graphics class could use the name distance alias "|-|" for a function computing the distance between two points, to be used in expressions such as + + point1 |-| point2 + + +==Type declaration== + +Every entity appearing in an Eiffel text is declared as being of a certain type, using the syntax already encountered in the above examples: + + entity_name: TYPE_NAME + + +This applies to attributes, formal arguments of routines and local entities. You will also declare the result type for a function, as in the earlier example + + deposit_count: INTEGER ... + + +Specifying such a function result type also declares, implicitly, the type for Result as used in the function's body. + +What is a type? With the elements seen so far, every type is a class . INTEGER, used in the declaration of deposits_count, is, as we have seen, a library class; and the declaration all_deposits: DEPOSIT_LIST assumes the existence of a class DEPOSIT_LIST . + +Three mechanisms introduced below -- expanded types, genericity, and anchored declarations -- will generalize the notion of type slightly. But they do not change the fundamental property that '''every type is based on a class''', called the type's '''base class'''. In the examples seen so far, each type is a class, serving as its own base class. + +An instance of a class C is also called "an object of type C". + +==Type categories== + +It was noted above that a value is either an object or a reference. This corresponds to two kinds of type: reference types and expanded types. + +If a class is declared as just + +class CLASS_NAME ... + + +it defines a reference type. The entities declared of that type will denote references. So in the declaration + + x: ACCOUNT + + +the possible run-time values for x are references, which will be either void or attached to instances of class ACCOUNT . + +Instead of class, however, you may use the double keyword expanded class , as in the EiffelBase class definition + +note + description : "Integer values" + +expanded class + INTEGER + +feature -- Basic operations + + plus alias "+" (other: INTEGER): INTEGER + do + ... + end + + ... Other feature declarations ... + +end -- class INTEGER + + +In this case the value of an entity declared as n: INTEGER is not a reference to an object, but the object itself -- in this case an atomic object, an integer value. + +Expanded classes make it possible to construct composite objects with subobjects. Suppose that two classes, ENGINE and PLANT, are suppliers to the class CAR. Further, ENGINE is defined as expanded, and PLANT is ''not'' defined as expanded. So, here's an abbreviated class declaration (note clause and routines omitted) for CAR: + +class CAR + +feature + + engine: ENGINE + + originating_plant: PLANT + +end -- class CAR + + +We can illustrate the structure of a typical instance of CAR like this: + + +[[Image:tutorial-8]] + + +The field for the attribute originating_plant is a reference to an object of type PLANT external to the instance of CAR. But in the case of the attribute engine, the fields for the instance of ENGINE exist as a subobject within the instance of CAR, because of class ENGINE's expanded nature. + +This example also illustrates that the distinction between expanded and reference types is important not just for system implementation purposes but for high-level system modeling as well. Consider the example of a class covering the notion of car. Many cars share the same originating_plant, but an engine belongs to just one car. References represent the modeling relation "knows about"; subobjects, as permitted by expanded types, represent the relation "has part", also known as aggregation. The key difference is that sharing is possible in the former case but not in the latter. + +==Basic operations== + +To assign, copy and compare values, you can rely on a number of mechanisms. Two of them, assignment and equality testing, are language constructs; the others are library features, coming from the top-level class ANY seen earlier. + +Assignment uses the symbol := . The assignment instruction + + x := y + + +updates the value of x to be the same as that of y. This means that for entities of reference types, the value of x will be a void reference if the value of y is void, and otherwise x will be attached to the same object OBJ2 as y: + + +[[Image:tutorial-9]] + + +For entities of expanded types, the values are objects; the object attached to x will be overwritten with the contents of the object attached to y. In the case of atomic objects, as in n := 3 with the declaration n: INTEGER , this has the expected effect of assigning to n the integer value 3; in the case of composite objects, this overwrites the fields for x, one by one, with the corresponding y fields. + +To copy an object, use + + x.copy (y) + +which assumes that both x and y are non-void, and copies the contents of y's attached object onto those of x's. For expanded entities the effect is the same as that of the assignment x := y. + +An operation performing similar duty to copy is twin . The assignment + + x := y.twin + +produces a newly created object (provided that y is non-void), initialized with a copy of the object attached to y and attaches the result to x . This means we may view twin as a function that performs the following two steps: + + create Result + Result.copy (Current) + +The new object is created, then its content is updated to match the content of y to which the twin call is targeted. + +So, assuming both entities of reference types and y not void, the assignment above will attach x to a '''new object''' identical to y's attached object, as opposed to the assignment x := y which attaches x to the '''same object''' as y. + + +To determine whether two values are equal, use the expression: + + x = y + +For references, this comparison will yield true if the values are either both void or both attached to the same object; this is the case in the last figure in the state after the assignment, but not before. The symbol for not equal is /= , as in: + + x /= y + + +As with assignment, there is also a form that works on objects rather than references: + + x.is_equal (y) + +will return true when x and y are both non-void and attached to field-by-field identical objects. This can be true even when x = y is not, for example, in the figure, ''before'' the assignment, if the two objects shown are field-by-field equal. + +The expression x.is_equal (y) can be written alternatively, using the ''tilde'' ('~') character, in a notation similar in form to x = y . The expression: + + x ~ y + +will be true only in cases in which x and y are the same type and x.is_equal (y) is true. + +A more general variant of is_equal is used under the form: + + equal (x, y) + +This is always defined, even if x is void, returning true whenever is_equal would but also if x and y are both void. (In contrast, x.is_equal (y) is not defined for void x and would, if evaluated, yield an exception as explained in [[ET: Design by Contract (tm), Assertions and Exceptions#Exception_handling|"Exception handling"]] below.) + +{{note|The ~ operator performs an object equality comparison, using the (possibly redefined) version of feature is_equal that is appropriate for the operand types. The operand types must be the same, or the result will be False. As such, the use of ~ is preferred to over the use of direct use of either x.is_equal (y) or equal (x, y), which can be susceptible to [[ET: Inheritance#Catcalls|catcalls]].}} + +Void denotes a void reference. So you can make x void through the assignment + + x := Void + +and test whether it is void through: + + if x = Void then ... + +Note that the assignment, := , and the equality operators, =, ~, /~, and /= , are language constructions, whereas copy, twin, is_equal, and equal are '''library features''' coming from class ANY . + +Void is a language keyword with built-in characteristics, but it is not harmful to imagine Void as another feature declared in class ANY, with type of NONE, the "bottom" type. This convenience allows any assignment of the for x := Void to be valid without any making exceptions to the type rules, regardless of the type of x . + +Using the redefinition mechanisms to be seen in the discussion of inheritance, a class can redefine copy and is_equal to cover specific notions of copy and equality. The assertions will ensure that the two remain compatible: after x.copy (y) , the property x .is_equal (y) must always be true. The effect of twin will automatically follow a redefinition of copy, and equal will follow is_equal. + +To guarantee the original, non-redefined semantics you may use the variants standard_copy, standard_twin, standard_equal, all defined in ANY as "frozen", that is to say non-redefinable. + +==Deep operations and persistence== + +Feature twin only duplicates one object. If some of the object's fields are references to other objects, the references themselves will be copied, not those other objects. + +It is useful, in some cases, to duplicate not just one object but an entire object structure. The expression y.deep_twin achieves this goal: assuming non-void y, it will produce a duplicate not just of the object attached to y but of the entire object structure starting at that object. The mechanism respects all the possible details of that structure, such as cyclic reference chains. Like the preceding features, deep_twin comes from class ANY. + +A related mechanism provides a powerful '''persistence''' facility. A call of the form + + x.store (Some_file_or_network_connection) + + +will store a copy of the entire object structure starting at x , under a suitable representation. Like deep_twin, procedure store will follow all references to the end and maintain the properties of the structure. The function retrieved can then be used -- in the same system, or another -- to recreate the structure from the stored version. + +As the name suggests, Some_file_or_network_connection can be an external medium of various possible kinds, not just a file but possibly a database or network. The EiffelNet client-server library indeed uses the store - retrieved mechanism to exchange object structures over a network, between compatible or different machine architectures, for example a Windows client and a Unix server. + +==Memory management== + +Reference reattachments, x := y , of the form illustrated by the figure just above can cause objects to become unreachable. This is the case for the object identified as OBJ1 on that figure (the object to which x was attached before the assignment) if no other reference was attached to it. + +In all but toy systems, it is essential to reclaim the memory that has been allocated for such objects; otherwise memory usage could grow forever, as a result of creation instructions create x ... and calls to twin and the like, leading to thrashing and eventually to catastrophic termination. + +The Eiffel method suggests that the task of detecting and reclaiming such unused object space should be handled by an automatic mechanism (part of the Eiffel run-time environment), not manually by developers (through calls to procedures such as Pascal's dispose and C/C++'s free). The arguments for this view are: + +'''Simplicity''' : handling memory reclamation manually can add enormous complication to the software, especially when -- as is often the case in object-oriented development -- the system manipulates complex run-time data structures with many links and cycles. + +'''Reliability''' : memory management errors, such as the incorrect reclamation of an object that is still referenced by a distant part of the structure, are a notorious source of dangerous and hard-to-correct bugs. + +The Eiffel Software's implementation of Eiffel provides a sophisticated '''garbage collector''' which efficiently handles the automatic reclamation process, while causing no visible degradation of a system's performance and response time. + +==Information hiding and the call rule== + +The basic form of computation, it has been noted, is a call of the form target.feature (...) . This is only meaningful if feature denotes a feature of the generating class of the object to which target (assumed to be non-void) is attached. The precise rule is the following: + +{{rule|name=Feature Call|text=A call of the form target.feature (...) appearing in a class C is only valid if feature is a feature of the base class of target's type, and is available to C.}} + + +The first condition simply expresses that if target has been declared as target: A then feature must be the name of one of the features of A. The second condition reflects Eiffel's application of the principles of information hiding. A feature clause, introducing one or more feature declarations, may appear not only as + +feature -- Comment identifying the feature category + + ... Feature declaration ... + + ... Feature declaration ... + + + ... + + + +but may also include a list of classes in braces, feature {A, B, ... } , as was illustrated for ACCOUNT: + +feature {NONE} -- Implementation + + all_deposits: DEPOSIT_LIST + -- List of deposits since account's opening. + + +This form indicates that the features appearing in that clause are only '''available''' -- in the sense of available for calls, as used in the Feature Call rule -- to the classes listed. In the example feature all_deposits is only available to NONE . Because of the [[ET: The Static Picture: System Organization#The_global_inheritance_structure|global inheritance structure]], this means it is in fact available to no useful client at all, and is equivalent in practice to feature { } with an empty class list, although the form listing NONE explicitly is more visible and hence preferred. + + + +With this specification a class text including the declaration acc: ACCOUNT and a call of the form + + acc.all_deposits + + +violates the Feature Call rule and will be rejected by the EiffelStudio compiler. + +Besides fully exported features (introduced by feature ... ; without further qualification) and fully secret ones (feature { } or feature {NONE} ), it is possible to export features selectively to some specified classes, using the specification + +feature {A, B, ...} + + +for arbitrary classes A, B, ... This enables a group of related classes to provide each other with privileged access, without requiring the introduction of a special module category above the class level (see [[ET: The Static Picture: System Organization#Clusters|"Clusters"]] ). + +Exporting features selectively to a set of classes A, B, ... also makes them available to the descendants of these classes. So a feature clause beginning with just feature is equivalent to one starting with feature {ANY} . + +These rules enable successive feature clauses to specify exports to different clients. In addition, the recommended style, illustrated in the examples of this chapter, suggests writing separate feature clauses -- regardless of their use for specifying export privileges -- to group features into separate categories. The standard style rules define a number of fundamental categories and the order in which they should appear; they include: Initialization for creation procedures, Access for general queries, Status report for boolean-valued queries, Status setting, Element change, Implementation (for selectively exported or secret features. Every feature in the EiffelBase library classes belongs to one of the predefined categories. + +The Feature Call rule is the first of the rules that make Eiffel a '''statically typed''' approach, where the applicability of operations to objects is verified at compile time rather than during execution. Static typing is one of the principal components of Eiffel's support for reliability in software development. + +==Execution scenario== + +The preceding elements make it possible to understand the overall scheme of an Eiffel system's execution. + +At any time during the execution of a system, one object is the '''current object''' of the execution, and one of the routines of the system, the '''current routine''', is being executed, with the current object as its target. (We will see below how the current object and current routine are determined.) The text of a class, in particular its routines, make constant implicit references to the current object. For example in the instruction + + balance := balance + sum + + +appearing in the body of procedure deposit of class ACCOUNT, the name of the attribute balance, in both occurrences, denotes the balance field of the current object, assumed to be an instance of ACCOUNT. In the same way, the procedure body that we used for the creation procedure make in the ACCOUNT1 variant + + make (sum: INTEGER) + -- Initialize account with sum . + do + deposit (sum) + end + + +contains a call to the procedure deposit. Contrary to earlier calls written in dot notation as target.feature (...), the call to deposit has no explicit target; this means its target is the current object, an instance of ACCOUNT1. Such a call is said to be '''unqualified'''; those using dot notations are '''qualified''' calls. + +Although most uses of the current object are implicit, a class may need to name it explicitly. The predefined expression Current is available for that purpose. A typical use, in a routine merge (other: ACCOUNT ) of class ACCOUNT, would be a test of the form + + if other = Current then + report_error ("Error: trying to merge an account with itself!") + else + ... Normal processing (merging two different account) ... + end + + +With these notions it is not hard to define precisely the overall scenario of a system execution by defining which object and routine will, at each instant, be the current object and the current routine: + +Starting a system execution, as we have seen, consists in creating an instance of the root class, the root object, and executing a designated creation procedure, the root procedure, with the root object as its target. The root object is the initial current object, and the root procedure is the initial current procedure. + +From then on only two events can change the current object and current procedure: a qualified routine call; and the termination of a routine. + +In a call of the form target.routine (...) , target denotes a certain object TC. (If not, that is to say, if the value of target is void, attempting to execute the call will trigger an exception, as studied below.) The generating class of TC must, as per the Feature Call rule, contain a routine of name routine. As the call starts, TC becomes the new current object and routine becomes the new current routine. + +When a routine execution terminates, the target object and routine of the most recent non-terminated call -- which, just before the terminated call, were the current object and the current routine -- assume again the role of current object and current routine. + +The only exception to the last rule is termination of the original root procedure call; in this case the entire execution terminates. + +==Abstraction== + +===Restriction of assignment targets=== + +The description of assignments stated that in x := y the target x must be an entity. More precisely it must be a '''writable''' entity. This notion excludes formal routine arguments: as noted, a routine r (arg: SOME_TYPE) may not assign to arg (reattaching it to a different object), although it can change the attached objects through calls of the form arg.procedure (...) . + +Allowing only entities to be the targets of assignments precludes assignments of the form + + obj.some_attribute := some_value + -- This syntax is disallowed (except in the presence of an `assigner command', see below) + +This is because the left-hand side obj.some_attribute is an expression (a feature call), not an entity: you may no more assign to obj.some_attribute than to, say, b + a -- another expression that is also, formally, a feature call. + +To obtain the intended effect of such an assignment you may use a procedure call, where the base class of obj's type has defined the procedure + + set_some_attribute (v: VALUE_TYPE) + -- Set value of some_attribute to `v'. + do + some_attribute := v + end + + +So instead of the disallowed assignment shown above, you would code: + + obj.set_some_attribute (some_value) + + +This rule is essential to enforcing the method. Permitting direct assignments to an object's fields -- as in C++ and Java -- would violate all the tenets of information hiding by letting clients circumvent the interface carefully crafted by the author of a supplier class. + +===Assigner commands=== + +However, many developers have become accustomed to reading and writing code in other languages which do allow assignments of the form: + + obj.some_attribute := some_value + +For this reason, it is possible in Eiffel to allow such a syntax without actually enabling an end-run around the constraints of the class. It is done by using a facility called an '''assigner command'''. In the example shown in the previous section, we might expect some_attribute to be declared something like this: + + some_attribute: SOME_TYPE + +If this were the case the assignment above would cause a syntax error at compile time. But if the declaration included the specification of an assigner command, as shown below, then the assignment syntax would be valid. + + some_attribute: SOME_TYPE assign set_some_attribute + +The assigner command then is the procedure set_some_attribute coded as shown in the previous section. In the presence of the assigner command, the previously invalid assignment syntax is now valid. But it is translated by the compiler as a call to set_some_attribute, using the source of the assignment as an argument. + +===Controlling modification of class fields=== + +It is the responsibility of each class author to define the exact privileges that the class gives to each of its clients, in particular field modification rights. Building a class is like building a machine: you design the internals, to give yourself the appropriate mechanisms; and you design the control panel, letting users (clients) access the desired subset of these mechanisms, safely and conveniently. + +The levels of privilege available to the class author include, for any field: +* Hide the field completely from clients, by exporting the corresponding attribute to NONE. +* Export it, but in read-only mode, by not exporting any procedure that modifies it. +* Export it for free read and write by any client, by also exporting a procedure of the set_attribute kind. +* Export it in '''restricted-write''' mode, by exporting a procedure such as deposit of class ACCOUNT, which adds a specified amount to the balance field, rather than directly setting the balance. + +The last case is particularly interesting is that it allows the class designer to set the precise way in which clients will manipulate the class instances, respecting the properties of the class and its integrity. The exported routines may, through the Design by Contract mechanism reviewed later in ( [[ET: Design by Contract (tm), Assertions and Exceptions]] ), place some further restrictions on the permitted modifications, for example by requiring the withdrawn amount to be positive. + +These rules follow directly from the more general goals (reusability, extendibility, reliability) and principles (Uniform Access, information hiding) underlying Eiffel software design. They reflect a view that each class must denote a well-understood abstraction, defined by a set of exported features chosen by the class designer -- the "control panel". + +The class documentation (see [[ET: Design by Contract (tm), Assertions and Exceptions#The_contract_form_of_a_class|the contract form of a class]] ) makes this view clear to client authors; no violation of that interface is permitted. This approach also paves the way for future '''generalization''' -- the final step of the cluster lifecycle, seen earlier in the section [[ET: The Software Process in Eiffel#Generalization_and_reuse|Generalization and reuse]] -- of the most promising components, and their inclusion into reusable libraries. + +===Attribute specializations=== + +In certain situations it is beneficial to be able to declare class attributes which behave in specialized ways. + +====Attribute specializations useful in void-safe programming==== + +Part of the strategy to ensure void-safety makes it necessary to be able to declare attributes as either [[Void-safety: Background, definition, and tools#Types as "attached" or "detachable"|'''detachable''' or '''attached''']]. + +'''[[Void-safety: Background, definition, and tools#Self-initializing attributes|Self-initializing attributes]]''' and '''[[Void-safety: Background, definition, and tools#Stable attributes|stable attributes]]''' are other tools for making void-safe programming more convenient. + +These attribute specializations are presented in the [[Void-safe programming in Eiffel|void-safe programming]] chapter. + +====Transient attributes==== + +Another special type of attribute supported by Eiffel Software's compiler is the '''transient attribute'''. When an instance of a class to which a transient attribute belongs is saved to persistent storage, the field for the transient attribute is not included. So, transient attributes are transient in the sense that they are part of the object at runtime, but not when the object is stored on disk. + +This type of attribute has benefits when using the persistence mechanisms provided with EiffelStudio, like [http://eiffel.com/developers/learning_maps/Training/Maps/PersistenceCanPayOff/Serialization.html SED]. Because transient attributes are not stored, they need not be accounted for upon retrieval. So, objects stored before changes to a class that only affect transient attributes will still be retrievable using the new class definition (whereas, if non-transient attributes were changed, a mismatch would occur during retrieval). + +An attribute is marked as transient by including a note option in its declaration: + + + transient_attribute: detachable STRING + note + option: transient + attribute + end + + +Only certain attributes can be marked as transient. Specifically, if attribute ''a'' is declared of type '''T''', it can be marked as transient only if it satisfies the following conditions: +# If '''T''' is a reference type, '''T''' must be detachable +# '''T''' is not a formal generic parameter +# '''T''' is not a user defined expanded type +# ''a'' is not an attribute of a user defined expanded class. + +The EiffelBase class INTERNAL includes features which are used to distinguish object fields as either persistent or transient and to reveal how many transient fields an object has. + + +{{note|Prior to version 6.6, support for transient attributes was limited to the C storable mechanism. In version 6.6, support was added for the Eiffel storable mechanism (SED) on both classic and .NET system targets.}} + + + + diff --git a/documentation/18.11/eiffel/Tutorials/eiffel-tutorial-et/et-eiffel-tutorial-copyright.wiki b/documentation/18.11/eiffel/Tutorials/eiffel-tutorial-et/et-eiffel-tutorial-copyright.wiki new file mode 100644 index 00000000..21ca7411 --- /dev/null +++ b/documentation/18.11/eiffel/Tutorials/eiffel-tutorial-et/et-eiffel-tutorial-copyright.wiki @@ -0,0 +1,34 @@ +[[Property:title|ET: Eiffel Tutorial Copyright]] +[[Property:weight|0]] +[[Property:uuid|105e9956-f168-b060-a6be-e78b221f269a]] +====MANUAL IDENTIFICATION AND COPYRIGHT==== + +Title: An Eiffel Tutorial, Eiffel Software Technical Report TR-EI-66/TU. + +Publication history + +First published July 2001. Corresponds to release 5.0 of the EiffelStudio environment. + +Author + +Software credits + +See acknowledgments in book [[Eiffel: The Language]]. + +Cover design + +Rich Ayling. + +Copyright notice and proprietary information + +Copyright Interactive Software Engineering Inc. (Eiffel Software), 2001. May not be reproduced in any form (including electronic storage) without the written permission of Eiffel Software . "Eiffel Power" and the Eiffel Power logo are trademarks of Eiffel Software . + +All uses of the product documented here are subject to the terms and conditions of the Eiffel Software Eiffel user license. Any other use or duplication is a violation of the applicable laws on copyright, trade secrets and intellectual property. + +Special duplication permission for educational institutions + +Degree-granting educational institutions using Eiffel Software Eiffel for teaching purposes as part of the [http://www.eiffel.com/educators/resources.html Eiffel University Partnership Program] may be permitted under certain conditions to copy specific parts of this book. Contact Eiffel Software for details. + + + + diff --git a/documentation/18.11/eiffel/Tutorials/eiffel-tutorial-et/et-general-properties.wiki b/documentation/18.11/eiffel/Tutorials/eiffel-tutorial-et/et-general-properties.wiki new file mode 100644 index 00000000..731c5ffd --- /dev/null +++ b/documentation/18.11/eiffel/Tutorials/eiffel-tutorial-et/et-general-properties.wiki @@ -0,0 +1,49 @@ +[[Property:title|ET: General Properties]] +[[Property:weight|-14]] +[[Property:uuid|1ad0b1d5-7ac6-9f55-92ec-ba6f42aee690]] +Here is an overview of the facilities supported by Eiffel:
+* Completely ''object-oriented'' approach. Eiffel is a full-fledged application of object technology, not a "hybrid" of O-O and traditional concepts. +* ''External interfaces''. Eiffel is a software composition tool and is easily interfaced with software written in such languages as C, C++, Java and C#. +* ''Full lifecycle support''. Eiffel is applicable throughout the development process, including analysis, design, implementation and maintenance. +* ''Classes'' as the basic structuring tool. A class is the description of a set of run-time objects, specified through the applicable operations and abstract properties. An Eiffel system is made entirely of classes, serving as the only module mechanism. +* ''Consistent type system''. Every type is based on a class, including basic types such as integer, boolean, real, character, string, array. +* ''Design by Contract''. Every system component can be accompanied by a precise specification of its abstract properties, governing its internal operation and its interaction with other components. +* ''Assertions''. The method and notation support writing the logical properties of object states, to express the terms of the contracts. These properties, known as assertions, can be monitored at run-time for testing and quality assurance. They also serve as documentation mechanism. Assertions include preconditions, postconditions, class invariants, loop invariants, and also appear in "check" instructions. +* ''Exception handling''. You can set up your software to detect abnormal conditions, such as unexpected operating system signals and contract violations, correct them, and recover +* ''Information hiding''. Each class author decides, for each feature, whether it is available to all client classes, to specific clients only, or just for internal purposes. +* ''Self-documentation''. The notation is designed to enable environment tools to produce abstract views of classes and systems, textual or graphical, and suitable for reusers, maintainers and client authors. +* ''Inheritance''. You can define a class as extension or specialization of others. +* ''Redefinition''. An inherited feature (operation) can be given a different implementation or signature. +* ''Explicit redefinition''. Any feature redefinition must be explicitly stated. +* ''Subcontracting''. Redefinition rules require new assertions to be compatible with inherited ones. +* ''Deferred features and classes''. It is possible for a feature, and the enclosing class, to be specified -- including with assertions -- but not implemented. Deferred classes are also known as abstract classes. +* ''Polymorphism''. An entity (variable, argument etc.) can become attached to objects of many different types. +* ''Dynamic binding''. Calling a feature on an object always triggers the version of the feature specifically adapted to that object, even in the presence of polymorphism and redefinition. +* ''Static typing''. A compiler can check statically that all type combinations will be valid, so that no run-time situation will occur in which an attempt will be made to apply an inexistent feature to an object. +* ''Object test'' ("type narrowing"). It is possible to check at run time whether the type of an object conforms to a certain expectation, for example if the object comes from a database or a network. +* ''Multiple inheritance''. A class can inherit from any number of others. +* ''Feature renaming''. To remove name clashes under multiple inheritance, or to give locally better names, a class can give a new name to an inherited feature. +* ''Repeated inheritance'': ''sharing and replication''. If, as a result of multiple inheritance, a class inherits from another through two or more paths, the class author can specify, for each repeatedly inherited feature, that it yields either one feature (sharing) or two (replication). +* ''No ambiguity under repeated inheritance''. Conflicting redefinitions under repeated inheritance are resolved through a "selection" mechanism. +* ''Unconstrained genericity''. A class can be parameterized, or "generic", to describe containers of objects of an arbitrary type. +* ''Constrained genericity''. A generic class can be declared with a generic constraint, to indicate that the corresponding types must satisfy some properties, such as the presence of a particular operation. +* ''Garbage collection''. The dynamic model is designed so that memory reclamation, in a supporting environment, can be automatic rather than programmer-controlled. +* ''No-leak modular structure''. All software is built out of classes, with only two inter-class relations, client and inheritance. +* ''Once routines''. A feature can be declared s "once", so that it is executed only for its first call, subsequently returning always the same result (if required). This serves as a convenient initialization mechanism, and for shared objects. +* ''Standardized library''. The Kernel Library, providing essential abstractions, is standardized across implementations. +* ''Other libraries''. Eiffel development is largely based on high-quality libraries covering many common needs of software development, from general algorithms and data structures to networking and databases. + + +It is also useful, as in any design, to list some of what is '''not''' present in Eiffel. The approach is indeed based on a small number of coherent concepts so as to remain easy to master. Eiffel typically takes a few hours to a few days to learn, and users seldom need to return to the reference manual once they have understood the basic concepts. Part of this simplicity results from the explicit decision to exclude a number of possible facilities:
+* ''No global variables'', which would break the modularity of systems and hamper extendibility, reusability and reliability. +* ''No union types'' (or record type with variants), which force the explicit enumeration of all variants; in contrast, inheritance is an open mechanism which permits the addition of variants at any time without changing existing code. +* ''No in-class overloading'', which by assigning the same name to different features within a single context, causes confusions, errors, and conflicts with object-oriented mechanisms such as dynamic binding. (Dynamic binding itself is a powerful form of inter-class overloading, without any of these dangers.) +* ''No goto instructions'' or similar control structures (break, exit, multiple-exit loops) which break the simplicity of the control flow and make it harder or impossible to reason about the software (in particular through loop invariants and variants). +* ''No exceptions to the type rules''. To be credible, a type system must not allow unchecked "casts" converting from a type to another. (Safe cast-like operations are available through object test.) +* ''No side-effect expression operators'' confusing computation and modification. +* ''No low-level pointers, no pointer arithmetic'', a well-known source of bugs. (There is however a type ''POINTER'', used for interfacing Eiffel with C and other languages.) + + + + + diff --git a/documentation/18.11/eiffel/Tutorials/eiffel-tutorial-et/et-genericity-and-arrays.wiki b/documentation/18.11/eiffel/Tutorials/eiffel-tutorial-et/et-genericity-and-arrays.wiki new file mode 100644 index 00000000..9350f805 --- /dev/null +++ b/documentation/18.11/eiffel/Tutorials/eiffel-tutorial-et/et-genericity-and-arrays.wiki @@ -0,0 +1,67 @@ +[[Property:title|ET: Genericity and Arrays]] +[[Property:weight|-9]] +[[Property:uuid|7f3bd1d7-357e-031d-9faa-b00594aa9ae0]] +Some of the classes that we will need, particularly in libraries, are '''container''' classes, describing data structures made of a number of objects of the same or similar types. Examples of containers include arrays, stacks and lists. The class DEPOSIT_LIST posited in earlier examples describes containers. + +It is not hard, with the mechanisms seen so far, to write the class DEPOSIT_LIST, which would include such features as count (query returning the number of deposit objects in the list) and put (command to insert a new deposit object). + +Most of the operations, however, would be the same for lists of objects other than deposits. To avoid undue replication of efforts and promote reuse, we need a way to describe '''generic''' container classes, which we can use to describe containers containing elements of many different types. + +==Making a class generic== + +The notation + +class C [G] + ... The rest as for any other class declaration ... + +introduces a generic class. A name such as G appearing in brackets after the class name is known as a '''formal generic parameter'''; it represents an arbitrary type. + +Within the class text, feature declarations can freely use G even though it is not known what type G stands for. Class LIST of EiffelBase, for example, includes features + + first: G + -- Value of first list item + + extend (val: G) + -- Add a new item of value val at end of list + ... + + +The operations available on an entity such as first and val, whose type is a formal generic parameter, are the operations available on all types: use as source y of an assignment x := y, use as target x of such an assignment (although not for val, which as a formal routine argument is not writable), use in equality comparisons x = y or x /= y, and application of universal features from ANY such as twin, is_equal and copy. + +To use a generic class such as list, a client will provide a type name as '''actual generic parameter'''. So instead of relying on a special purpose class DEPOSIT_LIST, the class ACCOUNT could include the declaration +all_deposits: LIST [DEPOSIT] + +using LIST as a generic class and DEPOSIT as the actual generic parameter. Then all features declared in LIST as working on values of type G will work, when called on the target all_deposits, on values of type DEPOSIT. With the target +all_accounts: LIST [ACCOUNT] + +these features would work on values of type ACCOUNT. + +{{info|A note of terminology: to avoid confusion, Eiffel always uses the word '''argument''' for routine arguments, reserving '''parameter''' for the generic parameters of classes. }} + +Genericity reconciles extendibility and reusability with the static type checking demanded by reliability. A typical error, such as confusing an account and a deposit, will be detected immediately at compile time, since the call all_accounts. extend ( dep ) is invalid for dep declared of type DEPOSIT. What is valid is something like all_accounts. extend ( acc ) for acc of type ACCOUNT. In other approaches, the same effect might require costly run-time checks (as in Java, C# or Smalltalk), with the risk of run-time errors. + +{{info|This form of genericity is known as '''unconstrained''' because the formal generic parameter, G in the example, represents an arbitrary type. You may also want to use types that are guaranteed to have certain operations available. This is known as '''constrained''' genericity and will be studied with inheritance. }} + +==Arrays== + +An example of generic class from the Kernel Library is ARRAY [G], which describes direct-access arrays. Features include: +* put to replace an element's value, as in my_array.put (val, 25) which replaces by val the value of the array entry at index 25. +* item to access an entry, as in my_array.item (25) yielding the entry at index 25. A synonym is infix "@", so that you may also write more tersely, for the same result, my_array @ 25 . +* lower, upper and count: queries yielding the bounds and the number of entries. +* The creation procedure make, as in create my_array.make (1, 50) which creates an array with the given index bounds. It is also possible to resize an array through resize, retaining the old elements. In general, the Eiffel method abhors built-in limits, favoring instead structures that resize themselves when needed, either from explicit client request or automatically. + +The comment made about INTEGER and other basic classes applies to ARRAY too: Eiffel compilers know about this class, and will be able to process expressions of the form my_array.put (val, 25) and my_array @ 25 in essentially the same way as a C or Fortran array access -- my_array [25] in C. But it is consistent and practical to let developers treat ARRAY as a class and arrays as objects; many library classes in EiffelBase, for example, inherit from ARRAY. Once again the idea is to get the best of both worlds: the convenience and uniformity of the object-oriented way of thinking; and the efficiency of traditional approaches. + +A similar technique applies to another Kernel Library class, that one not generic: STRING, describing character strings with a rich set of string manipulation features. + +==Generic derivation== + +The introduction of genericity brings up a small difference between classes and types. A generic class C is not directly a type since you cannot declare an entity as being of type C: you must use some actual generic parameter T -- itself a type. C [T] is indeed a type, but class C by itself is only a type template. + +The process of obtaining a type C [T] from a general class C is known as a '''generic derivation'''; C [T] is a '''generically derived type'''. Type T itself is, recursively, either a non-generic class or again a generically derived type D [U] for some D and U, as in LIST [ARRAY [INTEGER]].) + +It remains true, however, that every type is based on a class. The base class of a generically derived type C [T] is C. + + + + diff --git a/documentation/18.11/eiffel/Tutorials/eiffel-tutorial-et/et-hello-world.wiki b/documentation/18.11/eiffel/Tutorials/eiffel-tutorial-et/et-hello-world.wiki new file mode 100644 index 00000000..ca3520c1 --- /dev/null +++ b/documentation/18.11/eiffel/Tutorials/eiffel-tutorial-et/et-hello-world.wiki @@ -0,0 +1,80 @@ +[[Property:title|ET: Hello World]] +[[Property:weight|-12]] +[[Property:uuid|5b286f94-dd63-1169-a64e-74b5f8c5ef14]] +When discovering any approach to software construction, however ambitious its goals, it is reassuring to see first a small example of the big picture -- a complete program to print the famous "Hello World" string. Here is how to perform this fascinating task in the Eiffel notation. + +You write a class HELLO with a single procedure, say make, also serving as creation procedure. If you like short texts, here is a minimal version: + +class + HELLO + +create + make + +feature + + make + do + print ("Hello World%N") + end + +end + + +In practice, however, the Eiffel style rules suggest a better documented version: + +note + description: "Root for trivial system printing a message" + author: "Elizabeth W. Brown" + +class + HELLO + +create + make + +feature + + make + -- Print a simple message. + do + io.put_string ("Hello World") + io.put_new_line + end + +end -- class HELLO + + +The two versions perform identically; the following comments will cover the more complete second one. + +Note the absence of semicolons and other syntactic clatter or clutter. You may in fact use semicolons to separate instructions and declarations. But the language's syntax is designed to make the semicolon optional (regardless of text layout) and it's best for readability to omit it, except in the special case of successive elements on a single line. + +The note clause does not affect execution semantics; you may use it to associate documentation with the class, so that browsers and other indexing and retrieval tools can help users in search of reusable components satisfying certain properties. Here we see two notes, labeled description and author. + +The name of the class is HELLO. Any class may contain "features"; HELLO has just one, called make. The create clause indicates that make is a "creation procedure", that is to say an operation to be executed at class instantiation time. The class could have any number of creation procedures. + +The definition of make appears in a feature clause. There may be any number of such clauses (to separate features into logical categories), and each may contain any number of feature declarations. Here we have only one. + +The line starting with -- (two hyphen signs) is a comment; more precisely it is a "header comment", which style rules invite software developers to write for every such feature, just after the point at which the feature is named. As will be seen in [[ET: Design by Contract (tm), Assertions and Exceptions#The_contract_form_of_a_class|"The contract form of a class"]], the tools of EiffelStudio know about this convention and use it to include the header comment in the automatically generated class documentation. + +The body of the feature is introduced by the do keyword and terminated by end. It consists of two output instructions. They both use io, a generally available reference to an object that provides access to standard input and output mechanisms; the notation io.f, for some feature f of the corresponding library class (STD_FILES, in this case), means "apply f to io". Here we use two such features: +* put_string outputs a string, passed as argument, here "Hello World". +* put_new_line terminates the line. + +Rather than using a call to put_new_line, the first version of the class simply includes a new-line character, denoted as %N (the percent sign is used to introduce codes for [[Eiffel programming language syntax#Special characters|special characters]]), at the end of the string. Either technique is acceptable. + +You may have noticed another difference between the two versions. The first version uses a call to print where the second uses io.put_string . Here too, the effect is identical and either technique is acceptable. In the next section, you will begin to see how things like io and print become available for use in a class like HELLO. + +To build the system and execute it: +* Start EiffelStudio +* Create a new ''Basic application'' project +* Specify HELLO as the "root class" and make as the "root procedure". +* You can either use EiffelStudio to type in the above class text, or you may use any text editor and store the result into a file hello.e in the current directory. +* Click the "Compile" icon. +* Click the "Run" icon. + +Execution starts and outputs Hello World on the appropriate medium: under Windows, a Console; under Unix or OpenVMS, the windows from which you started EiffelStudio. + + + + diff --git a/documentation/18.11/eiffel/Tutorials/eiffel-tutorial-et/et-inheritance.wiki b/documentation/18.11/eiffel/Tutorials/eiffel-tutorial-et/et-inheritance.wiki new file mode 100644 index 00000000..d9a56e50 --- /dev/null +++ b/documentation/18.11/eiffel/Tutorials/eiffel-tutorial-et/et-inheritance.wiki @@ -0,0 +1,1057 @@ +[[Property:title|ET: Inheritance]] +[[Property:weight|-7]] +[[Property:uuid|c90e6ee3-b39d-48e5-2321-a34e12fd5327]] +Inheritance is a powerful and attractive technique. A look at either the practice or literature shows, however, that it is not always well applied. Eiffel has made a particular effort to tame inheritance for the benefit of modelers and software developers. Many of the techniques are original with Eiffel. Paul Dubois has written (comp.lang.python Usenet newsgroup, 23 March 1997): there are two things that [Eiffel] got right that nobody else got right anywhere else: support for design by contract, and multiple inheritance. Everyone should understand these "correct answers" if only to understand how to work around the limitations in other languages. + +==Basic inheritance structure== + +To make a class inherit from another, simply use an `inherit` clause: + +note ... + +class + D + +inherit + A + B + ... + +feature + ... + + +This makes `D` an heir of `A`, `B` and any other class listed. Eiffel supports '''multiple''' inheritance: a class may have as many parents as it needs. Later sections ( [[ET: Inheritance#Multiple_inheritance_and_renaming|"Multiple inheritance and renaming"]] and [[ET: Inheritance#Repeated_inheritance_and_selection|"Repeated inheritance and selection"]] ) will explain how to handle possible conflicts between parent features. + + +{{note|This discussion will rely on the terminology introduced in [[ET: The Static Picture: System Organization|The Static Picture: System Organization]]: descendants of a class are the class itself, its heirs, the heirs of its heirs and so on. Proper descendants exclude the class itself. The reverse notions are ancestors and proper ancestors. }} + + +By default `D` will simply include all the original features of `A`, `B`, ..., to which it may add its own through its `feature` clauses if any. But the inheritance mechanism is more flexible, allowing `D` to adapt the inherited features in many ways. Each parent name -- `A`, `B`, ... in the example -- can be followed by a '''Feature Adaptation''' clause, with subclauses, all optional, introduced by keywords `rename`, `export`, `undefine`, `redefine` and `select`, enabling the author of `D` to make the best use of the inheritance mechanism by tuning the inherited features to the precise needs of `D`. This makes inheritance a principal tool in the Eiffel process, mentioned earlier, of carefully crafting each individual class, like a machine, for the benefit of its clients. The next sections review the various Feature Adaptation subclauses. + +==Redefinition== + +The first form of feature adaptation is the ability to change the implementation of an inherited feature. + +Assume a class `SAVINGS_ACCOUNT` that specializes the notion of account. It is probably appropriate to define it as an heir to class `ACCOUNT`, to benefit from all the features of `ACCOUNT` still applicable to savings accounts, and to reflect the conceptual relationship between the two types: every savings account, apart from its own specific properties, also "is" an account. But we may need to produce a different effect for procedure `deposit` which, besides recording the deposit and updating the balance, may also need, for example, to update the interest. + +This example is typical of the form of reuse promoted by inheritance and crucial to effective reusability in software: the case of reuse with adaptation. Traditional forms of reuse are all-or-nothing: either you take a component exactly as it is, or you build your own. Inheritance will get us out of this "reuse or redo" dilemma by allowing us to reuse and redo. The mechanism is feature redefinition: + +note + description: "Savings accounts" + +class + SAVINGS_ACCOUNT + +inherit + ACCOUNT + redefine + deposit + end + +feature -- Element change + + deposit (sum: INTEGER) + -- Add sum to account. + do + ... New implementation (see below) ... + end + + ... Other features ... + +end -- class SAVINGS_ACCOUNT + + +Without the `redefine` subclause, the declaration of `deposit` would be invalid, yielding two features of the same name, the inherited one and the new one. The subclause makes this valid by specifying that the new declaration will override the old one. + +In a redefinition, the original version -- such as the `ACCOUNT` implementation of `deposit` in this example -- is called the '''precursor''' of the new version. It is common for a redefinition to rely on the precursor's algorithm and add some other actions; the reserved word `Precursor` helps achieve this goal simply. Permitted only in a routine redefinition, it denotes the parent routine being redefined. So here the body of the new `deposit` (called "New implementation" above) could be of the form + + + Precursor (sum) + -- Apply ACCOUNT's version of deposit + ... Instructions to update the interest ... + + +In the event that a routine has redefined a particular feature from multiple parent, the `Precursor` syntax allows the inclusion of a parent qualification: + + + Precursor {PARENT_X} (args...) + -- Apply PARENT_X's version of this feature + ... Instructions to update the interest ... + + + +Besides changing the implementation of a routine, a redefinition can turn an argument-less function into an attribute; for example a proper descendant of `ACCOUNT` could redefine `deposits_count`, originally a function, as an attribute. The Uniform Access Principle (introduced in [[ET: The Dynamic Structure: Execution Model|The Dynamic Structure: Execution Model]] ) guarantees that the redefinition makes no change for clients, which will continue to use the feature under the form + + acc.deposits_count + + +==Polymorphism== + +The inheritance mechanism is relevant to both roles of classes: module and type. Its application as a mechanism to reuse, adapt and extend features from one class to another, as just seen, covers its role as a '''module extension''' mechanism. But it's also a '''subtyping''' mechanism. To say that `D` is an heir of `A`, or more generally a descendant of `A`, is to express that instances of `D` can be viewed as instances of `A`. + +'''Polymorphic assignment''' supports this second role. In an assignment `x := y`, the types of `x` and `y` do not have, with inheritance, to be identical; the rule is that the type of `y` must simply '''conform''' to the type of `x`. + + +{{definition|Conformance|A class `D` conforms to a class `A` if and only if it is a descendant of `A` (which includes the case in which `A` and `D` are the same class); if these classes are generic, conformance of `D` `[U]` to `C` `[T]` requires in addition that type `U` conform to type `T` (through the recursive application of the same rules). }} + + +{{note|In addition, it will be shown in the discussion of tuples ([[ET: Other Mechanisms#Tuple_types|"Tuple types"]]), that `TUPLE [X]` conforms to `TUPLE`, `TUPLE [X, Y]` to `TUPLE [X]` and so on. }} + + +So with the inheritance structure that we have seen, the declarations + + acc: ACCOUNT + sav: SAVINGS_ACCOUNT + + +make it valid to write the assignment + + acc := sav + + +which will assign to `acc` a reference attached (if not void) to a direct instance of type `SAVINGS_ACCOUNT`, not `ACCOUNT`. + +Such an assignment, where the source and target types are different, is said to be polymorphic. An entity such as `acc`, which as a result of such assignments may become attached at run time to objects of types other than the one declared for it, is itself called a polymorphic entity. + +For polymorphism to respect the reliability requirements of Eiffel, it must be controlled by the type system and enable static type checking. We certainly do not want an entity of type `ACCOUNT` to become attached to an object of type `DEPOSIT`. Hence the second typing rule: + + +{{rule|name=Type Conformance|text=An assignment `x := y`, or the use of y as actual argument corresponding to the formal argument x in a routine call, is only valid if the type of y conforms to the the type of x. }} + + +The second case listed in the rule is a call such as `target.routine(..., y, ...)` where the routine declaration is of the form `routine (..., x: SOME_TYPE)`. The relationship between `y`, the actual argument in the call, and the corresponding formal argument `x`, is exactly the same as in an assignment `x := y`: not just the type rule, as expressed by Type Conformance (the type of `y` must conform to `SOME_TYPE`), but also the actual run-time effect which, as for assignments, will be either a reference attachment or, for expanded types, a copy. + +The ability to accept the assignment `x := Void` for `x` of any reference type (see [[ET: The Dynamic Structure: Execution Model#Basic_operations|"Basic operations"]] ) is a consequence of the Type Conformance rule, since `Void` is of type `NONE` which by construction ([[ET: The Static Picture: System Organization#The_global_inheritance_structure|"The global inheritance structure"]] ) conforms to all types. + +Polymorphism also yields a more precise definition of "instance". A '''direct instance''' of a type `A` is an object created from the exact pattern defined by the declaration of `A` 's base class, with one field for each of the class attributes; you will obtain it through a creation instruction of the form `create x` ..., for `x` of type `A`, or by cloning an existing direct instance. An '''instance''' of `A` is a direct instance of any type conforming to `A`: `A` itself, but also any type based on descendant classes. So an instance of `SAVINGS_ACCOUNT` is also an instance, although not a direct instance, of `ACCOUNT`. + +A consequence of polymorphism is the ability to define '''polymorphic data structures'''. With a declaration such as + + accounts: LIST [ACCOUNT] + + +the procedure call `accounts.extend (acc)`, because it uses a procedure `extend` which in this case expects an argument of any type conforming to `ACCOUNT`, will be valid not only if `acc` is of type `ACCOUNT` but also if it is of a descendant type such as `SAVINGS_ACCOUNT`. Successive calls of this kind make it possible to construct a data structure that, at run-time, might contain objects of several types, all conforming to `ACCOUNT`: + +[[Image:tutorial-10]] [[Image:tutorial-11]] + +Such polymorphic data structures combine the flexibility and safety of genericity and inheritance. You can make them more or less general by choosing for the actual generic parameter, here `ACCOUNT`, a type higher or lower in the inheritance hierarchy. Static typing is again essential here, prohibiting for example a mistaken insertion of the form `accounts.extend (dep)` where `dep` is of type `DEPOSIT`, which does not conform to `ACCOUNT`. + +At the higher (most abstract) end of the spectrum, you can produce an unrestrictedly polymorphic data structure `general_list: LIST [ANY]` which makes the call `general_list.extend (x)` valid for any `x`. The price to pay is that retrieving an element from such a structure will yield an object on which the only known applicable operations are the most general ones, valid for all types: assignment, copy, twin, equality comparison and others from `ANY`. The [[#Object test|object test]], studied below, will make it possible to apply more specific operations after checking dynamically that a retrieved object is of the appropriate type. + +==Dynamic binding== + +The complement of polymorphism is dynamic binding, the answer to the question "What version of a feature will be applied in a call whose target is polymorphic?". + +Consider `acc` is of type `ACCOUNT`. Thanks to polymorphism, an object attached to `acc` may be a direct instance not just of `ACCOUNT` but also of `SAVINGS_ACCOUNT` or other descendants. Some of these descendants, indeed `SAVINGS_ACCOUNT` among them, redefine features such as `deposit`. Then we have to ask what the effect will be for a call of the form + + acc.deposit (some_value) + + +Dynamic binding is the clearly correct answer: the call will execute the version of `deposit` from the generating class of the object attached to `acc` at run time. If `acc` is attached to a direct instance of `ACCOUNT`, execution will use the original `ACCOUNT` version; if `acc` is attached to a direct instance of `SAVINGS_ACCOUNT`, the call will execute the version redefined in that class. + +This is a clear correctness requirement. A policy of static binding (as available for example in C++ or Delphi, for non-virtual functions) would take the declaration of `acc` as an `ACCOUNT` literally. But that declaration is only meant to ensure generality, to enable the use of a single entity `acc` in many different cases: what counts at execution time is the object that `acc` represents. Applying the `ACCOUNT` version to a `SAVINGS_ACCOUNT` object would be wrong, possibly leading in particular to objects that violate the invariant of their own generating class (since there is no reason a routine of `ACCOUNT` will preserve the specific invariant of a proper descendant such as `SAVINGS_ACCOUNT`, which it does not even know about). + +In some cases, the choice between static and dynamic binding does not matter: this is the case for example if a call's target is not polymorphic, or if the feature of the call is redefined nowhere in the system. In such cases the use of static binding permits slightly faster calls (since the feature is known at compile time). This application of static binding should, however, be treated as a '''compiler optimization'''. The EiffelStudio compiler, under its "finalization" mode, which performs extensive optimization, will detect some of these cases and process them accordingly -- unlike approaches that make developers responsible for specifying what should be static and what dynamic (a tedious and error-prone task, especially delicate because a minute change in the software can make a static call, in a far-away module of a large system, suddenly become dynamic). Eiffel programmers don't need to worry about such aspects; they can rely on the semantics of dynamic binding in all cases, with the knowledge that the compiler will apply static binding when safe and desirable. + +Even in cases that require dynamic binding, the design of Eiffel, in particular the typing rules, enable compilers to make the penalty over the static-binding calls of traditional approaches very small and, most importantly, '''constant-bounded''' : it does not grow with the depth or complexity of the inheritance structure. The discovery in 1985 of a technique for constant-time dynamic binding calls, even in the presence of multiple and repeated inheritance, was the event that gave the green light to the development of Eiffel. + +Dynamic binding is particularly interesting for polymorphic data structures. If you iterate over the list of accounts of various kinds, `accounts: LIST [ACCOUNT]`, illustrated in the last figure, and at each step let `acc` represent the current list element, you can repeatedly apply + + acc.deposit (...) + + +to have the appropriate variant of the `deposit` operation triggered for each element. + +The benefit of such techniques appears clearly if we compare them with the traditional way to address such needs: using multi-branch discriminating instructions of the form + + if "Account is a savings account " then + ... + elseif "It is a money market account" then + ... + elseif ... + +and so on, or the corresponding `case ... of ..., switch` or `inspect` instructions. Apart from their heaviness and complexity, such solutions cause many components of a software system to rely on the knowledge of the exact set of variants available for a certain notion, such as bank account. Then any addition, change or removal of variants can cause a ripple of changes throughout the architecture. This is one of the majors obstacles to extendibility and reusability in traditional approaches. In contrast, using the combination of inheritance, redefinition, polymorphism and dynamic binding makes it possible to have a '''point of single choice''' -- a unique location in the system which knows the exhaustive list of variants. Every client then manipulates entities of the most general type, `ACCOUNT`, through dynamically bound calls of the form + + acc.some_account_feature (...) + + +These observations make dynamic binding appear for what it is: not an implementation mechanism, but an '''architectural technique''' that plays a key role (along with information hiding, which it extends, and Design by Contract, to which it is linked through the assertion redefinition rules seen below) in providing the modular system architectures of Eiffel, the basis for the method's approach to reusability and extendibility. These properties apply as early as analysis and modeling, and continue to be useful throughout the subsequent steps. + +==Deferred features and classes== + +The examples of dynamic binding seen so far assumed that all classes were fully implemented, and dynamically bound features had a version in every relevant class, including the most general ones such as `ACCOUNT`. + +It is also useful to define classes that leave the implementation of some of their features entirely to proper descendants. Such an abstract class is known as `deferred`; so are its unimplemented features. The reverse of deferred is effective, meaning fully implemented. + +`LIST` is a typical example of deferred class. As it describes the general notion of list, it should not favor any particular implementation; that will be the task of its effective descendants, such as `LINKED_LIST` (linked implementation), `TWO_WAY_LIST` (linked both ways) `ARRAYED_LIST, ` (implementation by an array), all effective, and all indeed to be found in EiffelBase. + +At the level of the deferred class `LIST`, some features such as `extend` (add an item at the end of the list) will have no implementation and hence will be declared as deferred. Here is the corresponding form, illustrating the syntax for both deferred classes and their deferred features: + +note + description: "[ + Sequential finite lists, without a commitment + to a representation. + ]" + +deferred class + LIST [G] + +feature -- Access + + count: INTEGER + -- Number of items in list + do + ... See below; this feature can be effective ... + end + +feature -- Element change + + extend (x: G) + -- Add `x' at end of list. + require + space_available: not full + deferred + ensure + one_more: count = old count + 1 + end + + ... Other feature declarations and invariants ... + +end -- class LIST + + +A deferred feature (considered to be a routine, although it can yield an attribute in a proper descendant) has the single keyword `deferred` in lieu of the `do` ''Instructions'' clause of an effective routine. A deferred class -- defined as a class that has at least one deferred feature -- must be introduced by `deferred class` instead of just `class`. + +As the example of `extend` shows, a deferred feature, although it has no implementation, can be equipped with assertions. They will be binding on implementations in descendants, in a way to be explained below. + +Deferred classes do not have to be fully deferred. They may contain some effective features along with their deferred ones. Here, for example, we may express `count` as a function: + +count: INTEGER + -- Number of items in list + do + from + start + until + after + loop + Result := Result + 1 + forth + end + end + + +This implementation relies on the loop construct described below ( `from` introduces the loop initialization) and on a set of deferred features of the class which allow traversal of a list based on moving a fictitious cursor: `start` to bring the cursor to the first element if any, `after` to find out whether all relevant elements have been seen, and `forth` (with precondition `not` `after`) to advance the cursor to the next element. Procedure `forth` itself appears as + + forth + -- Advance cursor by one position + require + not_after: not after + deferred + ensure + moved_right: index = old index + 1 + end + + +where `index` -- another deferred feature -- is the integer position of the cursor. + +Although the above version of feature `count` is time-consuming -- it implies a whole traversal just for the purpose of determining the number of elements -- it has the advantage of being applicable to all variants, without any commitment to a choice of implementation, as would follow for example if we decided to treat `count` as an attribute. Proper descendants can always redefine `count` for more efficiency. + +Function `count` illustrates one of the most important contributions of the method to reusability: the ability to define '''behavior classes''' that capture common behaviors (such as count) while leaving the details of the behaviors (such as `start`, `after`, `forth`) open to many variants. As noted earlier, traditional approaches to reusability provide closed reusable components. A component such as `LIST`, although equipped with directly usable behaviors such as count, is open to many variations, to be provided by proper descendants. + + +{{note|Some O-O languages support only the two extremes: fully effective classes, and fully deferred "interfaces", but not classes with a mix of effective and deferred features. This is an unacceptable limitation, negating the object-oriented method's support for a seamless, continuous spectrum from the most abstract to the most concrete. }} + + +A class `B` inheriting from a deferred class `A` may provide implementations -- effective declarations -- for the features inherited in deferred form. In this case there is no need for a `redefine` subclause; the effective versions simply replace the inherited versions. The class is said to '''effect''' the corresponding features. If after this process there remain any deferred features, B is still considered deferred, even if it introduces no deferred features of its own, and must be declared as `class deferred`. + +In the example, classes such as `LINKED_LIST` and `ARRAYED_LIST` will effect all the deferred features they inherit from `LIST` -- `extend`, `start` etc. -- and hence will be effective. + +Except in some applications restricted to pure system modeling -- as discussed next -- the main benefit of deferred classes and features comes from polymorphism and dynamic binding. Because `extend` has no implementation in class `LIST`, a call of the form `my_list.extend(...)` with my_list of type `LIST [T]` for some `T` can only be executed if `my_list` is attached to a direct instance of an effective proper descendant of `LIST`, such as `LINKED_LIST`; then it will use the corresponding version of `extend`. Static binding would not even make sense here. + +Even an effective feature of `LIST` such as count may depend on deferred features (start and so on), so that a call of the form `my_list.count` can only be executed in the context of an effective descendant. + +All this indicates that a deferred class must have '''no direct instance'''. (It will have instances, the direct instances of its effective descendants.) If it had any, we could call deferred features on them, leading to execution-time impossibility. The rule that achieves this goal is simple: if the base type of `x` is a deferred class, no creation instruction of target `x`, of the form `create x...`, is permitted. + +==Applications of deferred classes== + +Deferred classes cover abstract notions with many possible variants. They are widely used in Eiffel where they cover various needs:
+* Capturing high-level classes, with common behaviors. +* Defining the higher levels of a general taxonomy, especially in the inheritance structure of a library. +* Defining the components of an architecture during system design, without commitment to a final implementation. +* Describing domain-specific concepts in analysis and modeling. + + +These applications make deferred classes a central tool of the Eiffel method's support for seamlessness and reversibility. The last one in particular uses deferred classes and features to model objects from an application domain, without any commitment to implementation, design, or even software (and computers). Deferred classes are the ideal tool here: they express the properties of the domain's abstractions, without any temptation of implementation bias, yet with the precision afforded by type declarations, inheritance structures (to record classifications of the domain concepts), and contracts to express the abstract properties of the objects being described. + +Rather than using a separate method and notation for analysis and design, this approach integrates seamlessly with the subsequent phases (assuming the decision is indeed taken to develop a software system): it suffices to refine the deferred classes progressively by introducing effective elements, either by modifying the classes themselves, or by introducing design- and implementation-oriented descendants. In the resulting system, the classes that played an important role for analysis, and are the most meaningful for customers, will remain important; as we have seen ( [[ET: The Software Process in Eiffel#Seamlessness_and_reversibility|"Seamlessness and reversibility"]] ) this direct mapping property is a great help for extendibility. + +The following sketch (from the book [[Object-Oriented Software Construction, 2nd Edition]] ) illustrates these ideas on the example of scheduling the programs of a TV station. This is pure modeling of an application domain; no computers or software are involved yet. The class describes the notion of program segment. + +Note the use of assertions to define semantic properties of the class, its instances and its features. Although often presented as high-level, most object-oriented analysis methods (with the exception of Walden's and Nerson's Business Object Notation) have no support for the expression of such properties, limiting themselves instead to the description of broad structural relationships. + +note + description: "Individual fragments of a broadcasting schedule" + +deferred class + SEGMENT + +feature -- Access + + schedule: SCHEDULE deferred end + -- Schedule to which segment belongs + + index: INTEGER deferred end + -- Position of segment in its schedule + + starting_time, ending_time: INTEGER deferred end + -- Beginning and end of scheduled air time + + next: SEGMENT deferred end + -- Segment to be played next, if any + + sponsor: COMPANY deferred end + -- Segment's principal sponsor + + rating: INTEGER deferred end + -- Segment's rating (for children's viewing etc.) + + Minimum_duration: INTEGER = 30 + -- Minimum length of segments, in seconds + + Maximum_interval: INTEGER = 2 + -- Maximum time (seconds) between successive segments + +feature -- Element change + + set_sponsor (s: SPONSOR) + require + not_void: s /= Void + deferred + ensure + sponsor_set: sponsor = s + end + + ... change_next, set_rating omitted ... + +invariant + in_list: (1 <= index) and (index <= schedule.segments.count) + in_schedule: schedule.segments.item (index) = Current + next_in_list: (next /= Void) implies (schedule.segments.item (index + 1) = next) + no_next_if_last: (next = Void) = (index = schedule.segments.count) + non_negative_rating: rating >= 0 + positive times: (starting_time > 0) and (ending_time > 0) + sufficient_duration: ending_time - starting_time >= Minimum_duration + decent_interval: (next.starting_time) - ending_time <= Maximum_interval + +end + + +==Structural property classes== + +Some deferred classes describe a structural property, useful to the description of many other classes. Typical examples are classes of the Kernel Library in EiffelBase: + +`NUMERIC` describes objects on which arithmetic operations `+, -, *, /` are available, with the properties of a ring (associativity, distributivity, zero elements etc.). Kernel Library classes such as `INTEGER` and `REAL` -- but not, for example, `STRING` -- are descendants of `NUMERIC`. An application that defines a class `MATRIX` may also make it a descendant of `NUMERIC`. + +`COMPARABLE` describes objects on which comparison operations <, <=, >, >= are available, with the properties of a total preorder (transitivity, irreflexivity). Kernel Library classes such as `CHARACTER`, `STRING` and `INTEGER` -- but not our `MATRIX` example -- are descendants of `COMPARABLE`. + +For such classes it is again essential to permit effective features in a deferred class, and to include assertions. For example class `COMPARABLE` declares infix "<" as deferred, and expresses `>, >=` and <= effectively in terms of it. + + +{{note|The type `like Current` will be explained in [[ET: Inheritance#Covariance, anchored declarations, and "catcalls"|"Covariance, anchored declarations, and "catcalls""]] ; you may understand it, in the following class, as equivalent to `COMPARABLE`. }} + + +note + description: "Objects that can be compared according to a total preorder relation" + +deferred class + COMPARABLE + +feature -- Comparison + + infix "<" (other: like Current): BOOLEAN + -- Is current object less than `other'? + require + other_exists: other /= Void + deferred + ensure + asymmetric: Result implies not (other < Current) + end + + infix "<=" (other: like Current): BOOLEAN + -- Is current object less than or equal to `other'? + require + other_exists: other /= Void + do + Result := (Current < other) or is_equal (other) + ensure + definition: Result = (Current < other) or is_equal (other) + end + + ... Other features: infix ">", min, max, ... + +invariant + irreflexive: not (Current < Current) + +end -- class COMPARABLE + + +==Multiple inheritance and renaming== + +It is often necessary to define a new class in terms of several existing ones. For example: + +The Kernel Library classes `INTEGER` and `REAL` must inherit from both `NUMERIC` and `COMPARABLE`. + +A class `TENNIS_PLAYER`, in a system for keeping track of player ranking, will inherit from `COMPARABLE`, as well as from other domain-specific classes. + +A class `COMPANY_PLANE` may inherit from both `PLANE` and `ASSET`. + +Class `ARRAYED_LIST`, describing an implementation of lists through arrays, may inherit from both `LIST` and `ARRAY`. + +In all such cases multiple inheritance provides the answer. + +Multiple inheritance can cause '''name clashes''' : two parents may include a feature with the same name. This would conflict with the ban on name overloading within a class -- the rule that no two features of a class may have the same name. Eiffel provides a simple way to remove the name clash at the point of inheritance through the `rename` subclause, as in + +note + description: "Sequential finite lists implemented as arrays" + +class + ARRAYED_LIST [G] + +inherit + LIST [G] + + ARRAY [G] + rename + count as capacity, + item as array_item + end + +feature + + ... + +end -- class ARRAYED_LIST + + +Here both `LIST` and `ARRAY` have features called `count` and `item`. To make the new class valid, we give new names to the features inherited from `ARRAY`, which will be known within `ARRAYED_LIST` as `capacity` and `array_item`. Of course we could have renamed the `LIST` versions instead, or renamed along both inheritance branches. + +Every feature of a class has a '''final name''' : for a feature introduced in the class itself ("immediate" feature) it is the name appearing in the declaration; for an inherited feature that is not renamed, it is the feature's name in the parent; for a renamed feature, it is the name resulting from the renaming. This definition yields a precise statement of the rule against in-class overloading: + + +{{rule|name=Final Name|text=Two different features of a class may not have the same final name. }} + + +It is interesting to compare renaming and redefinition. The principal distinction is between features and feature names. Renaming keeps a feature, but changes its name. Redefinition keeps the name, but changes the feature. In some cases, it is of course appropriate to do both. + +Renaming is interesting even in the absence of name clashes. A class may inherit from a parent a feature which it finds useful for its purposes, but whose name, appropriate for the context of the parent, is not consistent with the context of the heir. This is the case with `ARRAY`'s feature `count` in the last example: the feature that defines the number of items in an array -- the total number of available entries -- becomes, for an arrayed list, the maximum number of list items; the truly interesting indication of the number of items is the count of how many items have been inserted in the list, as given by feature `count` from `LIST`. But even if we did not have a name clash because of the two inherited `count` features we should rename `ARRAY` 's `count` as `capacity` to maintain the consistency of the local feature terminology. + +The `rename` subclause appears before all the other feature adaptation subclauses -- `redefine` already seen, and the remaining ones `export`, `undefine` and `select` -- since an inherited feature that has been renamed sheds its earlier identity once and for all: within the class, and to its own clients and descendants, it will be known solely through the new name. The original name has simply disappeared from the name space. This is essential to the view of classes presented earlier: self-contained, consistent abstractions prepared carefully for the greatest enjoyment of clients and descendants. + +==Inheritance and contracts== + +A proper understanding of inheritance requires looking at the mechanism in the framework of Design by Contract, where it will appear as a form of subcontracting. + +The first rule is that invariants accumulate down an inheritance structure: + + +{{rule|name=Invariant Accumulation|text=The invariants of all the parents of a class apply to the class itself. }} + + +The invariant of a class is automatically considered to include -- in the sense of logical "and" -- the invariants of all its parents. This is a consequence of the view of inheritance as an "is" relation: if we may consider every instance of `B` as an instance of `A`, then every consistency constraint on instances of `A` must also apply to instances of `B`. + +Next we consider routine preconditions and postconditions. The rule here will follow from an examination of what contracts mean in the presence of polymorphism and dynamic binding. + +Consider a parent `A` and a proper descendant `B` (a direct heir on the following figure), which redefines a routine `r` inherited from `A`. + +[[Image:tutorial-12]] + +As a result of dynamic binding, a call `a1`.`r` from a client `C` may be serviced not by `A`'s version of `r` but by `B` 's version if `a1`, although declared of type `A`, becomes at run time attached to an instance of `B`. This shows the combination of inheritance, redefinition, polymorphism and dynamic binding as providing a form of subcontracting; `A` subcontracts certain calls to `B`. + +The problem is to keep subcontractors honest. Assuming preconditions and postconditions as shown on the last figure, a call in `C` of the form + + if a1.pre then + a1.r + end + + +or possibly + + a1.q + a1.r + + +where the postcondition of some routine `q` implies the precondition `pre` of `r`, satisfies the terms of the contract and hence is entitled to being handled correctly -- to terminate in a state satisfying `a1`.`post`. But if we let the subcontractor `B` redefine the assertions to arbitrary ''pre' ''and ''post','' this is not necessarily the case: ''pre' ''could be stronger than ''pre'', enabling `B` not to process correctly certain calls that are correct from `A`'s perspective; and ''post' ''could be weaker than ''post'', enabling `B` to do less of a job than advertized for `r` in the Contract Form of `A`, the only official reference for authors of client classes such as `C`. (An assertion `p` is stronger than or equal to an assertion `q` if `p` implies `q` in the sense of boolean implication.) + +The rule, then, is that for the redefinition to be correct the new precondition ''pre' ''must be weaker than or equal to the original ''pre'', and the new postcondition ''post' ''must be stronger than or equal to the original ''post''. + +Because it is impossible to check simply that an assertion is weaker or stronger than another, the language rule relies on different forms of the assertion constructs, `require else` and `ensure then`, for redeclared routines. They rely on the mathematical property that for any assertions `p` and `q`, the following are true: + + 1) p implies (p or q) + 2) (p and q) implies p + +For a precondition, using `require else` with a new assertion will perform an `or`, which can only weaken the original; for a postcondition, `ensure then` will perform an `and`, which can only strengthen the original. Hence the rule: + + +{{rule|name=Assertion Redeclaration|text=In the redeclared version of a routine, it is not permitted to use a require or ensure clause. Instead you may: Introduce a new condition with require else, for or-ing with the original precondition. Introduce a new condition with ensure then, for and-ing with the original postcondition. In the absence of such a clause, the original assertions are retained. }} + + +The last case -- retaining the original -- is frequent but by no means universal. + +The Assertion Redeclaration rule applies to '''redeclarations'''. This terms covers not just redefinition but also effecting (the implementation, by a class, of a feature that it inherits deferred). The rules -- not just for assertions but also, as reviewed below, for typing -- are indeed the same in both cases. Without the Assertion Redeclaration rule, assertions on deferred features, such as those on `extend`, `count` and `forth` in [[ET: Inheritance#Deferred_features_and_classes|"Deferred features and classes"]] , would be almost useless -- wishful thinking; the rule makes them binding on all effectings in descendants. + +From the Assertion Redeclaration rule follows an interesting technique: '''abstract preconditions'''. What needs to be weakened for a precondition (or strengthened for a postcondition) is not the assertion's concrete semantics but its abstract specification as seen by the client. A descendant can change the implementation of that specification as it pleases, even to the effect of strengthening the concrete precondition, as long as the abstract form is kept or weakened. The precondition of procedure `extend` in the deferred class `LIST` provided an example. We wrote the routine (in [[ET: Inheritance#Deferred_features_and_classes|"Deferred features and classes"]] ) as + + extend (x: G) + -- Add `x' at end of list. + require + space_available: not full + deferred + ensure + one_more: count = old count + 1 + end + + +The precondition expresses that it is only possible to add an item to a list if the representation is not full. We may well consider -- in line with the Eiffel principle that whenever possible structures should be of unbounded capacity -- that `LIST` should by default make `full` always return false: + + full: BOOLEAN + -- Is representation full? + -- (Default: no) + do + Result := False + end + + +Now a class `BOUNDED_LIST` that implements bounded-size lists (inheriting, like the earlier `ARRAYED_LIST`, from both `LIST` and `ARRAY`) may redefine `full`: + + full: BOOLEAN + -- Is representation full? + -- (Answer: if and only if number of items is capacity) + do + Result := (count = capacity) + end + + +Procedure `extend` remains applicable as before; any client that used it properly with `LIST` can rely polymorphically on the `FIXED_LIST` implementation. The abstract precondition of `extend` has not changed, even though the concrete implementation of that precondition has in fact been strengthened. + +Note that a class such as `BOUNDED_LIST`, the likes of which indeed appear in EiffelBase, is not a violation of the Eiffel advice to stay away from fixed-size structures. The corresponding structures are bounded, but the bounds are changeable. Although `extend` requires `not full`, another feature, called `force` in all applicable classes, will add an element at the appropriate position by resizing and reallocating the structure if necessary. Even arrays in Eiffel are not fixed-size, and have a procedure `force` with no precondition, accepting any index position. + +The Assertion Redeclaration rule, together with the Invariant Accumulation rule, provides the right methodological perspective for understanding inheritance and the associated mechanisms. Defining a class as inheriting from another is a strong commitment; it means inheriting not only the features but the logical constraints. Redeclaring a routine is bound by a similar committment: to provide a new implementation (or, for an effecting, a first implementation) of a previously defined semantics, as expressed by the original contract. Usually you have a wide margin for choosing your implementation, since the contract only defines a range of possible behaviors (rather than just one behavior), but you '''must''' remain within that range. Otherwise you would be perverting the goals of redeclaration, using this mechanism as a sort of late-stage hacking to override bugs in ancestor classes. + +==Join and uneffecting== + +It is not an error to inherit two deferred features from different parents under the same name, provided they have the same signature (number and types of arguments and result). In that case a process of '''feature join''' takes place: the features are merged into just one -- with their preconditions and postconditions, if any, respectively or-ed and and-ed. + +More generally, it is permitted to have any number of deferred features and at most one effective feature that share the same name: the effective version, if present will effect all the others. + +All this is not a violation of the Final Name rule (defined in [[ET: Inheritance#Multiple_inheritance_and_renaming|"Multiple inheritance and renaming"]] ), since the name clashes prohibited by the rule involve two different features having the same final name; here the result is just one feature, resulting from the join of all the inherited versions. + +Sometimes we may want to join ''effective'' features inherited from different parents, assuming again the features have compatible signatures. One way is to redefine them all into a new version. That is, list each in a `redefine` clause, then write a redefined version of the feature. In this case, they again become one feature, with no name clash in the sense of the Final Name rule. But in other cases we may simply want one of the inherited implementations to take over the others. The solution is to revert to the preceding case by '''uneffecting''' the other features; uneffecting an inherited effective feature makes it deferred (this is the reverse of effecting, which turns an inherited deferred feature into an effective one). The syntax uses the `undefine` subclause: + +class D + +inherit + A + rename + g as f + -- g was effective in A + undefine + f + end + + B + undefine + f + -- f was effective in B + end + + C + -- C also has an effective feature f , which will serve as + -- implementation for the result of the join. + +feature + ... + + + +Again what counts, to determine if there is an invalid name clash, is the final name of the features. In this example, two of the joined features were originally called `f`; the one from `A` was called `g`, but in `D` it is renamed as `f`, so without the undefinition it would cause an invalid name clash. + +Feature joining is the most common application of uneffecting. In some non-joining cases, however, it may be useful to forget the original implementation of a feature and let it start a new life devoid of any burden from the past. + +==Changing the export status== + +Another Feature Adaptation subclause, `export`, makes it possible to change the export status of an inherited feature. By default -- covering the behavior desired in the vast majority of practical cases -- an inherited feature keeps its original export status (exported, secret, selectively exported). In some cases, however, this is not appropriate: + +A feature may have played a purely implementation-oriented role in the parent, but become interesting to clients of the heir. Its status will change from secret to exported. + +In implementation inheritance (for example `ARRAYED_LIST` inheriting from `ARRAY`) an exported feature of the parent may not be suitable for direct use by clients of the heir. The change of status in this case is from exported to secret. + +You can achieve either of these goals by writing + +class D inherit + A + export {X, Y, ...} feature1, feature2, ... end + + ... + + +This gives a new export status to the features listed (under their final names since, as noted, `export` like all other subclauses comes after `rename` if present): they become exported to the classes listed. In most cases this list of classes, `X`, `Y`, ..., consists of just `ANY`, to re-export a previously secret feature, or `NONE`, to hide a previously exported feature. It is also possible, in lieu of the feature list, to use the keyword `all` to apply the new status to all features inherited from the listed parent. Then there can be more than one class-feature list, as in + +class ARRAYED_LIST [G] inherit + + ARRAY [G] + rename + count as capacity, item as array_item, put as array_put + export + {NONE} all + {ANY} capacity + end + + + + ... + + +where any explicit listing of a feature, such as `capacity`, takes precedence over the export status specified for `all`. Here most features of `ARRAY` are secret in `ARRAYED_LIST`, because the clients should not permitted to manipulate array entries directly: they will manipulate them indirectly through list features such as `extend` and `item`, whose implementation relies on `array_item` and `array_put`. But `ARRAY`'s feature `count` remains useful, under the name `capacity`, to the clients of `ARRAYED_LIST`. + +==Flat and Flat-Contract Forms== + +Thanks to inheritance, a concise class text may achieve a lot, relying on all the features inherited from direct and indirect ancestors. + +This is part of the power of the object-oriented form of reuse, but can create a comprehension and documentation problem when the inheritance structures become deep: how does one understand such a class, either as client author or as maintainer? For clients, the Contract Form, entirely deduced from the class text, does not tell the full story about available features; and maintainers must look to proper ancestors for much of the relevant information. + +These observations suggest ways to produce, from a class text, a version that is equivalent feature-wise and assertion-wise, but has no inheritance dependency. This is called the '''Flat Form''' of the class. It is a class text that has no inheritance clause and includes all the features of the class, immediate (declared in the class itself) as well as inherited. For the inherited features, the flat form must of course take account of all the feature adaptation mechanisms: renaming (each feature must appear under its final name), redefinition, effecting, uneffecting and export status change. For redeclared features, `require else` clauses are or-ed with the precursors' preconditions, and `ensure then` clauses are and-ed with precursors' postconditions. For invariants, all the ancestors' clauses are concatenated. As a result, the flat form yields a view of the class, its features and its assertions that conforms exactly to the view offered to clients and (except for polymorphic uses) heirs. + +As with the Contract Form ( [[ET: Design by Contract (tm), Assertions and Exceptions#The_contract_form_of_a_class|"The contract form of a class"]] ), producing the Flat Form is the responsibility of tools in the development environment. In EiffelStudio, you will just click the "Flat" icon. + +The Contract Form of the Flat Form of a class is known as its '''Flat-Contract Form'''. It gives the complete interface specification, documenting all exported features and assertions -- immediate or inherited -- and hiding implementation aspects. It is the appropriate documentation for a class. + +==Repeated inheritance and selection== + +An inheritance mechanism, following from multiple inheritance, remains to be seen. Through multiple inheritance, a class can be a proper descendant of another through more than one path. This is called repeated inheritance and can be indirect, as in the following figure, or even direct, when a class `D` lists a class `A` twice in its `inherit` clause. + +[[Image:tutorial-13]] + +The figure's particular example is in fact often used by introductory presentations of multiple inheritance, which is a pedagogical mistake: simple multiple inheritance examples (such as `INTEGER` inheriting from `NUMERIC` and `COMPARABLE`, or `COMPANY_PLANE` from `ASSET` and `PLANE`) should involve the combination of '''separate abstractions'''. Repeated inheritance is an advanced technique; although invaluable, it does not arise in elementary uses and requires a little more care. + +In fact there is only one non-trivial issue in repeated inheritance: what does a feature of the repeated ancestor, such as `change_address` and `computer_account`, mean for the repeated descendant, here `TEACHING_ASSISTANT`? (The example features chosen involve a routine and an attribute; the basic rules will be the same.) + +There are two possibilities: sharing (the repeatedly inherited feature yields just one feature in the repeated descendant) and duplication (it yields two). Examination of various cases shows quickly that a fixed policy, or one that would apply to all the features of a class, would be inappropriate. + +Feature `change_address` calls for sharing: as a teaching assistant, you may be both teacher and student, but you are just one person, with just one official domicile. + +If there are separate accounts for students' course work and for faculty, you may need one of each kind, suggesting that `computer_account` calls for duplication. + +The Eiffel rule enables, once again, the software developer to craft the resulting class so as to tune it to the exact requirements. Not surprisingly, it is based on names, in accordance with the Final Name rule (no in-class overloading): + + +{{rule|name=Repeated Inheritance|text=
A feature inherited multiply under one name will be shared: it is considered to be just one feature in the repeated descendant.
A feature inherited multiply under different names will be replicated, yielding as many variants as names. }} + + +So to tune the repeated descendant, feature by feature, for sharing and replication it suffices to use renaming. + +Doing nothing will cause sharing, which is indeed the desired policy in most cases (especially those cases of unintended repeated inheritance: making `D` inherit from `A` even though it also inherits from `B`, which you forgot is already a descendant of `A`). + +If you use renaming somewhere along the way, so that the final names are different, you will obtain two separate features. It does not matter where the renaming occurs; all that counts is whether in the common descendant, `TEACHING_ASSISTANT` in the last figure, the names are the same or different. So you can use renaming at that last stage to cause replication; but if the features have been renamed higher you can also use last-minute renaming to avoid replication, by bringing them back to a single name. + +The Repeated Inheritance rule gives the desired flexibility to disambiguate the meaning of repeatedly inherited features. There remains a problem in case of redeclaration and polymorphism. Assume that somewhere along the inheritance paths one or both of two replicated versions of a feature `f`, such as `computer_account` in the example, has been redeclared; we need to define the effect of a call `a.f` ( `a.computer_account` in the example) if `a` is of the repeated ancestor type, here `UNIVERSITY_PERSON`, and has become attached as a result of polymorphism to an instance of the repeated descendant, here `TEACHING_ASSISTANT`. If one or more of the intermediate ancestors has redefined its version of the feature, the dynamically-bound call has two or moreversions to choose from. + +A `select` clause will resolve the ambiguity, as in + +class TEACHING_ASSISTANT + +inherit + TEACHER + rename + computer_account as faculty_account + select + faculty_account + end + + STUDENT + rename + computer_account as student_account + end + + ... + + +We assume here that that no other renaming has occurred -- `TEACHING_ASSISTANT` takes care of the renaming to ensure replication -- but that one of the two parents has redefined `computer_account`, for example `TEACHER` to express the special privileges of faculty accounts. In such a case the rule is that one (and exactly one) of the two parent clauses in `TEACHING_ASSISTANT` '''must''' select the corresponding version. Note that no problem arises for an entity declared as + + ta: TEACHING_ASSISTANT + + +since the valid calls are of the form `ta.faculty_account` and `ta.student_account`, neither of them ambiguous; the call `ta.computer_account` would be invalid, since after the renamings class `TEACHING_ASSISTANT` has no feature of that name. The `select` only applies to a call + + up.computer_account + +with `up` of type `UNIVERSITY_PERSON`, dynamically attached to an instance of `TEACHING_ASSISTANT`; then the `select` resolves the ambiguity by causing the call to use the version from `TEACHER`. + +So if you traverse a list `computer_users: LIST [UNIVERSITY_PERSON]` to print some information about the computer account of each list element, the account used for a teaching assistant is the faculty account, not the student account. + +You may, if desired, redefine `faculty_account` in class `TEACHING_ASSISTANT`, using `student_account` if necessary, to take into consideration the existence of another account. But in all cases we need a precise disambiguation of what `computer_account` means for a `TEACHING_ASSISTANT` object known only through a `UNIVERSITY_PERSON` entity. + +The `select` is only needed in case of replication. If the Repeated Inheritance rule would imply sharing, as with change_address, and one or both of the shared versions has been redeclared, the Final Name rule makes the class invalid, since it now has '''two different features''' with the same name. (This is only a problem if both versions are effective; if one or both are deferred there is no conflict but a mere case of feature joining as explained in [[ET: Inheritance#Join_and_uneffecting|"Join and uneffecting"]] .) The two possible solutions follow from the previous discussions: + +If you do want sharing, one of the two versions must take precedence over the other. It suffices to '''undefine''' the other, and everything gets back to order. Alternatively, you can redefine both into a new version, which takes precedence over both. + +If you want to keep both versions, switch from sharing to replication: rename one or both of the features so that they will have different names; then you must `select` one of them. + +==Constrained genericity== + +Eiffel's inheritance mechanism has an important application to extending the flexibility of the '''genericity''' mechanism. In a class `SOME_CONTAINER [G]`, as noted in [[ET: Genericity and Arrays|"Genericity and Arrays"]] ), the only operations available on entities of type `G`, the formal generic parameter, are those applicable to entities of all types. A generic class may, however, need to assume more about the generic parameter, as with a class `SORTABLE_ARRAY [G ...]` which will have a procedure `sort` that needs, at some stage, to perform tests of the form + + if item (i) < item (j) then ... + +where `item (i)` and `item (j)` are of type `G`. But this requires the availability of a feature infix "<" in all types that may serve as actual generic parameters corresponding to `G`. Using the type `SORTABLE_ARRAY [INTEGER]` should be permitted, because `INTEGER` has such a feature; but not `SORTABLE_ARRAY [COMPLEX]` if there is no total order relation on `COMPLEX`. + +To cover such cases, declare the class as + +class SORTABLE_ARRAY [G -> COMPARABLE] + +making it '''constrained generic'''. The symbol `->` recalls the arrow of inheritance diagrams; what follows it is a type, known as the generic constraint. Such a declaration means that: + +Within the class, you may apply the features of the generic constraint -- here the features of `COMPARABLE`: infix "<", `infix ">"` etc. -- to expressions of type `G`. + +A generic derivation is only valid if the chosen actual generic parameter conforms to the constraint. Here you can use `SORTABLE_ARRAY [INTEGER]` since `INTEGER` inherits from `COMPARABLE`, but not `SORTABLE_ARRAY [COMPLEX]` if `COMPLEX` is not a descendant of `COMPARABLE`. + +A class can have a mix of constrained and unconstrained generic parameters, as in the EiffelBase class `HASH_TABLE [G, H -> HASHABLE]` whose first parameter represents the types of objects stored in a hash table, the second representing the types of the keys used to store them, which must be `HASHABLE`. As these examples suggest, structural property classes such as `COMPARABLE`, `NUMERIC` and `HASHABLE` are the most common choice for generic constraints. + +Unconstrained genericity, as in `C [G]`, is defined as equivalent to `C [G -> ANY]`. + +==Assignment attempt== + +{{Caution|As of version 7.1, the assignment attempt has been marked as obsolete. Use the object test (described [[ET: Inheritance#Object test|below]] in a variant of this same discussion) instead. The documentation for the assignment attempt will remain during a period of transition, but will be removed at some point in the future. }} + +The Type Conformance rule ( [[ET: Inheritance#Polymorphism|"Polymorphism"]] ) ensures type safety by requiring all assignments to be from a more specific source to a more general target. + +Sometimes you can't be sure of the source object's type. This happens for example when the object comes from the outside -- a file, a database, a network. The persistence storage mechanism( [[ET: The Dynamic Structure: Execution Model#Deep_operations_and_persistence|"Deep operations and persistence"]] ) includes, along with the procedure `store` seen there, the reverse operation, a function `retrieved` which yields an object structure retrieved from a file or network, to which it was sent using `store`. But `retrieved` as declared in the corresponding class `STORABLE` of EiffelBase can only return the most general type, `ANY`; it is not possible to know its exact type until execution time, since the corresponding objects are not under the control of the retrieving system, and might even have been corrupted by some external agent. + +In such cases you cannot trust the declared type but must check it against the type of an actual run-time object. Eiffel introduces for this purpose the '''assignment attempt''' operation, written + + x ?= y + + +with the following effect (only applicable if `x` is a writable entity of reference type): + +If `y` is attached, at the time of the instruction's execution to an object whose type conforms to the type of `x`, perform a normal reference assignment. + +Otherwise (if `y` is void, or attached to a non-conforming object), make `x` void. + +Using this mechanism, a typical object structure retrieval will be of the form + + x ?= retrieved + + if x = Void then + "We did not get what we expected" + else + "Proceed with normal computation, which will typically involve calls of the form x.some_feature " + end + + +As another application, assume we have a `LIST [ACCOUNT]` and class `SAVINGS_ACCOUNT`, a descendant of `ACCOUNT`, has a feature `interest_rate` which was not in `ACCOUNT`. We want to find the maximum interest rate for savings accounts in the list. Assignment attempt easily solves the problem: + + local + s: SAVINGS_ACCOUNT + do + from account_list.start until account_list.after loop + s ?= acc_list.item + -- item from LIST yields the element at + -- cursor position + if s /= Void and then s.interest_rate > Result then + -- Using and then (rather than and) guarantees + -- that s.interest_rate is not evaluated + -- if s = Void is true. + Result := s.interest_rate + end + account_list.forth + end + end + + +Note that if there is no savings account at all in the list the assignment attempt will always yield void, so that the result of the function will be 0, the default initialization. + +Assignment attempt is useful in the cases cited -- access to external objects beyond the software's own control, and access to specific properties in a polymorphic data structure. The form of the instruction precisely serves these purposes; not being a general type comparison, but only a verification of a specific expected type, it does not carry the risk of encouraging developers to revert to multi-branch instruction structures, for which Eiffel provides the far preferable alternative of polymorphic, dynamically-bound feature calls. + + +==Object test== + +The Type Conformance rule ( [[ET: Inheritance#Polymorphism|"Polymorphism"]] ) ensures type safety by requiring all assignments to be from a more specific source to a more general target. + +Sometimes you can't be sure of the source object's type. This happens for example when the object comes from the outside -- a file, a database, a network. The persistence storage mechanism( [[ET: The Dynamic Structure: Execution Model#Deep_operations_and_persistence|"Deep operations and persistence"]] ) includes, along with the procedure `store` seen there, the reverse operation, a function `retrieved` which yields an object structure retrieved from a file or network, to which it was sent using `store`. But `retrieved` as declared in the corresponding class `STORABLE` of EiffelBase can only return the most general type, `ANY`; it is not possible to know its exact type until execution time, since the corresponding objects are not under the control of the retrieving system, and might even have been corrupted by some external agent. + +In such cases you cannot trust the declared type but must check it against the type of an actual run-time object. Eiffel introduces for this purpose the '''object test''' operation, using a form of the [[Void-safety: Background, definition, and tools#The attached syntax (object test)|attached syntax]]. The complete attached syntax is: + + attached {SOME_TYPE} exp as l_exp + + +and is a boolean-valued expression. So we can use the attached syntax as an object test. A typical object structure retrieval will be of the form + + if attached retrieved as l_temp then +-- We got what we expected +-- Proceed with normal computation, typically involving calls of the form l_temp.some_feature + else +-- We did not get what we expected" + end + + +The expression `attached retrieved as l_temp` tests `retrieved` for voidness. If `retrieved` is not void, that is, `retrieved` is currently attached to an object, then a fresh local entity `l_temp` is created, the object is attached to `l_temp`, and the value of the expression is `True`. If `retrieved` is void, then the value of the expression is `False`. + + +As another application, assume we have a `LIST [ACCOUNT]` and class `SAVINGS_ACCOUNT`, a descendant of `ACCOUNT`, has a feature `interest_rate` which was not in `ACCOUNT`. We want to find the maximum interest rate for savings accounts in the list. Object test easily solves the problem: + + do + from account_list.start until account_list.after loop + if attached {SAVINGS_ACCOUNT} account_list.item as l_s and then l_s.interest_rate > Result then + -- Using and then (rather than and) guarantees + -- that l_s.interest_rate is not evaluated + -- if `attached {SAVINGS_ACCOUNT} account_list.item as l_s' is False. + Result := l_s.interest_rate + end + account_list.forth + end + end + + +Note that if there is no savings account at all in the list the object test will never be satisfied, so that the result of the function will be 0, the default initialization. + +The object test is useful also in building [[Void-safe programming in Eiffel|void-safe software systems]]. + +{{SeeAlso|[[Creating a new void-safe project#More about the attached syntax|More about the attached syntax]] in the section on [[Void-safe programming in Eiffel]]. }} + + +==Covariance, anchored declarations, and "catcalls"== + +The final properties of Eiffel inheritance involve the rules for adapting not only the implementation of inherited features (through redeclaration of either kind, effecting and redefinition, as seen so far) and their contracts (through the Assertion Redeclaration rule), but also their types. More general than type is the notion of a feature's '''signature''', defined by the number of its arguments, their types, the indication of whether it has a result (that is to say, is a function or attribute rather than a procedure) and, if so, the type of the result. + +===Covariance=== + +In many cases the signature of a redeclared feature remains the same as the original's. But in some cases you may want to adapt it to the new class. Assume for example that class `ACCOUNT` has features + + owner: HOLDER + + set_owner (h: HOLDER) + -- Make `h' the account owner. + require + not_void: h /= Void + do + owner := h + end + + +We introduce an heir `BUSINESS_ACCOUNT` of `ACCOUNT` to represent special business accounts, corresponding to class `BUSINESS` inheriting from `HOLDER`: + +[[Image:tutorial-14]] + +Clearly, we must redefine `owner` in class `BUSINESS_ACCOUNT` to yield a result of type `BUSINESS`; the same signature redefinition must be applied to the argument of `set_owner`. This case is typical of the general scheme of signature redefinition: in a descendant, you may need to redefine both results and arguments to types conforming to the originals. This is reflected by a language rule: + + +{{rule|name=Covariance|text=In a feature redeclaration, both the result type if the feature is a query (attribute or function) and the type of any argument if it is a routine (procedure or function) must conform to the original type as declared in the precursor version. }} + + +The term "covariance" reflects the property that all types -- those of arguments and those of results -- vary together in the same direction as the inheritance structure. + +If a feature such as `set_owner` has to be redefined for more than its signature -- to update its implementation or assertions -- the signature redefinition will be explicit. For example `set_owner` could do more for business owners than it does for ordinary owners. Then the redefinition will be of the form + + set_owner (b: BUSINESS) + -- Make b the account owner. + do + ... New routine body ... + end + + +====Anchored Declarations==== + +In other cases, however, the body will be exactly the same as in the precursor. Then explicit redefinition would be tedious, implying much text duplication. The mechanism of '''anchored redeclaration''' solves this problem. The original declaration of `set_owner` in `ACCOUNT` should be of the form + + set_owner (h: like owner) + -- Make h the account owner. + -- The rest as before: + require + not_void: h /= Void + do + owner := h + end + + +A `like` ''anchor'' type, known as an anchored type, may appear in any context in which ''anchor'' has a well-defined type; that is, ''anchor'' can be an attribute or function of the enclosing class. Then, assuming `T` is the type of ''anchor'', the type `like` ''anchor'' means the following: + +In the class in which it appears, `like` ''anchor'' means the same as `T`. For example, in `set_owner` above, the declaration of `h` has the same effect as if `h` had been declared of type `HOLDER`, the type of the anchor `owner` in class `ACCOUNT`. + +The difference comes in proper descendants: if a type redefinition changes the type of ''anchor'', any entity declared `like` ''anchor'' will be considered to have been redefined too. + +This means that anchored declarations are a form of of implicit covariant redeclaration. + +In the example, class `BUSINESS_ACCOUNT` only needs to redefine the type of `owner` (to `BUSINESS`). It doesn't have to redefine `set_owner` except if it needs to change its implementation or assertions. + +It is possible to use `Current` as anchor; the declaration `like Current` denotes a type based on the current class (with the same generic parameters if any). This is in fact a common case; we saw in [[ET: Inheritance#Structural_property_classes|"Structural property classes"]] , that it applies in class `COMPARABLE` to features such as + + is_less alias "<" (other: like Current): BOOLEAN ... + + +since we only want to compare two comparable elements of compatible types -- but not, for example, integer and strings, even if both types conform to `COMPARABLE`. (A "balancing rule" makes it possible, however, to mix the various arithmetic types, consistently with mathematical traditions, in arithmetic expressions such as `3 + 45.82` or boolean expressions such as 3 < 45.82.) + +Similarly, class `ANY` declares procedure `copy` as + + copy (other: like Current) ... + + +with the argument anchored to the current object. + +A final, more application-oriented example of anchoring to `Current` is the feature `merge` posited in an earlier example (in [[ET: The Dynamic Structure: Execution Model|"The Dynamic Structure: Execution Model"]] ) with the signature `merge (other: ACCOUNT)`. By using instead `merge (other: like Current)` we can ensure that in any descendant class -- `BUSINESS_ACCOUNT`, `SAVINGS_ACCOUNT`, `MINOR_ACCOUNT` ... -- an account will only be mergeable with another of a compatible type. + +====Qualified Anchored Declarations==== + +The anchored types shown above specify anchors which are either: +* The name of a query of the class in which the anchored declaration appears +** as in the case of: `set_owner (h: like owner)` or +* `Current` +** as in the case of: is_less alias "<" (other: like Current): BOOLEAN. + +Declarations can also use '''qualified''' anchored types. Consider this possible feature of `ACCOUNT`: + + + owner_name: like owner.name + + +Here the type of `owner_name` is determined as the type of the feature `name` as applied to the type of the feature `owner` of the current class. As you can imagine, for declarations like this to be valid, the feature names `name` and `owner` must be the names queries, i. e., the names of attributes or functions. + +This notion can be extended to declare the type through multiple levels of remoteness, so patterns like the following can be valid: + + + f: like a.b.c.d + + +For example if a class used a list of items of type `ACCOUNT`, it might include a declaration for that list: + + + all_accounts: LINKED_LIST [ACCOUNT] + -- All my accounts + + +This class could declare a feature with a qualified anchored type like this: + + + account_owner_name: like all_accounts.item.owner.name + + +A qualified anchored type can be qualified also by specifying a type for the qualifier: + + + owner_name: like {HOLDER}.name + + +In this case, the type of `owner_name` is the same as the type of the `name` feature of type `HOLDER`. + +Anchored declarations serve as another way to make software more concise and more resilient in a changing world. Let's look at one last example of using a qualified anchored type: + + + a: ARRAY [DATA] + ... + local + idx: like a.lower + do + from + idx := a.lower + until + idx > a.upper + + ... + + +Declaring the local entity `idx` as the qualified anchored type `like a.lower` puts this code (well, actually the producer of this code) in the enviable position of never having to worry about what type is used by class `ARRAY` for its feature `lower`. So, `{ARRAY}.lower` could be implemented as `INTEGER_32`, `NATURAL_64`, or some other similar type and this code would be fine, even if at some point that type changed. + +===Catcalls=== + +In our diversion about anchored declarations, we've gotten away from our discussion of covariance. Let's continue that now with a look at a side effect of covariance known as the '''catcall'''. + +Covariance makes static type checking more delicate; mechanisms of '''system validity''' and '''catcalls''' address the problem, discussed in detail in the book [[Object-Oriented Software Construction, 2nd Edition]]. + +The capabilities of polymorphism combined with covariance provide for powerful and flexible modeling. Under certain conditions, though, this flexibility can lead to problems. + +In short, you should be careful to avoid polymorphic '''catcalls'''. The '''call''' part of '''catcall''' means feature call. The '''cat''' part is an acronym for '''C'''hanged '''A'''vailability or '''T'''ype. What is changing here are features of descendant classes through the adaptation of inheritance. So maybe a descendant class has changed the export status of an inherited feature, so that that feature is not available on instances of the descendant class ... this is the case of '''changed availability'''. Or perhaps, through covariant modeling, the type of an argument to a feature in a descendant class has changed ... the case of '''changed type'''. + +Let's look at an example of changed type, due to covariant modeling. Suppose we have a system which uses the classes depicted on the following diagram: + +[[Image:Catcall example class diagram]] + +If in a client class, we declare the following attributes: + + + my_animal: ANIMAL + my_food_stuff: FOOD_STUFF + + +Also, the class `ANIMAL` contains the feature: + + eat (a_f: FOOD_STUFF) + -- Consume `a_f' + deferred + end + +This routine is implemented in `COW` as: + + eat (a_f: GRASS) + +and in class `LION` as: + + eat (a_f: WILDEBEEST_FILET) + + +So, covariant modeling is used to make the type of the argument for `eat` appropriate for each of `ANIMAL`'s heirs. + +Here's where the problem comes in. It is possible at run-time to attach to `my_animal` a direct instance of either `COW` or `LION`. So, `my_animal` is a polymorphic attribute. Likewise, it is possible at run-time that `my_food_stuff` could be attached to a direct instance of either `GRASS` or `WILDEBEEST_FILET`. + +So, the feature call: + + my_animal.eat (my_food_stuff) + +is a '''catcall''', because there is a possibility that through the changing type of the argument to `eat`, we could be causing a `COW` to engage in the inappropriate practice of eating a `WILDEBEEST_FILET`. + +Because this possibility exists, developers should exercise caution in using polymorphism and covariant modeling. + +In version 6.2 of EiffelStudio, a capability was added to detect harmful catcalls at runtime. So, in our example, if we used `my_animal.eat (my_food_stuff)` only to feed grass to cows and wildebeest filets to lions, then all would be well. But if we attempted to use that same call to feed an inappropriate food to an animal, we would see an exception. + +Likewise the compiler in EiffelStudio will produce warnings in cases in which catcalls are possible. Below is an example of the compiler warning issued on the example. + +[[Image:Catcall compiler warning]] + + + +==Non-conforming inheritance== + +So far, our experience with inheritance is that of "conforming" inheritance ... the most commonly used type of inheritance. Conforming inheritance is what allows a direct instance (in the '''catcall''' example above) of `COW` to be attached at runtime to an entity of type `ANIMAL`. This can be a powerful modeling capability, but it is this same polymorphism facilitated by conforming inheritance that puts us in the danger of using polymorphic '''catcalls'''. + +In cases in which polymorphic attachment is not anticipated, the possibility of catcalls can be avoided by using '''non-conforming inheritance'''. Non-conforming inheritance is just a more restrictive form of inheritance. + + +:'''Non-conforming inheritance allows features to be inherited from parent to heir, but it disallows polymorphic attachment of a direct instance of an heir to an entity based on a non-conforming parent.''' + + +In order to use non-conforming inheritance for a particular parent, we use the marker `{NONE}` in the appropriate inheritance part of the class: + + +class + MY_HEIR_CLASS + +inherit + MY_CONFORMING_PARENT + +inherit {NONE} + MY_NON_CONFORMING_PARENT + ... + + +Here there are two `inherit` clauses, one to specify conforming parents, and one to specify non-conforming parents. The clause specifying the conforming inheritance must precede the one specifying the non-conforming inheritance. + + +{{note|According to the Eiffel programming language [http://www.ecma-international.org/publications/standards/Ecma-367.htm standard], it is possible to have any number of inherit clauses an any order, however EiffelStudio versions as late as 6.5 allow only one conforming and one non-conforming clause, with the conforming clause preceding the non-conforming one. This restriction will be removed in a future release.}} + + +So, in this case, at runtime it is valid for a direct instance of `MY_HEIR_CLASS` to be attached to an entity of type `MY_CONFORMING_PARENT`, but not to an entity of type `MY_NON_CONFORMING_PARENT`. Accordingly, the compiler would reject any code in which an instance of `MY_HEIR_CLASS` could become attached to an entity of type `MY_NON_CONFORMING_PARENT`. Because the polymorphic attachment cannot be made, the possibility of a catcall is avoided. + + +{{note|As implemented, non-conforming inheritance mimics a copy/paste operation in which the features of the parent class are copied to the non-conforming heir class with no inheritance linkage maintained. You should keep this fact in mind when using non-conforming inheritance. In particular, `once` routines are replicated as unrelated features in the heir classes, so they share neither freshness status nor computed value (in the case of functions). Thus, a once function that comes from a non-conforming parent yields a result that is not related to the one returned by the parent's version.}} + + + diff --git a/documentation/18.11/eiffel/Tutorials/eiffel-tutorial-et/et-instructions.wiki b/documentation/18.11/eiffel/Tutorials/eiffel-tutorial-et/et-instructions.wiki new file mode 100644 index 00000000..a9c79262 --- /dev/null +++ b/documentation/18.11/eiffel/Tutorials/eiffel-tutorial-et/et-instructions.wiki @@ -0,0 +1,418 @@ +[[Property:title|ET: Instructions]] +[[Property:weight|-6]] +[[Property:uuid|628bf3db-728f-0b3c-bdbb-fe52deaae5b7]] +==Instructions== + +Eiffel has a remarkably small set of instructions. The basic computational instructions have been seen: creation, assignment, procedure call, retry. They are complemented by control structures: conditional, multi-branch, loop, as well as debug and check. + +===Assignment and attachment=== + +As noted above we have already introduced assignment. But let's take another look at the assignment in the context of the more abstract concept of '''attachment'''. Attachment can occur with reference types by assignment such as: + + x := y + +In this assignment, x is the target of the assignment and y is the source. The object associated with y becomes ''attached'' to the entity x. + +Attachment also occurs in other contexts. For example, when actual arguments are substituted for formal arguments in a call to a routine. + + f (w) + +In the call to f above, the object associated with the actual argument w will be ''attached'' to the formal argument for the duration of the execution of f. So, in this case, w can be viewed as the source of the attachment and the formal argument of f is the target. + +Other situations in which attachment occurs include [[ET: The Dynamic Structure: Execution Model#Creating and initializing objects|creation instructions]], attachment of [[Void-safety: Background, definition, and tools#The attached syntax (object test)|object test local variables]], and the attachment of local iteration cursors in the iteration form of the [[ET: Instructions#Loop|loop construct]]. + +We learned in the section on [[ET: Inheritance#Polymorphism|polymorphism]], that the type of the source of an assignment must conform to the type of the assignment's target. + +The rule that governs validity of assignments expands upon this and is generalized to apply to all attachments. + + +{{Rule|name=Assignment|text=An assignment is valid if and only if the type of its source expression is '''compatible''' with the type of its target entity. }} + + +The phrase "'''compatible with'''" in this rule means that either it "'''conforms to'''" or "'''converts to'''". + +We saw conformance defined in the section on [[ET: Inheritance#Polymorphism|Polymorphism]]. [[ET: Other Mechanisms#Convertibility|Convertibility]] is explained in the section on [[ET: Other Mechanisms#Convertibility|Other Mechanisms]]. + + +===Conditional=== + +A conditional instruction has the form + + if ... then + ... + elseif ... then + ... + else + ... + end + +The elseif ... then ... part (of which there may be more than one) and the else ... part are optional. After if and elseif comes a boolean expression; after then and else come zero or more instructions. + +===Multi-branch=== + +A multi-branch instruction has the form + + inspect + exp + when v1 then + inst + when v2 then + inst2 + ... + else + inst0 + end + + +where the else inst0 part is optional, exp is a character or integer expression, v1, v1, ... are constant values of the same type as exp, all different, and inst0, inst1, inst2, ... are sequences of zero or more instructions. + +The effect of such a multi-branch instruction, if the value of exp is one of the vi, is to execute the corresponding insti. If none of the vi matches, the instruction executes inst0, unless there is no else part, in which case it triggers an exception. + +{{note|Raising an exception is the proper behavior, since the absence of an else indicates that the author asserts that one of the values will match. If you want an instruction that does nothing in this case, rather than cause an exception, use an else part with an empty inst0. In contrast, if c then inst end with no else part does nothing in the absence of an else part, since in this case there is no implied claim that c must hold. }} + +===Loop=== + +The loop construct provides a flexible framework for iterative computation. Its flexibility lies in how the complete form can be tailored and simplified for certain purposes by including or omitting optional parts. + +You'll learn that the loop construct is always used in one of two forms: a '''base''' form which allows precise control over details of all loop aspects, and an '''iteration''' form which abstracts many of the details and provides a concise notation, ideal for traversing data structures and other objects which support iteration. + +We will explore the entire mechanism, but let's approach things a little at a time. + +====Two forms -- two examples==== + +First let's take a look at two examples. These examples accomplish the same goal: they both use a loop to visit and print the content of each node of a linked list of character strings. So, the list in question might be declared like this: + + + my_list: LINKED_LIST [STRING] + + +Here's one example: + + + from + my_list.start + until + my_list.off + loop + print (my_list.item) + my_list.forth + end + +''Loop example 1.'' + + +and the other: + + + across + my_list as ic + loop + print (ic.item) + end + +''Loop example 2.'' + + +At first observation, it may not appear that both of these examples are using the same language construct. But, indeed, they are simply two different forms of a single language construct, as you will see. + +Incidentally, there is no requirement that ''Loop example 1'' occupy multiple lines, and ''Loop example 2'' occupy only one line. ''Loop example 1'' could have been written like this: + + from + my_list.start + until + my_list.off + loop + print (my_list.item) + my_list.forth + end + +just as ''Loop example 2'' could have been written to take multiple lines. It comes down to a matter of balance among traditional style, conciseness, and readability. + +In fact, these two examples illustrate the two basic usage forms of the loop construct in Eiffel. The two basic forms can be differentiated by the parts of the construct with which they begin. + +The form shown in ''Loop example 1'' begins with an ''Initialization part'' ( from my_list.start ), which starts with the keyword from. Let's call this form the '''base''' form. So, the type of loop you see in ''Loop example 1'' has been the traditional mechanism for accomplishing iterative computation, including iterating across data structures. However, extensions to Eiffel's loop construct have provided a more concise way of expressing traversing "iterable" structures. + +This is the form shown in ''Loop example 2''. It begins with an ''Iteration part'' ( across my_list as c ), which starts with the keyword across. We'll call this form the '''iteration''' form. + +====A closer look at the ''base'' form==== + +What is happening in ''Loop example 1''? Let's dissect it and see. + +First there is the ''initialization'' part: + + + from + my_list.start + +''Initialization part.'' + + +The first thing to occur in the execution of the base loop is the execution of any instructions in the initialization part (it is permissible for the initialization part to be empty of instructions, but the keyword from must be present to distinguish the base loop form). In our example, the feature start is applied to my_list which will attempt to set the list cursor to the first element in my_list. + +The ''Exit condition part'': + + + until + my_list.off + +''Exit condition part.'' + + +The exit condition part of the loop construct defines the conditions under which the loop body (explained below) should no longer be executed. In our example, the loop will no longer execute if the cursor is "off", that is, there is no current item. So, if the list is empty, the loop body will not execute at all. + +The ''loop body'' part: + + + loop + print (my_list.item) + my_list.forth + +''loop body part.'' + + +The loop body part contains the sequence of instructions to be executed during each iteration. In the example, that includes printing the current list item and then advancing the cursor. At some point, the cursor will pass the last item in the list, causing the exit condition to become true and stop the loop's execution. So, at the risk of stating the obvious, the key to loops that always complete is to ensure that there is something in the loop body that is guaranteed always to cause the exit condition eventually to become true. Loop correctness will discussed in more detail [[#Loop invariants and variants|later]]. + +And finally, there's the ''End'' part: + + + end + +''end part.'' + + +====A closer look at the ''iteration'' form==== + +Now let's examine the iteration form (sometimes called the "across syntax") used in ''Loop example 2.'' + +The example begins with an iteration part: + + + across my_list as ic + +''Iteration part.'' + + +The iteration form is special in the sense that it is designed to work with objects which are ''iterable'', usually data structures. The iteration form always targets a particular object (usually a data structure) based on a class that inherits, either directly or indirectly from the library class ITERABLE. The iteration part specifies such a target for the iteration, in the case of our example, the target is my_list. + +The "as ic" indicates that a local iteration cursor object referenced by the name ic, and available only for the scope of the iteration, will be created to effect the iteration. The element of my_list which is currently referenced by the cursor ic is accessed through ic.item as you see in the loop body: + + + loop print (ic.item) + +''loop body part''. + + +Notice that the loop body does not contain the call to the structure's forth feature, as our example in base form did. Neither do you see the call to start nor the check of off in the exit condition. The iteration form abstracts these for you, relieving you of their burden ... while eliminating some opportunities for error. + +Notice also that the call "print (ic.item)"" accesses the current item as "ic.item"" versus "my_list.item"" in the base form. This is because in the iteration form, access to the current item is through the cursor variable, "ic" in the case of ''Loop example 2''. + +Concerning cursors, both ways of using the loop construct to traverse a structure employ a cursor. In the base form, the cursor is internal to the structure object. In the case of the example, that would be the instance of LINKED_LIST [STRING] called my_list. Applying the feature item to my_list retrieves the list element currently referenced by the cursor. In the iteration version of traversal, the variable ic holds the iteration cursor, external to the list object. So, you apply ic.item to get the current list element. The advantage to the external cursor is that multiple traversals of the structure can occur simultaneously without interfering with one another. This is possible in the base form, but only by saving and restoring the structure's cursor. + + +{{recommended|The ''iteration'' form of the loop construct is not appropriate for use in cases in which the target structure may be changed during the traversal. Therefore, if you choose to alter the structure during traversal, you must use the ''base'' loop form with explicit cursor manipulation. This is still tricky business, so you should be certain to protect your work with appropriate contracts.}} + + +Lastly, of course, the iteration form includes an ''end part'' ... at the end. + + +====The ''iteration'' form as a boolean expression==== + +In ''Loop example 2'', the loop behaves as an instruction. But it is possible to have the iteration loop form behave as a boolean expression. This is helpful in cases in which you might want to ask a question that can be answered by traversing all or part of a structure. + +To get this effect, you use the iteration form with one of two alternative body notations, the ''all body part'' or the ''some body part'' in place of the ''loop body''. When you use either of these notations, the ''body'' is a boolean expression. So, the forms for these body parts are: + + + all boolean_expression + +''all body part.'' + + + some boolean_expression + +''some body part.'' + + +So, to know if all the strings in my_list have lengths greater than three characters, we could code: + + + across my_list as ic all ic.item.count > 3 end + +''Loop example 3.'' + + +To know if at least one string in my_list has a length greater than three characters, we would use the ''some body part'': + + + across my_list as ic some ic.item.count > 3 end + +''Loop example 4.'' + +Of course you can use iteration loops with "all" or "some" bodies in the same way that you would any other boolean expression; in [[#Conditional|conditionals]], for example. + + +====Loop anatomy and rules for constructing loops==== + +Now that we've seen examples of the two forms of loops and broken down their component parts, we're ready to examine the anatomy of the entire construct in more detail. You may remember from the beginning of this discussion that the flexibility of the loop construct lies in its ability to use or omit its various parts to gain certain effects. + +Here are all the possible loop parts, most of which we've seen in examples, in the order in which they must appear when we code them: + + +{| border="2" cellpadding="8" +! This loop part: +! Has this pattern: +|- +| ''Iteration part'' || across expression as identifier +|- +| ''Initialization part'' || from zero_or_more_instructions +|- +| ''Invariant part'' || invariant assertion +|- +| ''Exit condition part'' || until boolean_expression +|- +| rowspan="3" | ''Body part'' || loop ''zero_or_more_instructions '' '''or''' +|- +| all ''boolean_expression'' '''or''' +|- +| some ''boolean_expression'' +|- +| ''Variant part'' || variant optional_tag: integer_expression +|- +| ''end part'' || end +|} + + +Apart from seeing examples, it is useful to understand some of the rules of constructing loops from these parts. Here's an informal summary of what you should know about putting together valid loops: + +# Any loop parts being used must appear in the order shown in the table above. +# Every loop used will assume one of the two forms mentioned early. As a result, every loop will begin either with the across keyword (''iteration'' form) or the from keyword (''base'' form). +# A ''Body part'' and an ''End part'' are both required for every loop. +## ''Body parts'' using either the all keyword or the some keyword are only allowed in the absence of an ''initialization part''. +# An ''exit condition part'' is required for all loops of ''base'' form. +# The expression you use in an ''iteration'' part, must have a type that is based on a class that inherits from the library class ITERABLE. +# The identifier you choose for the internal cursor used in loops of the ''iteration'' form shouldn't be the same as another identifier you are using. + +There are implications of these rules that are worth understanding. Let's look at some of them. + +Consider that all parts must appear in order (1) and that every loop starts with one of two keywords: either across or from (2). Taken together, these imply that it would be invalid for a loop in ''base'' form to include an ''iteration part''. However, the opposite is not true. Because the ''initialization part'' falls after the ''iteration part'' it is possible for a loop in ''iteration'' form to contain an ''initialization'' part. Imagine for example, that we wanted to compute the sum of the number of characters in all elements of the list of strings in our examples. The ''initialization'' part could be used to initialize the sum entity before starting the iteration: + + across + my_list as ic + from + sum := 0 + loop + sum := sum + ic.item.count + end + + +Loops of the ''base'' form require an ''exit condition part'' (4). This allows the possibility that ''Iteration'' loops ''may'' contain an ''exit condition part''. Indeed they may, but it is not required. Using an ''exit condition part'' in a loop of the ''iteration'' can be useful if you want to impose an early exit condition on an iteration. So, extending the previous example, if we wanted to sum the length of elements, but only until we reached an element whose content matched a certain criterion, we could add the ''exit condition part'': + + across + my_list as ic + from + sum := 0 + until + ic.item ~ "Stop now" + loop + sum := sum + ic.item.count + end + + +For loops of the ''iteration'' form, types of iteration targets must be based on classes inheriting from ITERABLE (5). What classes meet this criterion? All the appropriate classes in the EiffelBase library: lists, hash tables, arrays, intervals, etc. Although the details are beyond the scope of this tutorial, you also should recognize the implication that your own classes could be made iterable. + +One useful descendant of ITERABLE is the integer interval. The general operator "|..|" provides a concise way of creating the interval between two integers. So, you can use this to loop across a range of integers without a lot of setup. This example: + + across + 5 |..| 15 as ic + loop + print (ic.item.out+"%N") + end + +prints the integers in the interval 5 through 15. + +Also descending from ITERABLE are the iteration cursors themselves. This means that a cursor can be the target of a loop of the ''iteration'' form. Consider this example that prints the items in my_list in reverse order: + + across + my_list.new_cursor.reversed as ic + loop + print (ic.item) + end + +Here the feature new_cursor is applied to my_list. The result is a new iteration cursor for traversing my_list. Then the reversed feature is applied to that result, which itself results in an iteration cursor having the order of the elements reversed. It is this cursor that is used for ic in the traversal. + + +====Loop invariants and variants==== + +The only loop parts that we have yet to address are the ''invariant part'' and the ''variant part''. These two optional loop parts exist to help guarantee the correctness of loops. The ''invariant part'' expresses a loop invariant (not to be confused with [[ET: Design by Contract (tm), Assertions and Exceptions#Class invariants|class invariants]]). For the loop to be correct, the instructions in ''initialization part'' must ensure that the loop invariant assertion is true, and then every execution of the loop body must preserve the invariant; so the effect of the loop is to yield a state, eventually, in which both the loop invariant and the exit condition are true. + +The loop must terminate after a finite number of iterations, of course. This can be guaranteed by including the loop ''variant part''. The ''variant part'' provides an integer expression whose value is non-negative after the execution of the instructions in the ''initialization part''. The value of the variant is then decreased by at least one, while remaining non-negative, by any execution of the loop body. Because a non-negative integer cannot be decreased forever, this guarantees that the loop will terminate. + +When assertion monitoring is enabled for loop invariants and variants, the integrity of these properties is checked after initialization and after each loop iteration. An exception will be triggered if the loop invariant does not hold, or if the variant either becomes negative or does not decrease. + + +===Debug=== + +An occasionally useful instruction is debug (''Debug_key'', ... ) ''instructions'' end where ''instructions'' is a sequence of zero or more instructions and the part in parentheses is optional, containing if present one or more strings, called debug keys. The EiffelStudio compiler lets you specify the corresponding debug compilation option: yes, no, or an explicit debug key. The ''instructions'' will be executed if and only if the corresponding option is on. The obvious use is for instructions that should be part of the system but executed only in some circumstances, for example to provide extra debugging information. + +===Check=== + +The final instruction is connected with Design by Contract™. The instruction + + check + Assertion + end +where Assertion is a sequence of zero or more assertions, will have no effect unless assertion monitoring is turned on at the Check level or higher. If so it will evaluate all the assertions listed, having no further effect if they are all satisfied; if any one of them does not hold, the instruction will trigger an exception. + +This instruction serves to state properties that are expected to be satisfied at some stages of the computation -- other than the specific stages, such as routine entry and exit, already covered by the other assertion mechanisms such as preconditions, postconditions and invariants. A recommended use of check involves calling a routine with a precondition, where the call, for good reason, does not explicitly test for the precondition. Consider a routine of the form + + r (a_count: INTEGER) + require + valid_count: a_count >= minimum_allowable + do + ... + end + + +This routine will only work if its precondition is satisfied on entry. To guarantee this precondition, the caller may protect it by the corresponding test, as in + + if my_count >= a.minimum_allowable then + a.r (my_count) + end + + +In effect, this says that if the value of my_count meets r's precondition requirement, then call r, otherwise continue execution. This implies that there is something useful to be done in the case that the call to r could not be executed because the value of my_count did not meet the precondition. + +But suppose that due to previous processing, it is reasonably expected that my_count should always have a value that complies with r's precondition. In other words, it would always be expected that the call to r should proceed without failure. In this case it might be a good idea to use a check to document this property, + + check + my_count_is_large_enough: my_count >= a.minimum_allowable + -- Should always be large enough because ... + end + +if only to make sure that a reader of the code will realize that the omission of an explicit test was not a mistake. + +In production (finalized) mode, when assertion monitoring is typically turned off, this instruction will have no effect. But it will be precious for a maintainer of the software who is trying to figure out what it does, and in the process to reconstruct the original developer's reasoning. (The maintainer might of course be the same person as the developer, six months later.) And if the rationale is wrong somewhere, turning assertion checking on will immediately uncover the bug. + +There is, however, one form of check that continues to be monitored even when assertion monitoring is turned off. + + check Assertion then + Compound + end + +Here Assertion is a list of assertions as above, and Compound is a list of zero or more executable instructions. + +This variant is used often when ensuring [[Void-safe programming in Eiffel|void-safety]]. It is used make certain that certain detachable entities are actually attached to objects when expected, and to create a new void-safe scope for accessing the objects. For example: + + check attached my_detachable as l_temp then + l_temp.do_something + end + +In cases in which my_detachable is attached to an object (as is expected), the local entity l_temp will allow controlled access to the object during the scope of the check instruction. If a case occurs in which my_detachable is not attached to an object, then an exception is triggered. As noted above, for this variant of check, assertion monitoring is always in effect, even if it has been turned off for other cases. + +So, the form check ... then ... end is somewhat similar to if ... then ... end. The difference is that the if ... then ... end allows the possibility that valid cases might occur in which the boolean expression is not true, and processing continues. The check ... then ... end does not allow such a possibility. The boolean expression is expected always to hold. In fact, if the expression is not true, then like other assertion violations, this is indicative of a bug, and will cause an exception to be raised. + + +{{recommended|An extra indentation of the check part to separate it from the algorithm proper; and inclusion of a comment listing the rationale behind the developer's decision not to check explicitly for the precondition. }} + + + + diff --git a/documentation/18.11/eiffel/Tutorials/eiffel-tutorial-et/et-learn-more.wiki b/documentation/18.11/eiffel/Tutorials/eiffel-tutorial-et/et-learn-more.wiki new file mode 100644 index 00000000..4318f047 --- /dev/null +++ b/documentation/18.11/eiffel/Tutorials/eiffel-tutorial-et/et-learn-more.wiki @@ -0,0 +1,15 @@ +[[Property:title|ET: To Learn More]] +[[Property:weight|-1]] +[[Property:uuid|74a5c826-8f21-8cf2-4f2c-dee4ee28ead5]] +Beyond this introduction, you will find the following books essential to a mastery of the method and language:
+* [[Touch of class: Learning to Program Well with Objects and Contracts]], Bertrand Meyer, Springer-Verlag, 2009. A modern guide to developing durable skills for software professionals. +* [[Object-Oriented Software Construction, 2nd Edition]], Bertrand Meyer, Prentice Hall, 2nd edition 1997. (Be sure to get the second edition.) About object technology in general; presents the method behind Eiffel. +* [[Eiffel: The Language]], Bertrand Meyer, Prentice Hall, 1992. Language manual and reference. + + + + + + + + diff --git a/documentation/18.11/eiffel/Tutorials/eiffel-tutorial-et/et-lexical-conventions-and-style-rules.wiki b/documentation/18.11/eiffel/Tutorials/eiffel-tutorial-et/et-lexical-conventions-and-style-rules.wiki new file mode 100644 index 00000000..3a801bcb --- /dev/null +++ b/documentation/18.11/eiffel/Tutorials/eiffel-tutorial-et/et-lexical-conventions-and-style-rules.wiki @@ -0,0 +1,107 @@ +[[Property:title|ET: Lexical Conventions and Style Rules]] +[[Property:weight|-2]] +[[Property:uuid|60fdf029-8626-166d-cc4f-9069aacdda7f]] +Eiffel software texts are free-format: distribution into lines is not semantically significant, and any number of successive space and line-return characters is equivalent to just one space. The style rules suggest indenting software texts as illustrated by the examples in this chapter. + +Successive declarations or instructions may be separated by semicolons. Eiffel's syntax has been so designed, however, that (except in rare cases) '''the semicolon is optional'''. Omitting semicolons for elements appearing on separate lines lightens text and is the recommended practice since semicolons, as used by most programming languages, just obscure the text by distracting attention from the actual contents. Do use semicolons if you occasionally include successive elements on a single line. + +56 names -- all unabbreviated single English words, except for elseif which is made of two words -- are reserved, meaning that you cannot use them to declare new entities. Here is the list: + + +{| border="1" +|- +| agent +| alias +| all +| and +| as +| assign +| check +|- +| class +| convert +| create +| Current +| debug +| deferred +| do +|- +| else +| elseif +| end +| ensure +| expanded +| export +| external +|- +| False +| feature +| from +| frozen +| if +| implies +| indexing +|- +| infix +| inherit +| inspect +| invariant +| is +| like +| local +|- +| loop +| not +| obsolete +| old +| once +| or +| prefix +|- +| Precursor +| pure +| redefine +| reference +| rename +| require +| rescue +|- +| Result +| retry +| separate +| then +| True +| TUPLE +| undefine +|} + + +Since this tutorial has covered all the essential mechanisms, you may ignore the keywords not encountered; they are reserved for future use. + +Most of the reserved words are keywords, serving only as syntactic markers, and written in boldface in typeset texts such as the present one: class, feature, inherit. The others, such as Current, directly carry a semantic denotation; they start with an upper-case letter and are typeset in boldface. + +These conventions about letter case are only style rules. Eiffel is case-insensitive, since it is foolish to assume that two identifiers denote two different things just on the basis of a letter written in lower or upper case. The obvious exception is manifest character constants (appearing in single quotes, such as 'A') and manifest character strings (appearing in double quotes, such as "UPPER and lower"). + +The style rules, however, are precise, and any serious Eiffel project will enforce them; the tools of EiffelStudio also observe them in the texts they output (although they will not mess up with your source text unless you ask them to reformat it). Here are the conventions, illustrated by the examples of this tutorial: +* Class names in upper case, as ACCOUNT. +* Non-constant feature names and keywords in lower case, as balance and class. +* Constant features and predefined entities and expressions with an initial upper case, as Avogadro and Result. + +In typeset documents including Eiffel texts, the standard for font styles is also precise. You should use bold face for keywords and italics for all other Eiffel elements. Comments, however, are typeset in roman. This lets a software element, such as an identifier, stand out clearly in what is otherwise a comment text expressed in English or another human language, as in the earlier example + + -- Add `sum' to account. + + +which makes clear that sum is a software element, not the English word. + +There is also an Eiffel style to the choice of identifiers. For features, stay away from abbreviations and use full words. In multi-word identifiers, separate the constituents by underscores, as in LINKED_LIST and set_owner. The competing style of no separation but mid-identifier upper-case, as in linkedList or setOwner, is less readable and not in line with standard Eiffel practices. + +Features of reusable classes should use consistent names. A set of standard names -- put for the basic command to add or replace an element, count for the query that returns the number of element in a structure, item to access an element -- is part of the style rules, and used systematically in EiffelBase. Use them in your classes too. + +For local entities and formal arguments of routines, it is all right to use abbreviated names, since these identifiers only have a local scope, and choosing a loud name would give them too much pretense, leading to potential conflicts with features. + +The complete set of style rules applied by ISE is available on the web in both [http://archive.eiffel.com/doc/manuals/language/style/page.html HTML] and [http://archive.eiffel.com/doc/manuals/language/style/style.pdf PDF] forms. These rules are an integral part of the Eiffel method; in quality software, there is no such thing as a detail. Applying them systematically promotes consistency between projects in the Eiffel world, enhances reusability, and facilitates everyone's work. + + + + diff --git a/documentation/18.11/eiffel/Tutorials/eiffel-tutorial-et/et-once-routines-and-shared-objects.wiki b/documentation/18.11/eiffel/Tutorials/eiffel-tutorial-et/et-once-routines-and-shared-objects.wiki new file mode 100644 index 00000000..a6659d73 --- /dev/null +++ b/documentation/18.11/eiffel/Tutorials/eiffel-tutorial-et/et-once-routines-and-shared-objects.wiki @@ -0,0 +1,91 @@ +[[Property:title|ET: Once routines and shared objects]] +[[Property:weight|-5]] +[[Property:uuid|bc42c52f-c668-6036-9540-55d0f48b05cb]] +==About ''once'' routines== + +The Eiffel's method obsession with extendibility, reusability and maintainability yields, as has been seen, modular and decentralized architectures, where inter-module coupling is limited to the strictly necessary, interfaces are clearly delimited, and all the temptations to introduce obscure dependencies, in particular global variables, have been removed. There is a need, however, to let various components of a system access common objects, without requiring their routines to pass these objects around as arguments (which would only be slightly better than global variables). For example various classes may need to perform output to a common "console window", represented by a shared object. + +Eiffel addresses this need through an original mechanism that also takes care of another important issue, poorly addressed by many design and programming approaches: initialization. The idea is simple: if instead of do the implementation of an effective routine starts with the keyword once, it will only be executed the first time the routine is called during a system execution (or, in a multi-threaded environment, the first time in each thread), regardless of what the caller was. Subsequent calls from the same caller or others will have no effect; if the routine is a function, it will always return the result computed by the first call -- object if an expanded type, reference otherwise. + +In the case of procedures, this provides a convenient initialization mechanism. A delicate problem in the absence of a once mechanism is how to provide the users of a library with a set of routines which they can call in any order, but which all need, to function properly, the guarantee that some context had been properly set up. Asking the library clients to precede the first call with a call to an initialization procedure setup is not only user-unfriendly but silly: in a well-engineered system we will want to check proper set-up in every one of the routines, and report an error if necessary; but then if we were able to detect improper set-up we might as well shut up and set up ourselves (by calling setup). This is not easy, however, since the object on which we call setup must itself be properly initialized, so we are only pushing the problem further. Making setup a once procedure solves it: we can simply include a call + + setup + + +at the beginning of each affected routine; the first one to come in will perform the needed initializations; subsequent calls will have, as desired, no effect. + +Once functions will give us shared objects. A common scheme is + + console: WINDOW + -- Shared console window + once + create Result.make (...) + end + + +Whatever client first calls this function will create the appropriate window and return a reference to it. Subsequent calls, from anywhere in the system, will return that same reference. The simplest way to make this function available to a set of classes is to include it in a class SHARED_STRUCTURES which the classes needing a set of related shared objects will simply inherit. + +For the classes using it, console, although a function, looks very much as if it were an attribute -- only one referring to a shared object. + +The "[[ET: Hello World|Hello World]]" system at the beginning of this discussion used an output instruction of the form io. put_string (some_string). This is another example of the general scheme illustrated by console. Feature io, declared in ANY and hence usable by all classes, is a once function that returns an object of type STANDARD_FILES (another Kernel Library class) providing access to basic input and output features, one of which is procedure put_string. Because basic input and output must all work on the same files, io should clearly be a once function, shared by all classes that need these mechanisms. + +==Adjusting once semantics with "once keys"== + +Sometimes it is helpful to adjust the way that once routines work, and that is done by applying '''once keys'''. For example, in multithreaded mode, it is reasonable most often for once routines to be executed once per ''thread'', versus once per ''process''. Therefore, the default once syntax, as shown in the example above, would behave as once per thread in multithreaded mode. + +Sometimes, however, it is useful in multithreaded mode to create an object which can be shared among threads. To do this, once per process is needed. To create effects like this which are outside the default behavior, we can use once "keys". In following example, a once key is used to specify that the once routine is executed only once per process: + + + shared_object: SOME_TYPE + -- An object that can be shared among threads + -- without being reinitialized. + once ("PROCESS") + create Result.make (...) + end + + +Other valid once keys are "THREAD" and "OBJECT". Of course, "THREAD" ensures that the once routine executes only the first time it is called during the execution of a particular process thread. "OBJECT" is used when it is desirable to have a once routine executed on a once per object basis. + + +{| border="2" +|+ '''How once keys affect once routine execution''' +! Once key ... !! Routine executed the first time it is called ... +|- +| PROCESS || During process execution +|- +| THREAD || During each process thread execution +|- +| OBJECT || By each instance +|} + + +THREAD is the default once key if none is specified (which for single threaded systems will have the same effect as PROCESS). + +The concept of once keys is open ended, so additional keys may become supported in the future to allow even finer grained control of once routine behavior. + +==Once per object internal implementation warning == + +{{warning|As of version 6.6, once per object is implemented using 2 or 3 implementation attributes (these are used to store whether the once routine has already called or not, the eventual exception if any, and the result value if any).

The implementation attributes are named starting with an underscore '_', and if you use the class INTERNAL, the implementation attributes will be included in the field_count, and available through the INTERNAL features.
However this might change in the future, and the implementation attributes might be hidden, so you should not rely on them for your applications.
One last technical detail is that for now a once per object is transient (i.e the associated implementation attributes are [[ET: The Dynamic Structure: Execution Model#Transient attributes|transient]]).
}} + + +==Once routines and exceptions== + +It is possible that during the execution that happens when a once routine is called for the first time, an exception may occur. If this happens, then the '''same exception will be raised on each subsequent''' call to the once routine. + +==Syntax from previous versions== + +The syntax shown above is the current standard syntax. However in Eiffel code written for previous versions, you may run across once keys for multithreaded systems which are expressed in a different syntax. Specifically, the older syntax used a feature's note clause to specify a once key, as in the following example. + + + shared_object: SOME_TYPE + -- Obsolete syntax + -- An object that can be shared among threads + -- without being reinitialized. + note + once_status: global + once + create Result.make (...) + end + + + diff --git a/documentation/18.11/eiffel/Tutorials/eiffel-tutorial-et/et-other-mechanisms.wiki b/documentation/18.11/eiffel/Tutorials/eiffel-tutorial-et/et-other-mechanisms.wiki new file mode 100644 index 00000000..6149707e --- /dev/null +++ b/documentation/18.11/eiffel/Tutorials/eiffel-tutorial-et/et-other-mechanisms.wiki @@ -0,0 +1,343 @@ +[[Property:title|ET: Other Mechanisms]] +[[Property:weight|-4]] +[[Property:uuid|c0a01664-194c-4e84-0517-8e7c1ca61dec]] +We now examine a few important mechanisms that complement the preceding picture. + + +==Manifest constants== + +Sometimes we want to provide in software text a self-denoting value of a particular type. In Eiffel this is what we call a '''manifest constant'''. For example, if we are searching an indexed structure, we might have an integer variable that we would want to initialize to reference the first item in the structure: + + + my_index := 1 + + +In this case we used a manifest constant, 1, to provide an initial value for my_index. In particular, this is a manifest integer. + +Eiffel also supports [[Eiffel Programming Language Syntax#Manifest constants|manifest constants]] for real (and double) numbers (ex: 3.1415), boolean values (ex: True, False), and characters (ex: 'A', with [[Eiffel programming language syntax#Special characters|special characters]] expressed using a percent sign as in '%N' for new line, '%B' for backspace, '%"' for double quote, and '%U' for null). + +Manifest constants are also available for strings, using double quotes as in: "Hello world!". As with character constants, special characters are denoted using the % codes. + +===Verbatim strings=== + +You may occasionally have a need for a manifest string that represents a multi-line formatted string. In Eiffel we call this type of manifest string a '''verbatim string''', and there is a special syntax for specifying verbatim strings in Eiffel code. Verbatim strings are either '''aligned''' or '''non-aligned'''. Aligned verbatim strings will automatically be adjusted so that their leftmost line (the line with text characters closest to the left margin) contains no "white space" to the left of the first text character. For non-aligned verbatim strings, the white space is left untouched. You use a slightly different way of specifying each type of string. For example, this aligned verbatim string: + + + my_aligned_string: STRING = + "[ + Thrice hail the still unconquered King of Song! + For all adore and love the Master Art + That reareth his throne in temple of the heart; + And smiteth chords of passion full and strong + Till music sweet allures the sorrowing throng! + ]" + + +will print like this: + + + Thrice hail the still unconquered King of Song! + For all adore and love the Master Art + That reareth his throne in temple of the heart; +And smiteth chords of passion full and strong + Till music sweet allures the sorrowing throng! + + +The same string, declared as a non-aligned verbatim string: + + + my_non_aligned_string: STRING = + "{ + Thrice hail the still unconquered King of Song! + For all adore and love the Master Art + That reareth his throne in temple of the heart; + And smiteth chords of passion full and strong + Till music sweet allures the sorrowing throng! + }" + + +will print like this: + + + Thrice hail the still unconquered King of Song! + For all adore and love the Master Art + That reareth his throne in temple of the heart; + And smiteth chords of passion full and strong + Till music sweet allures the sorrowing throng! + + +The difference in declaration is that the aligned verbatim string uses as its "opener" the double-quote plus bracket combination, " "[ ", and the bracket plus double quote, " ]" ", as its "closer". The non-aligned verbatim string uses braces, " { " and " } " instead of the bracket. + +The syntax for specifying verbatim strings allows an option for the situation in which the specified string might conflict with the "closer". You can include a simple string between the double quote and the bracket on each end of the verbatim string to guarantee uniqueness. Here's our aligned verbatim string with the simple string " *? " inserted in the opener and closer: + + + my_aligned_string: STRING = + "*?[ + Thrice hail the still unconquered King of Song! + For all adore and love the Master Art + That reareth his throne in temple of the heart; + And smiteth chords of passion full and strong + Till music sweet allures the sorrowing throng! + ]*?" + + + +==Constant attributes== + +The attributes studied earlier were variable: each represents a field present in each instance of the class and changeable by its routines. + +It is also possible to declare '''constant attributes''', as in + + Solar_system_planet_count: INTEGER = 8 + + +These will have the same value for every instance and hence do not need to occupy any space in objects at execution time. (In other approaches similar needs would be addressed by symbolic constants, as in Pascal or Ada, or macros, as in C.) + +What comes after the = is a manifest constant. So you can declare a constant attribute for any type for which there is a manifest constant. + + +==Obsolete features and classes== + +One of the conditions for producing truly great reusable software is to recognize that although you should try to get everything right the first time around you won't always succeed. But if "good enough" may be good enough for application software, it's not good enough, in the long term, for reusable software. The aim is to get ever closer to the asymptote of perfection. If you find a better way, you must implement it. The activity of generalization, discussed as part of the lifecycle, doesn't stop at the first release of a reusable library. + +This raises the issue of backward compatibility: how to move forward with a better design, without compromising existing applications that used the previous version? + +The notion of obsolete class and feature helps address this issue. By declaring a feature as obsolete, using the syntax + + enter (i: INTEGER; x: G) + obsolete + "Use ` put (x, i)' instead " + require + ... + do + put (x, i) + end + + +you state that you are now advising against using it, and suggest a replacement through the message that follows the keyword obsolete, a mere string. The obsolete feature is still there, however; using it will cause no other harm than a warning message when someone compiles a system that includes a call to it. Indeed, you don't want to hold a gun to your client authors' forehead (''"Upgrade now or die !"''); but you do want to let them know that there is a new version and that they should upgrade at their leisure. + +Besides routines, you may also mark classes as obsolete. + +The example above is a historical one, involving an early change of interface for the EiffelBase library class ARRAY; the change affected both the feature's name, with a new name ensuring better consistency with other classes, and the order of arguments, again for consistency. It shows the recommended style for using obsolete:
+* In the message following the keyword, explain the recommended replacement. This message will be part of the warning produced by the compiler for a system that includes the obsolete element. +* In the body of the routine, it is usually appropriate, as here, to replace the original implementation by a call to the new version. This may imply a small performance overhead, but simplifies maintenance and avoids errors. + + +It is good discipline not to let obsolete elements linger around for too long. The next major new release, after a suitable grace period, should remove them. + +The design flexibility afforded by the obsolete keyword is critical to ensure the harmonious long-term development of ambitious reusable software. + + +==Creation variants== + +The basic forms of creation instruction, and the one most commonly used, are the two illustrated earlier ( [[ET: The Dynamic Structure: Execution Model#Creating_and_initializing_objects|"Creating and initializing objects"]] ): + + create x.make (2000) + create x + + +the first one if the corresponding class has a create clause, the second one if not. In either form you may include a type name in braces, as in + + create {SAVINGS_ACCOUNT} x.make (2000) + + +which is valid only if the type listed, here SAVINGS_ACCOUNT, conforms to the type of x, assumed here to be ACCOUNT. This avoids introducing a local entity, as in + + local + xs: SAVINGS_ACCOUNT + do + create xs.make (2000) + x := xs + ... + + +and has exactly the same effect. Another variant is the '''creation expression''', which always lists the type, but returns a value instead of being an instruction. It is useful in the following context: + + some_routine (create {ACCOUNT}.make (2000)) + + +which you may again view as an abbreviation for a more verbose form that would need a local entity, using a creation instruction: + + local + x: ACCOUNT + do + create x.make (2000) + some_routine (x) + ... + + +Unlike creation instructions, creation expressions must always list the type explicitly, {ACCOUNT} in the example. They are useful in the case shown: creating an object that only serves as an argument to be passed to a routine. If you need to retain access to the object through an entity, the instruction create x ... is the appropriate construct. + +The creation mechanism gets an extra degree of flexibility through the notion of default_create. The simplest form of creation instruction, create x without an explicit creation procedure, is actually an abbreviation for create x.default_create, where default_create is a procedure defined in class ANY to do nothing. By redefining default_create in one of your classes, you can ensure that create x will take care of non-default initialization (and ensure the invariant if needed). When a class has no create clause, it's considered to have one that lists only default_create. If you want to allow create x as well as the use of some explicit creation procedures, simply list default_create along with these procedures in the create clause. To disallow creation altogether, include an empty create clause, although this technique is seldom needed since most non-creatable classes are deferred, and one can't instantiate a deferred class. + +One final twist is the mechanism for creating instances of formal generic parameters. For x of type G in a class C [G], it wouldn't be safe to allow create x, since G stands for many possible types, all of which may have their own creation procedures. To allow such creation instructions, we rely on constrained genericity. You may declare a class as + + [G -> T create cp end] + + +to make G constrained by T, as we learned before, and specify that any actual generic parameter must have cp among its creation procedures. Then it's permitted to use create x.cp, with arguments if required by cp, since it is guaranteed to be safe. The mechanism is very general since you may use ANY for T and default_create for cp. The only requirement on cp is that it must be a procedure of T, not necessarily a creation procedure; this permits using the mechanism even if T is deferred, a common occurrence. It's only descendants of T that must make cp a creation procedure, by listing it in the create clause, if they want to serve as actual generic parameters for C. + + +==Non-object calls== + +The Eiffel model for object-oriented computation involves the application of some feature f to some object x, and possibly passing arguments a: + + + x.f (a) + + +This type of feature call is known as an '''object call''' because it applies the feature to a target object, in this case x. However, under certain circumstances we may apply a feature of a class in a fashion that does not involve a target object. This type of call is a '''non-object call'''. In place of the target object, the syntax of the non-object call uses the type on which the feature can be found. + + + circumference := radius * 2.0 * {MATH_CONST}.Pi + + +In the sample above, the call to feature {MATH_CONST}.Pi is a non-object call. This case illustrates one of the primary uses of non-object calls: constants. The library class MATH_CONST contains commonly used mathematical constants. Non-object calls make it possible to use the constants in MATH_CONST without having to create an instance of MATH_CONST or inherit from it. + +The other primary use is for external features. One example is when we use Microsoft .NET classes from Eiffel code and have to access mechanisms for which there is no direct analog in Eiffel. Microsoft .NET supports so-called "static" methods and enumeration types. To access these, we use non-object calls. In the example below, a non-object call is used to access the enumeration CreateNew from the .NET enumeration type System.IO.FileMode. + + + create my_file_stream.make ("my_file.txt", {FILE_MODE}.create_new) + + +The validity of a non-object call is restricted in ways that mirror these primary uses. That is, any feature called in a non-object call must be either a constant attribute or an external feature. See the [[ECMA Standard 367|ISO/ECMA Eiffel standard document]] for additional details. + + +==Convertibility== + +It is useful at times to designate that instances of one type can be created through the controlled conversion of instances of some other type. This can be done through a safe Eiffel type conversion mechanism called '''convertibility'''. + +Convertibility is useful when refactoring, moving from one design to another, or, as you will see in the example, accommodating external technologies over which we have no control. + + +{{Definition|Convertibility: converts to, converts from|
+
+A type U based on a class CU '''converts to''' a type T based on a class CT (and T '''converts from''' U) if either
+
+ CT has a ''conversion procedure'' using U as a conversion type, or
+
+ CU has a ''conversion query'' listing T as a conversion type,
+
+but not both.}} + + +Before we get into an example of convertibility, let's list some of its underlying principles: +# Conversion Principle: No type may both ''conform'' and ''convert'' to another. +# Conversion Asymmetry Principle: No type may convert to another through both a ''conversion procedure'' and a ''conversion query''. +# Conversion Non-transitivity Principle: That V converts to U and U converts to T does not imply that V converts to T. + +Let's look at an example with which you may already be familiar. + + + my_string: STRING_8 -- Native Eiffel string + my_system_string: SYSTEM_STRING -- Native Microsoft .Net string + + … + + my_string := my_system_string + + +In the snippet above, we have attributes declared of type STRING_8 and SYSTEM_STRING. + +We know that if we have a attribute of type STRING_8 that we can make a direct assignment of a .Net type of string (that is, the .Net type System.String which we see as class SYSTEM_STRING) to our STRING_8 attribute. + +We know also that SYSTEM_STRING does not conform to STRING_8, so according to the definition of [[ET: Instructions#Assignment and attachment|compatibility]], this must happen through conversion. + +Therefore SYSTEM_STRING converts to STRING_8. And according to the definition above this means that either: + +# Class SYSTEM_STRING has a conversion query listing STRING_8 as a conversion type, or +# Class STRING_8 has a conversion procedure listing SYSTEM_STRING as a conversion type + +In this case STRING_8 has a conversion procedure for objects of type SYSTEM_STRING. Conversion procedures are always [[ET: The Dynamic Structure: Execution Model#Creating and initializing objects|creation procedures]]. So they appear in both the create and the convert parts of the class. + + + class STRING_8 + … + create + make_from_cil + … + convert + make_from_cil ({SYSTEM_STRING}) + … + + +We won't show the implementation of the conversion procedure, but as you can imagine, it initializes its target with the content of its argument. + +Because of convertibility, this code: + + + my_string := my_system_string + + +is equivalent to: + + + create my_string.make_from_cil (my_system_string) + + +So, we've seen how SYSTEM_STRING converts to STRING_8. But, in the context of our example, we could also do this: + + + my_system_string := my_string + + +Which means that STRING_8 converts to SYSTEM_STRING. The convert part of class STRING_8 also has a conversion query listing SYSTEM_STRING as a conversion type: + + + class STRING_8 + … + create + make_from_cil + … + convert + make_from_cil ({SYSTEM_STRING}) + to_cil: {SYSTEM_STRING} + … + + +Because of convertibility, this code: + + + my_system_string := my_string + + +is equivalent to: + + + my_system_string := my_string.to_cil + + +You should bear in mind that assignments are not the only situation in which conversions take place. Convertibility works for other types of attachments as well. For example, if a routine calls for an argument of type SYSTEM_STRING, and you supply an actual argument of type STRING_8, this constitutes an attachment, and the conversion from STRING to SYSTEM_STRING will occur. + + +==Tuple types== + +The study of genericity described arrays. Another common kind of container objects bears some resemblance to arrays: sequences, or "tuples", of elements of specified types. The difference is that all elements of an array were of the same type, or a conforming one, whereas for tuples you will specify the types we want for each relevant element. A typical tuple type is of the form + + TUPLE [X, Y, Z] + + +denoting a tuple of at least three elements, such that the type of the first conforms to X, the second to Y, and the third to Z. + +You may list any number of types in brackets, including none at all: TUPLE, with no types in brackets, denotes tuples of arbitrary length. + +{{info|The syntax, with brackets, is intentionally reminiscent of generic classes, but TUPLE is a reserved word, not the name of a class; making it a class would not work since a generic class has a fixed number of generic parameters. You may indeed use TUPLE to obtain the effect of a generic class with a variable number of parameters. }} + +To write the tuples themselves -- the sequences of elements, instances of a tuple type -- you will also use square brackets; for example + + [x1, y1, z1] + + +with x1 of type X and so on is a tuple of type TUPLE [X, Y, Z]. + +The definition of tuple types states that TUPLE [X1 ... Xn] denotes sequences of at least n elements, of which the first n have types respectively conforming to X1, ..., Xn. Such a sequence may have more than n elements. + +Features available on tuple types include count: INTEGER, yielding the number of elements in a tuple, item (i: INTEGER): ANY which returns the i-th element, and put which replaces an element. + +Tuples are appropriate when these are the only operations you need, that is to say, you are using sequences with no further structure or properties. Tuples give you "anonymous classes" with predefined features count, item and put. A typical example is a general-purpose output procedure that takes an arbitrary sequence of values, of arbitrary types, and prints them. It may simply take an argument of type TUPLE, so that clients can call it under the form + + write ([your_integer, your_real, your_account]) + + +As soon as you need a type with more specific features, you should define a class. + diff --git a/documentation/18.11/eiffel/Tutorials/eiffel-tutorial-et/et-overview.wiki b/documentation/18.11/eiffel/Tutorials/eiffel-tutorial-et/et-overview.wiki new file mode 100644 index 00000000..805ddf19 --- /dev/null +++ b/documentation/18.11/eiffel/Tutorials/eiffel-tutorial-et/et-overview.wiki @@ -0,0 +1,24 @@ +[[Property:title|ET: Overview]] +[[Property:weight|-15]] +[[Property:uuid|0eaddff9-5d72-87fc-663a-2fc8a9152c25]] +Eiffel is a method and language for the efficient description and development of quality systems. + +As a language, Eiffel is more than a programming language. It covers not just programming in the restricted sense of implementation but the whole spectrum of software development:
+* ''Analysis, modeling and specification'', where Eiffel can be used as a purely descriptive tool to analyze and document the structure and properties of complex systems (even non-software systems). +* ''Design and architecture'', where Eiffel can be used to build solid, flexible system structures. +* ''Implementation'', where Eiffel provides practical software solutions with an efficiency comparable to solutions based on such traditional approaches as C and Fortran. +* ''Maintenance'', where Eiffel helps thanks to the architectural flexibility of the resulting systems. +* ''Documentation'', where Eiffel permits automatic generation of documentation, textual and graphical, from the software itself, as a partial substitute for separately developed and maintained software documentation. + + +Although the language is the most visible part, Eiffel is best viewed as a '''method''', which guides system analysts and developers through the process of software construction. The Eiffel method is focused on both productivity (the ability to produce systems on time and within budget) and quality, with particular emphasis on the following quality factors:
+* ''Reliability:'' producing bug-free systems, which perform as expected. +* ''Reusability:'' making it possible to develop systems from prepackaged, high-quality components, and to transform software elements into such reusable components for future reuse. +* ''Extendibility:'' developing software that is truly soft -- easy to adapt to the inevitable and frequent changes of requirements and other constraints. +* ''Portability:'' freeing developers from machine and operating system peculiarities, and enabling them to produce software that will run on many different platforms. +* ''Maintainability:'' yielding software that is clear, readable, well structured, and easy to continue enhancing and adapting. + + + + + diff --git a/documentation/18.11/eiffel/Tutorials/eiffel-tutorial-et/et-software-process-eiffel.wiki b/documentation/18.11/eiffel/Tutorials/eiffel-tutorial-et/et-software-process-eiffel.wiki new file mode 100644 index 00000000..3beba97e --- /dev/null +++ b/documentation/18.11/eiffel/Tutorials/eiffel-tutorial-et/et-software-process-eiffel.wiki @@ -0,0 +1,66 @@ +[[Property:title|ET: The Software Process in Eiffel]] +[[Property:weight|-13]] +[[Property:uuid|eef7f31a-25de-93cc-9a33-41d991c51ccb]] +Eiffel, as noted, supports the entire lifecycle. The underlying view of the system development lifecycle is radically different not only from the traditional "Waterfall" model (implying a sequence of discrete steps, such as analysis, global design, detailed design, implementation, separated by major changes of method and notation) but also from its more recent variants such as the spiral model or "rapid prototyping", which remain predicated on a synchronous, full-product process, and retain the gaps between successive steps. + +Clearly, not everyone using Eiffel will follow to the letter the principles outlined below; in fact, some highly competent and successful Eiffel developers may disagree with some of them and use a different process model. In the author's mind, however, these principles fit best with the language and the rest of the method, even if practical developments may fall short of applying their ideal form. + +==Clusters and the cluster model== + +Unlike earlier approaches, the Eiffel model assumes that the system is divided into a number of subsystems or '''clusters'''. It keeps from the Waterfall a sequential approach to the development of each cluster (without the gaps), but promotes '''concurrent engineering''' for the overall process, as suggested by the following picture: + + +[[Image:tutorial-2]] + + +The Eiffel techniques developed below, in particular information hiding and Design by Contract, make the concurrent engineering process possible by letting the clusters rely on each other through clearly defined interfaces, strictly limiting the amount of knowledge that one must acquire to use the cluster, and permitting separate testing. When the inevitable surprises of a project happen, the project leader can take advantage of the model's flexibility, advancing or delaying various clusters and steps through dynamic reallocation of resources. + +==The Single Product Principle== + +Each of the individual cluster life cycles is based on a continuous progression of activities, from the more abstract to the more implementation-oriented: + + +[[Image:tutorial-3]] + + +You may view this picture as describing a process of accretion (as with a stalactite), where each steps enriches the results of the previous one. Unlike traditional views, which emphasize the multiplicity of software products -- analysis document, global and detailed design documents, program, maintenance reports... --, the principle is here to treat the software as a '''single product''' which will be repeatedly refined, extended and improved. The Eiffel programming language supports this view by providing high-level notations that can be used throughout the lifecycle, from the most general and software-independent activities of system modeling to the most exacting details of implementation tuned for optimal run-time performance. + +These properties make Eiffel span the scope of both "object-oriented methods", with their associated notations such as UML and supporting CASE tools (whereas most such solutions do not yield an executable result), and "programming languages" (whereas most such languages are not suitable for design and analysis). + +Additionally, within the EiffelStudio development environment, the concept of '''single product''' is extended to documents external to the software itself, by the [[Eiffel Information System|Eiffel Information System (EIS)]] which allows the linking elements of the software text to portions of external documents and vice versa. + +==Seamlessness and reversibility== + +The preceding ideas define the '''seamless approach''' embodied by Eiffel. With seamlessness goes '''reversibility''': the ability to go back, even late in the process, to earlier stages. Because the developers work on a single product, they can take advantages of bouts of late wisdom -- such as a great idea for adding a new function, discovered only at implementation time -- and integrate them in the product. Traditional approaches tend to discourage reversibility because it is difficult to guarantee that the analysis and design will be updated with the late changes. With the single-product principle, this is much easier to achieve. + +Seamlessness and reversibility enhance extendibility by providing a direct mapping from the structure of the solution to the structure of the problem description, making it easier to take care of customers' change requests quickly and efficiently. They promote reliability, by avoiding possible misunderstandings between customers' and developers' views. They are a boost to maintainability. More generally, they yield a smooth, consistent software process that helps both quality and productivity. + +==Generalization and reuse== + +The last step of the cluster, Generalization, is unheard of in traditional models. Its task is to prepare the results of a cluster for reuse across projects by looking for elements of general applicability, and transform them for inclusion in libraries. + +Recent object-oriented literature has used the term "refactoring" to describe a process of continuous improvement of released software. Generalization includes refactoring, but also pursues a more ambitious goal: helping turn program elements (software modules useful only as part of a certain program) into software components -- reusable parts with a value of their own, ready to be used by diverse programs that can benefit from their capabilities. + +Of course not all companies using the method will be ready to include a Generalization phase in their. But those which do will see the reusability of their software greatly improved. + +==Constant availability== + +Complementing the preceding principles is the idea that, in the cluster lifecycle, the development team (under the responsibility of the project leader) should at all times maintain a current working demo which, although covering only a part of the final system, works well, and can be demonstrated or -- starting at a suitable time -- shipped as an early release. It is not a "prototype" in the sense of a meant to be thrown away, but an initial iteration towards the final product; the successive iterations will progress continuously towards until they become that final product. + +==Compilation technology== + +The preceding goals benefit from the ability to check frequently that the current iteration is correct and robust. Eiffel supports efficient compilation mechanisms through such mechanisms as the '''Melting Ice Technology''' in EiffelStudio. The Melting Ice achieves immediate recompilation after a change, guaranteeing a recompilation time that's a function of the size of the changes, not of the system's overall size. Even for a system of several thousand classes and several hundred thousand lines, the time to get restarted after a change to a few classes is, on a typical modern computer, a few seconds. + +Such a "melt" (recompilation) will immediately catch (along with any syntax errors) the type errors -- often the symptoms of conceptual errors that, if left undetected, could cause grave damage later in the process or even during operation. Once the type errors have been corrected, the developers should start testing the new functionalities, relying on the power of '''assertions''' -- explained in [[ET: Design by Contract (tm), Assertions and Exceptions|"Design By Contract™ Assertions, Exceptions"]] -- to kill the bugs while they are still larvae. Such extensive unit and system testing, constantly interleaved with development, plays an important part in making sure that the "current demo" is trustworthy and will eventually yield a correct and robust product. + +==Quality and functionality== + +Throughout the process, the method suggests maintaining a constant '''quality''' level: apply all the style rules, put in all the assertions, handle erroneous cases (rather than the all too common practice of thinking that one will "make the product robust" later on), enforce the proper architecture. This applies to all the quality factors except possibly reusability (since one may not know ahead of time how best to generalize a component, and trying to make everything fully general may conflict with solving the specific problem at hand quickly). All that varies is '''functionality''': as the project progresses and clusters come into place, more and more of the final product's intended coverage becomes available. The project's most common question, "Can we ship something yet?", translates into "Do we cover enough?", not "Is it good enough?" (as in "Will it not crash?"). + +Of course not everyone using Eiffel can, any more than in another approach, guarantee that the ideal just presented will always hold. But it is theoretical scheme to which the method tends. It explains Eiffel's emphasis on getting everything right: the grandiose and the mundane, the structure and the details. Regarding the details, the Eiffel books cited in the bibliography include many rules, some petty at first sight, about such low-level aspects as the choice of names for classes and features (including their grammatical categories), the indentation of software texts, the style for comments (including the presence or absence of a final period), the use of spaces. Applying these rules does not, of course, guarantee quality; but they are part of a quality-oriented process, along with the more ambitious principles of design. In addition they are particularly important for the construction of quality libraries, one of the central goals of Eiffel. + +Whenever they are compatible with the space constraints, the present chapter and the rest of this book apply these rules to their Eiffel examples. + + + + diff --git a/documentation/18.11/eiffel/Tutorials/eiffel-tutorial-et/et-static-picture-system-organization.wiki b/documentation/18.11/eiffel/Tutorials/eiffel-tutorial-et/et-static-picture-system-organization.wiki new file mode 100644 index 00000000..d20d27ce --- /dev/null +++ b/documentation/18.11/eiffel/Tutorials/eiffel-tutorial-et/et-static-picture-system-organization.wiki @@ -0,0 +1,76 @@ +[[Property:title|ET: The Static Picture: System Organization]] +[[Property:weight|-11]] +[[Property:uuid|46d3f41e-d41c-a443-4574-403dfebb60aa]] +We now look at the overall organization of Eiffel software. + +References to Eiffel Software's libraries appearing in subsequent examples include: '''EiffelBase''', the fundamental open-source library covering data structures and algorithms; the '''kernel library''', a subset of EiffelBase covering the most basic notions such as arrays and strings; and '''EiffelVision 2''', an advanced graphics and GUI library providing full compatibility across platforms (Unix, Windows, OpenVMS) with native look-and-feel on each. + +==Systems== + +An Eiffel system is a collection of classes, one of which is designated as the root class. One of the features of the root class, which must be one of its creation procedures, is designated as the root procedure. + +To execute such a system is to create an instance of the root class (an object created according to the class description) and to execute the root procedure. In anything more significant than "Hello World" systems, this will create new objects and apply features to them, in turn triggering further creations and feature calls. + +For the system to make sense, it must contains all the classes on which the root '''depends''' directly or indirectly. A class B depends on a class A if it is either a '''client''' of A, that is to say uses objects of type A, or an '''heir''' of A, that is to say extends or specializes A. (These two relations, client and inheritance, are covered below.) + +==Classes== + +The notion of class is central to the Eiffel approach. A class is the description of a type of run-time data structures (objects), characterized by common operations features) and properties. Examples of classes include: +* In a banking system, a class ACCOUNT may have features such as deposit, adding a certain amount to an account, all_deposits, yielding the list of deposits since the account's opening, and balance, yielding the current balance, with properties stating that deposit must add an element to the all_deposits list and update balance by adding the sum deposited, and that the current value of balance must be consistent with the lists of deposits and withdrawals. +* A class COMMAND in an interactive system of any kind may have features such as execute and undo , as well as a feature undoable which indicates whether a command can be undone, with the property that undo is only applicable if undoable yields the value true. +* A class LINKED_LIST may have features such as put, which adds an element to a list, and count, yielding the number of elements in the list, with properties stating that put increases count by one and that count is always non-negative. + +We may characterize the first of these examples as an analysis class, directly modeling objects from the application domain; the second one as a design class, describing a high-level solution; and the third as an implementation class, reused whenever possible from a library such as EiffelBase. In Eiffel, however, there is no strict distinction between these categories; it is part of the approaches seamlessness that the same notion of class, and the associated concepts, may be used at all levels of the software development process. + +==Class relations== + +Two relations may exist between classes: +* You can define a class C as a '''client''' of a class A to enable the features of C to rely on objects of type A. +* You may define a class B as an '''heir''' of a class A to provide B with all the features and properties of A, letting B add its own features and properties and modify some of the inherited features if appropriate. + +If C is a client of A, A is a '''supplier''' of C. If B is an heir of A, A is a '''parent''' of B. A '''descendant''' of A is either A itself or, recursively, a descendant of an heir of A; in more informal terms a descendant is a direct or indirect heir, or the class itself. To exclude A itself we talk of '''proper descendant'''. In the reverse direction the terms are '''ancestor''' and '''proper ancestor'''. + +The client relation can be cyclic; an example involving a cycle would be classes PERSON and HOUSE, modeling the corresponding informal everyday "object" types and expressing the properties that every person has a home and every home has an architect. The inheritance (heir) relation may not include any cycle. + +In modeling terms, client roughly represents the relation "has" and heir roughly represents "is". For example we may use Eiffel classes to model a certain system and express that every child has a birth date (client relation) and is a person (inheritance). + +Distinctive of Eiffel is the rule that classes can only be connected through these two relations. This excludes the behind-the-scenes dependencies often found in other approaches, such as the use of global variables, which jeopardize the modularity of a system. Only through a strict policy of limited and explicit inter-class relations can we achieve the goals of reusability and extendibility. + +==The global inheritance structure== + +An Eiffel class that you write does not come into a vacuum but fits in a preordained structure, shown in the figure and involving two library classes: ANY and NONE. + + +[[Image:tutorial-4]] + + +Any class that does not explicitly inherit from another is considered to inherit from ANY, so that every class is a descendant, direct or indirect, of ANY. ANY introduces a number of general-purpose features useful everywhere, such as copying, cloning and equality testing operations (see [[ET: The Dynamic Structure: Execution Model|The Dynamic Structure: Execution Model]] ) and default input-output. The procedure print used in the first version of our "[[ET: Hello World|Hello World]]" comes from ANY. + +NONE inherits from any class that has no explicit heir. Since inheritance has no cycles, NONE cannot have proper descendants. This makes it useful, as we will see, to specify non-exported features, and to denote the type of void values. Unlike ANY, class NONE doesn't have an actual class text; instead, it's a convenient fiction. + +==Clusters== + +Classes are the only form of module in Eiffel. As will be explained in more detail, they also provide the basis for the only form of type. This module-type identification is at the heart of object technology and of the fundamental simplicity of the Eiffel method. + +Above classes, you will find the concept of cluster. A cluster is a group of related classes. Clusters are a property of the method, enabling managers to organize the development into teams. As we have already seen (in [[ET: The Software Process in Eiffel|The Software Process in Eiffel]] ) they also play a central role in the lifecycle model. Clusters are an organizational concept, not a form of module, and do not require an Eiffel programming language construct. + +==External software== + +The subsequent sections will show how to write Eiffel classes with their features. In an Eiffel system, however, not everything has to be written in Eiffel: some features may be '''external''' , coming from languages such as C, C++, Java, C# Fortran and others. For example a feature declaration may appear (in lieu of the forms seen later) as + + file_status (filedesc: INTEGER): INTEGER + -- Status indicator for filedesc + external + "C" alias "_fstat" + end + + +to indicate that it is actually an encapsulation of a C function whose original name is _fstat. The alias clause is optional, but here it is needed because the C name, starting with an underscore, is not valid as an Eiffel identifier. + +Similar syntax exists to interface with C++ classes. EiffelStudio includes a tool called Legacy++ which will automatically produce, from a C++ class, an Eiffel class that encapsulates its facilities, making them available to the rest of the Eiffel software as bona fide Eiffel features. + +These mechanisms illustrate one of the roles of Eiffel: as an system architecturing and software composition tool, used at the highest level to produce systems with robust, flexible structures ready for extendibility, reusability and maintainability. In these structures not everything must be written in the Eiffel programming language: existing software elements and library components can play their part, with the structuring capabilities of Eiffel (classes, information hiding, inheritance, clusters, contracts and other techniques seen in this presentation) serving as the overall wrapping mechanism. + + + + diff --git a/documentation/18.11/eiffel/Tutorials/eiffel-tutorial-et/index.wiki b/documentation/18.11/eiffel/Tutorials/eiffel-tutorial-et/index.wiki new file mode 100644 index 00000000..e33b5c1d --- /dev/null +++ b/documentation/18.11/eiffel/Tutorials/eiffel-tutorial-et/index.wiki @@ -0,0 +1,6 @@ +[[Property:title|An Eiffel Tutorial (ET)]] +[[Property:link_title|Tutorial]] +[[Property:weight|2]] +[[Property:uuid|4dbc41e2-ecfc-8c50-9288-fce30f4abd90]] +This Eiffel Tutorial (ET) should provide you with a broad understanding of what Eiffel is all about and why it is different from other technologies. Still more detail is available in [[Object-Oriented Software Construction, 2nd Edition]]. + diff --git a/documentation/18.11/eiffel/Tutorials/index.wiki b/documentation/18.11/eiffel/Tutorials/index.wiki new file mode 100644 index 00000000..62bc013d --- /dev/null +++ b/documentation/18.11/eiffel/Tutorials/index.wiki @@ -0,0 +1,13 @@ +[[Property:title|Eiffel Tutorials]] +[[Property:link_title|Tutorials]] +[[Property:weight|2]] +[[Property:uuid|f443f10d-9dbc-4d6b-b9fb-c59af76abde9]] + +== Tutorials about Eiffel == + +* [[Invitation to Eiffel (I2E)]] +* [[An Eiffel Tutorial (ET)]] +* [https://webcourses.inf.ethz.ch/se_courses/edx/eiffel_tutorial/] from Marco Piccioni +* ... + +{{Note|Please, don't hesitate to comment this page to add link to other existing tutorials on the web.This list is for now far from being complete.}} diff --git a/documentation/18.11/eiffel/Tutorials/invitation-eiffel-i2e/i2e-classes.wiki b/documentation/18.11/eiffel/Tutorials/invitation-eiffel-i2e/i2e-classes.wiki new file mode 100644 index 00000000..51bd61cc --- /dev/null +++ b/documentation/18.11/eiffel/Tutorials/invitation-eiffel-i2e/i2e-classes.wiki @@ -0,0 +1,110 @@ +[[Property:title|I2E: Classes]] +[[Property:weight|-11]] +[[Property:uuid|218bead9-428e-f61d-1e45-7eea4291d895]] +A class, it was said above, is an implementation of an abstract data type. This means that it describes a set of run-time objects, characterized by the ''' features''' (operations) applicable to them, and by the formal properties of these features. + +Such objects are called the '''direct instances''' of the class. Classes and objects should not be confused: "class" is a compile-time notion, whereas objects only exist at run time. This is similar to the difference that exists in classical programming between a program and one execution of that program, or between a type and a run-time value of that type. + +{{info|"Object-Oriented" is a misnomer; "Class-Oriented Analysis, Design and Programming" would be a more accurate description of the method. }} + +To see what a class looks like, let us look at a simple example, ACCOUNT, which describes bank accounts. But before exploring the class itself it is useful to study how it may be used by other classes, called its '''clients'''. + +A class X may become a client of ACCOUNT by declaring one or more '''entities''' of type ACCOUNT. Such a declaration is of the form: +acc: ACCOUNT + +The term "entity" generalizes the more common notion of "variable". An entity declared of a reference type, such as acc, may at any time during execution become " '''attached to''' " an object; the type rules imply that this object must be a direct instance of ACCOUNT -- or, as seen below, of a "descendant" of that class. + +[[Image:invitation-2]] + +An entity is said to be void if it is not attached to any object. By default, entities are void at initialization. To obtain objects at run-time, a routine r appearing in the client class X may use a '''creation instruction''' of the form + + + create acc + + +which creates a new direct instance of ACCOUNT, attaches acc to that instance, and initializes all its fields to default values. A variant of this notation, studied below, makes it possible to override the default initializations. + +Once the client has attached acc to an object, it may call on this object the features defined in class ACCOUNT. Here is an extract with some feature calls using acc as their target: + + acc.open ("Jill") + acc.deposit (5000) + if acc.may_withdraw (3000) then + acc.withdraw (3000) + print (acc.balance) + end + + +These feature calls use dot notation, of the form target_name.feature_name, possibly followed by a list of arguments in parentheses. Features are of two kinds: +* '''Routines''', such as open, deposit, may_withdraw, withdraw, represent computations applicable to instances of the class. +* '''Attributes''' represent data items associated with these instances. + +Routines are further divided into '''procedures''' (commands, which do not return a value) and '''functions''' (queries, returning a value). Here may_withdraw is a function returning a boolean; the other three-routines called are procedures. + +{{info|A note on syntax: you may separate instructions by semicolons, and indeed you should when, as on the next-to-last line of the example, two or more instructions appear on a line. But the language's syntax has been designed so that the semicolon is almost always optional, regardless of the layout. Indeed the practice is to omit it between instructions or declarations on separate lines, as this results in lighter, clearer software texts. }} + +In class ACCOUNT, is feature balance an attribute, or is it a function with no argument? The above extract of the client class X doesn't say, and this ambiguity is intentional. A client of ACCOUNT must not need to know how class ACCOUNT delivers an account's balance when requested: by looking up a field present in each account object, or by calling a function that computes the balance from other fields. Choosing between these techniques is the business of class ACCOUNT, not anybody else's. Because such implementation choices are often changed over the lifetime of a project, it is essential to protect clients against their effects. This is known as the '''Uniform Access Principle''', stating that the choice between representing a property through memory (an attribute) or through an algorithm (function) shall not affect how clients use it. + +So much for how client classes will typically use ACCOUNT. Below is a first sketch of how class ACCOUNT itself might look. Line segments beginning with -- are comments. The class includes two feature clauses, introducing its features. The first begins with just the keyword feature, without further qualification; this means that the features declared in this clause are available (or "exported") to all clients of the class. The second clause is introduced by feature {NONE} to indicate that the feature that follows, called add, is available to no client. What appears between the braces is a list of client classes to which the corresponding features are available; NONE is a special class of the Kernel Library, which has no instances, so that add is in effect a secret feature, available only locally to the other routines of class ACCOUNT. So in a client class such as X, the call acc.add ( -3000 ) would be invalid. + +class + ACCOUNT + +feature + + balance: INTEGER + owner: PERSON + minimum_balance: INTEGER = 1000 + + open (who: PERSON) + -- Assign the account to owner who. + do + owner := who + end + + deposit (sum: INTEGER) + -- Deposit sum into the account. + do + add (sum) + end + + withdraw (sum: INTEGER) + -- Withdraw sum from the account. + do + add (-sum) + end + + may_withdraw (sum: INTEGER): BOOLEAN + -- Is there enough money to withdraw sum? + do + Result := (balance >= sum + minimum_balance) + end + +feature {NONE} + + add (sum: INTEGER) + -- Add sum to the balance + do + balance := balance + sum + end + +end -- ACCOUNT + + +Let us examine the features in sequence. The do ... end distinguishes routines from attributes. So here the class has implemented balance as an attribute, although, as noted, a function would also have been acceptable. Feature owner is also an attribute. + +The language definition guarantees automatic initialization, so that the initial balance of an account object will be zero after a creation instruction. Each type has a default initial value: zero for INTEGER and REAL, false for BOOLEAN, null character for CHARACTER, and a void reference for reference types. The class designer may also provide clients with different initialization options, as will be seen below in a revised version of this example. + +The other public features, withdraw, deposit, open, and may_withdraw are straight-forward routines. The special entity Result, used in may_withdraw, denotes the function result; it is initialized on function entry to the default value of the function's result type. You may only use Result in functions. + +The secret procedure add serves for the implementation of the public procedures deposit and withdraw; the designer of ACCOUNT judged it too general to be exported by itself. The clause "= 1000" introduces minimum_balance as a constant attribute, which will not occupy any space in instances of the class; in contrast, every instance has a field for every non-constant attribute such as balance. + +In Eiffel's object-oriented programming style any operation is relative to a certain object. A client invoking the operation specifies this object by writing the corresponding entity on the left of the dot, as acc in acc.open ("Jill"). Within the class, however, the "current" instance to which operations apply usually remains implicit, so that unqualified feature names, such as owner in procedure open or add in deposit, mean "the owner attribute or add routine relative to the current instance". + +If you need to denote the current object explicitly, you may use the special entity Current. For example the unqualified occurrences of add appearing in the class text above are equivalent to Current. add. + +In some cases, infix or prefix notation will be more convenient than dot notation. For example, if a class VECTOR offers an addition routine, most people will feel more comfortable with calls of the form v + w than with the dot-notation call v.plus (w). To make this possible it suffices to give the routine a "+" alias. The operation is still a normal routine call which can be invoked with either the infix form or the dot-notation. + +The above simple example has shown the basic structuring mechanism of the language: the class. A class describes objects accessible to clients through an official interface comprising some of the class features. Features are implemented as attributes or routines; the implementation of exported features may rely on other, secret ones. + + + diff --git a/documentation/18.11/eiffel/Tutorials/invitation-eiffel-i2e/i2e-combining-genericity-and-inheritance.wiki b/documentation/18.11/eiffel/Tutorials/invitation-eiffel-i2e/i2e-combining-genericity-and-inheritance.wiki new file mode 100644 index 00000000..2b15de29 --- /dev/null +++ b/documentation/18.11/eiffel/Tutorials/invitation-eiffel-i2e/i2e-combining-genericity-and-inheritance.wiki @@ -0,0 +1,34 @@ +[[Property:title|I2E: Combining Genericity and Inheritance]] +[[Property:weight|-3]] +[[Property:uuid|912e4c38-9add-e478-59c3-5c10aa75d784]] +Genericity and inheritance, the two fundamental mechanisms for generalizing classes, may be combined in two fruitful ways. + +The first technique yields '''polymorphic data structures'''. Assume that in the generic class LIST [G] the insertion procedure put has a formal argument of type G, representing the element to be inserted. Then with a declaration such as + + pl: LIST [POLYGON] + +the type rules imply that in a call pl.put (p) the permitted types for the argument p include not just POLYGON, but also RECTANGLE (an heir of POLYGON) or any other type conforming to POLYGON through inheritance. + +The basic conformance requirement used here is the inheritance-based type compatibility rule: V conforms to T if V is a descendant of T. + +Structures such as pl may contain objects of different types, hence the name "polymorphic data structure". Such polymorphism is, again, made safe by the type rules: by choosing an actual generic parameter ( POLYGON in the example) based higher or lower in the inheritance graph, you extend or restrict the permissible types of objects in pl. A fully general list would be declared as + + LIST [ANY] + +where ANY, a Kernel Library class, is automatically an ancestor of any class that you may write. + +The other mechanism for combining genericity and inheritance is '''constrained genericity'''. By indicating a class name after a formal generic parameter, as in + + VECTOR [T -> NUMERIC] + +you express that only descendants of that class (here NUMERIC) may be used as the corresponding actual generic parameters. This makes it possible to use the corresponding operations. Here, for example, class VECTOR may define a routine infix "+" for adding vectors, based on the corresponding routine from NUMERIC for adding vector elements. Then by making VECTOR itself inherit from NUMERIC, you ensure that it satisfies its own generic constraint and enable the definition of types such as VECTOR [VECTOR [T]] . + +As you have perhaps guessed, unconstrained genericity, as in LIST [G] , may be viewed as an abbreviation for genericity constrained by ANY, as in + + LIST [G -> ANY] + +Something else you may have guessed: if ANY, introduced in this session, is the top of the inheritance structure -- providing all classes with universal features such as equal to compare arbitrary objects and twin to duplicate objects -- then NONE, seen earlier in the notation feature {NONE}, is its bottom. NONE indeed conceptually inherits from all other classes. NONE is, among other things, the perceived type of the Void keyword which represents a void reference. + + + + diff --git a/documentation/18.11/eiffel/Tutorials/invitation-eiffel-i2e/i2e-deferred-classes-and-seamless-development.wiki b/documentation/18.11/eiffel/Tutorials/invitation-eiffel-i2e/i2e-deferred-classes-and-seamless-development.wiki new file mode 100644 index 00000000..306c1008 --- /dev/null +++ b/documentation/18.11/eiffel/Tutorials/invitation-eiffel-i2e/i2e-deferred-classes-and-seamless-development.wiki @@ -0,0 +1,64 @@ +[[Property:title|I2E: Deferred Classes and Seamless Development]] +[[Property:weight|-2]] +[[Property:uuid|b3264238-f160-a6fc-0b03-adcd80b1f55a]] +The inheritance mechanism includes one more major notion: deferred features and classes. + +Declaring a feature f as deferred in a class C expresses that there is no default implementation of f in C; such implementations will appear in eventual descendants of C. A class that has one or more deferred routines is itself said to be deferred. A non-deferred routine or class -- like all those seen until now -- is said to be '''effective'''. + +For example, a system used by a Department of Motor Vehicles to register vehicles might include a class of the form + +deferred class + VEHICLE + +feature + + dues_paid (year: INTEGER): BOOLEAN + do ... end + + valid_plate (year: INTEGER): BOOLEAN + do ... end + + register (year: INTEGER) + -- Register vehicle for year. + require + dues_paid (year) + deferred + ensure + valid_plate (year) + end + + ... Other features, deferred or effective ... + +end -- VEHICLE + + +This example assumes that no single registration algorithm applies to all kinds of vehicle; passenger cars, motorcycles, trucks etc. are all registered differently. But the same precondition and postcondition apply in all cases. The solution is to treat register as a deferred routine, making VEHICLE a deferred class. Descendants of class VEHICLE, such as CAR or TRUCK, effect this routine, that is to say, give effective versions. An effecting is similar to a redefinition; only here there is no effective definition in the original class, just a specification in the form of a deferred routine. The term '''redeclaration''' covers both redefinition and effecting. + + +[[Image:invitation-5]] + + +Whereas an effective class described an implementation of an abstract data types, a deferred class describes a set of possible implementations. You may not instantiate a deferred class: create v is invalid if v is declared of type VEHICLE. But you may assign to v a reference to an instance of an effective descendant of VEHICLE. For example, assuming CAR and TRUCK provide effective definitions for all deferred routines of VEHICLE, the following will be valid: + + v: VEHICLE + c: CAR + t: TRUCK + ... + create c + create t + ... + if "Some test" then + v := c + else + v := t + end + v.register (2008) + +This example fully exploits polymorphism: depending on the outcome of "Some test", v will be treated as a car or a truck, and the appropriate registration algorithm will be applied. Also, "Some test" may depend on some event whose outcome is impossible to predict until run-time, for example the user clicking with the mouse to select one among several vehicle icons displayed on the screen. + +Deferred classes are particularly useful at the design stage. The first version of a module may be a deferred class, which will later be refined into one or more effective classes. Eiffel's Design by Contract™ mechanisms are essential here: you may a precondition and a postcondition with a routine even though it is a deferred routine (as with register above), and an invariant with a class even though it is a deferred class. This enables you, as a designer, to attach precise semantics to a module at the design stage long before you will make any implementation choices. + +Beyond design and implementation, these techniques extend to the earliest stage of development, analysis. Deferred classes written at that stage describe not software objects, but objects from the external world being modeled -- documents, airplanes, investments. Here again the presence of contracts to express constraints, and the language's other structuring facilities, provide an attractive combination. + +Eiffel appears here in its full role of a lifecycle approach, covering areas traditionally considered separate: program implementation, the traditional province of development environments; system modeling and architecture, the traditional province of CASE tools based on UML or similar notations disconnected from the rest of the lifecycle. Eiffel instead emphasizes the fundamental unity of the software process and the usefulness of a single set of notations, concepts and tools applicable throughout. Such a seamless approach is indispensable to support the inevitable reversals that occur during the process of building software, such as detecting at implementation time a problem that leads to a change in the system's functionality, set at analysis time. The use of separate tools and notations, such as UML on one side and a programming language on the other, makes such round-trips difficult at best and often leads to monolithic, hard-to-change software. Eiffel lets you focus on the issues, without interposing artificial barriers between different software development activities. You'll use the fundamental problem-solving techniques -- data abstraction through classes, precise specification through contracts, modularity through information hiding, rational organization through inheritance, decentralized architecture through dynamic binding, parameterization of the solution through genericity, reusability through all these techniques -- all along; only the level of abstraction changes. + diff --git a/documentation/18.11/eiffel/Tutorials/invitation-eiffel-i2e/i2e-design-contract-and-assertions.wiki b/documentation/18.11/eiffel/Tutorials/invitation-eiffel-i2e/i2e-design-contract-and-assertions.wiki new file mode 100644 index 00000000..53f3af4a --- /dev/null +++ b/documentation/18.11/eiffel/Tutorials/invitation-eiffel-i2e/i2e-design-contract-and-assertions.wiki @@ -0,0 +1,150 @@ +[[Property:title|I2E: Design by Contract and Assertions]] +[[Property:weight|-9]] +[[Property:uuid|f563aa75-3a5a-5110-b4f1-07da5448f668]] +If classes are to deserve their definition as abstract data type implementations, they must be known not just by the available operations, but also by the formal properties of these operations, which did not yet appear in the preceding example. + +==The role of assertions== + +Eiffel encourages software developers to express formal properties of classes by writing '''assertions''', which may in particular appear in the following roles:
+* Routine '''preconditions''' express the requirements that clients must satisfy whenever they call a routine. For example the designer of ACCOUNT may wish to permit a withdrawal operation only if it keeps the account's balance at or above the minimum. Preconditions are introduced by the keyword require. +* Routine '''postconditions''', introduced by the keyword ensure, express conditions that the routine (the supplier) guarantees on return, if the precondition was satisfied on entry. +* A class '''invariant''' must be satisfied by every instance of the class whenever the instance is externally accessible: after creation, and after any call to an exported routine of the class. The invariant appears in a clause introduced by the keyword invariant, and represents a general consistency constraint imposed on all routines of the class. + + +With appropriate assertions, the class ACCOUNT becomes: + +class + ACCOUNT + +create + make + +feature + ... Attributes as before: + balance , minimum_balance , owner , open ... + + deposit (sum: INTEGER) + -- Deposit sum into the account. + require + sum >= 0 + do + add (sum) + ensure + balance = old balance + sum + end + + withdraw (sum: INTEGER) + -- Withdraw sum from the account. + require + sum >= 0 + sum <= balance - minimum_balance + do + add (-sum) + ensure + balance = old balance - sum + end + + may_withdraw ... -- As before + +feature {NONE} + + add ... + + make (initial: INTEGER) + -- Initialize account with balance initial. + require + initial >= minimum_balance + do + balance := initial + end + +invariant + balance >= minimum_balance + +end -- ACCOUNT + + +The notation old expression is only valid in a routine postcondition. It denotes the value the expression had on routine entry. + +==Creation procedures== + +In its last version above, the class now includes a creation procedure, make. With the first version, clients used creation instructions such as create acc1 to create accounts; but then the default initialization, setting balance to zero, violated the invariant. By having one or more creation procedures, listed in the create clause at the beginning of the class text, a class offers a way to override the default initializations. The effect of + + create acc1.make (5_500) + +is to allocate the object (as with the default creation) and to call procedure make on this object, with the argument given. This call is correct since it satisfies the precondition; it will ensure the invariant. + +{{info|The underscore _ in the integer constant ''5_500'' has no semantic effect. The general rule is that you can group digits by sets of three from the right to improve the readability of integer constants. }} + + +Note that the same keyword, create, serves both to introduce creation instructions and the creation clause listing creation procedures at the beginning of the class. + +A procedure listed in the creation clause, such as make, otherwise enjoys the same properties as other routines, especially for calls. Here the procedure make is secret since it appears in a clause starting with + +feature {NONE} + +so it would be invalid for a client to include a call such as + + acc.make (8_000) + +To make such a call valid, it would suffice to move the declaration of make to the first feature clause of class ACCOUNT, which carries no export restriction. Such a call does not create any new object, but simply resets the balance of a previously created account. + +==Design by Contract™== + +Syntactically, assertions are boolean expressions, with a few extensions such as the old notation. Also, you may split an assertion into two or more clauses, as here with the precondition of withdraw; this is as if you had separated the clauses with an and, but makes the assertion clearer, especially if it includes many conditions. + +Assertions play a central part in the Eiffel method for building reliable object-oriented software. They serve to make explicit the assumptions on which programmers rely when they write software elements that they believe are correct. Writing assertions amounts to spelling out the terms of the '''contract''' which governs the relationship between a routine and its callers. The precondition binds the callers; the postcondition binds the routine. + +The underlying theory of Design by Contract™, the centerpiece of the Eiffel method, views software construction as based on contracts between clients (callers) and suppliers (routines), relying on mutual obligations and benefits made explicit by the assertions. + +==The Contract Form== + +Assertions are also an indispensable tool for the documentation of reusable software components: one cannot expect large-scale reuse without a precise documentation of what every component expects (precondition), what it guarantees in return (postcondition) and what general conditions it maintains (invariant). + +Documentation tools in EiffelStudio use assertions to produce information for client programmers, describing classes in terms of observable behavior, not implementation. In particular the '''Contract Form''' of a class, also called its "short form", which serves as its interface documentation, is obtained from the full text by removing all non-exported features and all implementation information such as do clauses of routines, but keeping interface information and in particular assertions. Here is the Contract Form of the above class: + +class interface ACCOUNT + +create + make + +feature + + balance: INTEGER + ... + + deposit (sum: INTEGER) + -- Deposit sum into the account. + require + sum >= 0 + ensure + balance = old balance + sum + + withdraw (sum: INTEGER) + -- Withdraw sum from the account. + require + sum >= 0 + sum <= balance - minimum_balance + ensure + balance = old balance - sum + + may_withdraw ... + +end -- ACCOUNT + + +This is not actual Eiffel, only documentation of Eiffel classes, hence the use of slightly different syntax to avoid any confusion ( interface class rather than class). In accordance with the Uniform Access Principle (in [[I2E: Classes|Classes]]), the output for balance would be the same if this feature were a function rather than an attribute. + +You will find in EiffelStudio automatic tools to produce the Contract Form of a class. You can also get the '''Flat Contract''' form, based on the same ideas but including inherited features along with those introduced in the class itself. EiffelStudio can produce these forms, and other documentation views of a class, in a variety of output formats including HTML, so that collaborative projects can automatically post the latest versions of their class interfaces on the Internet or an Intranet. + +==Contracts for testing and debugging== + +Under EiffelStudio you may also set up compilation options, for the whole system or specific classes only, to evaluate assertions at run time, to uncover potential errors ("bugs"). EiffelStudio provides several levels of assertion monitoring: preconditions only, postconditions etc. When monitoring is on, an assertion which evaluates to true has no further effect on the execution. An assertion that evaluates to false will trigger an exception, as described next; unless you have written an appropriate exception handler, the exception will cause an error message and termination with a precise message and a call trace. + +This ability to check assertions provides a powerful testing and debugging mechanism, in particular because the classes of the EiffelBase Libraries, widely used in Eiffel software development, are protected by carefully written assertions. + +Run-time monitoring, however, is only one application of assertions, whose role as design and documentation aids, as part of the theory of Design by Contract™, exerts a pervasive influence on the Eiffel style of software development. + + + + diff --git a/documentation/18.11/eiffel/Tutorials/invitation-eiffel-i2e/i2e-design-principles.wiki b/documentation/18.11/eiffel/Tutorials/invitation-eiffel-i2e/i2e-design-principles.wiki new file mode 100644 index 00000000..0c9246c0 --- /dev/null +++ b/documentation/18.11/eiffel/Tutorials/invitation-eiffel-i2e/i2e-design-principles.wiki @@ -0,0 +1,22 @@ +[[Property:title|I2E: Design Principles]] +[[Property:weight|-13]] +[[Property:uuid|529659bd-ec13-5805-87f2-2fd9318ad442]] +The aim of Eiffel is to help specify, design, implement and modify quality software. This goal of quality in software is a combination of many factors; the language design concentrated on the three factors which, in the current state of the industry, are in direct need of improvements: reusability, extendibility and reliability. Also important were other factors such as efficiency, openness and portability. + +'''Reusability''' is the ability to produce components that may serve in many different applications. Central to the Eiffel approach is the presence of predefined libraries such as EiffelBase, and the language's support for the production of new libraries. + +'''Extendibility''' is the ability to produce easily modifiable software. "Soft" as software is supposed to be, it is notoriously hard to modify software systems, especially large ones. + +Among quality factors, reusability and extendibility play a special role: satisfying them means having less software to write -- and hence more time to devote to other important goals such as efficiency, ease of use or integrity. + +The third fundamental factor is '''reliability, ''' the ability to produce software that is correct and robust -- that is to say, bug-free. Eiffel techniques such as static typing, assertions, disciplined exception handling and automatic garbage collection are essential here. + +Three other factors are also part of Eiffel's principal goals:
+* The language enables implementers to produce high '''efficiency''' compilers, so that systems developed with Professional Eiffel may run under speed and space conditions similar to those of programs written in lower-level languages. +* Ensuring '''openness''', so that Eiffel software may cooperate with programs written in other languages. +* Guaranteeing '''portability''' by a platform-independent language definition, so that the same semantics may be supported on many different platforms. + + + + + diff --git a/documentation/18.11/eiffel/Tutorials/invitation-eiffel-i2e/i2e-event-driven-programming-and-agents.wiki b/documentation/18.11/eiffel/Tutorials/invitation-eiffel-i2e/i2e-event-driven-programming-and-agents.wiki new file mode 100644 index 00000000..b1c38b8a --- /dev/null +++ b/documentation/18.11/eiffel/Tutorials/invitation-eiffel-i2e/i2e-event-driven-programming-and-agents.wiki @@ -0,0 +1,42 @@ +[[Property:title|I2E: Event-Driven Programming and Agents]] +[[Property:weight|-7]] +[[Property:uuid|16fdab60-ae42-1bb8-f4bb-89e34d18a842]] +The division of roles in object technology is clear: of the two principal constituents of a system, object types and operations, the first dominates. Classes, representing object types, determines the structure of the software; every routine, representing an operation, belongs to a class. + +In some circumstances it is useful to define an object that denotes an operation. This is especially useful if you want to build an object structure that refers to operations, so that you can later traverse the structure and execute the operations encountered. A typical application is '''event-driven programming''' for Graphical User Interfaces (GUI), including Web programming. In GUI programming you will want to record properties of the form + +"When the user clicks this OK button, the system must update the file" + + +each involves a '''control''' (here the OK button), an '''event''' (mouse click) and an '''operation''' (update the file). This can be programmed by having an "event loop", triggered for each event, which performs massive decision-making (if "The latest event was `left mouse click on button 23'" then "Appropriate instructions" else if ... and so on with many branches); but this leads to bulky software architectures where introducing any new control or event requires updating a central part of the code. It's preferable to let any element of the system that encounters a new control-event-operation association + +[control, event, operation] + + +store it as a triple of objects into an object structure, such as an array or a list. Triples in that structure may come from different parts of the system; there is no central know-it-all structure. The only central element is a simple mechanism which can explore the object structure to execute each operation associated with a certain control and a certain event. The mechanism is not just simple; it's also independent of your application, since it doesn't need to know about any particular control, event or operation (it will find them in the object structure). So it can be programmed once and for all, as part of a library such as EiffelVision 2 for platform-independent graphics. + +To build an object structure, we need objects. A control, an event are indeed objects. But an operation is not: it's program code -- a routine of a certain class. + +Agents address this issue. An agent is an object that represents a routine, which can then be kept in an object structure. The simplest form of agent is written agent r, where r is a routine. This denotes an object. If your_agent is such an agent object, the call + + your_agent.call ([a, b]) + + +where a and b are valid arguments for r, will have the same effect as a direct call to r with arguments a and b. Of course, if you know that you want to call r with those arguments, you don't need any agents; just use the direct call r (a, b). The benefit of using an agent is that you can store it into an object structure to be called '''later''', for example when an event-driven mechanism finds the agent in the object structure, associated with a certain control and a certain event. For this reason agents are also called '''delayed calls'''. + +{{info|The notation [a, b] denotes a sequence of elements, or '''tuple'''. The reason call needs a tuple as argument, whereas the direct call r (a, b) doesn't, is that call is a general routine (from the EiffelBase class ROUTINE, representing agents) applicable to any agent, whereas the direct call refers explicitly to r and hence requires arguments a and b of specific types. The agent mechanism, however, is statically typed like the rest of the language; when you call call, the type checking mechanism ensures that the tuple you pass as argument contains elements a and b of the appropriate types. }} + + +A typical use of agents with EiffelVision 2 is + + ok_button.select_actions.extend (agent your_routine) + +which says: "add your_routine to the list of operations to be performed whenever a select event (left click) happens on ok_button". ok_button.select_actions is the list of agents associated with the button and the event; in list classes, procedure extend adds an item at the end of a list. Here, the object to be added is the agent. + +This enables the EiffelVision 2 event-handling mechanism to find the appropriate agent when it processes an event, and call call on that agent to trigger the appropriate routine. EiffelVision 2 doesn't know that it's your_routine; in fact, it doesn't know anything about your application. It simply finds an agent in the list, and calls call on it. For your part, as the author of a graphical application, you don't need to know how EiffelVision 2 handles events; you simply associate the desired agents with the desired controls and events, and let EiffelVision 2 do the rest. + +Agents extend to many areas beyond GUIs. In '''numerical computation''', you may use an agent to pass to an "integrator" object a numerical function to be integrated over a certain interval. In yet another area, you can use agents (as in the iteration library of EiffelBase) to program '''iterators''' : mechanisms that repetitively apply an arbitrary operation -- represented by an agent -- to every element of a list, tree or other object structure. More generally, agent embody properties of the associated routines, opening the way to mechanism for '''reflection''', also called "introspection": the ability, during software execution, to discover properties of the software itself. + + + + diff --git a/documentation/18.11/eiffel/Tutorials/invitation-eiffel-i2e/i2e-exceptions.wiki b/documentation/18.11/eiffel/Tutorials/invitation-eiffel-i2e/i2e-exceptions.wiki new file mode 100644 index 00000000..5668d427 --- /dev/null +++ b/documentation/18.11/eiffel/Tutorials/invitation-eiffel-i2e/i2e-exceptions.wiki @@ -0,0 +1,47 @@ +[[Property:title|I2E: Exceptions]] +[[Property:weight|-8]] +[[Property:uuid|e3e10dac-0dd7-bbe1-240c-6a6985c7376a]] +Whenever there is a contract, the risk exists that someone will break it. This is where exceptions come in. + +Exceptions -- contract violations -- may arise from several causes. One is an assertion violation, if you've selected run-time assertion monitoring. Another is a signal triggered by the hardware or operating system to indicate an abnormal condition such as arithmetic overflow, or an attempt to create a new object when there's not enough memory available. + +Unless a routine has made specific provision to handle exceptions, it will '''fail''' if an exception arises during its execution. This in turn provides one more source of exceptions: a routine that fails triggers an exception in its caller. + +A routine may, however, handle an exception through a rescue clause. This optional clause attempts to "patch things up" by bringing the current object to a stable state (one satisfying the class invariant). Then it can terminate in either of two ways:
+* The rescue clause may execute a retry instruction, which causes the routine to restart its execution from the beginning, attempting again to fulfill its contract, usually through another strategy. This assumes that the instructions of the rescue clause, before the retry, have attempted to correct the cause of the exception. +* If the rescue clause does not end with retry, then the routine fails: it returns to its caller, immediately triggering an exception. (The caller's rescue clause will be executed according to the same rules.) + + +The principle is that '''a routine must either succeed or fail''': it either fulfills its contract, or not; in the latter case it must notify its caller by triggering an exception. + +Usually, only a few routines of a system will explicitly include a rescue clause. A routine that doesn't have an explicit rescue is considered to have an implicit one, which calls a routine default_rescue that by default does nothing, so that an exception will cause the routine to fail immediately, propagating the exception to the caller. + +An example using the exception mechanism is a routine attempt_transmission that tries to transmit a message over a phone line. The actual transmission is performed by an external, low-level routine transmit; once started, however, transmit may abruptly fail, triggering an exception, if the line is disconnected. Routine attempt_transmission tries the transmission at most 50 times; before returning to its caller, it sets a boolean attribute successful to True or False depending on the outcome. Here is the text of the routine: + +attempt_transmission (message: STRING) + -- Try to transmit message, at most 50 times. + -- Set successful accordingly. + local + failures: INTEGER + do + if failures < 50 then + transmit (message) + successful := True + else + successful := False + end + rescue + failures := failures + 1 + retry + end + + +Initialization rules ensure that failures, a local entity, is set to zero on entry. + +This example illustrates the simplicity of the mechanism: the rescue clause never attempts to achieve the routine's original intent; this is the sole responsibility of the body (the do clause). The only role of the rescue clause is to clean up the objects involved, and then either to fail or to retry. + +This disciplined exception mechanism is essential for software developers, who need protection against unexpected events, but cannot be expected to sacrifice safety and simplicity to pay for this protection. + + + + diff --git a/documentation/18.11/eiffel/Tutorials/invitation-eiffel-i2e/i2e-genericity.wiki b/documentation/18.11/eiffel/Tutorials/invitation-eiffel-i2e/i2e-genericity.wiki new file mode 100644 index 00000000..01ab0951 --- /dev/null +++ b/documentation/18.11/eiffel/Tutorials/invitation-eiffel-i2e/i2e-genericity.wiki @@ -0,0 +1,28 @@ +[[Property:title|I2E: Genericity]] +[[Property:weight|-6]] +[[Property:uuid|091c0b65-73de-b454-b3f2-d8752983780e]] +Building software components (classes) as implementations of abstract data types yields systems with a solid architecture but does not in itself ensure reusability and extendibility. Two key techniques address the problem: genericity (unconstrained or constrained) and inheritance. Let us look first at the unconstrained form. + +To make a class generic is to give it '''formal generic parameters''' representing as unknown types, as in these examples from EiffelBase, an open-source library covering basic data structures and algorithms: + + ARRAY [G] + LIST [G] + LINKED_LIST [G] + +These classes describe data structures -- arrays, lists without commitment to a specific representation, lists in linked representation -- containing objects of a certain type. The formal generic parameter G denotes this type. + +A class such as these doesn't quite yet describe a type, but a type template, since G itself denotes an unknown type. To derive a directly usable list or array type, you must provide a type corresponding to G, called an '''actual generic parameter'''; this may be either an expanded type, including basic types such as INTEGER, or a reference type. Here are some possible generic derivations: + + il: LIST [INTEGER] + aa: ARRAY [ACCOUNT] + aal: LIST [ARRAY [ACCOUNT]] + +As the last example indicates, an actual generic parameter may itself be generically derived. + +It would not be possible, without genericity, to have static type checking in a realistic object-oriented language. + +A variant of this mechanism, constrained genericity, will enable a class to place specific requirements on possible actual generic parameters. Constrained genericity will be described after inheritance. + + + + diff --git a/documentation/18.11/eiffel/Tutorials/invitation-eiffel-i2e/i2e-inheritance.wiki b/documentation/18.11/eiffel/Tutorials/invitation-eiffel-i2e/i2e-inheritance.wiki new file mode 100644 index 00000000..b9045767 --- /dev/null +++ b/documentation/18.11/eiffel/Tutorials/invitation-eiffel-i2e/i2e-inheritance.wiki @@ -0,0 +1,72 @@ +[[Property:title|I2E: Inheritance]] +[[Property:weight|-5]] +[[Property:uuid|acf84989-0e7c-f2f7-427a-19e7fce404ce]] +Inheritance, the other fundamental generalization mechanism, makes it possible to define a new class by combination and specialization of existing classes rather than from scratch. + +The following simple example, from the Data Structure Library in EiffelBase, is typical. LIST, as noted, describes lists in any representation. One such representation if the lists have a fixed number of elements uses an array. We may define the corresponding class by combination of LIST and ARRAY, as follows: + +class ARRAYED_LIST [G] + inherit + LIST [G] + ARRAY [G] + + export ... See below ... end + +feature + ... Specific features of fixed-size lists ... + +end -- ARRAYED_LIST + + +The inherit ... clause lists all the "parents" of the new class, which is said to be their "heir". (The "ancestors" of a class include the class itself, its parents, grandparents etc.; the reverse term is "descendant".) Declaring ARRAYED_LIST as shown ensures that all the features and properties of lists and arrays are applicable to arrayed lists as well. Since the class has more than one parent, this is a case of multiple inheritance. + +Standard graphical conventions -- drawn from the Business Object Notation or BON, a graphical object-oriented notation based on concepts close to those of Eiffel, and directly supported by EiffelStudio -- illustrate such inheritance structures: + + +[[Image:invitation-4]] + + +An heir class such as ARRAYED_LIST needs the ability to define its own export policy. By default, inherited features keep their export status (publicly available, secret, available to selected classes only); but this may be changed in the heir. Here, for example, ARRAYED_LIST will export only the exported features of LIST, making those of ARRAY unavailable directly to ARRAYED_LIST 's clients. The syntax to achieve this is straightforward: + +class ARRAYED_LIST [G] + inherit + LIST [G] + ARRAY [G] + + export {NONE} all end + + ... The rest as above ... + + +Another example of multiple inheritance comes from a windowing system based on a class WINDOW, close to actual classes in EiffelVision 2. Windows have '''graphical''' features: a height, a width, a position, routines to scale windows, move them, and other graphical operations. The system permits windows to be nested, so that a window also has '''hierarchical''' features: access to sub windows and the parent window, adding a sub window, deleting a sub window, attaching to another parent and so on. Rather than writing complex class that would contain specific implementations for all of these features, it is preferable to inherit all hierarchical features from TREE (a class in EiffelBase describing trees), and all graphical features from a class RECTANGLE. + +Inheritance complements the "client" relation by providing another form of reuse that yields remarkable economies of effort -- for analysis, design, implementation, evolution -- and has a profound effect on the entire software development process. + +The very power of inheritance demands adequate means to keep it under control. Multiple inheritance, in particular, raises the question of name conflicts between features inherited from different parents; this case will inevitably arise in practice, especially for classes contributed by independent developers. You may remove such a name conflict through '''renaming''', as in + +class C + inherit + A + rename + x as x1, + y as y1 + end + + B + rename + x as x2, + y as y2 + end + +feature ... + + +Here, if both A and B have features named x and y, class C would be invalid without the renaming. + +Renaming also serves to provide more appropriate feature names in descendants. For example, class WINDOW may inherit a routine insert_subtree from TREE. For clients of WINDOW, however, such a routine name is no longer appropriate. An application that uses this class needs coherent window terminology, and should have to concern itself with the inheritance structure that led to the class. So you may wish to rename insert_subtree as add_subwindow in the inheritance clause of WINDOW. + +As a further protection against misusing multiple inheritance, the invariants of all parent classes automatically apply to a newly defined class. So classes may not be combined if their invariants are incompatible. + + + + diff --git a/documentation/18.11/eiffel/Tutorials/invitation-eiffel-i2e/i2e-invitation-eiffel-copyright.wiki b/documentation/18.11/eiffel/Tutorials/invitation-eiffel-i2e/i2e-invitation-eiffel-copyright.wiki new file mode 100644 index 00000000..c6aa3eaa --- /dev/null +++ b/documentation/18.11/eiffel/Tutorials/invitation-eiffel-i2e/i2e-invitation-eiffel-copyright.wiki @@ -0,0 +1,37 @@ +[[Property:title|I2E: Invitation to Eiffel Copyright]] +[[Property:weight|0]] +[[Property:uuid|ce7b4af4-b669-9fec-92e1-c24c4f089336]] +Title: Invitation to Eiffel, Eiffel Software Technical Report TR-EI-67/IV. + +==Publication history== +First published 1987. Some revisions (in particular Web versions) have used the title "Eiffel in a Nutshell"
+This version: July 2001. Introduces coverage of agents; several other improvements. Corresponds to release 5.0 of the EiffelStudio environment. +==Author== +Bertrand Meyer +==Software Credits== +See acknowledgments in book ''[[Eiffel: The Language]]''. +==Cover Design== +Rich Ayling. +==Copyright notice and proprietary information== +Copyright Interactive Software Engineering Inc. (Eiffel Software), 2001. May not be reproduced in any form (including electronic storage) without the written permission of Eiffel Software . "Eiffel Power" and the Eiffel Power logo are trademarks of Eiffel Software . All uses of the product documented here are subject to the terms and conditions of the Eiffel Software Eiffel user license. Any other use or duplication is a violation of the applicable laws on copyright, trade secrets and intellectual property. +==Special duplication permission for educational institutions== +Degree-granting educational institutions using Eiffel Software Eiffel for teaching purposes as part of the [http://www.eiffel.com/educators/resources.html Eiffel University Partnership Program] may be permitted under certain conditions to copy specific parts of this book. Contact Eiffel Software for details. +{{info|About Eiffel Software (Interactive Software Engineering) helps you produce software better, faster and cheaper. Eiffel Software provides a wide range of products and services based on object technology, including Eiffel Software Eiffel, a complete development environment for the full system life cycle. Eiffel Software's training courses, available worldwide, cover key management and technical topics. Eiffel Software's consultants are available to address your project needs at all levels. Eiffel Software's TOOLS (Technology of Object-Oriented Languages and Systems) conferences, [http://www.tools-conferences.com http://www.tools-conferences.com] , are the meeting point for anyone interested in the software technologies of the future. Eiffel Software originated one of the earliest . NET products and offers a full range of . NET services and training at [http://www.dotnetexperts.com http://www.dotnetexperts.com] . }} + +==For more information== +Interactive Software Engineering Inc.
+Eiffel Software Building,
+356 Storke Road,
+Goleta,
+CA, 93117
+USA.
+
+Telephone 805-685-1006,
+Fax 805-685-6869 +==Internet and email== +Eiffel Software maintains a rich source of information at [http://eiffel.com http://eiffel.com] , with more than 1200 Web pages including online documentation, downloadable files, product descriptions, links to Eiffel Software partners, University Partnership program, mailing list archives, announcements, press coverage, Frequently Asked Questions, Support pages, and much more. Visit [http://www.eiffel.com/general/contact_details.html http://www.eiffel.com/general/contact_details.html] to request information about products and services. To subscribe to the Eiffel Software Eiffel user list, go to [http://groups.eiffel.com/join http://groups.eiffel.com/join] . +==Support programs== +Eiffel Software offers a variety of support options tailored to the diverse needs of its customers. See [http://support.eiffel.com http://support.eiffel.com] for details. + + + diff --git a/documentation/18.11/eiffel/Tutorials/invitation-eiffel-i2e/i2e-object-oriented-design.wiki b/documentation/18.11/eiffel/Tutorials/invitation-eiffel-i2e/i2e-object-oriented-design.wiki new file mode 100644 index 00000000..2ee7b3fc --- /dev/null +++ b/documentation/18.11/eiffel/Tutorials/invitation-eiffel-i2e/i2e-object-oriented-design.wiki @@ -0,0 +1,25 @@ +[[Property:title|I2E: Object-Oriented Design]] +[[Property:weight|-12]] +[[Property:uuid|e0a1f24e-5dd7-e5f8-8be8-8da32cc6a91c]] +To achieve reusability, extendibility and reliability, the principles of object-oriented design provide the best known technical answer. + +An in-depth discussion of these principles fall beyond the scope of this introduction but here is a short definition: + +{{info|Object-oriented design is the construction of software systems as structured collections of abstract data type implementations, or "classes". }} + + +The following points are worth noting in this definition:
+* The emphasis is on structuring a system around the types of objects it manipulates (not the functions it performs on them) and on reusing whole data structures together with the associated operations (not isolated routines). +* Objects are described as instances of abstract data types -- that is to say, data structures known from an official interface rather than through their representation. +* The basic modular unit, called the class, describes one implementation of an abstract data type (or, in the case of "deferred" classes, as studied below, a set of possible implementations of the same abstract data type). +* The word ''collection'' reflects how classes should be designed: as units which are interesting and useful on their own, independently of the systems to which they belong, and may be reused by many different systems. Software construction is viewed as the assembly of existing classes, not as a top-down process starting from scratch. +* Finally, the word ''structured'' reflects the existence of two important relations between classes: the client and inheritance relations. + + +Eiffel makes these techniques available to developers in a simple and practical way. + +As a language, Eiffel includes more than presented in this introduction, but not much more; it is a small language, not much bigger (by such a measure as the number of keywords) than Pascal. It was meant to be a member of the class of languages which programmers can master entirely -- as opposed to languages of which most programmers know only a subset. Yet it is appropriate for the development of industrial software systems, as has by now been shown by many full-scale projects, some in the thousands of classes and hundreds of thousands of lines, in companies around the world. + + + + diff --git a/documentation/18.11/eiffel/Tutorials/invitation-eiffel-i2e/i2e-polymorphism-and-dynamic-binding.wiki b/documentation/18.11/eiffel/Tutorials/invitation-eiffel-i2e/i2e-polymorphism-and-dynamic-binding.wiki new file mode 100644 index 00000000..1e3ed292 --- /dev/null +++ b/documentation/18.11/eiffel/Tutorials/invitation-eiffel-i2e/i2e-polymorphism-and-dynamic-binding.wiki @@ -0,0 +1,71 @@ +[[Property:title|I2E: Polymorphism and Dynamic Binding]] +[[Property:weight|-4]] +[[Property:uuid|1c3221be-0237-1c9a-407d-652a4084de12]] +Inheritance is not just a module combination and enrichment mechanism. It also enables the definition of flexible entities that may become attached to objects of various forms at run time, a property known as polymorphism. + +This remarkable facility must be reconciled with static typing. The language convention is simple: an assignment of the form a : = b is permitted not only if a and b are of the same type, but more generally if a and b are of reference types A and B, based on classes A and B such that B is a descendant of A. + +This corresponds to the intuitive idea that a value of a more specialized type may be assigned to an entity of a less specialized type -- but not the reverse. (As an analogy, consider that if you request vegetables, getting green vegetables is fine, but if you ask for green vegetables, receiving a dish labeled just "vegetables" is not acceptable, as it could include, say, carrots.) + +What makes this possibility particularly powerful is the complementary facility: '''feature redefinition'''. A class may redefine some or all of the features which it inherits from its parents. For an attribute or function, the redefinition may affect the type, replacing the original by a descendant; for a routine it may also affect the implementation, replacing the original routine body by a new one. + +Assume for example a class POLYGON, describing polygons, whose features include an array of points representing the vertices and a function perimeter which computes a polygon's perimeter by summing the successive distances between adjacent vertices. An heir of POLYGON may begin as: + +class RECTANGLE + inherit + POLYGON + redefine + perimeter + end + +feature -- Specific features of rectangles, such as: + + side1: REAL + side2: REAL + + perimeter: REAL + -- Rectangle-specific version + do + Result := 2 * (side1 + side2) + end + +... Other RECTANGLE features ... + + +Here it is appropriate to redefine perimeter for rectangles as there is a simpler and more efficient algorithm. Note the explicit redefine sub clause (which would come after the rename if present). + +Other descendants of POLYGON may also have their own redefinitions of perimeter. The version to use in any call is determined by the run-time form of the target. Consider the following class fragment: + + p: POLYGON + r: RECTANGLE + ... + + create p + create r + ... + if c then + p := r + end + print (p.perimeter) + +The polymorphic assignment p := r is valid because of the above rule. If condition c is false, p will be attached to an object of type POLYGON for the computation of p. perimeter, which will thus use the polygon algorithm. In the opposite case, however, p will be attached to a rectangle; then the computation will use the version redefined for RECTANGLE. This is known as '''dynamic binding'''. + +Dynamic binding provides a high degree of flexibility. The advantage for clients is the ability to request an operation (such as perimeter computation) without explicitly selecting one of its variants; the choice only occurs at run-time. This is essential in large systems, where many variants may be available; dynamic binding protects each component against changes in other components. + +This technique is particularly attractive when compared to its closest equivalent in traditional approaches, where you would need records with variant components, or union types (C), together with case (switch) instructions to discriminate between variants. This means that every client must know about every possible case, and that any extension may invalidate a large body of existing software. + +The combination of inheritance, feature redefinition, polymorphism and dynamic binding supports a development mode in which every module is open and incremental. When you want to reuse an existing class but need to adapt it to a new context, you can define a new descendant of that class (with new features, redefined ones, or both) without any change to the original. This facility is of great importance in software development, an activity that -- by design or circumstance -- is invariably incremental. + +The power of these techniques demands adequate controls. First, feature redefinition, as seen above, is explicit. Second, because the language is typed, a compiler can check statically whether a feature application a.f is correct. In contrast, dynamically typed object-oriented languages defer checks until run-time and hope for the best: if an object "sends a message" to another (that is to say, calls one of its routines) one just expects that the corresponding class, or one of its ancestors, will happen to include an appropriate routine; if not, a run-time error will occur. Such errors will not happen during the execution of a type-checked Eiffel system. + +In other words, the language reconciles dynamic binding with static typing. Dynamic binding guarantees that whenever more than one version of a routine is applicable the right version (the one most directly adapted to the target object) will be selected. Static typing means that the compiler makes sure there is at least one such version. + +This policy also yields an important performance benefit: in contrast with the costly run-time searches that may be needed with dynamic typing (since a requested routine may not be defined in the class of the target object but inherited from a possibly remote ancestor), the EiffelStudio implementation always finds the appropriate routine in constant-bounded time. + +Assertions provide a further mechanism for controlling the power of redefinition. In the absence of specific precautions, redefinition may be dangerous: how can a client be sure that evaluation of p.perimeter will not in some cases return, say, the area? Preconditions and postconditions provide the answer by limiting the amount of freedom granted to eventual redefiners. The rule is that any redefined version must satisfy a weaker or equal precondition and ensure a stronger or equal postcondition than in the original. This means that it must stay within the semantic boundaries set by the original assertions. + +The rules on redefinition and assertions are part of the Design by Contract™ theory, where redefinition and dynamic binding introduce subcontracting. POLYGON, for example, subcontracts the implementation of perimeter to RECTANGLE when applied to any entity that is attached at run-time to a rectangle object. An honest subcontractor is bound to honor the contract accepted by the prime contractor. This means that it may not impose stronger requirements on the clients, but may accept more general requests: weaker precondition; and that it must achieve at least as much as promised by the prime contractor, but may achieve more: stronger postcondition. + + + + diff --git a/documentation/18.11/eiffel/Tutorials/invitation-eiffel-i2e/i2e-putting-system-together.wiki b/documentation/18.11/eiffel/Tutorials/invitation-eiffel-i2e/i2e-putting-system-together.wiki new file mode 100644 index 00000000..05baa13d --- /dev/null +++ b/documentation/18.11/eiffel/Tutorials/invitation-eiffel-i2e/i2e-putting-system-together.wiki @@ -0,0 +1,33 @@ +[[Property:title|I2E: Putting a System Together]] +[[Property:weight|-1]] +[[Property:uuid|97460714-8ae1-a7cb-8216-235827045ea6]] +We have now studied the constituents of Eiffel software. It remains to see how you can combine these elements into executable '''systems''' (the Eiffel concept closest to the traditional notion of program) and libraries. + +How do you get an executable system? All you need is to
+* Provide a set of classes, called a '''universe'''. +* Designate one of these classes as the '''root class'''. +* Designate one of its creation procedures as the '''root procedure'''. + + +This defines what it means to execute the system: create one direct instance of the root class (the execution's '''root object'''); and call the root procedure on it. That's all. + +In any practical case, the root procedure will create other objects, call other routines on them, leading to further creations and calls. + +For the system to be valid, it must include all the classes which the root '''needs''' directly or indirectly; a class "needs" another if it is one of its heirs or clients. + +For a library we don't need to specify a root. If we want to make sure that every class in a library compiles fine we can specify that we want all classes to be the root. + +The Eiffel method suggests grouping related classes (typically 5 to 40 classes) into collections called '''clusters'''. A universe is then a set of clusters. For example the EiffelBase library is divided into clusters corresponding each to a major category of data structure: lists, tables, iteration, and so on. You can nest clusters, using for example EiffelBase, with its own subclusters as listed, as a cluster of your system. + +How will you specify a universe? Any Eiffel implementation can use its own conventions. EiffelStudio applies a simple policy:
+* Store each class in a single file, called its class file, with a name of the form name.e . For clarity, name should be the lower-case version of the class name, although this is a style rule, not a requirement. +* Put all the class files of a cluster into a single directory (folder on Windows), called its cluster directory. +{{note|It is desirable for clarity, as a style rule, to separate clusters that directly contain classes ("terminal clusters") from those that have subclusters. Cluster directories will then contain class files or cluster subdirectories, but not both. }} +* To specify a system, it suffices to provide a list of cluster directories, along with the name of the root class and root procedure. The universe consists of the classes contained in all the class files in the listed cluster directories. + + +Such a system specification is written in an ecf (eiffel configuration file) which is an xml based file format. It can be created by using the project settings in EiffelStudio. + + + + diff --git a/documentation/18.11/eiffel/Tutorials/invitation-eiffel-i2e/i2e-types.wiki b/documentation/18.11/eiffel/Tutorials/invitation-eiffel-i2e/i2e-types.wiki new file mode 100644 index 00000000..005c69b9 --- /dev/null +++ b/documentation/18.11/eiffel/Tutorials/invitation-eiffel-i2e/i2e-types.wiki @@ -0,0 +1,24 @@ +[[Property:title|I2E: Types]] +[[Property:weight|-10]] +[[Property:uuid|344a9fdc-3346-5e2d-5fdd-77464e92f72f]] +Eiffel is strongly typed for readability and reliability. Every entity is declared of a certain type, which may be either a reference type or an expanded type. + +Any type T is based on a class, which defines the operations that will be applicable to instances of T. The difference between the two categories of type affects the semantics of an entity x declared of type T: for a reference type, the most common case, possible values for x are references to objects; for an expanded type, the values are objects. In both cases, the type rules guarantee that the objects will be instances of T. + +A non-expanded class such as ACCOUNT yields a reference type. As a result, an entity of type ACCOUNT, such as acc in the earlier client example (see the declaration of acc and the accompanying picture as given in [[I2E: Classes]] ), denotes possible run-time references to objects of type ACCOUNT. + +In contrast, the value of an entity acc declared of type expanded ACCOUNT is an object such as the one shown on the figure below, with no reference. The only difference with the earlier figure is that the value of acc is now an ACCOUNT object, not a reference to such an object. No creation instruction is needed in this case. (The figure does not show the PERSON object to which the owner field of the ACCOUNT object -- itself a reference -- is attached.) + + +[[Image:invitation-3]] + + +An important group of expanded types, based on library classes, includes the basic types CHARACTER, DOUBLE, REAL, INTEGER, and BOOLEAN. Clearly, the value of an entity declared of type INTEGER should be an integer, not a reference to an object containing an integer value. Operations on these types are defined by prefix and infix operators such as "+" and "<". + +As a result of these conventions, the type system is uniform and consistent: all types, including the basic types, are defined from classes, either as reference types or as expanded types. + +In the case of basic types, for obvious reasons of efficiency, the compilation mechanism implements the standard arithmetic and boolean operations directly through the corresponding machine operations, not through routine calls. But this is only a compiler optimization, which does not hamper the conceptual homogeneity of the type edifice. + + + + diff --git a/documentation/18.11/eiffel/Tutorials/invitation-eiffel-i2e/i2e-what-must-i-know-first.wiki b/documentation/18.11/eiffel/Tutorials/invitation-eiffel-i2e/i2e-what-must-i-know-first.wiki new file mode 100644 index 00000000..a40b4903 --- /dev/null +++ b/documentation/18.11/eiffel/Tutorials/invitation-eiffel-i2e/i2e-what-must-i-know-first.wiki @@ -0,0 +1,10 @@ +[[Property:title|I2E: What Must I Know First?]] +[[Property:weight|-14]] +[[Property:uuid|f40b4a30-87f7-2c27-b6e7-ef2f2a74661b]] +This Invitation assumes that you have some experience of software development, but that's all. Previous exposure to object technology is not required. If you've had it, it will help; but if it has all been to notations like UML or programming languages like C++ and Java, you should not let it guide your study of this Invitation. Although Eiffel shares a number of properties with these other approaches, it takes a fresh path to object technology, based on a small number of simple, far-reaching concepts. + +Once you are familiar with the basic ideas you may want to try them with EiffelStudio, which provides a direct implementation of the Eiffel concepts, available in a completely portable way across Windows, Linux, many versions of Unix and OpenVMS. + + + + diff --git a/documentation/18.11/eiffel/Tutorials/invitation-eiffel-i2e/index.wiki b/documentation/18.11/eiffel/Tutorials/invitation-eiffel-i2e/index.wiki new file mode 100644 index 00000000..ad06e3be --- /dev/null +++ b/documentation/18.11/eiffel/Tutorials/invitation-eiffel-i2e/index.wiki @@ -0,0 +1,6 @@ +[[Property:title|Invitation to Eiffel (I2E)]] +[[Property:link_title|Invitation to Eiffel]] +[[Property:weight|-15]] +[[Property:uuid|7a606387-2653-b122-b4ef-e283a389656e]] +The Invitation to Eiffel (I2E) is a short set of pages that should provide you with the essence of the Eiffel way, without taking too much of your time. Enjoy this profoundly different way of thinking about developing software! When you are done, move on to the more detailed Eiffel tutorial. + diff --git a/documentation/18.11/eiffel/_files/expression_language.pdf b/documentation/18.11/eiffel/_files/expression_language.pdf new file mode 100644 index 00000000..6aab45db Binary files /dev/null and b/documentation/18.11/eiffel/_files/expression_language.pdf differ diff --git a/documentation/18.11/eiffel/_files/void-safe-eiffel.pdf b/documentation/18.11/eiffel/_files/void-safe-eiffel.pdf new file mode 100644 index 00000000..a736f52a Binary files /dev/null and b/documentation/18.11/eiffel/_files/void-safe-eiffel.pdf differ diff --git a/documentation/18.11/eiffel/_images/Catcall_demo_class_diagram.png b/documentation/18.11/eiffel/_images/Catcall_demo_class_diagram.png new file mode 100644 index 00000000..bc9dc593 Binary files /dev/null and b/documentation/18.11/eiffel/_images/Catcall_demo_class_diagram.png differ diff --git a/documentation/18.11/eiffel/_images/Catcall_demo_class_diagram.png.data b/documentation/18.11/eiffel/_images/Catcall_demo_class_diagram.png.data new file mode 100644 index 00000000..9deac1f8 --- /dev/null +++ b/documentation/18.11/eiffel/_images/Catcall_demo_class_diagram.png.data @@ -0,0 +1,3 @@ +title=Catcall example class diagram +author=halw +path=content/catcall-example-class-diagram diff --git a/documentation/18.11/eiffel/_images/Catcall_warning.png b/documentation/18.11/eiffel/_images/Catcall_warning.png new file mode 100644 index 00000000..4dd3ed4d Binary files /dev/null and b/documentation/18.11/eiffel/_images/Catcall_warning.png differ diff --git a/documentation/18.11/eiffel/_images/Catcall_warning.png.data b/documentation/18.11/eiffel/_images/Catcall_warning.png.data new file mode 100644 index 00000000..0d58433f --- /dev/null +++ b/documentation/18.11/eiffel/_images/Catcall_warning.png.data @@ -0,0 +1,3 @@ +title=Catcall compiler warning +author=halw +path=content/catcall-compiler-warning diff --git a/documentation/18.11/eiffel/_images/ECMA-367_cover.png b/documentation/18.11/eiffel/_images/ECMA-367_cover.png new file mode 100644 index 00000000..4c837a29 Binary files /dev/null and b/documentation/18.11/eiffel/_images/ECMA-367_cover.png differ diff --git a/documentation/18.11/eiffel/_images/ECMA-367_cover.png.data b/documentation/18.11/eiffel/_images/ECMA-367_cover.png.data new file mode 100644 index 00000000..f0adb2c8 --- /dev/null +++ b/documentation/18.11/eiffel/_images/ECMA-367_cover.png.data @@ -0,0 +1,3 @@ +title=ECMA-367 cover small +author=halw +path=content/ecma-367-cover-small diff --git a/documentation/18.11/eiffel/_images/ETL.png b/documentation/18.11/eiffel/_images/ETL.png new file mode 100644 index 00000000..7de269ca Binary files /dev/null and b/documentation/18.11/eiffel/_images/ETL.png differ diff --git a/documentation/18.11/eiffel/_images/ETL.png.data b/documentation/18.11/eiffel/_images/ETL.png.data new file mode 100644 index 00000000..10d4f2c1 --- /dev/null +++ b/documentation/18.11/eiffel/_images/ETL.png.data @@ -0,0 +1,3 @@ +title=ETL +author=halw +path=content/etl diff --git a/documentation/18.11/eiffel/_images/OOSC2_small.png b/documentation/18.11/eiffel/_images/OOSC2_small.png new file mode 100644 index 00000000..9da6e0b4 Binary files /dev/null and b/documentation/18.11/eiffel/_images/OOSC2_small.png differ diff --git a/documentation/18.11/eiffel/_images/OOSC2_small.png.data b/documentation/18.11/eiffel/_images/OOSC2_small.png.data new file mode 100644 index 00000000..fdb8413c --- /dev/null +++ b/documentation/18.11/eiffel/_images/OOSC2_small.png.data @@ -0,0 +1,3 @@ +title=OOSC2 small +author=halw +path=content/oosc2-small diff --git a/documentation/18.11/eiffel/_images/Touch_of_Class_cover_small.png b/documentation/18.11/eiffel/_images/Touch_of_Class_cover_small.png new file mode 100644 index 00000000..34f00bff Binary files /dev/null and b/documentation/18.11/eiffel/_images/Touch_of_Class_cover_small.png differ diff --git a/documentation/18.11/eiffel/_images/Touch_of_Class_cover_small.png.data b/documentation/18.11/eiffel/_images/Touch_of_Class_cover_small.png.data new file mode 100644 index 00000000..e87bab71 --- /dev/null +++ b/documentation/18.11/eiffel/_images/Touch_of_Class_cover_small.png.data @@ -0,0 +1,3 @@ +title=Touch of Class cover small +author=halw +path=content/touch-class-cover-small diff --git a/documentation/18.11/eiffel/_images/Tour_sec_5_class_diagram.png b/documentation/18.11/eiffel/_images/Tour_sec_5_class_diagram.png new file mode 100644 index 00000000..e7364c8e Binary files /dev/null and b/documentation/18.11/eiffel/_images/Tour_sec_5_class_diagram.png differ diff --git a/documentation/18.11/eiffel/_images/Tour_sec_5_class_diagram.png.data b/documentation/18.11/eiffel/_images/Tour_sec_5_class_diagram.png.data new file mode 100644 index 00000000..e1c7e593 --- /dev/null +++ b/documentation/18.11/eiffel/_images/Tour_sec_5_class_diagram.png.data @@ -0,0 +1,3 @@ +title=tutorial-4 +author=halw +path=content/tutorial-4 diff --git a/documentation/18.11/eiffel/_images/VGCC_error.png b/documentation/18.11/eiffel/_images/VGCC_error.png new file mode 100644 index 00000000..4acfde61 Binary files /dev/null and b/documentation/18.11/eiffel/_images/VGCC_error.png differ diff --git a/documentation/18.11/eiffel/_images/VGCC_error.png.data b/documentation/18.11/eiffel/_images/VGCC_error.png.data new file mode 100644 index 00000000..f89f3679 --- /dev/null +++ b/documentation/18.11/eiffel/_images/VGCC_error.png.data @@ -0,0 +1,3 @@ +title=VGCC error +author=halw +path=content/vgcc-error diff --git a/documentation/18.11/eiffel/_images/VoidSafeAddLibraryDialog_noGobo.png b/documentation/18.11/eiffel/_images/VoidSafeAddLibraryDialog_noGobo.png new file mode 100644 index 00000000..edbba2fc Binary files /dev/null and b/documentation/18.11/eiffel/_images/VoidSafeAddLibraryDialog_noGobo.png differ diff --git a/documentation/18.11/eiffel/_images/VoidSafeAddLibraryDialog_noGobo.png.data b/documentation/18.11/eiffel/_images/VoidSafeAddLibraryDialog_noGobo.png.data new file mode 100644 index 00000000..4807a799 --- /dev/null +++ b/documentation/18.11/eiffel/_images/VoidSafeAddLibraryDialog_noGobo.png.data @@ -0,0 +1,3 @@ +title=VoidSafeAddLibraryDialog +author=halw +path=content/voidsafeaddlibrarydialog diff --git a/documentation/18.11/eiffel/_images/VoidSafeErrorList.png b/documentation/18.11/eiffel/_images/VoidSafeErrorList.png new file mode 100644 index 00000000..9e2a5614 Binary files /dev/null and b/documentation/18.11/eiffel/_images/VoidSafeErrorList.png differ diff --git a/documentation/18.11/eiffel/_images/VoidSafeErrorList.png.data b/documentation/18.11/eiffel/_images/VoidSafeErrorList.png.data new file mode 100644 index 00000000..48731813 --- /dev/null +++ b/documentation/18.11/eiffel/_images/VoidSafeErrorList.png.data @@ -0,0 +1,3 @@ +title=VoidSafeErrorList +author=halw +path=content/voidsafeerrorlist diff --git a/documentation/18.11/eiffel/_images/VoidSafePrecompileOffer.png b/documentation/18.11/eiffel/_images/VoidSafePrecompileOffer.png new file mode 100644 index 00000000..d0c2739e Binary files /dev/null and b/documentation/18.11/eiffel/_images/VoidSafePrecompileOffer.png differ diff --git a/documentation/18.11/eiffel/_images/VoidSafePrecompileOffer.png.data b/documentation/18.11/eiffel/_images/VoidSafePrecompileOffer.png.data new file mode 100644 index 00000000..a559422c --- /dev/null +++ b/documentation/18.11/eiffel/_images/VoidSafePrecompileOffer.png.data @@ -0,0 +1,3 @@ +title=VoidSafePrecompileOffer +author=halw +path=content/voidsafeprecompileoffer diff --git a/documentation/18.11/eiffel/_images/VoidSafeVEVI1.png b/documentation/18.11/eiffel/_images/VoidSafeVEVI1.png new file mode 100644 index 00000000..9ebc80e4 Binary files /dev/null and b/documentation/18.11/eiffel/_images/VoidSafeVEVI1.png differ diff --git a/documentation/18.11/eiffel/_images/VoidSafeVEVI1.png.data b/documentation/18.11/eiffel/_images/VoidSafeVEVI1.png.data new file mode 100644 index 00000000..cfa1e2c5 --- /dev/null +++ b/documentation/18.11/eiffel/_images/VoidSafeVEVI1.png.data @@ -0,0 +1,3 @@ +title=VoidSafeVEVI1 +author=halw +path=content/voidsafevevi1 diff --git a/documentation/18.11/eiffel/_images/VoidSafeVJAR1.png b/documentation/18.11/eiffel/_images/VoidSafeVJAR1.png new file mode 100644 index 00000000..b757a42b Binary files /dev/null and b/documentation/18.11/eiffel/_images/VoidSafeVJAR1.png differ diff --git a/documentation/18.11/eiffel/_images/VoidSafeVJAR1.png.data b/documentation/18.11/eiffel/_images/VoidSafeVJAR1.png.data new file mode 100644 index 00000000..a6ce8267 --- /dev/null +++ b/documentation/18.11/eiffel/_images/VoidSafeVJAR1.png.data @@ -0,0 +1,3 @@ +title=VoidSafeVJAR1 +author=halw +path=content/voidsafevjar1 diff --git a/documentation/18.11/eiffel/_images/invitation-2.png b/documentation/18.11/eiffel/_images/invitation-2.png new file mode 100644 index 00000000..644c0fda Binary files /dev/null and b/documentation/18.11/eiffel/_images/invitation-2.png differ diff --git a/documentation/18.11/eiffel/_images/invitation-2.png.data b/documentation/18.11/eiffel/_images/invitation-2.png.data new file mode 100644 index 00000000..08f9b58b --- /dev/null +++ b/documentation/18.11/eiffel/_images/invitation-2.png.data @@ -0,0 +1,3 @@ +title=invitation-2 +author=admin +path=content/invitation-2 diff --git a/documentation/18.11/eiffel/_images/invitation-3.png b/documentation/18.11/eiffel/_images/invitation-3.png new file mode 100644 index 00000000..d5b7d3b6 Binary files /dev/null and b/documentation/18.11/eiffel/_images/invitation-3.png differ diff --git a/documentation/18.11/eiffel/_images/invitation-3.png.data b/documentation/18.11/eiffel/_images/invitation-3.png.data new file mode 100644 index 00000000..9ff2ef7b --- /dev/null +++ b/documentation/18.11/eiffel/_images/invitation-3.png.data @@ -0,0 +1,3 @@ +title=invitation-3 +author=admin +path=content/invitation-3 diff --git a/documentation/18.11/eiffel/_images/invitation-4.png b/documentation/18.11/eiffel/_images/invitation-4.png new file mode 100644 index 00000000..75d213eb Binary files /dev/null and b/documentation/18.11/eiffel/_images/invitation-4.png differ diff --git a/documentation/18.11/eiffel/_images/invitation-4.png.data b/documentation/18.11/eiffel/_images/invitation-4.png.data new file mode 100644 index 00000000..0a9644cd --- /dev/null +++ b/documentation/18.11/eiffel/_images/invitation-4.png.data @@ -0,0 +1,3 @@ +title=invitation-4 +author=admin +path=content/invitation-4 diff --git a/documentation/18.11/eiffel/_images/invitation-5.png b/documentation/18.11/eiffel/_images/invitation-5.png new file mode 100644 index 00000000..5733334b Binary files /dev/null and b/documentation/18.11/eiffel/_images/invitation-5.png differ diff --git a/documentation/18.11/eiffel/_images/invitation-5.png.data b/documentation/18.11/eiffel/_images/invitation-5.png.data new file mode 100644 index 00000000..d852bd29 --- /dev/null +++ b/documentation/18.11/eiffel/_images/invitation-5.png.data @@ -0,0 +1,3 @@ +title=invitation-5 +author=admin +path=content/invitation-5 diff --git a/documentation/18.11/eiffel/_images/tutorial-10.png b/documentation/18.11/eiffel/_images/tutorial-10.png new file mode 100644 index 00000000..c5d680f5 Binary files /dev/null and b/documentation/18.11/eiffel/_images/tutorial-10.png differ diff --git a/documentation/18.11/eiffel/_images/tutorial-10.png.data b/documentation/18.11/eiffel/_images/tutorial-10.png.data new file mode 100644 index 00000000..00154ebf --- /dev/null +++ b/documentation/18.11/eiffel/_images/tutorial-10.png.data @@ -0,0 +1,3 @@ +title=tutorial-10 +author=admin +path=content/tutorial-10 diff --git a/documentation/18.11/eiffel/_images/tutorial-11.png b/documentation/18.11/eiffel/_images/tutorial-11.png new file mode 100644 index 00000000..fc3ff485 Binary files /dev/null and b/documentation/18.11/eiffel/_images/tutorial-11.png differ diff --git a/documentation/18.11/eiffel/_images/tutorial-11.png.data b/documentation/18.11/eiffel/_images/tutorial-11.png.data new file mode 100644 index 00000000..fec1db81 --- /dev/null +++ b/documentation/18.11/eiffel/_images/tutorial-11.png.data @@ -0,0 +1,3 @@ +title=tutorial-11 +author=admin +path=content/tutorial-11 diff --git a/documentation/18.11/eiffel/_images/tutorial-12.png b/documentation/18.11/eiffel/_images/tutorial-12.png new file mode 100644 index 00000000..0c8eb762 Binary files /dev/null and b/documentation/18.11/eiffel/_images/tutorial-12.png differ diff --git a/documentation/18.11/eiffel/_images/tutorial-12.png.data b/documentation/18.11/eiffel/_images/tutorial-12.png.data new file mode 100644 index 00000000..60f09c82 --- /dev/null +++ b/documentation/18.11/eiffel/_images/tutorial-12.png.data @@ -0,0 +1,3 @@ +title=tutorial-12 +author=admin +path=content/tutorial-12 diff --git a/documentation/18.11/eiffel/_images/tutorial-13.png b/documentation/18.11/eiffel/_images/tutorial-13.png new file mode 100644 index 00000000..e1cf7705 Binary files /dev/null and b/documentation/18.11/eiffel/_images/tutorial-13.png differ diff --git a/documentation/18.11/eiffel/_images/tutorial-13.png.data b/documentation/18.11/eiffel/_images/tutorial-13.png.data new file mode 100644 index 00000000..812c0a57 --- /dev/null +++ b/documentation/18.11/eiffel/_images/tutorial-13.png.data @@ -0,0 +1,3 @@ +title=tutorial-13 +author=admin +path=content/tutorial-13 diff --git a/documentation/18.11/eiffel/_images/tutorial-14.png b/documentation/18.11/eiffel/_images/tutorial-14.png new file mode 100644 index 00000000..c067ec78 Binary files /dev/null and b/documentation/18.11/eiffel/_images/tutorial-14.png differ diff --git a/documentation/18.11/eiffel/_images/tutorial-14.png.data b/documentation/18.11/eiffel/_images/tutorial-14.png.data new file mode 100644 index 00000000..517f06ad --- /dev/null +++ b/documentation/18.11/eiffel/_images/tutorial-14.png.data @@ -0,0 +1,3 @@ +title=tutorial-14 +author=admin +path=content/tutorial-14 diff --git a/documentation/18.11/eiffel/_images/tutorial-2.png b/documentation/18.11/eiffel/_images/tutorial-2.png new file mode 100644 index 00000000..941406b5 Binary files /dev/null and b/documentation/18.11/eiffel/_images/tutorial-2.png differ diff --git a/documentation/18.11/eiffel/_images/tutorial-2.png.data b/documentation/18.11/eiffel/_images/tutorial-2.png.data new file mode 100644 index 00000000..0901a1a7 --- /dev/null +++ b/documentation/18.11/eiffel/_images/tutorial-2.png.data @@ -0,0 +1,3 @@ +title=tutorial-2 +author=admin +path=content/tutorial-2 diff --git a/documentation/18.11/eiffel/_images/tutorial-3.png b/documentation/18.11/eiffel/_images/tutorial-3.png new file mode 100644 index 00000000..0a58d632 Binary files /dev/null and b/documentation/18.11/eiffel/_images/tutorial-3.png differ diff --git a/documentation/18.11/eiffel/_images/tutorial-3.png.data b/documentation/18.11/eiffel/_images/tutorial-3.png.data new file mode 100644 index 00000000..d94c5dcf --- /dev/null +++ b/documentation/18.11/eiffel/_images/tutorial-3.png.data @@ -0,0 +1,3 @@ +title=tutorial-3 +author=admin +path=content/tutorial-3 diff --git a/documentation/18.11/eiffel/_images/tutorial-5.png b/documentation/18.11/eiffel/_images/tutorial-5.png new file mode 100644 index 00000000..2e4dd67e Binary files /dev/null and b/documentation/18.11/eiffel/_images/tutorial-5.png differ diff --git a/documentation/18.11/eiffel/_images/tutorial-5.png.data b/documentation/18.11/eiffel/_images/tutorial-5.png.data new file mode 100644 index 00000000..bbca28cb --- /dev/null +++ b/documentation/18.11/eiffel/_images/tutorial-5.png.data @@ -0,0 +1,3 @@ +title=tutorial-5 +author=admin +path=content/tutorial-5 diff --git a/documentation/18.11/eiffel/_images/tutorial-6.png b/documentation/18.11/eiffel/_images/tutorial-6.png new file mode 100644 index 00000000..6ac1f2b1 Binary files /dev/null and b/documentation/18.11/eiffel/_images/tutorial-6.png differ diff --git a/documentation/18.11/eiffel/_images/tutorial-6.png.data b/documentation/18.11/eiffel/_images/tutorial-6.png.data new file mode 100644 index 00000000..b180a4e0 --- /dev/null +++ b/documentation/18.11/eiffel/_images/tutorial-6.png.data @@ -0,0 +1,3 @@ +title=tutorial-6 +author=admin +path=content/tutorial-6 diff --git a/documentation/18.11/eiffel/_images/tutorial-7.png b/documentation/18.11/eiffel/_images/tutorial-7.png new file mode 100644 index 00000000..513ac0f8 Binary files /dev/null and b/documentation/18.11/eiffel/_images/tutorial-7.png differ diff --git a/documentation/18.11/eiffel/_images/tutorial-7.png.data b/documentation/18.11/eiffel/_images/tutorial-7.png.data new file mode 100644 index 00000000..c38f5f4e --- /dev/null +++ b/documentation/18.11/eiffel/_images/tutorial-7.png.data @@ -0,0 +1,3 @@ +title=tutorial-7 +author=admin +path=content/tutorial-7 diff --git a/documentation/18.11/eiffel/_images/tutorial-8.png b/documentation/18.11/eiffel/_images/tutorial-8.png new file mode 100644 index 00000000..07e4f070 Binary files /dev/null and b/documentation/18.11/eiffel/_images/tutorial-8.png differ diff --git a/documentation/18.11/eiffel/_images/tutorial-8.png.data b/documentation/18.11/eiffel/_images/tutorial-8.png.data new file mode 100644 index 00000000..cdcab461 --- /dev/null +++ b/documentation/18.11/eiffel/_images/tutorial-8.png.data @@ -0,0 +1,3 @@ +title=tutorial-8 +author=admin +path=content/tutorial-8 diff --git a/documentation/18.11/eiffel/_images/tutorial-9.png b/documentation/18.11/eiffel/_images/tutorial-9.png new file mode 100644 index 00000000..ed7980ac Binary files /dev/null and b/documentation/18.11/eiffel/_images/tutorial-9.png differ diff --git a/documentation/18.11/eiffel/_images/tutorial-9.png.data b/documentation/18.11/eiffel/_images/tutorial-9.png.data new file mode 100644 index 00000000..46d38ae6 --- /dev/null +++ b/documentation/18.11/eiffel/_images/tutorial-9.png.data @@ -0,0 +1,3 @@ +title=tutorial-9 +author=admin +path=content/tutorial-9 diff --git a/documentation/18.11/eiffel/index.wiki b/documentation/18.11/eiffel/index.wiki new file mode 100644 index 00000000..bef52569 --- /dev/null +++ b/documentation/18.11/eiffel/index.wiki @@ -0,0 +1,16 @@ +[[Property:title|Eiffel]] +[[Property:description|Eiffel development method and the Eiffel programming language]] +[[Property:link_title|Eiffel]] +[[Property:weight|1]] +[[Property:uuid|ae6f212e-bdc6-d5f2-972a-1bfee586479e]] +== The Eiffel Method and Language == + +Here you can learn about the Eiffel development method and the Eiffel programming language. + +At the heart of the Eiffel Development Framework is the Eiffel method. Everything else -- the language, the tools, the libraries -- exists because of the method. + +In order for us to communicate effectively about the activities of the method we must have some way to record the products of those activities. That is what the Eiffel programming language does for us ... with the added benefit that, ultimately, we implement whole running software systems in the language. + +The method is laid out in wonderful detail in [[Object-Oriented Software Construction, 2nd Edition]]. But, if you're just getting started, you will find some good introductory material on this page. The invitation to Eiffel is fairly short introduction to the method and language. and the tutorial gives a more detailed look. + + diff --git a/documentation/18.11/eiffelstudio/Tutorials/Technical_papers/index.wiki b/documentation/18.11/eiffelstudio/Tutorials/Technical_papers/index.wiki new file mode 100644 index 00000000..f390f47e --- /dev/null +++ b/documentation/18.11/eiffelstudio/Tutorials/Technical_papers/index.wiki @@ -0,0 +1,9 @@ +[[Property:title|Technical papers about EiffelStudio]] +[[Property:description|Background, foundation, or supplemental information about uncovered topics]] +[[Property:link_title|Papers]] +[[Property:weight|4]] +[[Property:uuid|97fe7aa0-adbf-405a-b5be-8187470dce50]] +Occasionally papers are produced providing background, foundation, or supplemental information about the topics covered by the EiffelStudio documentation. Although the material in these papers might be of interest to many EiffelStudio users, they might not be suitable in their current form for inclusion in the mainstream documentation books. + +You will find a collection of these papers in this book. + diff --git a/documentation/18.11/eiffelstudio/Tutorials/appendix-writing-documentation-filters-eff-eiffel-filter-format.wiki b/documentation/18.11/eiffelstudio/Tutorials/appendix-writing-documentation-filters-eff-eiffel-filter-format.wiki new file mode 100644 index 00000000..ad07140c --- /dev/null +++ b/documentation/18.11/eiffelstudio/Tutorials/appendix-writing-documentation-filters-eff-eiffel-filter-format.wiki @@ -0,0 +1,119 @@ +[[Property:title|Appendix: Writing Documentation Filters with EFF, the Eiffel Filter Format]] +[[Property:weight|6]] +[[Property:uuid|0d17d433-3d4f-9575-49f7-d97eccb1a5b1]] +This appendix provides reference information, not needed in simple uses of EiffelStudio. + +We saw in the [[PRODUCING AND EXPORTING DOCUMENTATION|section on documentation]] that you can output documentation about your system in many different formats. A number of predefined formats are available, from Postscript to Microsoft's Rich Text Format, FrameMaker, HTML with and without style sheets, TEX and others. There's nothing special about these formats: they just make their conventions known to EiffelStudio through a '''filter''' expressed in a simple notation called EFF, or Eiffel Filter Format. If you have a favorite format that you'd like EiffelStudio to use for producing documentation, you can define your own filter in EFF. Applications include: +* Producing a variant of an existing format, to support some "house style" that you have defined, such as a different formatting or fonts. +* Producing documentation for a text processing tool that's not among those supported by default. +* Producing documentation that purposely omit some parts of Eiffel texts, in line with the ideas applied by the Contract and Flat Contract forms. + +This appendix describes EFF and its conventions, enabling you to write filters. Note that in practice the best way to write an EFF filter is usually not from scratch, but by copying an existing filter -- one that seems closest to your needs -- and adapting the copy. + +==Where to put filters== + +When you choose to generate documentation, EiffelStudio will ask you to select a filter from a list it obtains by looking up the files of extension . fil in the directory +$ISE_EIFFEL/studio/filters + +To make a new filter available to yourself and other users of this installation, just add the corresponding file name . fil to this directory. Make sure to choose the appropriate name, since this is what the menu of available filters will display. + +==Filter basics== + +An EFF filter follows a very simple structure. As with all other Eiffel-related notations (such as Eiffel itself and Lace, the control language for Eiffel systems), any line or part of a line beginning with two consecutive dashes -- is a comment, except if it immediately follows a percent sign since, as will be seen below, - %- is used to denote an Eiffel comment in the class text. Blank lines are also permitted. Comments and blank lines carry no semantic value. + +Except for comments and blank lines, a filter is a sequence of entries, all of the form +Construct | Replacement + +where: Construct is one of a set of possible strings, most of which correspond to Eiffel constructs such as Class_declaration or Eiffel keywords such as class ; and Replacement is a string indicating how to format specimens of the Construct that appear in a class text. + +For readability, there may be any number of blanks or tabs between the Construct and the vertical bar |, so that you can align all the bars if you wish. On the right of the bar, however, all characters including blanks and tabs are significant, since they are part of the replacement for the Construct. + +==The asterisk== + +In the Replacement part, you may use the symbol * (asterisk) to denote the construct specimen itself. So for example the entry +Feature_clause | %N%N*%N%N + +specifies the following formatting for any Feature_clause: two successive blank lines (expressed as %N, New Line, a convention taken from Eiffel); the feature clause itself; two blank lines. + +Similarly, in an HTML format, the entry +External | * + +means that the Eiffel keyword external must appear in the filtered form immediately preceded by , the HTML code for switching to boldface, and immediately followed by , the code for reverting to the previous setup. Here you can also write the right-hand side without the asterisks, as external. If, however, all keywords are to use boldface, it is preferable to write a single entry +Keyword | * + +which, thanks to the asterisk, will govern all construct specimens of the Keyword category. You can still override this specification for an individual keyword by including a specific entry for it. + +==Constructs== + +The following general syntactic constructs may appear as the left-hand side, Construct, of an entry: + +Class_declaration +Class_end +Class_header +Class_name +Comment +Creators +Escape +Feature_clause +Feature_declaration +Features +Formal_generics +Indexing_clause +Inheritance +Invariant_clause +Keyword +New_line +Obsolete_clause +Suffix +Symbol +Tab + + +Most of these denote Eiffel constructs as they appear in the official language reference, the book [[Eiffel: The Language]] . Since the Eiffel construct names Feature, Invariant and Obsolete are also keywords and EFF, like Eiffel, is case-insensitive, the EFF construct names use the suffix _clause, for example Feature_clause. + +The constructs corresponding to syntactic constructs are self-explanatory. The others are: +* Class_end, denoting the final end of a class text. +* Keyword, denoting any Eiffel keyword among those listed in boldface in the corresponding appendix in [[Eiffel: The Language]] +* New_line, denoting any passage to a new line in the class text. +* Suffix, used to introduce the file extension for the generated documentation files. If you don't specify this, EiffelStudio will use the filter's name as extension. +* Symbol, denoting any of the Eiffel symbols listed in the corresponding appendix of [[Eiffel: The Language]] . +* Escape, to protect special characters of the external tool, as explained below. +* Tab, denoting any tab character appearing in the class text. + +==Keywords== + +A Construct part may consist of the name of an Eiffel keyword. To see the complete list of possible keywords, look at the template filter, file format.fil-template in the default filter directory $ISE_EIFFEL/studio/filters, which includes all of them with a single asterisk * as the Replacement part. + +If entries are present for both the Keyword construct and individual keywords, the individual keyword entries will override the general entry for the keywords listed; the general entry will apply to all other keywords. This makes it possible to have both a general convention for keywords and a special convention for some of them. + +==Symbol== + +A Construct part may consist of an Eiffel symbol, such as :=, /= and many others. Again, you may see the complete list by looking at format.fil-template. Note the following conventions: +* % * represents an asterisk. For example as a multiplication operator; the % avoids the confusion with the special meaning of the asterisk for EFF. You can find examples of this convention in the EFF filters for troff and gtroff. +* Similarly, the Eiffel comment symbol appears as - %-, since just writing - - would introduce a comment in the EFF filter itself. + +As with keywords, you may specify a general convention for symbols, defined by an entry for the construct Symbol, and special conventions for certain individual symbols. Specific symbol entries will override the general Symbol convention. + +==Escape characters== + +A text processing system or other external tool may attach a special role to characters that may normally appear in Eiffel texts. For example, the braces { and }, used in Eiffel's Export clauses, have a special meaning for TEX. Including them without precaution in TEX input will cause trouble. Similarly, many text processing formats attach a special meaning to the backslash character \ which, although not special for Eiffel, may appear in an Eiffel string. + +In such cases the filter must " escape " the special character, that is to say, protect it by other characters. For example troff and other text processing tools treat two successive backslash characters \\ as denoting a single backslash in the text to be output. The first backslash is the escape character, protecting the second one. + +The Escape construct addresses such cases. The first character that follows Escape (after one or more blanks or tabs) is the character to be escaped. The string after the vertical bar is the replacement for that character. + +Here for example is an escape entry for the backslash in tools that need to escape it through another backslash: + +==Special characters and strings== + +EFF uses Eiffel-like conventions, based on the percent sign, for control characters appearing in Replacement parts of entries. Two of these conventions have just been noted: % * to represent an asterisk and %- to represent a dash that does not introduce an Eiffel comment. In addition: +* %| denotes a vertical bar. (This is necessary since EFF uses | by itself in each entry to separate the Construct from the corresponding Replacement.) +* %N (recommended form) or %n denotes a new line. +* %T (recommended form) or %t denotes a tab. +* %% denotes a percent sign. +* % (percent followed by a space) denotes a space. This is equivalent to just a space, but more visible. + +If c is not one of the characters for which special conventions have been listed, % c denotes the character c itself. + +A multi-line entry uses the Eiffel convention for string continuations: % at the end of a line to signal that there is a continuation; a continuation line begins with zero or more spaces and tabs followed by a % ; the characters after the % are the continuation of the string. + diff --git a/documentation/18.11/eiffelstudio/Tutorials/browsing-features.wiki b/documentation/18.11/eiffelstudio/Tutorials/browsing-features.wiki new file mode 100644 index 00000000..c4c70a05 --- /dev/null +++ b/documentation/18.11/eiffelstudio/Tutorials/browsing-features.wiki @@ -0,0 +1,95 @@ +[[Property:title|Browsing Features]] +[[Property:weight|-6]] +[[Property:uuid|2c0b0a6c-08e8-fdbc-1eab-e2d87b01ce48]] +Let us get back to EiffelStudio. Before studying the documentation generation we saw how to display properties of '''classes'''. It's also interesting to explore the properties of '''features'''. + +There are two tools with similar sounding names that we will use to explore features: +# The [[Features Tool|Features tool]] (plural) which provides a list of the immediate features of the class on which the development window is targeted. This tool is located by default in the vertical pane on the right hand side of the development window. +# The Feature tool (singular) which allows you to explore the properties of some particular feature. By default, the Feature tool is available as a tab on the lower pane of the development window along with the Class tool, Outputs tool, and others. + +Your Development Window should still be targeted to class LIST, from the last view, Routines, that you displayed on it. If you've lost it, just retarget a Development Window to this class. + +Let's start by making the [[Features Tool|Features tool]] visible. To see the Features tool click on the tab labeled [[Image:features-tab]] (note that this is the plural "Features" versus the singular "Feature"). + +If the tab for the Features tool is not visible, bring it back by following the menu path: + +View --> Tools --> Features + + +While we are at it, let's get make the Feature tool visible as well. Click on the tab on the lower pane that's labeled [[Image:feature-tab]]. As with the Features tool, if the Feature tab is missing, you can use the menu path to restore it. + +One more thing, and we'll look at some features. If you restarted EiffelStudio since you worked through the [[Viewing Classes]] section, you may have to select Link Context Tool again from the View menu. + + +==Targeting to a feature== + +The list of features, organized by feature clauses, appears in the Features tool: + +[[Image:es gt features tool 01]] + +The class only has a few immediate features because most of its interesting features are inherited. Make sure the Editor tool is tall enough (as on the above figure) and click the feature forth, the last one, in the Feature Tree on the left. This makes the feature the Editor tool's current target, and scrolls the text to its declaration: + +[[Image:es gt features tool 02]] + +Note how both of the top target fields are now filled: the first one shows the target class, LIST, and the second one shows the target feature, forth. + + +==Basic feature information== + +Now let's look at the views of the feature forth provided in the Feature tool. + +A view of forth is already visible in the Feature tool. By default, it is the Flat view. + +[[Image:es gt feature tool 01]] + +The flat view of a feature, similar in concept to the flat view of a class, gives the full text of a feature, taking into account any inherited precondition or postcondition clauses. Here the feature as declared in the class appears in the top Editing Tool, with no precondition and an ensure then postcondition clause. But it's a redefinition of an inherited feature; the flat view in the bottom Context Tool shows the full precondition, inherited from the ancestor LINEAR, as well as the postcondition from LIST. + +Flat is just one of the available Feature Views, shown by the buttons on the toolbar of the Feature tool. + +[[Image:es gt feature tool toolbar buttons 01]] + +You can mouse-over the different buttons to see the views they represent. + +Just to the left of Flat, Basic Text gives the feature text, fully clickable. + + +==Who calls this feature?== + +To the right of Flat is Callers. Try it now by clicking the corresponding button. You may have to scroll down some in the display to see the series of entries show in the image below; + +[[Image:es gt feature tool callers 01]] + +This view shows all the places in the system that call the routine, or one of its redefinitions. Such information can be invaluable for debugging in particular. The successive paragraphs correspond to the various versions of forth in class LIST, its ancestors and its descendants. Reading from the top we'll examine a few entries: +* The version from LIST is called in LIST itself by the function is_equal. +* The version from LIST is called in routines in two debugger classes RT_DBG_CALL_RECORD and RT_DBG_COMMON +* The version forth from MULTI_ARRAY_LIST is a version in a descendant of LIST, and is called by three routines of MULTI_ARRAY_LIST itself: duplicate, put_right, and remove_right. +* Although it is not shown in the figure, if you scroll around some, you will find cases in which a descendant of forth has been renamed and that renamed version is called. For example child_forth from LINKED_TREE is descendant version of forth and is called by routines in LINKED_CURSOR_TREE and LINKED_TREE. + +The following five view buttons are similar except that they let you specify what kind of callers you are looking for, or what is being called by the currently selected feature. Feel free to explore these views. + + +==What happens to my feature through the inheritance hierarchy?== + +After the caller/callee views, the next view button is Implementers. + +This is a very useful view, showing all the ancestors and descendants of LIST that provide a separate version of forth, including the original introduction of this feature in LINEAR and subsequent redeclarations (redefinitions or effectings). The mention (version from) signals the version applicable to the current class, here LIST. + +Since all class and feature names on these views are hyperlinks, you can display any of the listed versions in a new Development Window by control-right-clicking it (we will see shortly how to display it in the ''same'' tool). Right-click on the feature name forth on the line that reads MULTI_ARRAY_LIST forth. This brings up a context menu and chose Show --> Text. The tool is now targeted to the routine forth from MULTI_ARRAY_LIST, so that you can see the implementation of the routine in that class. + +We still have two unexplored views, Ancestor versions and Descendant versions. Click the first of these to obtain the ancestor versions of forth from MULTI_ARRAY_LIST. + +The format is self-explanatory: for each ancestor of MULTI_ARRAY_LIST that has a version of MULTI_ARRAY_LIST 's forth feature, it indicates the name of that feature -- which could be something else than forth as a result of renaming, although here this happens only in descendants, not ancestors -- and the version of the feature applicable to the given class. + +In the case of feature merging (combining several features inherited from different parents, in conformance with the rules of the language) there could be more than one history branch, in this case each branch is labeled Branch #X. + +The next button, Descendant versions, similarly tells you all that happens to a feature in the descendants of the current class. + + +==Who has the same name?== + +The last button, Homonyms, displays all the features of the system which, related or not to the current feature by redeclaration, have the same name. You can then explore any such feature to see if the relationship is more than casual. + +In any system or library that takes advantage of inheritance and its associated mechanisms -- renaming, redefinition, effecting, undefinition, multiple and repeated inheritance, polymorphism, dynamic binding -- the feature browsing facilities that we have just explored are invaluable to track what happens to features. What makes them even more precious is their connection with the rest of the browsing and documentation capabilities, especially the pick-and-drop which we will now study. + + + diff --git a/documentation/18.11/eiffelstudio/Tutorials/command-line-compiler.wiki b/documentation/18.11/eiffelstudio/Tutorials/command-line-compiler.wiki new file mode 100644 index 00000000..2d56c99a --- /dev/null +++ b/documentation/18.11/eiffelstudio/Tutorials/command-line-compiler.wiki @@ -0,0 +1,10 @@ +[[Property:title|The Command-Line Compiler]] +[[Property:weight|4]] +[[Property:uuid|62bd8d62-a734-3ec0-9533-eaa096e7b81f]] +Along with compilation from within EiffelStudio, it is possible to start compilation from a command line (shell). This is useful in particular to recompile your system automatically as part of a script. + +Click [[EiffelStudio: Using command line options|here]] to see how to use the command line compiler and the set of supported options. + + + + diff --git a/documentation/18.11/eiffelstudio/Tutorials/compiling-and-executing-system.wiki b/documentation/18.11/eiffelstudio/Tutorials/compiling-and-executing-system.wiki new file mode 100644 index 00000000..509942a3 --- /dev/null +++ b/documentation/18.11/eiffelstudio/Tutorials/compiling-and-executing-system.wiki @@ -0,0 +1,56 @@ +[[Property:title|Compiling and Executing a System]] +[[Property:weight|-12]] +[[Property:uuid|58494be3-f29f-3a15-a27e-e635bdc71c53]] +EiffelStudio first comes up with a window and a dialog on top of it; the dialog looks like this (from here on the look-and-feel will be slightly different on platforms other than Windows, but the content will be the same): + +[[Image:es gt open 01]] + + +As this is our first project we want to "Add Project...". We could also +* "Create project", which would let you select one among the common schemes -- basic application, graphical Windows application, graphical multi-platform application, Microsoft .NET application -- and set up everything for you. +* "Open project", which would let you open a previously added project. + +In future sessions you'll probably use "Create project" for a new project, as it takes care of generating a root class and configuration file for you, and Open project" to open an existing project. + +Right now you first have to add the project, so click on the Add Project... button. This brings up a File Explorer inviting you to select an ECF file. The file you want is the file + + simple.ecf + + +in the directory "YOURDIR", (either $ISE_EIFFEL\examples\studio\tour or the copy that you have made). The ".ecf" file is an Eiffel Configuration File which contains the information necessary for construction of an Eiffel project. + +So, use the File Explorer to find and select the file simple.ecf. + +[[Image:es gt open 02]] + + +Click the button labeled Open to confirm. This starts compilation of your project. + +During Eiffel compilation, you can observe the successive compilation steps, or "degrees", in the [[Outputs tool]]. The bulk of our little project is the EiffelBase library, which the EiffelStudio installation procedure has precompiled; as a result, there are only a few extra classes to compile, and the process is almost instantaneous on a state-of-the-art computer. + + +{{note|As a frame of reference, on a Toshiba Satellite laptop, mobile dual core 1.73 GHz, 1 GB memory, running Windows Vista, this Eiffel compilation takes about 3.5 seconds. }} + +After Eiffel compilation completes you will see the message + + Eiffel Compilation Succeeded + +in the Outputs tool. + +At this stage your project has finished compiling. + +So, congratulations! You have successfully compiled your first Eiffel project. More precisely your project has been "melted". Strange terminology, you may think; in a [[How EiffelStudio Compiles|later section]] we'll see the derivation of the names used in the compilation process. + +==Executing the system== + +Our system doesn't do anything very exciting, but let's execute it anyway. Find and click the Run button ( [[Image:debug-run-icon]] ) on the toolbar at the top of the EiffelStudio window. + +This little application doesn't use graphics or any other fancy stuff. It simply creates some objects and displays some information. Output is accomplished by using the default Eiffel I/O features (from the EiffelBase classes ANY and STANDARD_FILES), and that output goes to a console. On Unix/Linux and OpenVMS it's the window from which you started EiffelStudio. On Windows, by default, it's a new console window that comes up when and if the system does its first output operation, and stays up you dismiss it: + +[[Image:es gt execute 01]] + + +The message "Press Return to finish the execution..." would not appear if you executed the system from outside of EiffelStudio, for example from a command line. Its purpose within EiffelStudio is clear: to let you see the console output; without it, the console would go away at the end of execution. (None of this applies to Unix/Linux/OpenVMS because no new console window was created when we executed the system.) + +Before closing the console window, if you look at the main EiffelStudio window (by moving the console window aside) you will notice that it looks different than it did before. This is because EiffelStudio is now in debug mode, so it shows the fields useful in monitoring, controlled execution, and debugging. But we'll look at all this later. For the moment just dismiss the console by following the advice to "Press Return to finish the execution...": hit the Return or Enter key. + diff --git a/documentation/18.11/eiffelstudio/Tutorials/computing-project-metrics.wiki b/documentation/18.11/eiffelstudio/Tutorials/computing-project-metrics.wiki new file mode 100644 index 00000000..5cb20342 --- /dev/null +++ b/documentation/18.11/eiffelstudio/Tutorials/computing-project-metrics.wiki @@ -0,0 +1,51 @@ +[[Property:title|Computing Project Metrics]] +[[Property:weight|0]] +[[Property:uuid|8d1a3556-d9a2-0ac8-4d54-458f18cb56ad]] +In earlier sections we saw how EiffelStudio provides extensive documentation on your systems. That information was qualitative. Project managers and developers will also be interested in quantitative information about their projects. You can get such information through the Metrics tool, which enables you to perform a number of operations, detailed over the next few pages: +* Apply predefined metrics -- number of classes, number of invariants, number of features, number of compilations so far and many others -- to components of a system at various levels including feature, class, cluster, entire system. +* Define new metrics, through mathematical formulae or boolean selection, and apply them to your project. +* Store measurement results, as well as metric definitions, into an XML archive that can be stored locally or made available on the Web for future reference. +* Compare the measurements on a system to those on record locally or on a Web site. Eiffel Software has released on its own site an archive recording the metric properties of its basic libraries, available to any other project for comparison. + +==Methodological observations== + +Although the field of software metrics is a rich one with an abundant literature, its methodological basis is sometimes subject to question. One should resist the tendency to believe numbers just because they are numbers ("lies, damn lies, and metrics"). + +Software engineers and their managers expect, however, to reap at least some of the benefits that precise quantification has brought to other engineering fields. Such is the purpose of software metrics, defined as '''quantitative estimates of product and project properties'''. Object-oriented development, with the rich software structures that it induces, is a particularly amenable to metric analysis. Even when some of the measures do not seem to bring much by themselves, comparing them to those of other projects may reveal significant peculiarities of a system or of some of its parts. + +The metrics capabilities of EiffelStudio were designed with these observations in mind. They result from a conservative approach, where no metric is provided without a credible assumption that it reflects some meaningful project or product attribute. For example, you will find a way to define a new metric as a linear combination of existing ones, but not a way to compute arbitrary arithmetic operations, since it isn't clear that -- say -- multiplying two metrics ever makes sense. + +==Metric terminology== + +The following terms are used in the presentation of EiffelStudio metric mechanisms. + +A '''metric''' -- not to be confused with a measure -- is a quantitative property of software products or processes whose possible values are numbers. A '''measure''' is the value of a metric for a certain product or process. + +For example, we can evaluate the metric "number of classes in the system", called just Classes, by counting the classes in our system. This yields a measure. + +We may distinguish between '''product''' ''' metrics''', which measure properties of the elements being turned out (code, designs, documentation, bug reports...) and '''process''' ''' metrics''', which measure properties of the process used to turn them out (salaries, expenses, time spent, delays...). The current metric facilities of EiffelStudio are primarily product-oriented but include a process metric: "number of compilations". + +Any metric should be relevant: related to some interesting property of the processes or products being measured, such as cost, estimated number of bugs, ease of maintenance...A '''metric theory''' is a set of metric definitions accompanied with a set of convincing arguments to show that the metrics are relevant. Neither EiffelStudio nor this manual provide a metric theory. + +The numbers yielded by measures are meaningless unless we describe what they refer to. Every metric is relative to a certain '''unit''', specified as part of its definition. For example the unit for a metric that counts classes, such as Classes, is called class. + +EiffelStudio provides a set of predefined units. Some simply serve to count occurrences of certain construct specimens in the software; examples include group, class, feature, line, ... The metric ratio describes metrics whose values are divisions, for example "average number of classes per cluster", obtained by dividing the number of classes by the number of classes. + +A metric can be computed over a scope. This scope is defined using a '''domain'''. A domain is a set of program elements. You build up a domain by adding development objects to a list. These development objects are things like application targets, clusters, libraries, classes, and features. + + +==Metric tool interface== + +The following links will take you out of the Guided Tour and into the EiffelStudio Reference: + +* EiffelStudio reference: [[Metric Evaluation Panel|Metric Evaluation panel]] +* EiffelStudio reference: [[Detailed Result Panel|Detailed Result panel]] +* EiffelStudio reference: [[Metric Definition Panel|Metric Definition panel]] +* EiffelStudio reference: [[Metric History Panel|Metric History panel]] +* EiffelStudio reference: [[Metric Archive Panel|Metric Archive panel]] + + +{{SeeAlso| The EiffelStudio Reference section on the [[Metrics Tool]] for more comprehensive discussion and precise definitions of terminology.}} + + + diff --git a/documentation/18.11/eiffelstudio/Tutorials/copying-example-files.wiki b/documentation/18.11/eiffelstudio/Tutorials/copying-example-files.wiki new file mode 100644 index 00000000..2e7bd8a8 --- /dev/null +++ b/documentation/18.11/eiffelstudio/Tutorials/copying-example-files.wiki @@ -0,0 +1,19 @@ +[[Property:title|Copying the Example Files]] +[[Property:weight|-14]] +[[Property:uuid|bb8ff7d7-2e93-d150-339c-d9afb967bc98]] +{{note|If you are using Eiffel on a personal computer, you have the option of working directly in the installation directory and would not necessarily need to make copies of files as per the present section. If you choose to work directly in the installation directory, skip this section and go on to the next section, [[Starting EiffelStudio and Opening a Project]]. If you work under Unix or OpenVMS, or may have to share the Eiffel installation with other users, do not have write permissions on the installation, or want to keep the installation unchanged, then please do read the present section and apply its instructions.}} + +If you are going to work on a copy, choose or create a directory of your own; let's call it YOURDIR for the rest of the discussion. + +To copy all the files of the example to YOURDIR: +* On Windows, open a Windows Explorer, go to $ISE_EIFFEL\examples\studio\tour , select all the files in that directory, and drag-and-drop them to YOURDIR . +* On Unix execute the shell command + +cp $ISE_EIFFEL/examples/studio/tour/* YOURDIR + +* On OpenVMS execute the command + +copy $ISE_EIFFEL:[examples.studio.tour]*.* YOURDIR + + + diff --git a/documentation/18.11/eiffelstudio/Tutorials/customizing-tools-layout-and-toolbars.wiki b/documentation/18.11/eiffelstudio/Tutorials/customizing-tools-layout-and-toolbars.wiki new file mode 100644 index 00000000..4c361a7d --- /dev/null +++ b/documentation/18.11/eiffelstudio/Tutorials/customizing-tools-layout-and-toolbars.wiki @@ -0,0 +1,267 @@ +[[Property:modification_date|Tue, 21 Aug 2018 18:55:21 GMT]] +[[Property:publication_date|Tue, 21 Aug 2018 18:55:21 GMT]] +[[Property:title|Customizing the tools layout and toolbars]] +[[Property:weight|-8]] +[[Property:uuid|eb75573e-c653-9290-376a-063cb5fa32d4]] +==Overview== + +We saw in [[Viewing Classes]] how EiffelStudio panes could be resized and how the Auto Hide feature works for a pane. + +Now let's look at some other ways in which you can customize the layout the EiffelStudio tools. + +The first time you use EiffelStudio, it will display a '''default''' tools layout that reflects the preferences of a majority of users. Typical user preferences change, so don't be too surprised if things look just a little different after installing a new version. + +As you gain more experience with EiffelStudio, you may want to adapt the layout to your personal preferences. For example, you may always want to have certain tools visible which were not visible by default. Once you make a change like this, EiffelStudio generally remembers that change and it will be in force the next time you open EiffelStudio. But you can also save a complete tools layout and recall it at a later time. For example, you might have two or three different development '''modes''' that you work in, and have a saved tools layout for each. + +The ways in which the EiffelStudio tools can be arranged are nearly endless. You can make tools visible or hide them. You can make almost any tool a tab in almost any pane. You can re-order the tabs for a pane. You can pull tools completely out of EiffelStudio as free-floating windows. You can create additional panes as needed. Almost any pane can be "pinned" open or "auto hidden". + + +==Reverting to the default layout== + +If you changed the layout and are not pleased with the result, you can revert to the default. Use the menu path: + +View --> Tools Layout --> Reset Tools Layout + +to reset EiffelStudio to the default tools layout. + +[[Image:es gt reset tools layout 01|Reset Tools Layout]] + +Figure 1 + + +So at the end of the section [[Viewing Classes]] we manually reversed the changes that we had made to the layout to make additional space. We could have just selected Reset Tools Layout to restore the default layout. + +You can try this now and see the effect. Your tools layout will probably not change very much. + +You can see in the image above that you would also follow that menu path in order to save a tools layout or to activate one that you had previously saved. + + +==Minimizing, maximizing, restoring, and closing tools== + +At the right end of the top bar for each tool you will see buttons that help you control the way the tool and its containing pane are displayed. Here are the icons and what they mean: + +* [[Image:minimize-icon]] Minimize this pane. +* [[Image:maximize-icon]] Maximize this pane. +* [[Image:restore-icon]] Restore this pane to its previous size. +* [[Image:auto-hide-icon]] Set this pane to Auto Hide. +* [[Image:close-icon]] Close this tool. + +There are a few subtleties you should understand when using these: + +The pane in which the Editing tool resides is special. It is the only pane that supports '''minimize'''. And it does not support Auto Hide, nor Close. We'll learn a little more about this in the section on [[#Docking|Docking]]. + +When you maximize a pane it fills all available space. At the same time, its maximize icon changes to the Restore icon. When you click Restore, the pane relinquishes the extra space it annexed when you maximized it, and then returns to its original size and location. + +The Close button will close only the current tool. So, that tool goes away, but any other tools in the same pane remain. However, when you close the last tool in a pane, the pane itself disappears and the space is absorbed by other panes. Remember that you can re-display closed tools through the menu path: + +View --> Tools --> tool name + + +{{note|EiffelStudio supports a number of [[EiffelStudio: Key shortcuts|'''key shortcuts''']] (sometimes called '''accelerators''', some of which can be useful for changing aspects of the Development Window. For example, CTRL+M will toggle the Editing pane between Maximize and Restore, and CTRL+N will create a fresh Development Window. Keyboard shortcuts themselves are tailorable in the [[Keyboard shortcuts preferences|EiffelStudio Preferences]].}} + + +==Re-ordering tabs== + +Within a particular pane, it is possible to have many tools visible. Each will be represented as a tab at the bottom of the pane. For example, the pane that contains the Class and Feature tools has the following tabs by default in the version that is current at the time of this writing: + + +[[Image:es gt default pane tabs|A default set of tool tabs]] + +Figure 2 + + +One easy way to customize your tool layout is to change the order of these tabs if you prefer. Just drag a tab horizontally to a new position to the right or left of where it originally was located and release it. As you drag the tab, you'll see it relocate itself, so you'll know just were it will end up when you release it. + +So suppose that you felt that it would be more convenient to your style of work to have the Outputs tool be the left most tool, versus the Class tool. Just drag it over there ... and now your tabs should reflect the new order: + + +[[Image:es gt reordered pane tabs|Tool tabs after moving Outputs tool to the left end]] + +Figure 3 + + +Try this now, if you'd like but be careful to move the tab '''only''' horizontally along the row of other tabs. If you move it off the row of tabs, you may inadvertently enter the extraordinary, but more complex realm of '''docking''', our next topic. Just in case you do get off the row of tabs and you see strange icons appearing on the Development Window, don't release the mouse button, just press the ESC key to cancel the dragging action. + + +==Docking== + +The docking ability within EiffelStudio is arguably the most powerful tool at your disposal for tailoring the tools layout to your liking. Docking can be a little daunting at first, but once you understand a few concepts, you will likely find it both easy to use and helpful. + +Maybe the first thing to know about docking is that EiffelStudio gives you the option of locking elements of the interface against inadvertent changes in docking. Following the menu path: + +View --> Docking Lock + +you can choose to lock (or leave docking enabled) on toolbars, tool panes, and/or editing panes. So, if you get things just the way you want them, in addition to save your tool layout, you may want to lock the elements against additional docking changes. + +Perhaps the second thing to understand, if you haven't already guessed, is that, for docking purposes, the EiffelStudio interface supports toolbars and two different types of panes. One type of pane is the one in which the Editing tools reside, which we'll call an '''editing pane'''. The other is the type of pane is the '''tools pane''' where other tools can be docked. + +So, with this in mind, we can take another look at the EiffelStudio layout. + + +[[Image:es gt a development window 02|Default tools layout]] + +Figure 4 + + +Here we see the editing pane with one editing tool targeted to the class LIST. + +There are two tools panes. Docked in one are the Class, Feature, Outputs, and Error List tools. In the other are the Groups, Features, and AutoTest tools ... and to the right of the AutoTest tab we see the icon ([[Image:continued-icon]]) and a number indicating that there are more tabs, but no room to display them. In this case there is only one more tab; it is for the Favorites tool. Of course, if the that tools pane were a little wider, we would see the tab for the Favorites tool and the "continued" icon and the number would disappear. + +It turns out that there are actually two more tools panes in this layout. One contains the Diagrams tool and the other contains the Dependency, Metrics, and Info tools. These two panes are Auto Hidden so we only see the minimum evidence that they exist ... just their tabs. You can tell that these are two different panes by how the tabs are distributed. Diagram is somewhat "off by itself" whereas Dependency, Metrics and Info are grouped closely together. + +As we learned in [[Viewing Classes]] you can make one of these tool panes visible by moving your cursor over it, or clicking on one its tabs. The pane will expose itself for the length of time that the cursor remains over it, then recede into hiding again when the cursor is moved away. + +Try this now with the Diagram tool. The pane housing the diagram tool appears from the bottom of the screen. Notice also that it has occluded the pane containing Class, Feature, Outputs, and Error List tools, and about half of the pane containing the Groups, Features, AutoTest, and Favorites tools. + + +[[Image:es gt development window diagram tool unhidden|Diagram tool unhidden]] + +Figure 5 + + +So, Auto Hide works well to keep panes that we might not use very often out of the way ... but still pretty handy. + +===Floating a pane=== + +Let's dive into our first docking (or maybe undocking) experience. Suppose, though, that you were in the analysis and design phase of a project and you wanted the Diagram tool to be open and available at all times. Of course, you could move your cursor over it to "un-hide" it, then pin it open. But then it would be covering the other tool panes which we use often. + +One great capability of the docking mechanisms in EiffelStudio is that you can disconnect, or '''float''', a pane away from the rest of the EiffelStudio development window. Let's float the hidden pane that now contains just the Diagram tool out to the right of the entire Development Window. + +In order to float this tool pane, we first have to set Auto Hide off. + + +{{note|In versions of EiffelStudio starting with version 6.6, it will no longer be necessary to set Auto Hide off before moving a pane. }} + + +So move your cursor over the Diagram tab and the pane should expand (if it does not make it self visible, then click on the tab). Then move to the upper right and click the horizontal pushpin icon ([[Image:auto-hide-off-icon]]) to turn off Auto Hide and pin the pane open. + + +[[Image:es gt diagram tool pane pinned 01|With Auto Hide off, occluded panes become visible.]] + +Figure 6 + + +You may notice that a pane that is auto hidden may, when it expands, occlude other panes. However, when you turn of Auto Hide by pinning the pane open, any panes that it had occluded will become at least minimally visible. In the case of this example, the pane containing the Class tool was temporarily covered by the expanded Diagram pane, as was the row of tabs on the pane containing Groups. When you pin the Diagram pane open, the title bar for the pane with the Class tool becomes visible, and the pane with the Groups tool gets shortened to fit above the Diagram tool's pane. + +It is at this point that new EiffelStudio sometimes have problems understanding what's happening. So read the following description of what's going on before you actually try to move the pane ... and don't forget that you can always reset the tools layout if things don't go the way you intended. + +Now that we've turned off Auto Hide for Diagram's pane, we can move the pane and either re-dock it somewhere else in the development window or, as is our intention, "float" it as a window separate from the Development Window. + +To undock and re-dock or float a pane, you drag the pane by its title bar (but don't do this quite yet). As soon as you begin to drag the pane, you will see the look of the Development window change: + + +[[Image:es gt docking in progress 01|Dragging a pane to dock]] + +Figure 7 + + +In the figure you can see the cursor arrow on the title bar of the pane. The pane has been dragged very slightly and EiffelStudio has sensed that we want to move the pane from its current position. In response, EiffelStudio has overlaid the Development Window with a set of icons that represent valid docking targets for the pane being moved. We'll look closer at those in a moment. + +But for now, notice the large dark, semi-transparent '''docking feedback''' area at the bottom left of the image above. This represents what will happen to your pane if you release the mouse button at the current time. So in the case of the figure above, releasing the mouse button immediately will '''float''' the pane on top of the Development Window. This is nearly our intent, although we want to move the floating pane out to the right of the Development Window. So, without releasing we drag the pane off the top and to the right of the Development Window, then release it. + + +[[Image:es gt diagram tool pane floating 01|800px|Diagram tool floating]] + +Figure 8 + + +So go ahead and try it now. If you've pinned the pane with the Diagram tool open, then drag the pane by its title bar out to the right and off the Development Window and release it. + +===Docking a pane=== + +The problem that some users have when first trying to adjust the tool layout using docking (without the benefit of this Guided Tour) is that once they move a pane, it's not obvious to them what to do next to get the effect that they want. As a consequence, they attempt to put things back the way that they were when they first dragged the pane ... and usually they aren't successful. Remember that you can always press the ESC key to cancel the drag while still holding the mouse button down. + +Now let's take a look at the target graphics and what they mean, and we'll do an exercise in which we put the pane with the Diagram tool back where it was originally. + +In Figure 7 above, you can see the docking target graphics. You see this figure: + + +[[Image:docking-target|Docking target]] + +Figure 9 + + +in two places, and four smaller figures: + +[[Image:docking-target-top|Top]] [[Image:docking-target-left|Left]] [[Image:docking-target-right|Right]] [[Image:docking-target-bottom|Bottom]] + +Figure 10 + + +one near each border of the Development Window. + +The graphic in Figure 9, shaped like a "plus" sign or cross, will appear in any pane which is a valid docking target for the pane you are moving. So, in Figure 7, those panes are the pane housing the Groups tool and the one housing the Class tool. + +The center of the graphic represents the target pane itself. So, if you drag your pane over the center of the graphic and release it, your pane will now become a new tab in the target pane. You can see the docking feedback area hinting to this effect. In the figure below, the pane with the Diagram tool was dragged over the center of the target graphic on the tool with the Class pane. Notice that the whole pane is covered with the docking feedback area, which even shows the hint of a new tab. + + +[[Image:es gt add tab to pane|Hovering over center target will add a pane as a new tab]] + +Figure 11 + + +If we were to release the pane at this point, it would dock as a new tab along side Class, Feature, Outputs, and Error List. In this case, the pane we are moving contains only one tool, Diagram, but if it contained multiple tools, each of those tools would become a new tab in the target pane. + +But remember that our goal in this exercise is to restore the pane holding the Diagram tool back to its original position. So, making it a tab in the pane with Class, won't achieve that goal. Let's look at some other possibilities. + +What happens if we drag our pane over one of the tips of the cross shaped target graphic? These targets will allow us to split the target pane into two panes, one containing the original content and the other containing the content of the pane we are moving. The original pane will be split according to which tip of the cross you drop your pane onto. For example dropping on the right tip will split the target pane into left and right panes an put your pane on the right. Again you can see this depicted in a preview when you hover over one of these, as shown below. + + +[[Image:es gt split pane right|Hovering over the tip of a cross causes the target pane to be split and the new pane added adjacent]] + +Figure 12 + + +It's pretty obvious that this will not get Diagram back to its original location. The only options left unexplained are the four graphics shown in Figure 10. These each look like a detached version of one of the tips of the cross shaped graphic, but they are located along the four edges of the Development Window. If you drop your pane on one of these it will add it as a new pane along the corresponding margin of the Development Window. + +We know that originally our pane with Diagram was in Auto Hide mode at the bottom of the Development Window. + +So, drag the pane from its floating position and drop it at the bottom of the Development window on this graphic: + +[[Image:docking-target-bottom|Bottom]] + + +The effect is that now your pane has been docked back into the Development Window at the bottom. The only thing left to do now is turn Auto Hide back on by clicking the push-pin icon. Now the pane that houses the Diagram tool is back in its original place in the layout. + + +===Docking and the Editing pane=== + +As we learned earlier in [[#Minimizing, maximizing, restoring, and closing tools|Minimizing, maximizing, restoring, and closing tools]], the pane in which the Editing tools reside has special properties and restrictions not present for panes housing other tools. It's the same for docking. Just as you can't close the Editing pane, you can't re-dock it in any other location. You can't dock other tools, the Feature tool for example, in the Editing pane (notice that you don't get a targeting cross in the Editing pane when you drag a pane). + +Although the Editing pane can house only Editing tools, you ''can'' re-order the tabs for Editing tools and you ''can'' re-dock Editing tools by splitting the Editing pane. For example you might want to look at two classes side by side in two different panes. In the image below, after opening tabs for classes LIST and CHAIN, we dragged the tab for CHAIN and dropped over the right tip of the cross shaped graphic that appeared in the Editing pane. Then we put the pane Groups and the one with Class in Auto Hide to enlarge the size of the Editing tools. This allows us to view LIST and CHAIN side by side. + + +[[Image:es gt side by side editing|Viewing two classes side by side in the Editing pane]] + +Figure 13 + + +===Docking and toolbars=== + +You can drag toolbars and re-dock them in different places. You can float toolbars in the same way you would do a tool pane. In the figure below, the Project toolbar has been dragged away from its default home to the right of the Standard Buttons toolbar. Now it's over undockable space, so if released here it will float, just as we saw with tool panes. + + +[[Image:es gt redocking project toolbar|Dragging the Project toolbar around]] + +Figure 14 + + +When you move a toolbar, drag it by its "head". The head is indicated by an icon ([[Image:toolbar-head-icon]]) that looks like a vertical row of dots at the left end of each toolbar. + +The figure above shows that there are two "rows" available for placing toolbars. This is the way it is in the default layout. But the number of rows can be expanded if needed. So, if you drag a toolbar toward the bottom of the toolbar area, you will see that a new row will become available in which you can dock the toolbar that you are moving. + + +[[Image:es gt redocking project toolbar new row|Dragging a toolbar to a new toolbar row]] + +Figure 15 + + +In the figure above, the Project toolbar has been dragged near the bottom of the toolbar area, and a new toolbar row has opened up to allow the Project toolbar to be docked there. + + +==Customizing toolbars== + +In addition to using the docking facilities to move toolbars around to suit your work style, you can also customize each toolbar by adding, removing, or re-ordering the buttons on that toolbar. See more about this on the page [[Toolbar customization]]. + + + diff --git a/documentation/18.11/eiffelstudio/Tutorials/debugging-and-run-time-monitoring.wiki b/documentation/18.11/eiffelstudio/Tutorials/debugging-and-run-time-monitoring.wiki new file mode 100644 index 00000000..12877521 --- /dev/null +++ b/documentation/18.11/eiffelstudio/Tutorials/debugging-and-run-time-monitoring.wiki @@ -0,0 +1,127 @@ +[[Property:title|Debugging and Run-time Monitoring]] +[[Property:weight|-2]] +[[Property:uuid|a53f6a74-7145-35ab-ed5e-2905aeb88774]] + +The next set of EiffelStudio capabilities enables you to control and monitor the execution of your systems. The obvious immediate application is to debugging; but the more general goal is to let you follow the execution of your systems, explore the object structures, and gain a better understanding of the software. + + +==A reminder about debugging in Eiffel== + +Before looking at debugging facilities don't forget that debugging in Eiffel is different. The presence of Design by Contract mechanisms gives the debugging process a clear sense of direction. The speed of the recompilation process makes it easy to recompile after a change; after getting rid of syntax and validity errors, you run the system again, and remaining errors are often caught as violations of contract clauses -- routine preconditions, routine postconditions, class invariants. + +The facilities to be described now are also useful when you find such an error, as they will help you study its execution context. In fact, one of the characteristics of the debugging mechanism is that there is no "debugger" proper, no more than there is a "browser"; you have instead a set of facilities supporting controlled execution and debugging. This means for example that: +* While debugging, you can access all the browsing capabilities to explore the features and classes surrounding the cause of an error. +* While browsing, you can launch or resume execution, and follow its progress through the debugging facilities. +* If execution stops on an exception -- for example, an assertion violation or arithmetic overflow -- you have all the environment's facilities at your disposal to understand what happened. + + +==Setting breakpoints== + +To control the execution you will set breakpoints, indicating places where you want to interrupt the execution. You may set a breakpoint on an individual instruction of a routine, on the routine's precondition or postcondition, or on the routine as a whole, meaning its first operation (precondition or instruction). + +A group of icons on the Project Toolbar help control breakpoints. They are known in EiffelStudio terminology as "''buttonholes''", meaning that they can serve both as buttons (you can click them to get some functions) and holes (you can pick-and-drop into them to get some other functions). + +[[Image:es gt debug buttons|Run and debug buttons]] + +The labels correspond to the icons' use as buttons: enable all set breakpoints ([[Image:16x16--breakpoints-enable-icon]]), disable them all ([[Image:16x16--breakpoints-disable-icon]]), remove them all ([[Image:breakpoints-delete-icon]]), and display information on current breakpoints using the Breakpoints tool ([[Image:debug-show-breakpoints-tool]]). The difference between "disabling" and "removing" is that disabling turns off breakpoints until further notice but remembers them, so that you can later re-enable them, whereas "removing" clears them for good. + +Here you also see icons for controlling execution: '''run''' ([[Image:debug-run-icon]]), '''step-by-step''' ([[Image:debug-step-over-icon]]), '''step into routine''' ([[Image:debug-step-into-icon]]), '''step out of routine''' ([[Image:debug-step-out-icon]]). + +Target a Development Window to the class TESTROOT and pick-and-drop the name of the procedure make (the first routine, after the declaration of the two attributes o1 and o2) to the '''Enable all''' icon, used here as a hole. This sets and enables a breakpoint on the routine. Click the button labeled '''Show information about breakpoints''' ([[Image:debug-show-breakpoints-tool]]). This will invoke the '''Breakpoints tool''', as shown in the next figure. + +[[Image:es gt breakpoints tool 01|The Breakpoints tool]] + +This shows that so far you have enabled only one breakpoint. For a finer degree of control, let's look at the feature's flat form. Close the Breakpoints tool, then pick-and-drop make from the Editing Tool to the Feature tool (anywhere in the lower left pane should do; this sets the pane's context to the Feature Tool. Select the '''Flat''' view if that wasn't the last one used: + +[[Image:es gt development window breakpoints 01|Breakpoint set in "make"]] + +The small circles on the left side of the Flat form indicate breakpoint positions. Empty ones are not set; enabled breakpoints are marked by a circle filled with red. At the moment only one is enabled, corresponding to the first instruction of the routine since, as noted, setting a breakpoint on a routine as a whole means setting it on its first operation. + +By (left) clicking on a breakpoint mark, you toggle it between enabled and not set. You can also right-click on a mark to get a [[Breakpoint menu|menu]] of possibilities: + +[[Image:es gt breakpoint context menu 01|Breakpoint context menu]] + +Try enabling and unsetting a few of these marks; you might get something like this: + +[[Image:es gt development window breakpoints 02|Multiple breakpoints: not set; enabled; set but disabled]] + +The breakpoint mark for the routine's third instruction, create o2, is filled but not red ([[Image:bp-disabled-icon]]); this means it is set but not enabled. You can obtain this by right-clicking on the mark and choosing '''Disable breakpoint''' on the menu that comes up. Any potential breakpoint will be in one of three states: '''not set''' ([[Image:bp-slot-icon]]); '''set and enabled''' ([[Image:bp-enabled-icon]]); '''set but not enabled''' ([[Image:bp-disabled-icon]]). + +Remember, you can see the complete list of enabled and disabled breakpoints by making the Breakpoints tool visible ... which you do by clicking the '''Show information about breakpoints''' ([[Image:debug-show-breakpoints-tool]]) button in the Project Toolbar. + +For the remainder of this chapter it doesn't matter which exact breakpoints of make you've set, as long as the one on its first instruction is set and enabled (red-filled circle) as above. Please make sure this is the case before proceeding. + + +==Executing with breakpoints== + +To execute, you will use the following Run buttons in the Project toolbar, or the corresponding entries in the '''Execution menu''': + +[[Image:es gt debug buttons|Run and debug buttons]] + +Most of the buttons shown here are enabled, but at different times some of them will be disabled (grayed out.) + +The '''Execution menu''' entries will also remind you of shortcuts: F10 for '''Step-by-step''', F11 for '''Step into routine''', Shift-F11 for '''Step out of routine''', CTRL-F5 for '''Run ignoring breakpoints''', F5 for '''Run with breakpoints''', CTRL-Shift-F5 for '''Interrupt execution''', Shift-F5 for '''Stop execution'''. + +[[Image:es gt execution menu 01|Execution menu]] + +Start execution of the compiled system by clicking the '''Run''' button ([[Image:debug-run-icon]]). Run actually means "Run and stop at enabled breakpoints." EiffelStudio automatically switches to '''Execution mode''' to accommodate supplementary tools providing debugging information. Execution stops on the breakpoint that you have enabled on the first instruction of procedure make: + +[[Image:es gt debug breakpoint reached 01|Stopped at first breakpoint in "make"]] + +By default, in Execution mode, EiffelStudio looks a little different. Specifically, the Feature tool now occupies the space that was previously held by the Editing tool. The '''Call Stack''' is in the tall pane on the right, and the '''Object tool''' and '''Watch tool''' are on the bottom, under the Feature tool. + +The Call Stack indicates that execution has stopped in make. The Feature tool shows the flat form of that routine, with an icon ([[Image:debug-stopped-on-breakpoint-icon|Stopped on enabled breakpoint]]) to indicate the stop point which execution has reached. The Object tool, which shows the content of current object and (later) related objects. At the moment you can see that: +* The current object is an instance of class TESTROOT. +* The class (as you could also see from its text in a Development Window) has two attributes o1 and o2, both declared as type PARENT, for which the corresponding fields in the current object are both void; this is as expected since you haven't yet executed the two creation instructions create {HEIR} o1 and create o2, as they come after the breakpoint. +* Along with attributes, an Eiffel class may have '''once functions''', executed at most once -- the first time they are called -- in a given session, and from then on always returning the same value. You can see the status of these by expanding the entry "Once routines" in the Object tool. Here the once function io has not yet been called, but after it has it will return an object of type STD_FILES. + +The execution-time objects that you may display in the Object tool are our latest kind of EiffelStudio "development object", along with classes, features, explanations, clusters; notice the distinctive icon ([[Image:debugger-object-eiffel-icon]]), a rectangular mesh shape suggestive of an object's division into fields. It appears colored for actual objects and gray ([[Image:debugger-object-void-icon]]) for Void references such as operating_environment. + + +==Monitoring progress== + +Click twice on '''Step-by-step''' ([[Image:debug-step-over-icon]]), or press the function key F10 twice. Monitor, in the flat form of make, the marker that shows execution progress; note that the marker always points to the ''next'' operation to be executed. After the two steps, the Feature and Object tools look like this: + +[[Image:es gt debug step by step 01]] + +The last instruction that you executed is create {HEIR} o1, meaning create an object and attach it to o1, but instead of using the declared type PARENT of o1 use its proper descendant HEIR. As a result, the entry for o1 in the Object tool no longer shows Void but an object of type HEIR. Note that all objects are identified by their addresses in hexadecimal; such an address is by itself meaningless, but enables you to see quickly whether two object references are attached to the same object. The addresses you see as you run the Guided Tour will -- except for some unlikely coincidence -- be different from the ones appearing here. + +Note that since the garbage collector compacts memory and hence may move objects around, the address of a given object is not guaranteed to remain the same throughout a session. + +To see the details of the object, expand its entry in the Object tool. + + +==From the instance to the class== + +Now notice what happens if you pick the type name (HEIR) from the entry for object o1 in the Object tool, and then drop it in the Feature tool above. The context changes from the Feature tool to the Class tool and is retargeted on HEIR. The Class tool has switched to the default format for classes, '''Ancestors''', and is showing the ancestors of HEIR. Click the Feature tab to get back to feature information for the continuation of our debugging session. + + +==Stepping into and out of a routine== + +Click '''Step-by-step''' once more to advance just before the call o1.display. + +Choosing '''Step-by-step''' again would execute the next step in the current routine, the call o1.display, treating the entire execution of display from class HEIR as a single operation. Assume instead that you want to go ''into'' that routine and follow the details of its execution. For one thing, you might not know that it's a routine of class HEIR, since o1 is declared of type PARENT and it's only through polymorphism, that is, o1 being dynamically of type HEIR at this point, and through dynamic binding, that the execution ends up calling a routine from HEIR. Of course here it's obvious because of the wording of the create a few lines up, but in many cases, especially all those for which polymorphism and dynamic binding are ''really'' interesting, the exact type won't be immediately clear from the neighboring software text. + +Click the '''Step into routine''' button (or press F11). This brings execution to the beginning of the appropriate display routine in class HEIR. + +[[Image:es gt debug step into 01]] + +While you're here notice the Call Stack tool. It shows that we are currently executing feature display of class HEIR, which, as can be seen on the second line of the stack, was called from feature make of class TESTROOT. + +Now click '''Step out of routine''' ([[Image:debug-step-out-icon]]), or press Shift-F11 to finish the execution of display. This brings you back to the next instruction of the calling routine, make of TESTROOT. + + +==Terminating== + +You may now click the '''Stop execution''' button ([[Image:debug-stop-icon]]), or press Shift-F5, to end execution. The execution-specific tools go away and the display returns to what it was before execution. + + +==Other debugging capabilities== + +In this little application nothing runs long enough to give you the time to interrupt it. In a longer-running application you may want to interrupt execution, without necessarily terminating it, while it's running (not stopped on a breakpoint). This is the purpose of the '''Interrupt execution''' button ([[Image:debug-pause-icon]]), which can also be triggered by pressing CTRL-Shift-F5. It will interrupt execution at the closest potential breakpoint position, letting you -- as when execution stops because of an exception -- take advantage of all the debugging and browsing facilities to see what's going on inside your running system. You may then restart execution -- with or without breakpoints, single-stepping, out of the current routine, into the next routine -- by choosing the appropriate Run button + +In debugging sessions for more advanced applications, you will also find self-explanatory mechanisms enabling you, in addition to what we have seen, to examine all the objects on the "call stack": arguments and local entities of the current routine, its caller, caller's caller and so on. + +The combination of these facilities provides you with a level of ''dynamic'' information on the execution of your system that matches the ''static'' information that the browsing mechanisms studied in preceding sections provide about the system's structure. + + diff --git a/documentation/18.11/eiffelstudio/Tutorials/executing-system-within-and-without-eiffelstudio.wiki b/documentation/18.11/eiffelstudio/Tutorials/executing-system-within-and-without-eiffelstudio.wiki new file mode 100644 index 00000000..0ecb71f8 --- /dev/null +++ b/documentation/18.11/eiffelstudio/Tutorials/executing-system-within-and-without-eiffelstudio.wiki @@ -0,0 +1,37 @@ +[[Property:title|Executing a System Within and Without EiffelStudio]] +[[Property:weight|5]] +[[Property:uuid|8256398e-d1a9-0471-664a-3225c7dfb306]] +To complete this study of the compilation process let's see a few more properties of how you can execute an Eiffel system, both in EiffelStudio and as a compiled system that you deliver to its users, who may need to run it without EiffelStudio. + +==Arguments== + +Our example system is very simple and has no need for execution arguments. In more advanced cases you may want to pass values to the execution, such as a numeric parameter or a file name, so that you can have different executions without changing and recompiling the software. + +In the Eiffel text, you can access such run-time arguments through the Kernel Library class ARGUMENTS. There is another technique -- using the arguments to the root creation procedure -- but using ARGUMENTS is the most general way. Any class of your system can inherit from ARGUMENTS and use queries argument_count to know the number of arguments passed to the execution, and argument (i), for i between 1 and argument_count to access the i-th element. Class ARGUMENTS has more features; since you have Eiffelstudio up, you can check the details if you wish (use the contract form). + +There are 2 ways to specify execution arguments from within EiffelStudio. The first is through the menu path Execution --> Execution Parameters . +The second is through the argument dialog which can be opened by right-clicking on any of the debugging or program execution buttons on the main toolbar. The latter is more convenient for quick and easy access to execution arguments. + +==Executing from EiffelStudio== + +We have seen how to execute a compiled system from within EiffelStudio: choose one of the appropriate execution buttons, with or without breakpoints. + +==Executing a finalized system outside of EiffelStudio== + +A finalized system can be executed on any computer of the appropriate platform; it doesn't need EiffelStudio. The executable version is in the directory `project_directory/EIFGENs/target_name/F_code` where `project_directory` is the project's directory and `target_name` is the name of the target. The name of the executable file is `system_name` (or `system_name.exe` on Windows) where `system_name` is the name that you have assigned to your system in the project settings (reflected in the ECF file). + +The target of the Guided Tour system is `classic` and the name is `simple`, so you can locate `simple.exe` (or `simple.exe` on Windows) in `EIFGENs/classic/F_code` for your project, and run it stand-alone if you like. + +If you run the system from a command line, and it requires arguments (`simple` doesn't), you will provide the appropriate arguments after the command name: `system_name ... arg ...` . + +Because various platforms have different conventions, "relative paths" referenced in your system will mean something different under Unix/Linux, where they relate to the directory from which the command is launched, and under Windows, where they relate to the application's directory. + +==Executing a frozen or melted system outside of EiffelStudio== + +A system compiled in "Workbench mode" -- frozen or melted -- is normally meant for execution within EiffelStudio, not for outside delivery, since it is not optimized. If you need to execute it outside of EiffelStudio, make sure that you have access to the system_name.melted file in project_directory /EIFGENs/target_name/W_code. + +==Moving on== + +With this discussion of compilation and execution we have finished our review of the key capabilities of EiffelStudio. Not everything has been covered, but you are now familiar with the essentials and ready to discover the rest by yourself, both by trying out various capabilities -- most of which should be self-explanatory -- and examining the extensive online documentation that accompanies the product. + + diff --git a/documentation/18.11/eiffelstudio/Tutorials/graphics-based-design.wiki b/documentation/18.11/eiffelstudio/Tutorials/graphics-based-design.wiki new file mode 100644 index 00000000..ac2d1afd --- /dev/null +++ b/documentation/18.11/eiffelstudio/Tutorials/graphics-based-design.wiki @@ -0,0 +1,298 @@ +[[Property:title|Graphics-based Design]] +[[Property:weight|1]] +[[Property:uuid|78239225-67a7-8718-857d-f2c8fb70ef18]] +So far the project modifications that we have made used the text editor in the Editing Tool. Now let's look at EiffelStudio's ability to provide a graphical depiction of our software system. + +In line with the principles of seamlessness and reversibility recalled at the beginning of this Tour, EiffelStudio's interaction between text and diagram access to software is bi-directional. When you make a textual modification, the next incremental recompilation will update the diagram; but you can also work directly from the diagram, and the text will be generated or updated after each graphical operation. + +Many people like to use the graphical mechanisms at the beginning of a project, to draft the overall structure of a system in "bubbles-and-arrows" style, then concentrate on text as they get closer to implementation. But there is really no such obligation. At any point in the development, just use the form that is more suited to your taste and to your needs of the moment. + + +==Displaying a cluster view== + +We are going to play with the root cluster. So, we can work from EiffelStudio's default tools layout. Remember that you can reset the tools layout to the default by following the menu path: + +View --> Tools Layout --> Reset Tools Layout + +Now target an Editing tool to the class TESTROOT. So to start out, your Development window should look about like this: + + +[[Image:es gt graphics based design starting point|A starting point]] + + +Before getting started, another thing we want to do is to make sure that the the [[Making the context tool independent from the editor|tools are in "Unlinked" mode]]; you can see this by going to the View menu you will see either a menu item '''Unlink Context Tool''' (if tools are currently "Linked") or an item '''Link Context Tool''' (if tools are currently "Unlinked"). So if you see '''Link Context Tool''', you don't have to do anything. But if you see '''Unlink Context Tool''', then select that item to unlink the tools. + +Let's start working with '''cluster views''', showing the content of a cluster. Make the Diagram tool visible: move your cursor over (or click on) [[Image:diagram-tool-tab|Diagram tool]] at the bottom of the Development Window. You may want to float the tool away from the Development Window or "pin" it open (as we learned in the section on [[Customizing the tools layout and toolbars#Docking|docking]], and then maybe enlarge the tool some. You should see a graphical rendition of the root_cluster in the Diagram tool, something like the figure below. In the case that root_cluster is not visible, click the '''Target to class or cluster''' button ([[Image:diagram-target-cluster-or-class-icon]]) on the Diagram tool's toolbar. + + +[[Image:es gt testroot cluster diagram|root_cluster diagram]] + + + + +==Hiding a class== + +First we might decide that we don't want to be bothered with class INVALID. We could delete it altogether from the system by a pick-and-drop of its bubble to the Delete ([[Image:16x16--general-delete-icon|Delete]]) hole. This is not what we want, but try this now to see the confirmation request: + + +[[Image:es gt diagram delete confirmation]] + + +Make sure to answer '''No''' to that confirmation request (you want to keep the class even though it wouldn't be a catastrophe to lose it). Instead pick-and-drop the INVALID bubble into the Hide figure ([[Image:general-reset-icon|Hide figure]]) hole. This time there is no confirmation request, since the operation is reversible -- it just affects what's displayed in the cluster view -- and the class is removed from the display: + + +[[Image:es gt class invalid is hidden|Class INVALID is hidden]] + + +You can try '''undoing''' this change ([[Image:general-undo-icon]]), then '''redoing''' it ([[Image:general-redo-icon]]). + +You can also click the '''History''' icon ([[Image:general-undo-history-icon]]) which, during the rest of the session, will display the list of executed operations, and let you undo or redo many operations at once by clicking the oldest to be kept or the youngest to be redone. + +For the rest of this discussion we assume INVALID is hidden. + + +==Adding a class== + +We are now going to add a class graphically to our system. This means you don't have to worry about creating and initializing a file; EiffelStudio will take care of the details. + +The useful button here is '''Create new class''': + +[[Image:es gt create new class button|Create a new class]] + +When you click this button you'll see the '''Add New Class''' dialog box: + + +[[Image:es gt new class dialog]] + + +Overwrite the default class name being proposed by the name HEIR2, as we are going to create a new heir of PARENT. Now click the button labeled '''Create'''. + +The new class is created and added to the diagram as part of root_cluster: + + +[[Image:es gt class heir2 created|Class HEIR2 created]] + + +Using conventional drag-and-drop (not pick-and-drop), move the class bubbles for HEIR2, TESTROOT and PARENT so that the display looks approximately like the following. The double circle around TESTROOT is the [[Notation|BON]] (Business Object Notation) convention to identify a system's root class. + + +[[Image:es gt class heir2 relocated|Classes rearranged]] + + +==Adding an inheritance link== + +Now we are going to make HEIR2 an heir of PARENT. To create relationship links between classes you pick-and-drop from the source class, but don't do that yet. First we have to specify that we want an inheritance relationship. + +By default, the new relationship '''Creation Mode''' will be client/supplier ([[Image:diagram-new-supplier-link-icon]]). To change the creation mode to inheritance, click on the selection triangle next to the new client/supplier link icon, and choose '''Conforming inheritance Creation Mode ...''' from the drop-down menu, as shown below. + + +[[Image:es gt select conforming inheritance link creation mode|Selecting Conforming Inheritance Creation Mode]] + + +Notice that the current Creation Mode icon has changed to indicate conforming inheritance ([[Image:diagram-new-conforming-inheritance-link-icon]]). + +Now pick-and-drop from the HEIR2 bubble to the PARENT bubble. (Now you see why conventional drag-and-drop is used to move bubbles: pick-and-drop on the diagram serves to add links between classes). + +[[Image:es gt class heir2 inheriting parent|HEIR2 now inherits from PARENT]] + +To convince yourself that the new class has been made an heir of PARENT, not just in the diagram, but in its text as well, you can look at the class in an Editing tool. Unless you are so fortunate as to have plenty of monitor space, you may have to un-pin the Diagram tool to be able to see the Editing pane. Pick-and-drop HEIR2 bubble to the Editing tool to see its text. + + +[[Image:es gt class heir2 text|Class HEIR2 in an Editing tool]] + + +The code for a minimal class HEIR2 has been generated from your graphical operations: creating the class produced a class template, and the creation of the new inheritance link made HEIR2 inherit from PARENT. + +In a moment we'll use this Editing Tool to see how, conversely, EiffelStudio will automatically reflect in the diagram a change made to the text. + +For now, make sure the Diagram tool is visible again. + + +==Adding a client link== + +Next let's make TESTROOT a client of HEIR2. + +First, re-select ''Client-Supplier''' as the Creation Mode for new links. + +Pick-and-drop from the TESTROOT bubble to the HEIR2 bubble. This causes the '''New Feature''' dialog box to appear: + + +[[Image:es gt new feature dialog|The New Feature dialog box]] + + +This technique gives you many option and in fact is a convenient way to build your classes, whether at the analysis, design or implementation level. Here, fill the fields as follows. For the top choice, keep the default, Attribute; we'll give class TESTROOT an attribute of type HEIR2. For its feature category, keep the choice currently displayed, Access. For its name, replace the default, by the name o3. In the '''invariant''' box, choose + + o3_not_void: o3 /= Void + + +from the list to specify the invariant property that this attribute should never be void. Finally, to see how EiffelStudio can generate the full accompaniment to an attribute, in the box '''Setter?''' choose + + set_o3 + + +This will create a routine with this name which clients can use to set the value of o3. + +You may have noticed that the checkbox labeled '''Assigner?''' became enabled when you chose a name for the '''Setter'''. This will make the setter routine be called if a client uses an assignment of the form: + + my_testroot.o3 := some_value + + +The assigner makes this is a syntactical shortcut for writing: + + my_testroot.set_o3 (some_value) + + +Without the assigner, the direct assignment by a client would result in a syntax error, because in Eiffel clients are prohibited from assigning directly to their suppliers' attributes. + +So, check the '''Assigner?''' box. + +Now, click '''OK'''. + +The diagram now shows that TESTROOT is a client of HEIR2. + + +[[Image:es gt testroot is client of heir2|TESTROOT is now a client of HEIR2]] + + +Now, if you'd like, you can check the text of TESTROOT as we did earlier with HEIR2, but here are the highlights: + +You'll notice that the attribute o3 has been added under the feature category "Access": + + +feature -- Access + + o3: HEIR2 assign set_o3 + -- `o3' + attribute Result := ({like o3}).default end --| Remove line when attached attribute is correctly assigned + + +After the attribute declaration the keyword assign declares that the feature set_o3 is to be called when assignments are made to o3 by clients. + +You see that the header comment is trivial ( -- `o3' ), simply echoing the feature name. This is because we failed in our duty to fill in a reasonable header comment in the New Feature dialog. Every feature should have a meaningful header comment. + +Now notice the last line, beginning with the keyword attribute. This line is intended to be temporary. It makes your new attribute o3 a [[Void-safety: Background, definition, and tools#Self-initializing attributes|self-initializing attribute]], which just allows you to avoid certain errors until you insert code to initialize o3 properly. + +The "setter" routine for o3 is generated and categorized as "Element change": + + +feature -- Element change + + set_o3 (an_o3: like o3) + -- Assign `o3' with `an_o3'. + require + an_o3_not_void: an_o3 /= Void + do + o3 := an_o3 + ensure + o3_assigned: o3 = an_o3 + end + + +Notice that EiffelStudio has included both a precondition and postcondition for set_o3. + +Also, a clause has been added to the class invariant to ensure that set_o3 is not void: + + + o3_not_void: o3 /= Void + + +The situation here is different from what we saw earlier with HEIR2, which had been generated from scratch by the diagram. Here TESTROOT existed before, in text form; so the diagram mechanisms have had to preserve the existing feature and feature clauses, and add the elements corresponding to what you have specified through the diagram mechanisms. The unlabeled Feature clause of the existing class has been kept; the new features have been entered into clauses labeled Access and Element change, observing the Eiffel standard for common feature clauses in libraries. + + +==Updating the diagram from the text== + +In this tour of the diagram facilities we have, so far, worked on the diagram and seen the text updated immediately. Of course we want full reversibility. So let's make a change in the text and check the diagram. + +The change will be very simple. We'll make TESTROOT a client of HEIR. In the Editing tool, add an attribute declaration + + other: HEIR + + +Now save the file by clicking the [[Image:16x16--general-save-icon|save]] icon. + +Nothing happens yet to the diagram. This is normal: EiffelStudio doesn't update the diagram every time you type some text (which, for one thing, might be syntactically incorrect, or invalid). You need to recompile first. Click the [[Image:compile-button]] button. Then the new relation appears: + + +[[Image:es gt testroot is client of heir|Now TESTROOT is a client of HEIR]] + + +If the label other of that relation doesn't appear in the exact place shown here, try moving it using conventional drag-and-drop. You can only move such a link label within a small area on either side of the link. + + +==Creating a cluster== + +Earlier on, we saw how to create a class from the EiffelStudio diagram, letting EiffelStudio take care of creating and initializing the file. Similarly, you can create a new cluster graphically, and let EiffelStudio create the corresponding directory. + +To create a cluster, you can go through [[EiffelStudio: Project settings window|Project settings]], or you can do so directly from the Groups tool. Let's use the Groups tool. On the title bar of the Groups tool, you'll find the '''Add a cluster''' button ([[Image:new-cluster-icon]]). (You may have to expand the titlebar menu through its double chevron placeholder >>). + +The resulting dialog asks you for the cluster name, and the existing cluster (non-precompiled) of which you want to make it a subcluster, here leaving only one choice: + +[[Image:es gt add cluster dialog]] + +Instead of the default name, type my_cluster; select the only possible supercluster, root_cluster, and click '''Create''' at the bottom of the dialog. + +Now the diagram shows the new subcluster: + + +[[Image:es gt new cluster added|A new cluster has been added]] + + +Try to make your display look approximately like the above; you will probably have to move (drag from the center) and/or resize (drag from a corner) either or both clusters. + + +==Moving a class to a different cluster== + +Among the many operations you can do graphically is to move a class from one cluster to another. Pick-and-drop the HEIR2 class bubble to the rounded rectangle for MY_CLUSTER. + +This graphical manipulation has caused a structural change: class HEIR2 is now part of MY_CLUSTER. Check this by expanding the Cluster Tree on the left: + +[[Image:es gt class HEIR2 moved to new cluster|Class HEIR2 has been moved to my_cluster.]] + +If you like, you can also look into the project directory -- using the Windows Explorer, or cd and ls on Unix/Linux -- and check that it now has a subdirectory my_cluster with a file heir2.e containing the text of class HEIR2. + +Clearly, it's much more convenient to use EiffelStudio for such manipulations than to move files around manually. + + +==Adjusting the display== + +A number of buttons enable you to customize the display. So far all class bubbles had the same default color. Try pick-and-dropping a bubble into the '''Color hole''' ([[Image:diagram-choose-color-icon]]) to get a color palette that enables you to select a different color. This is useful if you want to highlight classes possessing certain properties, for example classes that are part of a certain Design Pattern. + +'''Relation depth''' ([[Image:diagram-depth-of-relations-icon]]) enables you to select the depth at which inter-class relations will be displayed. (Don't change this setting now.) '''Include all classes of cluster''' ([[Image:diagram-fill-cluster-icon]]) is more useful for class diagrams than for the cluster diagram we have now, which by default included all classes of the cluster; if you click it here it will add the class INVALID that you removed earlier. There is no need to do this now. + + +==Views== + +So far the top-right '''View''' field has always shown '''DEFAULT:BON'''. You can define any number of views in your project, and apply them to various class and cluster diagrams. + +For example, using the buttons to show and hide links of various kinds you can produce diagrams that only show the inheritance links, and others that only show the client links. If you want to keep both kinds of diagram, simply define views by typing view names -- such as '''Inheritance''', '''Client''', '''All_links''' -- into the '''View''' field. + +You can also use views to retain some of the choices seen just before, such as different colors and depths. + +To load a previously defined view, just use the menu associated with the '''View''' field. + +You may remember that when we generated HTML documentation, the dialog asked you to select a view among the available ones. You can choose a different view for each cluster. + +You may have guessed that the '''BON''' in '''DEFAULT:BON''' means that the diagram view is in Business Object Notation. You can also view diagrams in UML-style notation. To do this you would click the '''Show UML''' button ([[Image:diagram-view-uml-icon]]). Click it again to return to the BON view. + + +==Class diagrams, cluster diagrams== + +In the present discussion we have used cluster diagrams. Both are interesting. To obtain a class diagram, you will target a Class tool to a class, and select the Diagram tool. By default, this shows the parents of the class. Do this now for TESTROOT. + +{{note|Because at the beginning of this page, we put the EiffelStudio context tools in "unlinked" mode, it may be necessary to synchronize the context to see the class diagram. You can do this by clicking '''Synchronize context''' ([[Image:context-sync-icon]]) in the main toolbar. }} + + +[[Image:es gt testroot class diagram]] + + +It's for class diagrams that the '''Relation depth''' ([[Image:diagram-depth-of-relations-icon]]) button is most interesting. It will let you select the exact depth that you wish displayed for each relation type: + + +[[Image:es gt relation depth dialog]] + + + +This will conclude our review of the Diagram facilities of EiffelStudio, although you'll surely discover some further riches by yourself and through the rest of the documentation. We hope the complete seamlessness between text and pictures will enable you to increase the effectiveness of your analysis work, or your design work, or your programming -- whatever level of system development you need to tackle. + + + diff --git a/documentation/18.11/eiffelstudio/Tutorials/handling-syntax-and-validity-errors.wiki b/documentation/18.11/eiffelstudio/Tutorials/handling-syntax-and-validity-errors.wiki new file mode 100644 index 00000000..61a3dcd6 --- /dev/null +++ b/documentation/18.11/eiffelstudio/Tutorials/handling-syntax-and-validity-errors.wiki @@ -0,0 +1,81 @@ +[[Property:title|Handling Syntax and Validity Errors]] +[[Property:weight|-3]] +[[Property:uuid|c2be8123-b793-f8ce-e082-d4fdacc6bbe6]] +So far we have tried to make sure that everything went smoothly. But in actual software development you may encounter error situations, and it is useful to know what can happen then. + + +==Levels of language description== + +Let's remind ourselves first of how the language is specified. The [[ECMA Standard 367|ISO/ECMA Eiffel standard]] and the book [[Eiffel: The Language]] carefully distinguish between three levels of description: '''syntax''', '''validity''' and '''semantics'''. Their roles are clearly distinct: +* Syntax defines the structure of software texts. A typical syntax rule states that an assignment starts with a Writable entity, continues with the symbol :=, and ends with an Expression. This is a purely structural specification, saying nothing for example about the types of the Writable and the Expression. +* Validity, applicable only to syntactically legal texts, defines required consistency conditions. A typical validity rule states that in an assignment the right-hand-side Expression must conform -- a property of its type, defined rigorously on the basis of inheritance -- to the left-hand-side Writable. Eiffel has about 75 validity rules; part of the language's originality is that these rules are of the "if and only if" form, not only telling you individual error cases ("this is valid only if ... ") but also reassuring you that your text will in fact be valid if it satisfies the conditions listed exhaustively. +* Semantics, applicable only to valid texts, defines the software's expected run-time behavior. A typical semantic rule states that an assignment replaces the value of its left-hand-side Writable by the value of the right-hand-side Expression at the time the assignment is executed, with precise rules on the different possible cases involving references, objects and simple values. + +You may make an error at any of these levels: +* Writing = instead of := for the assignment symbol is a syntax error. +* Writing your_integer := your_real, with the types suggested by the names, is a validity error. +* Violating a precondition, causing a division by zero, are semantic errors. + +Syntax and validity errors will be detected by the compilation process. For semantic errors, you will rely on contract checking and on the debugging tools described later. Let's look now at examples of the first two cases. + + +==A syntax error== + +To see what happens for a syntax error, replace the keyword do by dont in the routine display of class PARENT (click the position immediately after the o and type nt.). Save the file by clicking the Save button or using CTRL-S and then compile the system. + +[[Image:es gt development window syntax error 01|Purposely injected syntax error]] + +The error shows up in the [[Error List Tool|Error List tool]]. You can expand the entry to show the point at which the error was recognized by the compiler. + +To correct the error, just bring the mouse back to its location, remove the spurious nt, and click Save again; also click Compile to make sure that the project is recompiled up-to-date. + +You may wonder why the syntax error messages are not a little more verbose than just Syntax error. The reason is merely that Eiffel's syntax, being simple and regular, does not require sophisticated error messages; syntax errors usually result from trivial oversights. If you make a syntax error and the reason is not immediately clear, check the syntax summary in the [[Quick reference to the Eiffel programming language]] or the [[ECMA Standard 367|ISO/ECMA Eiffel Standard]]. + + +==A validity error== + +A validity error is a violation of one of the validity constraints given in [[ECMA Standard 367|ISO/ECMA Eiffel Standard]]. Every such constraint is identified by a four-letter code of the form VXXX (the first letter is always V). + +A validity error will produce a precise error message, which includes the validity code. Although short, the error message is usually sufficient to find out what the error is. If not, you can get the complete rule, straight from the book. + +To see this mechanism at work, let us introduce a validity error. There is in fact one ready for you in class TESTROOT. Target a Development Window to this class; at the end of its text, just before the final end, you will find the following comment line: + +-- inv: INVALID; + +If uncommented, this is a declaration of a feature of type INVALID. A class called INVALID indeed exists in file invalid.e of the root cluster, but it contains a validity error. To see what it is, remove the initial double-hyphen -- in the above line from class TESTROOT so that it is not a comment any more. + +[[Image:es gt development window validity error 01|inv: INVALID uncommented]] + +Click Save, then Compile. Compilation starts but after a few degrees it stops with an error message that appears in the Error List tool. Expand the entry and perhaps do some resizing to see it in its entirety: + +[[Image:es gt development window validity error 02|Validity error]] + +As the error message indicates, you have (shame on you) violated the validity rule VUAR, which requires the number and types of actual arguments in a routine call to match the number and types of formal arguments declared in the routine. + +One of the interesting properties of the error message is that everything in color is '''clickable''': class name, feature name, but also the error code. This means that you can start a Pick-and-Drop on any of these elements to find out more. + +For example, to see the exact context of the error, pick-and-drop the name of the affected feature, display -- appearing in green on the fifth non-blank line -- and pick-and-drop it to the Editing tool. This displays the erroneous feature: + +[[Image:es gt development window validity error 03|Validity error exposed]] + +Note on this display a special property of Pick-and-Drop when its source is a feature name appearing in a validity error message: the instruction that causes the error is highlighted. + +In the error message in the Error List tool, the error code itself, VUAR, is also clickable. Assuming the message was not sufficient to understand the error, you can use it to start a Pick-and-Drop. Do this now, by picking that code and starting to move the mouse, but not dropping yet. The pebble shape for such information elements is a question mark ? enclosed in a small gold talk bubble ([[Image:error-cursor]]). Like other picked objects, when it is not over a droppable target, the pebble will be crossed in red ([[Image:error-cursor-disabled]]). The place to drop is the Explanation hole ([[Image:error-info]]) in the Error List toolbar: + +[[Image:es gt error list tool pnd validity error|Dropping a validity error pebble]] + +When you drop the pebble, you'll see the Compilation Error Wizard appear: + +[[Image:es gt compilation error wizard 01]] + +The wizard displays the complete text of the violated rule. Depending upon the particular violation, the rule will come straight from the pages of either [[Eiffel: The Language]] or the [[ECMA Standard 367|ISO/ECMA Eiffel standard]]. In this case, the VUAR rule definition used comes from Chapter 22, page 369 of [[Eiffel: The Language]]. An rule cited from the ISO/ECMA Eiffel standard will be state as such and will include the specific edition of the standard and the section number, for example: + +VEVI, ECMA-367, 2nd edition, section 8.19.17 + + +The VUAR rule that we violated has two clauses, numbered. Since the error message showed the error code as VUAR(1), the violated clause is the first; this convention of showing the clause number in parentheses applies to all multi-clause validity constraints. + +To correct the error the easiest is to go back to class TESTROOT and reinstate the comment symbol -- (two consecutive hyphens) on the erroneous line. Save and compile to continue with a valid system. + + + diff --git a/documentation/18.11/eiffelstudio/Tutorials/how-eiffelstudio-compiles.wiki b/documentation/18.11/eiffelstudio/Tutorials/how-eiffelstudio-compiles.wiki new file mode 100644 index 00000000..91b4543e --- /dev/null +++ b/documentation/18.11/eiffelstudio/Tutorials/how-eiffelstudio-compiles.wiki @@ -0,0 +1,214 @@ +[[Property:title|How EiffelStudio Compiles]] +[[Property:weight|3]] +[[Property:uuid|6fc86303-8afe-78af-6ca7-2853e8bfcbc3]] +So far we have relied on the compiling capabilities of EiffelStudio without exploring them in any detail. We must now understand the principles behind EiffelStudio's compiling strategy, in particular how it reconciles fast turnaround, efficient generated code, and strong typing. + + +==Compilation is automatic== + +Any speed issue aside, the most important property of the compilation process is that it is entirely automatic. + +You've seen it from the beginning of this Tour: all the information the compiler has -- obtained from a configuration file, as here, or generated automatically by the other options -- is the name of the root class and the list of directories holding Eiffel clusters. In fact it only needs these directories for non-precompiled clusters; here, because we are using precompiled EiffelBase, and because we've started EiffelStudio from the Tour's own root cluster directory, EiffelStudio has all the information it needs. + +The compiler takes care of finding all the classes that must be compiled. + +There is never any need, when compiling Eiffel systems, to supply "Make files", "include files", or other manual descriptions of inter-module dependencies. + + +==Compilation modes== + +EiffelStudio offers several forms of compilation, which you can see in the entries of the Compile menu (don't trigger any of them right now) as well as keyboard shortcuts and, in some cases, buttons: +* '''Melt''': quick incremental recompilation, doesn't optimize code for changed parts. +* '''Freeze''': incremental recompilation, not as fast as Melt, but generates more efficient code for changed parts. +* '''Finalize''': recompile entire system, generating highly optimized code. +* '''Precompile''' (available both in the Project menu and through Tools --> Precompilation wizard), to process an entire library, on which many systems can then rely without having to compile it. + +You'll quickly learn to use each of these modes to suit your needs. + + +==Criteria== + +EiffelStudio's '''Melting Ice Technology''' reconciles the following goals: +* ''Security and efficiency of the generated code'': compiling techniques for the strongly typed Eiffel programming language ensure that compilers can catch many errors before it is too late, and generate more efficient code. The "validity constraints" of the language, whose violations are caught as compilation errors, are particularly useful here, playing the role of enforceable design rules. +* ''Quick turnaround '': you should experience an almost immediate transition from the time you write or (more commonly) modify software to the time you can execute it. +* ''C code generation'': for portability, it is useful to take advantage of C in its proper role, that of a portable assembly language. C's closeness to machine concepts -- one of the very properties making it less suitable for human programming except in the case of short routines to access low-level mechanisms --, its almost universal availability, and its good level of standardization, make it an excellent target language for a code generator. This also enables the environment to benefit from the often extensive optimizations performed by good C compilers, and facilitates interfacing new software with the large body of existing C-based systems, tools and libraries. As the final output of Eiffel compilation, you can obtain a complete C package that you can either C-compile on the same machine or port to other platforms, making EiffelStudio a tool of choice for '''cross-platform development''': develop on one platform, deploy on one or more others. + + +==The Melting Ice Principle== + +The idea of the melting ice is based on the observation that, for the practicing software developer, the crucial day-to-day compilation problem is not how to process an entire system but how best to process a '''changed system''', of which an earlier state had previously been processed. + +The change may be big or small; the system may be big or small. ("Small system" here means up to a few tens of thousands of lines.) This gives four possible cases, of which only one is really critical: + + +{| border="1" +|- +| +| '''Small System''' +| '''Large System''' +|- +| Small Change +| +| xxx +|- +| Big Change +| +| +|} + + +If the system is small, as in both of the left column entries, speed of recompilation with a good compiler will be acceptable. + +In the bottom-right box, the developers have spent days or weeks changing many classes in a large system, so they will not resent having to wait a little to see the results of the recompilation, as long as the time remains reasonable. In EiffelStudio this corresponds, as we'll see shortly, to ''finalization'', which is in fact fairly fast anyway, but not as fast as the incremental modes. + +In the day-to-day, minute-by-minute practice of building and modifying software, the case that recurs by far the most often -- and can cause most frustration -- is the one marked xxx: you change only a small share of a big system. Then the result should come quickly enough. More precisely: + +{{definition|Melting Ice Principle|The time to re-process a system after a change should be a function of the logical size of the change, not of the size of the system. }} + +''The "logical size" of a change may be different from its physical size because a small physical change in a class may have consequences in many others. Imagine for example that you add a feature to class '' ANY'', although this is an extreme case and won't normally happen. Since every class is a descendant of '' ANY'', the logical change may affect the entire system.'' + +''In practice, however, most small physical changes will also be small logical changes and will only cause minimal recompilation. In particular, EiffelStudio will detect that a change does not affect the interface of a class -- for example if it's only a change to non-exported features -- avoiding the need to re-process its clients.'' + +Processing such incremental changes, in time proportional to the logical size of the changes, is known in EiffelStudio as '''melting'''. The reason for this terminology is the metaphor illustrated on the following figure. Think of a compiled system as a block of ice; it may have taken some time to "freeze" -- compile. Now you start working on it again; the changes are like melted drops of water, dripping from the ice as a result of the heat generated by your work. + +[[Image:index-140]] + +The Melting Ice Technology ensures that incremental compilation will only process the "melted" part, usually small, leaving alone the "frozen" part, which may be large. This is crucial to the incrementality of the mechanism. + +The roles of the four compilation modes follow from this analysis: +* '''Melting''' is the fastest mode: it processes the melted part without affecting the frozen part. With EiffelStudio, the melted elements will be ''interpreted'' while the rest is compiled. +* '''Freezing''' is the process of putting back the melted parts into the "freezer": bringing them to the same compiled state as the parts that have not been modified. +* '''Finalizing''' is the non-incremental process of producing a stand-alone C package and the resulting executable, extensively optimized, from the current system. +* '''Precompiling''' is the process of compiling an entire set of reusable classes, once and for all, so that it can be shared by many systems and many users without duplicating the code or compiling it again for each project. + + +==Properties of the compilation modes== + +The following table summarizes the differences between the four compilation modes: + + +{| border="1" +|- +| +| '''Regenerate C Code?''' +| '''Incremental?''' +| '''Compilation result shared between projects?''' +|- +| '''Melt''' +| No +| Yes (fast) +| No +|- +| '''Freeze''' +| Yes +| Yes (but requires C compilation of changes and linking) +| No +|- +| '''Finalize''' +| Yes +| No +| No +|- + + +| '''Precompile''' + + +| Yes +| No +| Yes +|} + + +During the production and modification of your software, you will usually alternate between melting and freezing, since both of these modes are incremental. Most of the time, you will simply '''melt''', since melting satisfies the Melting Ice Principle: the time to get back to a working system is very short -- proportional to the size of the changes. Note in particular that the unit of melting is the smallest possible one: each feature of a class -- attribute or routine -- may be melted separately. + +The main difference between melting and '''freezing''' is that freezing implies re-generating C code for the changed elements, and hence relinking the system as well. In contrast, when you melt changes, you do not change any C code: it remains frozen. + +As a consequence, melting can only process changes to Eiffel code. If you add new external code (in C, C++ or other languages whose modules will require linking), you must freeze. This is also true if you add new Eiffel agents. If you ask for a Melt in such cases, the operation will trigger a freeze anyway. More generally, the Compile button, which you have used a number of times to recompile the system in this Tour, triggers a Melt by default, and a Freeze when it has to. + +EiffelStudio knows how to hide the differences and present you with a uniform view of the frozen parts (the C code) and the melted parts. Here indeed is the full view of the picture that was previously given in part: + +[[Image:index-141]] + +When you examine a component of the system -- to edit a class, produce a view such as Contract or Interface, enable a breakpoint on a routine, run the system, inspect a run-time object -- EiffelStudio automatically knows where to look for the corresponding information: melted or frozen part. If one of your actions requires melting or freezing more elements, EiffelStudio will also handle this automatically. + +As suggested by the lower red arrow, successive melting operations "pour water into the bowl", corresponding to the elements that you have changed since the last freeze. Freezing, represented by the top red arrow, updates the C code so that it integrates all the latest changes, emptying the bowl in the process. + +Because the difference between melted and frozen code is largely invisible to users of the environment, the term '''workbench code''' will cover both kinds; workbench code is code resulting from a succession of freezing and melting operations. As long as you are working within EiffelStudio, you are using workbench code. + +When you are happy with the results of your development, you will normally finalize the system, thereby generating '''final code'''. Although not strictly required, this step is in most cases appropriate since final code is significantly more efficient than workbench code in both time and space: finalization performs a number of optimizations -- dead code removal, replacement of dynamic by static binding -- that wouldn't be justified in incremental development where, for example, some code element that is "dead" one minute may be resurrected the next moment through the addition of just one line of text. In addition, because finalized code is more efficient than frozen code, it is the natural choice if, using EiffelStudio for cross-platform development, you wish to port the resulting C-package to other architectures. + +If you have a set of reusable classes that may be useful to many applications, you can '''precompile them''' into a library. This set of classes must be ''self-contained'' in the sense that all the classes needed by any of them must be either in the library itself or in another library that you will include in the precompilation. + + +==Bytecode== + +The result of melting operations -- the contents of the "bowl" -- is an internal software representation known as melted code or (for no particularly good reason) as ''bytecode''. EiffelStudio generated bytecode serves two complementary purposes: +* It can be executed directly. This is what happens during melting: while the rest of your system, the frozen part, is executed in the form produced by Eiffel compilation generation and C-compilation of the result, the melted part is interpreted "as is" without further translation. +* It can be compiled into C for further processing. + +Internally, the melted code is in a file simple.melted (where simple is our project's name) in the subdirectory EIFGENs/simple/W_CODE of the project directory. The file is not human-readable, but as you add elements to your software and melt you watch its size grow. Whenever you freeze, it's emptied. + +{{note|For systems targeted to Microsoft .Net, bytecode is replaced by that platform's own internal code, MSIL.}} + + +==Degrees== + +You can now see the reason behind the terminology used to describe compilation steps, called '''degrees''' on the messages that flash on the screen when you do a compilation. The names are inspired by the international temperature scale -- Celsius, also known as centigrade -- where water freezes at 0 (and boils at 100, but Eiffel software never reaches that). For EiffelStudio: +* Compilation starts at degree 6, which examines the clusters of your system to determine what classes may have changed. In many cases the compilation can safely skip part of this degree. +* Degree 5 parses modified classes. It's executed not only when you explicitly request a compilation, but also when you save a class from the EiffelStudio editor, or exit from an external editor, so that you can see and fix syntax errors without delay. +* Degrees 4 down to 1 take care of melting. +* Negative degrees only take place when you freeze or finalize. +* After negative degrees comes C-compilation if needed. + + +==Using melting and freezing== + +When should you melt, freeze, finalize or precompile? The answers are simple and follow directly from the preceding overview; they provide the key to getting the environment to work for you in the most effective way possible. + +Melting is the bread and butter of the Eiffel developer. As you build your software, either from scratch or by modifying an existing system, you will regularly melt to benefit from the various checks that compilation performs and, of course, to generate executable code that you can test and debug immediately. During this process, there is no need to refreeze, since this operation (although still incremental) takes significantly more time than melting. + +Only two operations, noted above, ''require'' freezing: the addition of external (non-Eiffel) routines, such as C functions or C++ classes, and the addition of agents. The reason is easy to understand: the EiffelStudio compiler knows how to melt Eiffel software, but not software written in C or other languages; agents similarly require special code generation. + +''For the first compilation of a system that does not use precompiled EiffelBase, a Freeze is needed since class '' ANY'', from which all other classes inherit, uses some external routines. In this case the environment automatically starts a freeze even if you just click Melt. This does not apply if you have access to precompiled EiffelBase.'' + +Except for the addition of external routines or agents, freezing is never strictly necessary. It is indeed possible to use melting throughout a development, never requesting a freeze after the first compilation. But as the melted-to-frozen ratio grows, you may detect a certain degradation in the performance of the system (determined by how big a share of your system is melted, not how many times you melt it). After a while, then, you may want to refreeze. Like melting, freezing is incremental: only those parts of a system that have been logically changed will be recompiled; as with melting, the determination of what needs to be recompiled is entirely performed by the environment, without any manual intervention on the developer's part. + +The principal difference is that freezing takes longer than melting. Because of this you are requested to confirm the first time you freeze. Freeze the example system by choosing the menu entry + +Project --> Freeze +You get the following dialog: + +[[Image:es gt freeze warning|Freezing requires external compilation]] + +Note the No option: by default, freezing will start a C compilation, but you can stop after C generation if you wish. This is useful for example if you want to generate a C package for cross-development, C-compiling the result on a different platform. + +Click Yes to confirm freeze and C-compilation. Once the Eiffel compilation is complete, a message in the Development Window ( C compilation launched in background) tells you when that C-compilation has started. C-compilation does not block EiffelStudio: at this point you can continue working with the environment. Any messages from C compiler will appear in the [[External compilation pane]] of the [[Outputs Tool|Outputs tool]]. + +You will be able to execute the frozen system as soon as the C compilation finishes. + +You will note that freezing, although it takes more time than melting, is actually quite fast, both due to the speed of Eiffel compilation and to the structure of the generated C code, designed to optimize the operation of the C compiler. + +{{note|When you freeze a system targeted to Microsoft .NET, the external compilation of your system is not necessary. The intermediate language generated by EiffelStudio and other .Net compatible compilers will be converted to machine code at runtime by .Net's just-in-time (JIT) translator.}} + + +==Using finalizing== + +The main reason for finalizing a system is run-time performance of the generated system. Finalization enables you to generate the high-performance executables that are among the hallmarks of ISE Eiffel. As a consequence, finalized code is the best vehicle for cross-development: you can port the resulting C package to various target platforms and C-compile them on these platforms. + +The '''optimizations''' performed by finalization affect both space and time: +* ''Dead code removal'' strips the executable module of all the routines in the system that are not actually called, directly or indirectly, by the root's creation procedure. In a large system relying on many general-purpose classes, dead code removal can easily reduce an executable's size by one third or more. +* Finalization also applies ''static binding'' to non-polymorphic calls, and ''inlines'' some routine calls. + +As long as you continue changing, melting and freezing your system, the workbench compiling mechanisms cannot perform such optimizations: if a routine is "dead" today you may resurrect it tomorrow by adding a new call to it somewhere; and if a call is non-polymorphic a single additional assignment may require dynamic binding. Compilation can only generate optimal code by working on a full, stable system. This is the task of finalization. + +'''Cross-development''', the second reason for finalizing, is important if you are taking advantage of the portability of ISE Eiffel to develop your system on a certain platform and then run the result on target computers with possibly different architectures. A target machine may lack an ISE Eiffel compiler (unmistakably signaling its owner's backwardness) but include a C compiler. If the development and target platforms are of different architectures you will need to obtain a copy of the run-time system for the target architecture. The run-time system is also ANSI-C-based, so porting it is usually a straightforward matter. + +Note that cross-development does not ''require'' finalization, since you can cross-compile a frozen version. In practice, however, the finalized version is usually the preferred form for porting a C package because of the performance advantage. + +Finalize the example system now by selecting the menu entry + +Project --> Finalize +Here too you will be asked to confirm, although the dialog enables you to suppress that confirmation for later attempts, and you may skip C compilation. You will note that finalization is longer than freezing, but still remains quite reasonable thanks to the extensive optimization of the Eiffel compilation process and the structure of the generated C code. + + diff --git a/documentation/18.11/eiffelstudio/Tutorials/index.wiki b/documentation/18.11/eiffelstudio/Tutorials/index.wiki new file mode 100644 index 00000000..19f06edf --- /dev/null +++ b/documentation/18.11/eiffelstudio/Tutorials/index.wiki @@ -0,0 +1,6 @@ +[[Property:title|EiffelStudio tutorials]] +[[Property:link_title|Tutorials]] +[[Property:weight|2]] +[[Property:uuid|4d68a136-f7c2-ddd3-d30d-e16ee7692302]] +This is a guided tour of Eiffel Software's EiffelStudio interactive software development environment. + diff --git a/documentation/18.11/eiffelstudio/Tutorials/look-project-directory.wiki b/documentation/18.11/eiffelstudio/Tutorials/look-project-directory.wiki new file mode 100644 index 00000000..03217f3d --- /dev/null +++ b/documentation/18.11/eiffelstudio/Tutorials/look-project-directory.wiki @@ -0,0 +1,31 @@ +[[Property:title|A Look at the Project Directory]] +[[Property:weight|-11]] +[[Property:uuid|d82eae3f-fe0d-3e27-008e-61afd05f8cb0]] +Before we proceed with the facilities of the environment, let's take a look at the way EiffelStudio organizes project files. + +With EiffelStudio, you build projects. Most projects yield an executable system, although you can also build a project just to define a library for use by such systems. + +Every session is relative to a project; you can start a new project from within EiffelStudio by following the menu path: + +File --> New Project + +... but please '''don't select that menu entry now''' as we have many more things to do with our current project first. + +Every project has a '''project directory''' which will contain the files generated and managed by EiffelStudio. The project directory may also host some of the source files containing your Eiffel classes, the ECF (eiffel configurationl file), and external software written in other languages. However, it is not required that everything be stored together; the source files and ecf may reside anywhere. Some users, in fact, like to put nothing other than the EiffelStudio-generated files in the project directory; this separates user-managed and system-managed files, and can facilitate configuration management, backups and porting. + +In this simple Tour, things have been set up so that all the files of interest, source texts as well as generated ones, will appear in the project directory YOURDIR (either $ISE_EIFFEL\examples\studio\tour or the copy that you have made). Go to that project directory using the Windows explorer or a cd command, and look at its contents (using ls on Unix/Linux): + +[[Image:es gt project directory 01]] + +The contents of this YOURDIR directory includes the following: +* First you see a number of files with the extension .e , for "Eiffel": heir.e , invalid.e and others. These are the Eiffel source files, each containing one class. The recommended convention is to store a class of name CLASS_NAME into a file of name class_name.e , where class_name is the lower-case version of CLASS_NAME ; here, file heir.e contains the class HEIR and so on. As you may remember, Eiffel is case-insensitive, but the standard convention for class names is to write them in all upper case. Calling the file class_name.e is only a recommendation, not an obligation; but you are required to store one class per file. This keeps things simple and facilitates project and configuration management. +* You also notice a file with an ecf extension. This is the configuration file that specifies this project. As you remember, the ECF file for this example was available as part of the delivery; we used it to compile the project. In most practical cases, however, you won't need to build an ECF; if you use the "Create project" option of EiffelStudio, EiffelStudio will build the ECF for you; if you change the Project Settings during a session, EiffelStudio will update the ECF. ECF files are written in a XML notation. +* You will notice a subdirectory called EIFGENs, for "EIF''fel'' GEN''eration''s". EIFGENs is created and maintained by the compiler to store information about your project, including generated code for execution. EiffelStudio manages your project in such a way that EIFGENs can always be re-generated if need be; this means in particular that if things go wrong for any reason and you want to make a fresh start you can always delete this directory and recompile your system. This also means that you should not add any files into this directory, or modify any of its files, since a later compilation is free to change or regenerate whatever it chooses in EIFGENs. +* Because the demonstration system for the Tour is a Microsoft Windows system, there is a file named simple.rc in the folder. This is a Windows resource file that was created automatically by EiffelStudio. + +Later on, we will see that EiffelStudio may generate three more subdirectories of the project directory: Diagrams, if you produce graphical system diagrams; Documentation, if you request system documentation, for example HTML; and Metrics, if you perform measurements on your system. Other than these directories, EIFGENs EiffelStudio will not touch anything in the project directory, so you may safely add and change whatever files and subdirectories you like. + +You seldom need to look into EIFGENs, although you should know that it's there. Right now if you check the contents of the project directory YOURDIR (using the Windows Explorer on Windows, the ls command on Unix, or some equivalent mechanism), you will see that EIFGENs has been created, itself with a subdirectory called classic which is the name of the target and which has some subdirectories, including W_Code which contains the generated code ( W for "Workbench" -- we'll see the reason later). Feel free to browse through it if you like, but don't change anything. + +By the way, we are now done with any platform-specific instructions. Everything in the rest of this Tour, other than the graphical look-and-feel, will work the same across all EiffelStudio platforms. + diff --git a/documentation/18.11/eiffelstudio/Tutorials/manual-identification-and-copyright.wiki b/documentation/18.11/eiffelstudio/Tutorials/manual-identification-and-copyright.wiki new file mode 100644 index 00000000..2e3ac457 --- /dev/null +++ b/documentation/18.11/eiffelstudio/Tutorials/manual-identification-and-copyright.wiki @@ -0,0 +1,73 @@ +[[Property:title|Manual identification and copyright]] +[[Property:weight|7]] +[[Property:uuid|c581a81b-fc9b-99bd-e73a-f290f6051a45]] +Title: ''EiffelStudio: A Guided Tour'', Eiffel Software Technical Report TR-EI-68/GT. (Replaces TR-EI-38/EB.) + +===Publication history=== + +First published 1993 as ''First Steps with EiffelBench'' (TR-EI-38/EB) and revised as a chapter of ''Eiffel: The Environment'' [http://www.eiffel.com/doc/ (TR-EI-39/IE), also available as] An Object-Oriented Environment (Prentice Hall, 1994, ISBN 0-13-245-507-2. + +Version 3.3.8, 1995. + +Version 4.1, 1997 + +This version: July 2001. Corresponds to release 5.0 of the EiffelStudio environment. + +===Author=== +''Bertrand Meyer'' +===Software credits=== + +Emmanuel Stapf, Arnaud Pichery, Xavier Rousselot, Raphael Simon; Etienne Amodeo, Jrome Bou Aziz, Vincent Brendel, Gauthier Brillaud, Paul Colin de Verdiere, Jocelyn Fiat, Pascal Freund, Savrak Sar, Patrick Schonbach, Zoran Simic, Jacques Sireude, Tanit Talbi, Emmanuel Texier, Guillaume Wong-So; EiffelVision 2: Leila Ait-Kaci, Sylvain Baron, Sami Kallio, Ian King, Sam O'Connor, Julian Rogers. See also acknowledgments for earlier versions in ''Eiffel: The Environment''(TR-EI-39/IE) + +Non-Eiffel Software: special thanks to Thomas Beale, Eric Bezault, Paul Cohen, Paul-Georges Crismer, Michael Gacsaly, Dave Hollenberg, Mark Howard, Randy John, Eirik Mangseth, Glenn Maughan, Jacques Silberstein. + +===Cover design=== + +Rich Ayling. + +===Copyright notice and proprietary information=== + +Copyright Interactive Software Engineering Inc. (Eiffel Software), 2001. May not be reproduced in any form (including electronic storage) without the written permission of Eiffel Software. "Eiffel Power" and the Eiffel Power logo are trademarks of Eiffel Software. + +All uses of the product documented here are subject to the terms and conditions of the Eiffel Software user license. Any other use or duplication is a violation of the applicable laws on copyright, trade secrets and intellectual property. + +Any third-party products mentioned in this document are hereby acknowledged as trademarks of their respective owners. + +===Special duplication permission for educational institutions=== + +Degree-granting educational institutions using EiffelStudio teaching purposes as part of the [http://www.eiffel.com/educators/resources.html Eiffel University Partnership Program] may be permitted under certain conditions to copy specific parts of this book. Contact Eiffel Software for details. +{| +|- +|
'''About Eiffel Software '''
+|- +| +Eiffel Software (Interactive Software Engineering) helps you produce software better, faster and cheaper. + +Eiffel Software provides a wide range of products and services based on object technology, including EiffelStudio, a complete development environment for the full system lifecycle. Eiffel Software's training courses, available worldwide, cover key management and technical topics. Eiffel Software's consultants are available to address your project needs at all levels. + +Eiffel Software's TOOLS (Technology of Object-Oriented Languages and Systems) conferences, [http://www.tools-conferences.com http://www.tools-conferences.com] , are the meeting point for anyone interested in the software technologies of the future. + +Eiffel Software originated one of the earliest .NET products and offers a full range of .NET services and training at [http://www.dotnetexperts.com http://www.dotnetexperts.com] . + +For more information
+
+Interactive Software Engineering Inc.
+Eiffel Software Building, 360 Storke Road
+Goleta, CA 93117 USA
+Telephone 805-685-1006, Fax 805-685-6869
+
+Internet and e-mail + +Eiffel Software maintains a rich source of information at [http://www.eiffel.com http://www.eiffel.com] , with more than 1200 Web pages including online documentation, downloadable files, product descriptions, links to Eiffel Software partners, University Partnership program, mailing list archives, announcements, press coverage, Frequently Asked Questions, Support pages, and much more. + +Visit [http://www.eiffel.com/general/contact_details.html http://www.eiffel.com/general/contact_details.html] to request information about products and services. To subscribe to the Eiffel Software user list, go to[http://groups.eiffel.com/join http://groups.eiffel.com/join] . + +Support programs + +Eiffel Software offers a variety of support options tailored to the diverse needs of its customers. See [http://support.eiffel.com http://support.eiffel.com] for details. + +|} + + + + diff --git a/documentation/18.11/eiffelstudio/Tutorials/producing-and-exporting-documentation.wiki b/documentation/18.11/eiffelstudio/Tutorials/producing-and-exporting-documentation.wiki new file mode 100644 index 00000000..bde3f645 --- /dev/null +++ b/documentation/18.11/eiffelstudio/Tutorials/producing-and-exporting-documentation.wiki @@ -0,0 +1,161 @@ +[[Property:title|Producing and Exporting Documentation]] +[[Property:weight|-7]] +[[Property:uuid|ca43a3c2-9e1a-a69f-81cf-55d0b12294ea]] +Software development is, most of the time, cooperative work. You must tell the rest of the team what you're up to, and find out what they can offer you. Bring in distributed development -- increasingly common these days, with some people working at headquarters, others at home, others traveling, an offshore team half a world away ... -- and the problem becomes even more critical. + +EiffelStudio provides unique facilities to make such distributed development possible in a safe, effective, harmonious way. Some of the key criteria are: +* You must be able to export the information easily to the World-Wide Web, the most general and widely available interaction mechanism. +* The documentation must be faithful to the software. Because of the ever-changing nature of software, this goal is impossible to satisfy unless the documentation is extracted from the software -- as opposed to the traditional approach, still perpetuated by many CASE tools, of treating the two as separate. +* The task of updating the documentation after a software change must be straightforward and automatic. +* It's not enough to support HTML; many other formats are useful too. +* Users must have the ability to adapt the mechanism to support new formats. +* For existing formats, they must have a way to tune the output easily to any specific style standards, company policies, local variants. + +EiffelStudio's documentation generation satisfies all these requirements. + +==Documentation filters== + +Let's see how documentation works by starting to generate it for our Guided Tour system -- which really means for EiffelBase, since that's what it mostly consists of. The HTML result is available as part of the present documentation (we'll tell you where in just a minute), so you don't have to regenerate it unless you want to. Indeed we'll show you when to click Cancel if you are happy with the pre-generated version. But let's get started anyway to understand the principles and possibilities. + +Click the following menu entry, used to generate documentation: + + Project --> Generate documentation... + + +This is the next-to-last entry in the Project menu. The last one, by the way, XMI Export ..., is directly relevant too: it will make it possible to export information in the standard XML representation for UML, for consumption by third-party products such as Rational Rose. But for the moment we choose the Documentation entry to start the Eiffel Documentation Wizard. + +The Wizard starts with a list of available output formats, also called filters: + +[[Image:index-37]] + +The filter names correspond to major documentation formats which EiffelStudio supports by default. Among the most important, listed here in rough order of appearance in the list: +* ASCII : plain text, no formatting codes. +* eiffel : essentially the same as ASCII; useful if you want EiffelStudio to pretty-print your class texts and replace the originals, as explained below. +* MML : internal format for Adobe FrameMaker. +* Postscript : to generate Adobe Postscript output, suitable for printing on a Postscript printer, display on a Postscript previewer such as Ghostscript, or distilling to Adobe PDF. +* COM : to generate class specifications in the form of an Interface Description Language (IDL) interface for Microsoft's COM component model. +* RTF : Microsoft's Rich Text Format, used in particular for Windows "Help" files. +* TeX1, TeX2 : two variants for Donald Knuth's TEX processing format. +* troff : if you already know what this is, congratulations (or condolences), you've been around the industry for a while. This is a traditional text-processing format available on Unix systems. Also works for the gtroff variant. +* html-classic : HTML, no style sheets. The next variant, with style sheets, is strongly recommended unless your colleagues will be reading your documentation with Mosaic 1, vintage 1993, or Netscape 2, Vintage 1995. +* html-stylesheet : HTML with style sheets. This is particularly attractive for Web publishing not only because the output makes full use of style sheet capabilities (fonts, colors, layout, formatting) but also because it becomes trivial to change the look-and-feel to support any style you or your users like, even after generation, simply by editing the style sheet file. + +Not only do these predefined filters provide support for a number of important industry formats; better yet, if you want another format not represented on the list, or would like to adapt an existing format to your own style preferences, it's easy to define a new filter. The list that EiffelStudio displays comes from the files with a .fil extension that it finds in a subdirectory of the installation: +$ISE_EIFFEL/studio/filters + +To define a new filter, simply add a file to this directory. Filters are expressed in a simple notation called EFF ( Eiffel Filter Format ), general enough to support a wide variety of tools for text processing, project management, Web publishing etc. The best way to define a new filter is usually to start from an existing one and adapt it. You will find the specification of EFF at the end of this manual, [[APPENDIX: WRITING DOCUMENTATION FILTERS WITH EFF, THE EIFFEL FILTER FORMAT|here]] . + +==Generating an HTML record of your project== + +Let's select the most obviously attractive of the predefined filters: HTML with stylesheets. Click the line html-stylesheet in the list to make it active, then click Next at the bottom of the Documentation Wizard window. The next window appears: + +[[Image:index-38]] + +In this pane you select which parts of your system you want to be included in the documentation. By default, all library and cluster names are checked. You should uncheck any that you do not want included. + +Note that each library or cluster name must be checked or unchecked individually. For example, unchecking "base" will not automatically deselect "elks" and "ise" which appear under "base". + +For this Tour we'll want to generate everything, including EiffelBase, so make sure that in the end all library and cluster names are checked, as in the figure. Then click Next. + +==Generating Metatags from Note entries== + +The next step of the documentation wizard asks you to select Note entries: + +[[Image:index-39]] + +Eiffel classes, as you know, may start with an note entry that enables class authors to include documentary information in any category they like. It is standard (and part of the official style guidelines) to include at the very least an entry of the form description: Descriptive text in every class. The earlier displays of class LIST showed that entry, which read " Sequential lists, without commitment to a particular representation". + +You may have noted that the purpose of Eiffel's note clauses is, conceptually, similar to that of '''metatags''' in HTML. Metatags carry information which Web page visitors do not normally see in the browser; this information is available, however, to search engines and other tools that explore and classify Web pages. So it seems quite appropriate to generate metatags from note entries. + +The dialog illustrated in the last figure lets you select the entries you wish to transform into metatags. It appears only if you have selected an HTML filter. It lists all the note tags found anywhere in the system; those that are checked will be retained for metatags. Initially unchecked are three tags ("date", "revision", and "status") conventionally used -- at Eiffel Software and other Eiffel sites -- for interfacing with configuration management tools, and hence of internal interest only. + +There is no need to change the default selection, so just click Next. + +==Choosing a level of detail== + +The next step of the Documentation Wizard lets you specify what kinds of documents you want to generate: + +[[Image:index-40]] + +This is a very important facility since it gives you control over how much you want to publish about the properties of the software: +* You may want to publish everything, source included, for example on your Intranet for a group of developers working closely together on the same classes, or on the Internet for open-source software. +* You may want to publish only the interfaces (Contract or Flat-Contract views). This is not necessarily to protect proprietary information; even if you don't care about showing your source code, it is usually too detailed for client programmers, especially in the case of libraries. If various teams work on separate parts of a project, what each releases to the other should usually be the specification, not the implementation. +* You may of course want to publish both the text and the interface, and let the recipients use the version that best suits their needs for each use. +* You may want to publish the diagrams, showing the structure in graphical form. Note the warning -- which we are about to ignore -- telling us this may take a while. +* The class list, cluster list, cluster hierarchy view, cluster chart (following the conventions of BON) are also optional. + +The dialog shown on the last figure lets you specify the exact combination you wish. The figure indicates the default options. + +This time, if we generate anything, we'll generate everything. Please check '''all''' the boxes (the generation won't occur until the last step) and click Next to move to the next dialog of the Documentation Wizard. + +==Specifying cluster views== + +The next dialog only appears when you have asked to generate diagrams: + +[[Image:index-41]] + +Although we didn't use this possibility yet, the Diagram view lets you define different subviews of any cluster. One view might show inheritance only, the other client links only; one might include all classes, the other hide some library classes. The last dialog shown will allow you, for any cluster, to select a subview other than the default for the generated diagram. + +Here we only have the default view, so just click Next. + +==Generating== + +The last dialog simply asks you where you want to generate the result: + +[[Image:index-42]] + +By default, as shown, EiffelStudio will produce the documentation in a subdirectory -- created for the occasion, if it doesn't exist yet -- of the project directory: + +.../your_project_directory/Documentation + +You may, however, select any other location you like. In the case of HTML generation, as here, EiffelStudio takes great care to use only '''relative hyperlinks''' so that you can move the Documentation directory around, for use either on a file system or on your Web site, with the guarantee that the hyperlinks will work -- as long as you move the entire directory together. + +To continue the Guided Tour, you do '''not''' need to complete the generation now unless you want to. If you are happy to continue without generating the documentation at the moment then click Cancel on the last dialog. + +{{note|If you do prefer to produce your own local version of the full documentation for the guided tour system, click "Finish". The process takes 7 minutes on the Thinkpad configuration mentioned earlier, and generates a documentation directory of about 220 megabytes. }} + +==Browsing generated documentation== + +Let's take a look at the generated documentation. We start with the root of the generated documentation, Documentation/index.html : + +[[Image:index-43]] + +This root page shows overall information about the system. The top set of links, repeated at the bottom, enables you to browse the system from its list of classes, its list of clusters, or the cluster hierarchy; note the box labeled to Go, which provides a built-in search engine, enabling you to type any class list and go directly to the corresponding page. Let's look at the class list: click the box Classes at the top left. + +[[Image:index-44]] + +This shows the beginning of the list of classes, alphabetically sorted. You could click any class to get the corresponding information, but wait; we'll look at individual classes in a moment. Instead, click Cluster hierarchy to see the overall organization of the system into clusters: + +[[Image:index-45]] + +Click BASE to see details of the EiffelBase library where (under EiffelStudio) we had found the class LIST used as example in the preceding sections: + +[[Image:index-46]] + +This indicates the relations of the cluster to others in the hierarchy, and its list of classes. Again you could click any class name but instead note the link (diagram) next to the cluster name near the top. Remember that when generating the documentation we elected to generate everything, diagrams included. Hadn't we checked the corresponding check box, the (diagram) link wouldn't be there. Click it now to get the diagram that has been generated for BASE: + +[[Image:index-47]] + +The output is a diagram showing graphically the classes of the cluster and their inheritance relations. All EiffelStudio-generated HTML diagrams use the PNG graphics format ( Portable Network Graphics ), supported by all recent browsers. + +The class bubbles in a diagram are all hyperlinks. To see the HTML documentation for our old friend the class LIST you could just click its bubble. But because this diagram includes the whole library and is automatically generated, you'd have to look around a bit for the LIST bubble. Go ahead and do that if you wish, or just type the class name LIST into the Go to field and press return: + +[[Image:index-48]] + +The display shows key information on the class, in a form called the "Chart format" listing the ancestors and then the features, divided into Queries (shown in part on the figure) and Commands. Note that all class names and feature names are hyperlinks, which would lead you to the appropriate place in a class text. + +The top row of hyperlinks now includes class formats corresponding to those we discovered in [[Viewing Classes]] in EiffelStudio: Relations (covering ancestors, descendants, clients, suppliers, ), full Text, Contracts, Flat contracts. Click Flat contracts to see the full interface of the class: + +[[Image:index-49]] + +We'll stop this brief review here but you may continue browsing through the HTML pages if you like. Note how closely the appearance of the class texts, flat forms, contract forms, diagrams and other forms of documentation matches the corresponding formats under EiffelStudio. + +Although we suggest staying with the standard, you can easily change any convention that doesn't match your own preferences: +* For the EiffelStudio appearance, use Tools --> Preferences. +* For the HTML appearance, if you know about Cascading Style Sheets (CSS) for HTML, edit the style sheet default.css. You will find this file in the generated documentation directory; alternatively, to ensure the changes are applicable to the generated documentation of all future projects, edit defaults.css in the directory after backing it up. For more profound changes in the structure of the generated HTML, you may also backup and edit the Eiffel Filter Format file html-stylesheet.fil in the same directory. EFF is described in the [[APPENDIX: WRITING DOCUMENTATION FILTERS WITH EFF, THE EIFFEL FILTER FORMAT|Appendix]] . + + $ISE_EIFFEL/studio/filters + + +The documentation generation mechanisms, using HTML or other formats, let you publish your designs, at the level of detail you desire, on an Intranet, the Internet, or as part of documents you release. They are an important part of the power of EiffelStudio for quality software development. + diff --git a/documentation/18.11/eiffelstudio/Tutorials/recompiling-and-editing.wiki b/documentation/18.11/eiffelstudio/Tutorials/recompiling-and-editing.wiki new file mode 100644 index 00000000..4a9df320 --- /dev/null +++ b/documentation/18.11/eiffelstudio/Tutorials/recompiling-and-editing.wiki @@ -0,0 +1,173 @@ +[[Property:title|Recompiling and Editing]] +[[Property:weight|-4]] +[[Property:uuid|6574a573-48b9-6088-aa98-53d7119d7c5c]] + +So far we have relied on existing class texts. Fascinating as it may be to explore excellent software such as EiffelBase, you probably want to write your own too (with the help of the reusable components in the Eiffel libraries). EiffelStudio provides a built-in editor -- as well as the ability to use some other editor if you prefer -- and sophisticated compilation mechanisms. + +==Recompiling== + +When we started, we compiled the example system. Let's recompile it, just to see. We'll see compilation entries in the Project menu, but the easiest for the moment is to use the compilation button ([[Image:compile-button]]) in the Project toolbar. Click this button. You haven't changed anything in the project since it was compiled (at least you were not supposed to!), so EiffelStudio will very quickly detect this and finish compilation. On our test platform this takes less than a second. Now of course we should see what happens if you do change something. + + +==Editing== + +We don't want to touch EiffelBase classes (and in fact can't, since it is used in precompiled form), so let's focus on classes of our small root cluster. In the Groups tool, expand cluster root_cluster and click class PARENT to retarget the Development Window to it. + +Make sure that the Editing Tool is big enough to display the text of the class: + +[[Image:es gt development window targeted to parent 01|Class PARENT in Editing tool]] + +The Editing Tool hosts a text editor which you can use to change the class text. Here the routine display starts by outputting a simple message; let's precede it by another line of display to check that we affected the outcome. We'll want to add the following two lines just after the do, before the first two instructions of the routine: + + io.put_string ("THIS IS SOME ADDED TEXT") + io.new_line + + +You can just use copy-paste from the example above: select the two lines with the mouse, copy them using CTRL-C (or Copy from the Edit menu), then paste them just after the do using CTRL-V (or Paste from the Edit menu). Add or remove tabs to align with the rest of the routine, so that the result will look like what's shown on the next figure. Please check the result and be careful not to introduce any mistakes; in the next section we'll study how EiffelStudio will report syntax and other errors, but right now we want to see what happens when everything is right! + +[[Image:es gt development window targeted to parent 02|Class PARENT with changes]] + +Now save your changes; you may indifferently use CTRL-S, the Save entry from the Edit menu, or the Save button ([[Image:save-button]]), at the cursor location on the figure. (If you forget to save, the next compilation will tell you so, and ask you if from now on you want all non-saved class edits to be saved automatically.) + + +==Recompiling and executing after a change== + +Next compile again, using the Compilation button. Some "degree" messages appear quickly; EiffelStudio has found out what class has changed and deduced what exactly to recompile -- only a subset of the whole system. So this again will proceed very quickly. + +Execute the system again now, using one of the execution buttons, with or without breakpoints, on the right in the bottom Project toolbar. You will see that the message output by the execution has changed to include the added string. + + +==Views in the Editing Tool== + +In studying the Class tool we discovered a number of views of a class text. For convenience, you can also display a number of these views in the Editing Tool, although only the basic Text view is editable. A row of buttons next to the Class and Feature fields lets you choose between them. + +[[Image:view-buttons]] + +You can try some of these view now, although there is nothing exciting to show about class PARENT. Make sure to come back to the Text view -- through the leftmost of these buttons -- so that we can continue exploring the editing facilities. + + +==Basic editing facilities== + +The editing facilities in the Editing Tool are provided by the EiffelStudio Editor, a specialized tool supporting the development and update of Eiffel texts. As we'll see next, if you have a preferred editor you can use it instead, but the EiffelStudio Editor is worth knowing. + +The [[EiffelStudio Editor|EiffelStudio Reference section]] on the Editor provides many more details about editing functions. Here are the essentials. + +First, the key property of any interactive system: '''Undo'''. You can cancel the latest editing command, or any earlier one performed during the current session, by choosing Undo from the Edit menu, or typing CTRL-Z. To cancel more than one command, apply Undo repetitively; there is no limit to the number of undoable commands within a session. (When you exit EiffelStudio, however, the editing history is lost.) To redo an undone command, use Redo from the Edit menu or CTRL-Y. + +{{note|Since right now we don't need to do any actual editing to continue this Guided Tour, we suggest that you don't change the text of class PARENT but simply look up the menu entries described next, without actually selecting them. If you do make a change, voluntary or not, you should at the end of this editor discussion perform enough Undo commands to get the text of class PARENT back to its original state. }} + +To '''copy''', '''cut''' and '''paste''' use the corresponding entries in the Edit menu or the familiar keyboard shortcuts CTRL-C, CTRL-X and CTRL-V. + +When you edit text, it will be automatically '''indented''' according to standard Eiffel style rules. If you prefer to remain in charge of your own indenting, you can disable this facility through + +Tools --> Preferences --> Editor + +To indent a sequence of lines, select the lines, then use + +Edit --> Advanced --> Indent selection +You can also use the Tab key, but only if the selection consists of one or more entire lines; otherwise typing Tab will simply replace the selected text with a Tab character. Shift-Tab will similarly decrease indentation by one step. + +To '''comment out''' a sequence of lines, select them and use + +Edit --> Advanced --> Comment +or CTRL-K. Conversely, CTRL-Shift-K will uncomment. Also in the Edit --> Advanced menu are "set to upper case", with the keyboard shortcut CTRL-U, and to lower case, CTRL-Shift-U. + +Other useful facilities of the Edit --> Advanced menu are: +* Embed in "if", or CTRL-I, which will create a conditional instruction and include the selected instructions in it. +* Embed in "debug", CTRL-D, which will include the selected instructions in a debug ... end instruction, so that their execution becomes conditional on a Debug compilation option. + + +== Search and replace == + +The editor lets you search for text and replace occurrences, individually or globally. We assume you have seen a text search facility before, so we'll just emphasize some of the less obvious features. + +To start a search, make sure the [[Search Tool]] is active by clicking the Search button in the top toolbar (this one we'll let you find) or using the + +Edit --> Find + +menu entry. + +{{note|If you press CTRL-F in a tool you will get a quick search bar that quickly allows you to search for something in the current text.}} + +The [[Search Tool]] presents a number of self-explanatory options: + + + +[[Image:search-tool]] + +You can enter a term to replace your search term in the Replace with box. + +Having filled the two fields, you can elect to replace the last found occurrence, or all occurrences at once. + +The Search for field has an associated drop-down list, so that you can reuse a recently entered search string without retyping it. + + +==Let the editor do the typing== + +Particularly interesting are the editor's '''automatic completion''' facilities (often, we shorten the name to '''auto-completion'''). Well, particularly interesting for ''most'' people: maybe you like your editor to do the grunt work for you, or maybe you don't. In the latter case -- if you prefer to be in control of all the details -- don't worry: through + +Tools --> Preferences --> Editor +you can easily disable any facility that you don't like. The behavior described here is the default. + +The EiffelStudio Editor knows about Eiffel syntax and will recognize syntactic elements as you type them. It will color them according to standard conventions: basic elements in black, keywords in blue, comments in dark red. You can change these conventions through Preferences. + +If you start typing a control structure through its opening keyword, such as if, or from for a loop, the editor will automatically display the structure of the whole construct. Here for example is the result if you type the from followed by Return/Enter at the beginning of our example routine: + +[[Image:es gt auto complete from 01]] + +This has produced the structure of an Eiffel loop: from ... until ... loop ... end. You can then fill in the blanks with the appropriate expression and instructions. The generated lines start with the appropriate number of Tab characters to support the standard Eiffel indenting conventions. If you want a more compact style, follow the from with a space rather than Return. Typing if followed by Return or a space will similarly produce the outline of a conditional instruction. + +Also interesting is '''feature completion'''. Feature completion is activated by default, and it works at two levels: +* You can type the beginning of the name of a feature of the current class, then CTRL-SPACE to get possible completions. +* Once you have typed the name of a query (attribute or function), either all by yourself or aided by the previous completion technique, you can type a period to get the list of possible features to be applied, deduced from the list of features in the corresponding class (the type of the query). + +In both cases, if more than one completion is possible, you will get a menu of the possibilities. You can scroll through it with the up and down arrow keys, or the mouse, and select one through Enter or double-click. You can also or give up through the Escape key. + +Here for example is the menu you will see in the body of our example routine if you type io. , where io is the feature, coming from class ANY, that provides access to standard input and output facilities: + +[[Image:es gt auto complete feature 01|Feature auto-completion]] + +If only one completion is possible, no menu appears; the completion is selected. + +When a menu of possible completions is displayed, you can use the arrow keys to traverse the list. + +If you select a routine with arguments, auto-complete will show the arguments and their types, allowing you to provide your value for each argument. The figure below shows auto-completion of a routine with only one argument. + +[[Image:es gt auto complete argument 01|Auto-completion of arguments]] + +You can see that the argument is pre-selected and is of type STRING_8. As soon as you begin to type your substitution for the argument, the pre-selected argument definition is replaced with what you type. When you complete an argument, the Tab key will either pre-select the next argument (in the case of routines with multiple arguments), or place the cursor to the right of the right parenthesis that terminates the routine call (in the case of the last argument). + +Auto-completion will only work for queries that were present at the time of the last successful compilation. So if you add an attribute, say attr, to the current class, and do not recompile, typing a then CTRL-SPACE will not display attr. To make sure that it's included in completion proposals, save and recompile. (Remember, incremental compilation is fast in EiffelStudio, so there is nothing wrong in compiling early and often.) The same rule holds for features of ''other'' classes, those that will appear in proposed completions after a period. + +The features proposed for auto-completion include all features of the class: those declared in the class itself, or ''immediate'' features, and those ''inherited'' from proper ancestors, direct or indirect, with one exception: by default the list will not include features from the universal class ANY, which serves as ancestor to all classes and provides many features for comparison, copying, input-output, reflection etc. Including ANY's features would clutter all menus with too many features. So for example typing i followed by CTRL-SPACE will not suggest io among the possible completions. You can change this policy through Preferences. The policy does not apply to remote feature completion for an entity x declared of type ANY. In the case that you type x., auto-completion will produce the list of ANY's features. + + +==Using your own editor== + +You may have a favorite editor and prefer to use it, at least in some cases. The EiffelStudio incremental compilation mechanism, to be studied shortly, recognizes that files have been modified outside of EiffelStudio (by checking their time stamps) and will without any fuss take their modified versions into account. + +You can also call an outside editor on a class from within EiffelStudio. Just use + +File --> External editor +or the corresponding button in the top toolbar. + +This will call the editor of your choice. The default is Notepad on Windows and Vi on Unix and Linux. You can easily change this to any editor by entering the desired editor command in + +Tools --> Preferences --> General --> External editor command + + +In this command text you can use the two special notations $target and $line ; when EiffelStudio calls the selected command, it will replace any occurrence of $target by the name of the file where the current class resides, and $line by the line number at which the Editing Tool is currently scrolled. If you include one or both of these markers at the appropriate argument positions for the command, this will enable you -- assuming the editor supports the appropriate options -- to make sure it starts at exactly the right place. For example the default editor command under Unix is + +vi +$line $target + +meaning: start the Vi editor on the $target file, initially positioned at line $line (the + line_number command-line option of Vi directs it to start at line line_number ). + +If you start an external editor on a class, then exit the editor after possibly making changes, EiffelStudio will immediately update the class text in the Editing Tool. More generally, note that EiffelStudio will detect changes made separately on the same class, and warn you of possible conflicts. + +Several important text editors from various providers have '''Eiffel modes''', which support the syntax-directed editing of Eiffel texts. They include: +* '''Vim''', for Vi iMproved, an extension of Vi available on both Unix/Linux and Windows -- see www.vim.org +* '''Emacs''' -- see www.emacs.org. +* '''Editeur''', a Windows syntax highlighting editor -- see www.studioware.com. + + + diff --git a/documentation/18.11/eiffelstudio/Tutorials/retargeting-through-pick-and-drop.wiki b/documentation/18.11/eiffelstudio/Tutorials/retargeting-through-pick-and-drop.wiki new file mode 100644 index 00000000..aa048315 --- /dev/null +++ b/documentation/18.11/eiffelstudio/Tutorials/retargeting-through-pick-and-drop.wiki @@ -0,0 +1,164 @@ +[[Property:title|Retargeting Through Pick-and-Drop]] +[[Property:weight|-5]] +[[Property:uuid|a3789781-153b-7f4d-bb94-4bdf8923fb56]] + +You now know quite a few ways of re-targeting a Development Window to a "development object" -- a class or a feature -- but haven't yet seen one of the most important: "Pick-and-Drop", which lets you pick a development object that you have spotted anywhere in the display, and retarget the current tool, or another, to it. + + +==Trying Pick-and-Drop== + +We restart from the last state, with a Development Window target to feature forth of class LIST. The next figure shows the whole window; it should look like what you see as a result of the last operations. We'll use the Descendant versions view of the Feature Tab. + +If for some reason the window doesn't look like the next figure, it's easy to reconstruct it: make sure both the Cluster tree and the Feature tree are visible (if not, make visible using the instructions given in [[Viewing Classes#Making some room|Viewing Classes]]); target the tool to class LIST; target further to its feature forth by clicking that feature name in the Features tool's roll of the features of LIST; make sure both the top-left Editing tool and the bottom-left Feature tool are visible; in the Feature tool, select the Descendant versions format. + +[[Image:es gt development window feature descendants 01|Descendant versions of forth]] + +In the Feature tool near the bottom, there is an entry that reads + + MULTI_ARRAY_LIST [G] forth + + +referring to the version of feature forth in class MULTI_ARRAY_LIST. Let's assume you want to see what that version actually is. It suffices to retarget the tool to it. Of course you could type or copy-paste the class name MULTI_ARRAY_LIST in the Class field at the top of the window, and the feature name forth in the adjacent Feature field. But there is an easier way; after all, you have just seen a reference to the feature, through its name as it appears in the Descendant version format, so it's natural to use it directly from the graphical interface. + +As we've seen before, you could control-right-click on the feature name at the place where it appears; this would create a new tab and retarget the Development Window to forth from MULTI_ARRAY_LIST. But you might not necessarily want a new tab. Instead you can use Pick-and-Drop to retarget the current window. + +Here is how it works. Position the cursor on the desired feature reference: the word forth in the line forth MULTI_ARRAY_LIST. Right-click, that is to say click the rightmost mouse button and then release it. You will see a context menu that looks like the figure below. + + +[[Image:es gt pnd context menu 01]] + + +The item we want to choose from this menu is "Pick Feature 'forth'". So do that now, by left-clicking over the item. + +Now move the mouse around some, but ''without pressing any button'': + + +[[Image:es gt picked forth 01]] + + +The cursor has changed into a new shape, a cross representing the type of development object that you have picked, a feature. For a class, as you may have guessed, it would be a small ellipse ("bubble"). Each kind of development object that you may create and manipulate during your work with EiffelStudio has its distinctive icon. When you '''pick''' an item, you'll notice that the item's icon stays connected to its origin by a dotted line that stretches or shrinks as you move the icon around. + +So, now you have '''picked''' the feature forth. You can '''drop''' it at any appropriate place to retarget the corresponding tool. Move your cursor (and the feature icon for forth) over the Editing tool now. + +To '''drop''', just '''right-click''' again. (That is to say, as before, press the rightmost mouse button and release it immediately.) Drop the icon representing {MULTI_ARRAY_LIST}.forth in the Editing tool. + +This retargets the Development Window to the chosen feature, forth from the class MULTI_ARRAY_LIST. The Feature tool (assuming the Link Context tool option is selected), keeps its current view ( Descendant versions in the Feature tool) and now shows descendants of {MULTI_ARRAY_LIST}.forth. + + +[[Image:es gt development window multi array list forth 01|Retargeted to {MULTI_ARRAY_LIST}.forth]] + + +==Bypassing the context menu== + +In the example above, when you right-clicked over an item, you were presented with a "context" menu, containing choices applicable for the item you clicked. We chose to pick the item. It's possible that if you use pick-and-drop quite a bit that you might rather not see the context menu each time you right click. You can make this happen in a couple of ways. First, if you use the context menu most of the time, but you want to pick directly at other times, you can '''shift-right-click''' to bypass the context menu and pick the item immediately. + +The other option is used if you want a right-click to pick by default, and only use the context menu occasionally. To make this happen, you need to change the '''Pick and drop (pnd) mode''' [[EiffelStudio Preferences|EiffelStudio preference]]. You can change this preference by following the menu path: + +Tools --> Preferences... + +When the preferences window opens, expand the '''General''' preferences folder. You'll see '''Pick and drop (pnd) mode''' is set to '''False''' by default. If you wish to change the behavior, then check the box and the value will change to '''True'''. Then you can exit the preferences window. + +With '''Pick and drop (pnd) mode''' set to '''True''', you will always get a pick when you right-click over an development object. If you occasionally wish to use the context menu, then you would shift-right-click, which would cause the context menu to appear. + + +==How Pick-and-Drop works== + + +The Pick-and-Drop mechanism is very simple. It consists of three steps: +* '''Pick''' step: find the development object and pick it: either through the context menu, or by shift-right-click, or by right-click, depending upon EiffelStudio's Pick and Drop Mode. +* '''Move''' step: move the mouse to the desired drop point, without pressing any button. +* '''Drop''' step: right-click (again releasing the button immediately) at the drop position. + +During the Move step, you can at any time '''cancel the whole operation''' simply through a '''left-click'''. + +The Move step is actually optional: if the current position is a valid drop target, as explained next, you can drop immediately after the pick without moving the mouse. + + +==Pebbles, holes, drop targets and type compatibility== + +The Pick-and-Drop mechanism relies on the metaphor of '''pebbles and holes'''. When you pick a development object, the cursor changes into a '''pebble''' whose shape represents the type of the development object: cluster, class, feature, run-time object ... You may then drop it into a '''hole''', which can be a window, a tree view entry, or a hole-shaped icon. This performs the appropriate action such as retargeting a tool. + +In the same way that Eiffel is a typed object-oriented language, the Pick-and-Drop mechanism is typed: you can only drop a pebble into a compatible hole. For example you may drop a class pebble into a Development Window, to retarget it to the chosen class. If you have picked a development object and have moved its pebble over an area which is an unacceptable place to drop it, you will notice that the pebble takes on its "disabled" form. An enabled class pebble ([[Image:context-class-cursor]]), for example, would become a disabled class pebble ([[Image:context-disabled-class-cursor]]) for the time that it's hovering over unfriendly territory. + +In Eiffel, type compatibility is not necessarily type identity, but is governed by ''conformance'', based on inheritance and polymorphism: to an entity of type POLYGON, you may assign not only an expression of that same type, but also one of type RECTANGLE, if class RECTANGLE inherits from -- conforms to -- class POLYGON. Similarly, EiffelStudio considers that the development type "feature" conforms to "class"; this means you may drop a feature into a Development Window targeted to a class; this will retarget the tool to the feature's class and the feature itself, with the text of the class scrolled to the position of the feature. + + +==Clickable formats== + +A good deal of the power of Pick-and-Drop comes from its connection with the various views of the Class and Feature tools ... and the Diagram tool which we will see later. As was mentioned when we saw these views, all the feature and class names or other graphical representations that appear in these views are '''clickable''' ; this means that you can select any of them as the source of a Pick-and-Drop. + +As a result, you can quickly traverse a system and get to its essential properties by displaying the information of a class in any of the many available views -- the contract and flat contract of a class, its routines, its attributes, its clients, its ancestors, the ancestor and descendant versions of a feature, and so on -- then wherever you see a feature or class name follow the corresponding link. This '''proximity-based''' form of browsing, combined with the other techniques seen earlier, provides considerable help when you are dealing with a large, possibly complex system, and want to master its intricacies, be it for development, testing, debugging, maintenance or revision. + +Other places where you can pick development objects include the icons representing classes and features in the Groups tool, Feature tool, and Favorites tool. + + +==Semantic consistency== + +An important property of the pick-and-drop mechanism, shared by its cousin the right-click mechanism, has already been mentioned in this chapter: semantic consistency, which guarantees that the operations you can perform on a class, such as pick-and-drop, only depend on the ''development object'' to which you are applying the operation. It doesn't matter where you picked the object -- in any development tool under any view -- and in what form: textual, as a class or feature name; graphical representation, as a class bubble in the Diagram tool; or an icon, for example in the Groups tool, Features tool, Favorites tool. + +The pebble that you see during the Move step of Pick-and-Drop represents the underlying development object -- such as a class or a feature -- regardless of how you got to it. + + +==Behind the Pick-and-Drop conventions== + +Pick-and-Drop works differently from the usual Drag-and-Drop present on many computing platforms. The usual Drag-and-Drop retains a role within EiffelStudio (to move class bubbles around in the Diagram view) and you may of course have to use it for operating system functions such as copying files. But the key EiffelStudio operation is Pick-and-Drop. This technique is motivated by careful consideration of ergonomics and user comfort. In particular: +* Pick-and-Drop is much less stressful. Drag-and-Drop requires you to maintain pressure throughout the move, being careful not to drop on the wrong place. With Pick-and-Drop there is no stress: you click and release; get a drop from your coffee cup if you like (optional step); move the cursor with no pressure from your fingers or on your mind; make sure, at your leisure, to find the right drop place; and right-click again on it. At the end of the day, after many such operations, the stress reduction can make a real difference. +* With Drag-and-Drop, it's easy to lessen the pressure involuntarily and drop on the wrong place. The consequences can be damaging, especially since in such a case you may well not know where you dropped the element; after all, that wasn't intentional. It is possible, for example, to lose files that way. With Pick-and-Drop this is much less likely to happen. +* Pick-and-Drop makes it easy to cancel the operation if you change your mind: just left-click anywhere. With Drag-and-Drop you have to find an invalid place to drop; this may be difficult, or even impossible! (Sometimes pressing the Escape key works, but this is not universal.) + +If you are new to EiffelStudio you may find Pick-and-Drop surprising at first. We trust you will join the ranks of EiffelStudio users who consistently rate it among the most convenient features of the environment. + + +==Pick-and-Drop miscellany== + +When you start repeatedly retargeting the Class and Feature tools -- especially when set to "unlinked" behavior -- you will notice the following properties: +* In most cases, pick-and-dropping a ''class'' into the lower pane where the Class and Feature tools are docked will switch the view to the Class tool, and pick-and-dropping a feature switches to the Feature tool. This is true even if the pane is currently set to the Outputs tool or another unrelated tool. +* The view displayed in each case -- for example Ancestors for the ''Class'' tool and Flat for the ''Feature'' tool -- is default view for the corresponding tool. + +You know by now that if you pick an object and drop in into the Editing tool it will retarget the Development Window and will evict the previous occupant of the current Editing tool tab and display the dropped object in that tab. But, you can also use Pick-and-Drop to create new tabs in the Editing tool. Instead of dropping into a tab, drop the pebble instead in the tab bar of the Editing tool next to existing tabs, or on the "New Tab" icon ([[Image:new-document-icon]]) in the Standard buttons toolbar. + + +==The many paths to retargeting== + +As a conclusion to this review of Pick-and-Drop let's recapitulate the various ways we've seen for retargeting a whole Development Window or a tool to a class: +{| border="2" +|- +| '''How to retarget''' +| '''Same window/tab/tool, or new?''' +| '''Where described''' +|- +| Type class name, then Enter, in class field at top-left of tool +| Same +| [[Starting to Browse#Retargeting by name|"Retargeting by name" in the chapter "Starting To Browse".]] +|- +| Choose class in Cluster tree +| Same +| [[Starting to Browse#Retargeting from the Groups tool|"Retargeting from the Groups tool" in the chapter "Starting To Browse". ]] +|- +| Choose class in Favorites +| Same +| [[Starting to Browse#Adding to Favorites|"Adding to Favorites" in the chapter "Starting To Browse".]] +|- +| "Back" button +| Same +| [[Starting to Browse#Moving back and forth|"Moving back and forth" in the chapter "Starting To Browse".]] +|- +| "Forth" button +| Same +| [[Starting to Browse#Moving back and forth|"Moving back and forth" in the chapter "Starting To Browse".]] +|- +| Pick class from history list +| Same +| [[Starting to Browse#The Target History|"The Target History" in the chapter "Starting To Browse".]] +|- +| Pick-and-drop +| Existing or new (depending upon drop target) +| [[Retargeting Through Pick-and-Drop|Chapter "Retargeting Through Pick-and-Drop".]] +|- +| Control-right-click on class name or graphical representation found in any tool +| New tab +| [[Starting to Browse|"Starting a new tool" in the chapter "Starting To Browse".]] +|} + + + diff --git a/documentation/18.11/eiffelstudio/Tutorials/starting-browse.wiki b/documentation/18.11/eiffelstudio/Tutorials/starting-browse.wiki new file mode 100644 index 00000000..f0088c4f --- /dev/null +++ b/documentation/18.11/eiffelstudio/Tutorials/starting-browse.wiki @@ -0,0 +1,179 @@ +[[Property:title|Starting To Browse]] +[[Property:weight|-10]] +[[Property:uuid|cb6c2e52-d238-9b55-0b78-ab3af9568550]] +It was important to take a look at how EiffelStudio stores your project, but unless your idea of fun is to poke around directories to look at compiler-generated files that's not really the exciting part yet. Among the most innovative aspects of EiffelStudio is a unique set of facilities to "browse" through a software system. + + +==Browsing style== + +Browsing -- traversing the structure -- is particularly important in object-oriented development and especially in Eiffel because of the speed at which you can construct sophisticated class structures, making use of inheritance, genericity, the client relation and information hiding, and subjecting features to all kinds of adaptations -- renaming, redefinition, undefinition, effecting -- that are key to the expressive power of the software, but call for smart tools to keep track of what's going on. EiffelStudio's tools are second to none. Among their key properties: +* You can choose many different ways of browsing: sometimes you know the ''name'' of a class or feature, and will get to it just by typing it; sometimes you want to traverse the system through its cluster-subcluster ''structure''; often, you see a reference to element (class or feature) in the text of another element, and just want to get to it by following that reference, like a ''hyperlink''. You'll be able to use all these techniques, and alternate freely between them. +* The browsing facilities are always available. There is no "browser" in EiffelStudio; you just browse when you want to, by looking at the information you need. You can do this while editing, debugging, or performing any other of the analysis, design, implementation, extension and maintenance tasks of system construction. +* Although classes are stored in files and clusters in directories, you can for the most part forget about the file system. Unlike most environments, which let you manipulate files containing software texts, EiffelStudio lets you concentrate on your development objects -- the units that make sense for you: features, classes, clusters, systems. You think in terms of those conceptual units, and don't have to worry about where they are stored. Most of the time, you'll just forget about files and directories. +* You can produce many views of the development objects. For a class, you may see the full text, the interface only, the inheritance structure, the clients, the features, and many other views. You can even display graphical views along with textual ones. All these are fully browsable; you can go from one to the other as you please. + + +==A Development Window== + +Let's see how this works. First, take a look at the EiffelStudio window: + + +[[Image:es gt a development window 01]] + + +{{note|If some parts are too small, just resize the window to arrive at something like what's on the figure. As soon as you have resized it, EiffelStudio will remember that size, and start up in the next session with the size you've set.}} + +You can see that the bulk of the Development Window is divided into three primary panes or areas. The [[EiffelStudio Editor|'''Editing''']] tool is the large pane on the top left. The Editing tool supports a tabbed display of the elements in your system ... usually that's class text, and it's in the Editing tool that you make changes to your software. In the image above, it is targeted to the root cluster of our example system. We'll target the Editing tool to a class in a moment. The other two areas support multiple tools, also using a tabbed display. In the area below the Editing tool you see the '''Outputs''' tool currently selected. As you can see there are other tools represented by the tabs at the bottom of the same area. Likewise, the area to the right of the Editing tool shows the '''Groups''' tool selected, but in that area are also tabs for other tools. You will find that the layout of the Development Window is very flexible. Different tools can be made visible or hidden, panes can be removed, new panes created, tools can be docked in these areas or viewed as standalone windows. The appearance of EiffelStudio can be tailored to your needs and preferences. + +So far we have talked about "the EiffelStudio window", but in fact that's not correct. What you see is one '''Development Window''', of which you can have as many as you wish. Some people prefer to use a single development tool, avoiding screen clutter; others don't think twice about having lots of windows, taking the "desktop metaphor" to its full conclusion (some non-computer desktops are quite cluttered). There are many ways to start a new Development Window; for example if you look at the entries in the File menu at the top left -- don't select any of these entries yet, just look -- you'll see, among others, New window, which would create a new Development Window. + +Whether you have one Development Window or many, each may have as its '''target''' an element of the system: system, cluster, class (the most common case), feature, run-time object. This simply means that the tool displays information about that element. + + +==Retargeting by name== + +In our first look at the Development Window, the Editing tool was empty. To target it to a specific class, you can just type the class name -- if you know it -- into the '''Class field''' at the top left: + + +[[Image:es gt class field 01]] + + +Let's use one of the most basic classes, STRING_32 from the Kernel Library of EiffelBase. Bring the cursor to the Class Field, click to make it active, type string_32 (or STRING_32 ) and the Enter key. As shown on the next figure, this causes a new tab to be created in the Editing tool and retargets the Development Window to class STRING_32. Note that you didn't have to worry about where the class resides in the files of your computer. Also, it doesn't matter, when you enter the name into the field, whether you use lower or upper case, or some mix; EiffelStudio will show the name in all upper case because that is the standard Eiffel convention for class names. + + +[[Image:es gt string 01]] + + +Retargeting by name is only one way to retarget a Development Window. There are other ways of retargeting that are useful at different times. Let's look at some of them. + + +==Retargeting from the Groups tool== + +Your first browsing action used a class of which you knew the name, STRING. What if you don't know what's in the system and want to explore it? Among other techniques, you can let the Groups tool, guide you through the classes that are available to your system. + +An Eiffel system, as you know, is organized into clusters and libraries (and assemblies on some .NET systems). Additionally, clusters can be structured hierarchically into subclusters. You can expand the clusters and libraries nodes in the Groups tool (by clicking the little + signs to the left of the node icons) in order to see the classes. Try it, and what you see should look about like the following figure: + +[[Image:es gt groups tool 01]] + + +You'll see one cluster: root_cluster, containing the few classes specific to our Guided Tour system. Under libraries you'll see base which provides the classes of the EiffelBase library, and base_precompile which does not provide any classes directly (precompiles are present to speed up compilation time by precompiling classes, so base_precompile is just a precompiled version of the contents of the EiffelBase library). Let's go into base, Eiffel Software's open-source library of fundamental reusable mechanisms. + +The most extensive subcluster of the EiffelBase library is structures, which contains implementations of major data structures and algorithms of computing science. Expand structures to see its own subclusters: + +[[Image:es gt groups tool 02]] + +{{note|If you initially don't see as many details as shown on this figure, you may get them by resizing the window, moving the vertical pane boundary, and/or scrolling.}} + +The EiffelBase Data Structure library and its subclusters are described in the book [http://www.eiffel.com/services/training/books.html Reusable Software]. Let's go to one of the most frequently used subclusters, list, containing implementations of list structures. Expand the subcluster list. This time, since list is a terminal cluster, it's not subclusters you'll see, but '''classes''', identified by small ellipses ([[Image:class-normal-icon]]): + +[[Image:es gt groups tool 03]] + +The ellipse, or "bubble", is indeed throughout EiffelStudio, as in the Business Object Notation (BON, the underlying graphical convention), the distinctive symbol for classes. You will notice that instead of the bubble, some classes are represented by what we call the "expanded" icon ([[Image:expanded-normal-icon]] ). These are still Eiffel classes. They are represented this way to show that they are marked as [[I2E: Types|expanded]]. Still other classes have a modified bubble ( [[Image:class-deferred-icon]] ) indicating that they are marked as [[ET: Inheritance#Deferred features and classes|deferred]]. + +Our second technique for retargeting a Development Window to a class (other than typing the class name as we did before) is to click the class in the Groups tool. Do this now: click LIST in the tree. It doesn't matter whether you click on the class name or the adjacent bubble. This retargets the tool to class LIST. + +[[Image:es gt Development Window targeted to list 01]] + + +As the tool is now targeted to LIST, the Class Field at the top left now shows the name of that class, exactly as if we had typed that name, the way we did with STRING_32 in the previous method of retargeting. + + +==Moving back and forth== + +Here now is a third way to retarget. Towards the top-left part of the Development Window there are Back and Forth buttons, which will enable you to revisit classes already seen during the current session: + +[[Image:es gt go back 01]] + +Click the Back button. This retargets the tool to the class you visited previously: STRING_32. The Forth button, immediately to the right of Back, becomes active. Click it to retarget back to LIST. + +Note that all buttons of the interface have a "tooltip" as shown in the figure above. if you move the cursor on a button, '''without clicking''', and wait a second or so, a small message comes up, explaining the purpose of the button. Also, if there is an associated keyboard shortcut, it will be displayed in the tooltip. + + +==The Target History== + +As a fourth way to retarget -- there are more, and after this one we'll stop counting -- you can also use the Target History menu, which you can bring up through the little arrow to the right of the Class Field: + +[[Image:es gt target history 01]] + +If you click this arrow -- the little black triangle -- you will see a menu of all your recent targets. Doing this now will only show the two classes visited so far, STRING_32 and LIST, but later on there will be more entries. By default EiffelStudio remembers 20 history entries; this is one of the settings you can change later if you wish, through the menu path: + +Tools --> Preferences + +But, let's don't do that now. + + +==Adding to Favorites== + +If you find yourself often needing to examine a particular class, you can add it to your [[Favorites tool|Favorites]], much like adding an interesting page's web link to the bookmarks of a Web browser. + +It's easy to add the current target -- currently, LIST -- to your Favorites. Do it now by following the menu path: + +Favorites --> Add to Favorites + + +[[Image:es gt add to favorites 01]] + +Now display the favorites; one way is to go back to that same Favorites menu: + +Favorites --> Favorites + +The Favorites tool appears as a tab in the same area as the Groups tool: + +[[Image:es gt favorites 01]] + +This gives us one more way to retarget a Development Window: click a class in the Favorites tool. ''Two'' ways actually, because once you add a class to Favorites, it appears in the Favorites menu and you can select it by choosing its menu item. + +[[Image:es gt list added to favorites 01]] + +Right now we don't need the Favorites tool, so you can get rid of it by clicking the little Close icon at the top right of the Favorites pane: + +[[Image:es gt close favorites 01]] + + +After you close the Favorites tool, you may see some tool other than the Groups tool that we had been using. If this is the case, click on the Groups tool's tab at the bottom of the pane to make the library classes visible again. + + +==Using additional Editing tool tabs== + +So far, even though we've targeted to the Development Window to different classes, we've only used one Editor tab. But it is helpful sometimes to have views of several classes handy in multiple editor tabs. Its easy enough to create a new tab at the time that you target the Development Window to a new class. For example, you should see the class CHAIN in the Groups tool's view of the the list subcluster of structures (the same place we found class LIST. Instead of clicking on CHAIN the way we did LIST, this time '''control-right-click''' on CHAIN, that is to say, click with the rightmost button of the mouse while holding the CONTROL key on the keyboard. This creates a new tab for CHAIN and retargets the Development Window to that class, while sliding the existing tab for class LIST to the right a bit. + + +[[Image:es gt development window multiple tabs 01]] + + +You can click on any of the tabs and the Development Window will be retargeted to the class associated with the tab. Each tab has a "Close" button on it, so you can close tabs you no longer need. + +So, for now, close the tab with the class CHAIN and leave just the one tab with class LIST. + +==Using additional Development Windows== + +With all the techniques seen so far, you were able to retarget the current the Development Window to a new class. And that may be all you'll ever need. But, as noted earlier, you may also wish to have two or more Development Windows active simultaneously. + +To create a new Development Window, follow the menu path: + +File --> New Window + +This will create a new Development Window with a title bar that reads "Empty development tool #1" because the window is (as yet) untargeted. You can also create a new Development Window by using the keyboard accelerator: CTRL-N. + +You can close a Development Window either by clicking its close button in the corner of the window, or by following the menu path: + +File --> Close Window + + +Be careful not to try to use: + + File --> Exit + +to close a single window. This menu command will exit the entire EiffelStudio development environment, closing all windows. + +If, during a session, you end up with a number of windows active and want to see an active index to them, you can invoke the [[Windows tool|active windows tool]] by following the menu path: + +View--> Tools--> Active windows + + +[[Image:es gt active windows tool 01]] + + + + + diff --git a/documentation/18.11/eiffelstudio/Tutorials/starting-eiffelstudio-and-opening-project.wiki b/documentation/18.11/eiffelstudio/Tutorials/starting-eiffelstudio-and-opening-project.wiki new file mode 100644 index 00000000..3adf479f --- /dev/null +++ b/documentation/18.11/eiffelstudio/Tutorials/starting-eiffelstudio-and-opening-project.wiki @@ -0,0 +1,29 @@ +[[Property:title|Starting EiffelStudio and Opening a Project]] +[[Property:weight|-13]] +[[Property:uuid|676cf329-5640-69c4-d10b-b56fcd3f2ff9]] +In the rest of this Tour YOURDIR denotes the directory where the example resides (the original, $ISE_EIFFEL/examples/studio/tour , or a copy). Launching will use the operating system's mechanism for starting a program, so we look separately at Windows and at Unix/OpenVMS. + + +==Launching EiffelStudio under Window== + +On Windows, you can launch EiffelStudio from the Start Menu by following the path: + +Start --> Programs --> EiffelStudio Version --> EiffelStudio + + +where Version is the version number, e.g. 6.5. Alternatively, you can double-click the icon that the installation procedure will have added to your desktop (if you have selected that option during installation). + +If this is the first time you are using EiffelStudio, you may get a dialog asking for an unlock code or inviting you to register the product. See [[Software Installation for EiffelStudio|your platform installation instructions]] for registration information. + + +==Launching EiffelStudio under Unix or OpenVMS== + +To launch EiffelStudio on Unix or OpenVMS, change directory to YOURDIR and, from the command line, type + +estudio + + +In general you can start EiffelStudio from any directory, but to make things simple for this Tour '''please make sure''' indeed to execute the estudio command from YOURDIR. (This will allow us to use relative rather than absolute names for some of the files involved.) + + + diff --git a/documentation/18.11/eiffelstudio/Tutorials/using-automatic-class-licensing.wiki b/documentation/18.11/eiffelstudio/Tutorials/using-automatic-class-licensing.wiki new file mode 100644 index 00000000..77b9b1a2 --- /dev/null +++ b/documentation/18.11/eiffelstudio/Tutorials/using-automatic-class-licensing.wiki @@ -0,0 +1,137 @@ +[[Property:title|Using automatic class licensing]] +[[Property:weight|2]] +[[Property:uuid|3abb5fc8-b5e5-2d25-fcac-72929abba0a7]] +You can use EiffelStudio to include a license text in each of your classes automatically. The automatic class licensing facility is flexible so that you can use various strategies to retrieve the license text used. + +When you save the text of a class file in EiffelStudio, the automatic licensing facility searches for an appropriate license text file to use. If such a file is found, then EiffelStudio includes the contents of that file as an ending note part in your class. Here's the text of a class that includes an Eiffel Software license: + + +class + APPLICATION + +inherit + ARGUMENTS + +create + make + +feature {NONE} -- Initialization + + make + -- Run application. + do + print ("Hello Eiffel World!%N") + end + +note + copyright: "Copyright (c) 1984-2010, Eiffel Software" + copying: "[ + Duplication and distribution prohibited. May be used only with + Eiffel Software products, under terms of user license. + Contact Eiffel Software for any other use. + ]" + source: "[ + Eiffel Software + 5949 Hollister Ave., Goleta, CA 93117 USA + Telephone 805-685-1006, Fax 805-685-6869 + ]" +end + + + +==License file format== + +License text should appear in a text file with the file type ".lic". The text should contain the note clause which includes the license text and nothing more. EiffelStudio will parse the text and invalid instances of license text will not be merged into the target class. + +The following text is the content of the license text file which was used to annotate the class shown above: + + +${NOTE_KEYWORD} + copyright: "Copyright (c) 1984-${YEAR}, Eiffel Software" + copying: "[ + Duplication and distribution prohibited. May be used only with + Eiffel Software products, under terms of user license. + Contact Eiffel Software for any other use. + ]" + source: "[ + Eiffel Software + 5949 Hollister Ave., Goleta, CA 93117 USA + Telephone 805-685-1006, Fax 805-685-6869 + ]" + + +Notice that a variable is used for the note keyword (to support the language keyword change from indexing to note). Also a variable for the current year is used in the copyright notice. + + +==Location of license text files== + +Where you keep your license text files depends upon which method you use to have EiffelStudio retrieve the license text from the files. Generally, license text is retrieved from files in one of three places: + +===Your project directory=== +This is the directory that contains your project configuration file, the ".ecf" file). + +[[Image:Automatic class license project directory]] + +===The Eiffel Software license template directory=== +This directory is located at: $ISE_EIFFEL/studio/templates/licenses + +[[Image:Automatic class license Eiffel Software directory]] + +===The Eiffel user files license template directory=== +This directory is located at: $ISE_USER_FILES/studio/templates/licenses + +[[Image:Automatic class license Eiffel user files directory]] + + +==Methods of retrieval== + +===Designating a license in class source code=== + +You can put a note in the source code of a class which will cause EiffelStudio to search for a corresponding license file and then include the license text from that file. Here's what such a note might look like: + + +note + license_name: "OurLicense" + + +The license_name term should be placed in the top note clause of the class. (If you include in the bottom note clause, the license_name term itself will be removed when the class license gets replaced.) + +In this case, EiffelStudio will search for the file `OurLicense.lic'. It will look first in the '''Eiffel user files license template directory''', then in the '''Eiffel Software license template directory'''. + +If you look in the '''Eiffel Software license template directory''' (or in the image of that directory shown above), you will see several standard license files that are used by Eiffel Software, for example, forum2.lic and eiffelsoftware. Also included is default.lic, which we'll examine [[#The default license|later]]. + +You should create your customized license text files in the '''Eiffel user files license template directory''', or in a local project directory as described below. + + +===Using a local project license file=== + +If you use the same license for a particular project, or set of related projects, you can keep the license file in the project directory along with your project ( .ecf ) file. In this case EiffelStudio will include the license text from that license file in each class in the project. + +This method has the advantage that it is not necessary to put the license_name term in the source code of classes. + +The license text file should be named in one of two ways: + +:# The .lic file name corresponds to the project name (e.g., my_project.lic for my_project.ecf) +:# The license text file is named license.lic + +The second option is convenient if you have a project, a library for instance, that has multiple .ecf files for different purposes. + +Even if the license text you want to use is in one of the license template directories, you can use this local method to retrieve that text without including a license_name term in the source code for each class. You do this by building a local license text file and include in it only a reference to the appropriate license name. + +For example, suppose that the our license text is in the file OurLicense.lic in the '''Eiffel user files license template directory'''. To include the license text in the classes of our_project, the our_project.lic (or license.lic) file would contain this reference: + + + reference:OurLicense + + + +===The default license=== + +As mentioned earlier, the file default.lic exists in the '''Eiffel Software license template directory'''. This file is empty ... and you should probably leave it that way. + +The license text in default.lic is added to a class when no license_name term is found in the source code and no appropriate license text file exists in the project directory. So, because the default.lic file is empty, no license text is added to classes by default. + +However, if you would like to set up a different default license text behavior, you can do so. Just create a default.lic file in the '''Eiffel user files license template directory''', and whenever license text is not found by some other method, the text from your customized default.lic will be included. + + + diff --git a/documentation/18.11/eiffelstudio/Tutorials/using-autotest/create-manual-test.wiki b/documentation/18.11/eiffelstudio/Tutorials/using-autotest/create-manual-test.wiki new file mode 100644 index 00000000..ff00d6bc --- /dev/null +++ b/documentation/18.11/eiffelstudio/Tutorials/using-autotest/create-manual-test.wiki @@ -0,0 +1,323 @@ +[[Property:title|Create a manual test]] +[[Property:weight|2]] +[[Property:uuid|32273F6B-AA84-475F-86B8-143F212FB40E]] +==A system to test== + +For developing our manual test, let's use a simple system that contains a class modeling bank accounts. Here are two classes that will make up our system. The first, APPLICATION will be the root class of our system. APPLICATION really only serves to declare an attribute of type BANK_ACCOUNT, which is the class we will write a test against. APPLICATION looks like this: + + +class + APPLICATION + +inherit + ARGUMENTS + +create + make + +feature {NONE} -- Initialization + + make + -- Run application. + do + create my_account + end + + my_account: BANK_ACCOUNT + +end + + + +And here's the class BANK_ACCOUNT: + + +class + BANK_ACCOUNT +inherit + ANY + redefine + default_create + end +feature + default_create + do + balance := 0 + end + + balance: INTEGER + + deposit (an_amount: INTEGER) + -- Deposit `an_amount'. + require + amount_large_enough: an_amount > 0 + do + ensure + balance_increased: balance > old balance + deposited: balance = old balance + an_amount + end + + withdraw (an_amount: INTEGER) + -- Withdraw `an_amount'. + require + amount_large_enough: an_amount > 0 + amount_valid: balance >= an_amount + do + balance := balance - an_amount + ensure + balance_decreased: balance < old balance + withdrawn: balance = old balance + an_amount + end + +invariant + balance_not_negative: balance >= 0 +end + + +You shouldn't let it worry you if you've noticed that the class BANK_ACCOUNT contains some flaws. We'll deal with these later. + +If you want to work along with this tutorial, you should be able to copy the text of each these classes from this page and paste it into the EiffelStudio editor pane. Build a system using these two classes, and {APPLICATION}.make as the root. + + +{{note|If you are using EiffelStudio version 6.3, there two things you will need to do to prepare your system for use with AutoTest. Both of these are done from the [[EiffelStudio: Project settings window]].
1) Set your project to be a console application in the [[Advanced options]].
2) Set a value of False for the Recursive attribute of your project cluster in [[Group options]].}} + +==Getting to the AutoTest interface== + +If the AutoTest interface is not on a tab next to Clusters, Features, and Favorites, you can invoke it by following the menu path: + +View --> Tools --> AutoTest + +Depending upon your version and platform, the AutoTest interface should look about like this: + + +[[Image:AutoTest empty tool 01]] + + +==Creating a new test== + +To begin the process of creating a new test, click the Create New Test button ( [[Image:create new tests]] ) on the interface's tool bar. When you click this button, by default AutoTest will set you up to create a new Manual test. To choose a different test type, click the small triangle to the right of the Create New Test button and you'll be presented with a drop-down menu of choices: + + +[[Image:AutoTest create new test|Create new test drop-down menu]] + + +For now, let's select Create Manual Test. + +If this is the first time you've used the testing tool for this project, it is likely that you will be presented with a dialog box asking if you want to add the testing library classes to your project and recompile: + + +[[Image:AutoTest add testing libraries dialog]] + +You want EiffelStudio to do this before launching the wizard so, click "Yes". In a moment, your system will have recompiled with the testing library classes available. Remember that you won't need to interact much with the testing classes, but AutoTest uses them, so they need to be available. As long as the testing classes stay available, you should not see this dialog again for the current project. + + +==The Manual Test Pane== + +After the compile completes, then the first pane of the New Eiffel Test Wizard appears. It's the Manual Test pane and should look like this: + + +[[Image:AutoTest Manual Test pane]] + + +Here we will name our test. Let's say that we plan to write this test against the feature {BANK_ACCOUNT}.deposit. We'll give this test the name test_deposit_01. The name uses an ad hoc naming convention for tests. You can use this, or develop your own. The prefix test_ comes before the feature name it will test, and the suffix _01 follows, so that we have a framework for adding more tests against deposit. Again, you can choose any naming scheme that makes sense to you. You may want to try to describe the test in its name. For example, test_deposit_very_large_amount. + +We're ready to click '''Next''', but before we do, let's look at the check boxes on this wizard pane. The two check boxes labeled '''Redefine `on_prepare`''' and '''Redefine `on_clean`''' have to do with the way that tests are run. + +AutoTest runs each test as a three step process: +# Preparation +# Execution +# Clean up + +There are features in class EQA_TEST_SET named prepare and clean which accomplish steps 1 and 3 above. These features are frozen, therefore you cannot redefine them in a test class (i.e., a descendant of EQA_TEST_SET) However the class does provide features that can be redefined so that you can include custom behavior before and/or after the execution of a test. These features are on_prepare and on_clean. So if you check one of these boxes, then the test class that is built for you will include a redefined feature ready for you to implement. In this simple example, we'll leave both boxes unchecked. + + +{{note|The check box labeled '''System level test''' is displayed here as not sensitive. This box is reserved for future system level testing capability in AutoTest, so for versions including 7.0, you can ignore it. }} + + +Another thing to notice before we click '''Next''', is that at this point we could click '''Launch'''. '''Launch''' will immediately try to create the test with the information it has available. The idea is that if you are creating several similar tests, you can change the test routine name and leave the rest of the information as you had entered it on a previous test. This keeps you from having to traverse the wizard panes entering the same information repeatedly. + +But in our case, we need to use the subsequent wizard panes, so let's click '''Next''', to go to the next one. + + +==The Tags Pane== + + +[[Image:AutoTest Tags pane empty|Tags pane]] + + +With this pane, you identify tags for your test that allow you to manage your test set more easily in the future. Read more in [[#About Tags|About Tags]] below. + +For this test, we will include only a tag that identifies the class and feature covered by the test. To do this we click '''Add tag for covered class/feature'''. When we do, we are presented with a dialog in which we can choose a class and feature. + + +[[Image:Autotest test coverage tag dialog|Dialog for coverage tag]] + + +We'll choose class BANK_ACCOUNT and feature deposit, click '''OK'''. + +Now you should see the coverage tag in the list of '''Tags used in new test'''. + + +[[Image:AutoTest Tags pane|Tags pane]] + + +That takes care of adding our coverage tag, so let's click '''Next''' to go to the next wizard pane, the '''General''' pane. + + +==The General Pane== + + +[[Image:AutoTest General pane empty|The General Pane]] + + +We will use this wizard pane to name our test class and let AutoTest know where we want the test class to reside. You can give a test class any name you wish, as long as it doesn't conflict with another class name in your system. If you try to type in a class name that already exists, the wizard will let you know right away by changing the text color to red. There is a convention that has arisen around test class names. If possible, make the test class name the name of the target class, prefixed with TEST_. So in our case, we want to build a test against a feature of the BANK_ACCOUNT class, so we will name our test class TEST_BANK_ACCOUNT. + +Now, for the question of where the tests should be kept. + +By default, tests will be stored in a subdirectory of the EIGENs directory that is generated by the Eiffel compiler. Because it's the default, it's the quickest, easiest way to house tests. But it may not be the best for you in the long run. For example, if you manually delete the EIFGENs directory, which is occasionally necessary, you will lose your tests. + +You could include them in the same cluster as some of your application classes. But there are some advantages to keeping the test classes in a '''test cluster''' separate from your target classes. For example, it will be easier for you to deliver your application or library classes if the testing classes aren't mixed with your domain classes. A '''test cluster''' is just a cluster of classes that EiffelStudio and AutoTest expect to contain test classes. So, in our case, let's create a new testing cluster as a subcluster of the cluster in which the classes APPLICATION and BANK_ACCOUNT reside. + +First, uncheck the box labeled '''Use EIFGENs cluster'''. + +Notice the '''New cluster''' link on the General pane. We click that link to add a new test cluster. The '''Add Cluster''' dialog box appears: + + +[[Image:AutoTest Add Cluster dialog]] + + +We can name our test cluster tests, the default, and make it a subcluster to our root cluster accounts. Notice that there is a '''test cluster''' check box on the dialog. It is checked and disabled, so at this point in the wizard you would always create a test cluster. Let's also check the box labeled '''recursive'''. Once the test cluster is created, we're back to the General pane which now looks like this: + + +[[Image:AutoTest General pane]] + + +At this point we have provided all the information necessary for AutoTest to create the shell for a manual test on the deposit feature of the BANK_ACCOUNT class. + +So, now we click '''Launch''', and AutoTest creates our test set and test. + + + +==Writing a test== + +Let's look at the class TEST_BANK_ACCOUNT: + + +note + description: "[ + Eiffel tests that can be executed by testing tool. + ]" + author: "EiffelStudio test wizard" + date: "$Date$" + revision: "$Revision$" + testing: "type/manual" + +class + TEST_BANK_ACCOUNT + +inherit + EQA_TEST_SET + +feature -- Test routines + + test_deposit_01 + -- New test routine + note + testing: "covers/{BANK_ACCOUNT}.deposit" + do + assert ("not_implemented", False) + end + +end + + +We can see that the feature test_deposit_01 exists, but doesn't really test anything. So, let's change that. We'll alter test_deposit_01 so that it creates an instance of BANK_ACCOUNT and then makes a deposit to that account. + +So, test_deposit_01 now looks like this: + + + test_deposit_01 + -- New test routine + note + testing: "covers/{BANK_ACCOUNT}.deposit" + local + l_ba: BANK_ACCOUNT + do + create l_ba + l_ba.deposit (500) + end + + +Now we have created and written a manual test using AutoTest. + +Next let's look into the notion of '''Tags''' in a little more detail, then see what it takes to execute a test. + + +==About Tags== + +The '''Tags''' pane allows us to associate our test with any AutoTest '''tags''' that we feel are appropriate. + +'''Tags''' are simply names or otherwise meaningful strings of characters that are arranged hierarchically and can be associated with a test to help manage, maintain, execute, and monitor its results. Any one test can support many tags. It is quite likely that during the development process, your system may eventually accumulate a great number of tests. And you may want only to execute some selected portion of those tests at any particular time. '''Tags''' allow you do that with the help of AutoTest. + +One of the most common types of tags specifies what class and feature a test covers. In our example, we wrote our test against the deposit procedure of the class BANK_ACCOUNT. The tag that we added to express this is: + +covers/{BANK_ACCOUNT}.deposit + +When we look at a tag in this notation, each hierarchical level is delimited by the forward slash. So the tag above specifies a root "covers" and its child "{BANK_ACCOUNT}.deposit". If this same test tested both deposit and withdraw, then its list of tags would be: + +covers/{BANK_ACCOUNT}.deposit +covers/{BANK_ACCOUNT}.withdraw + +So when ever you ask to view or run all the tests that covers either deposit or withdraw, this test would show up in that set. + +The "covers" tags, as you saw earlier, can be generated by AutoTest's New Eiffel Test Wizard when you create a new test. But you could enter the tag manually, as well. For example if you had written a high-level test that exercised all or most of the functionality of the class BANK_ACCOUNT, you could manually add a tag that expresses that, i.e., a "covers" tag for BANK_ACCOUNT that does not specify a particular routine: + +covers/{BANK_ACCOUNT} + + +Tags can be completely arbitrary, too. So, for example if you were building software that you expected to run on multiple platforms, in the test suite, you might have a test with the following tags: + +platform/os/linux +platform/architecture/i386 + +So this test would be specifically for Linux running on Intel architecture. When you were testing on that platform combination, you could select the appropriate tests to run using tags. + + +===Associating tags with a new test=== + +Looking again at the '''Tags''' pane, you will see that there are two boxes under the label '''Tags used in new test'''. The first is just a display of the list of tags that you have added to the new test. The next box down allows you to add an arbitrary tag sequence like: + +platform/os/linux + +Below that box, there are links that allow you to add certain commonly used or predefined tag types. One of these, '''Add tag for covered class/feature''' is the link we used to add the "covers" tag for our test on {BANK_ACCOUNT}.deposit. + + +===Other predefined tags=== + +In addition to '''Add tag for covered class/feature''', choices for other predefined tags are shown as links. For example, '''Add tag to run test in private evaluator''' and '''Add tag to run test serially'''. + +Selecting '''Run test in private evaluator''' will insert the tag: + +execution/isolated + + +When tests are executed, they do so within the context of '''evaluator processes'''. Normally, evaluator processes are reused for multiple test executions. But if you select '''Run in private evaluator''', the tag added to your test guarantees that this test will be run in a fresh evaluator process, that terminates when the test completes. This can be helpful, for example, when you don't want your test to enter or leave the evaluator process with the effects of "once" routines or any other action that might affect the efficacy of other tests. For example, if your test executes external routines which might have a damaging effect on memory, you should run the test in a private evaluator. + +If you select '''Run test serially''', the following tag will be inserted: + +execution/serial + + +Tests tagged with this tag will not run concurrently with any other similarly tagged test is running. + +You can extend the serial execution tag with arbitrary terms that will differentiate groups of tagged tests. For example, if some of your tests are tagged like this: + +execution/serial/group_1 + +and some are tagged: + +execution/serial/group_2 + +then AutoTest will not run any group_1 tagged test concurrently with any other group_1 test, and likewise for tests tagged group_2. + + diff --git a/documentation/18.11/eiffelstudio/Tutorials/using-autotest/execute-tests.wiki b/documentation/18.11/eiffelstudio/Tutorials/using-autotest/execute-tests.wiki new file mode 100644 index 00000000..4f08f0b0 --- /dev/null +++ b/documentation/18.11/eiffelstudio/Tutorials/using-autotest/execute-tests.wiki @@ -0,0 +1,110 @@ +[[Property:title|Execute tests]] +[[Property:weight|3]] +[[Property:uuid|d0515cb1-0792-3028-2a24-a71b56506959]] +In the previous section we coded a manually created test. AutoTest will allow us to execute that test, or, in more practical terms, any set of tests that we select. But before we execute our test, let's take a look at what we will get out of such an execution. + +==About test results== + +It is important to understand that for AutoTest, test results are solely determined by whether an exception occurs during the execution of a test, and, in cases in which an exception does occur, what kind of exception it is. So, with AutoTest, it is not necessary for you to write anything special into a test that propagates the test's results. + +When AutoTest executes a test, the result will be one of only three possibilities: +# The test is '''successful''' +# The test is '''failing''' +# The test result is '''unresolved''' + +These possibilities are defined as follows. + +{{definition|Successful test|A test which has executed without causing and exception to occur. }} + + +{{definition|Failing test|A test which has caused an exception to occur during its execution, specifically during the execution of a target routine. }} + + +{{definition|Unresolved test result|A test which has caused an exception to occur during its execution, but exclusive of the execution of a target routine. }} + + +So, successful tests are easy enough to understand. The test executed with no exception. + +Failing tests and unresolved test results both mean that an exception occurred during the execution of the test. The distinction is made based on the location of the feature that causes the exception. + +When we execute our test {TEST_BANK_ACCOUNT}.test_deposit_01, we know that test_deposit_01 will make a call to {BANK_ACCOUNT}.deposit. If the exception occurs during the execution of a target routine (i.e., in {BANK_ACCOUNT}.deposit), then the test is considered failing. If the exception occurs anywhere else in the execution of {TEST_BANK_ACCOUNT}.test_deposit_01, then the test is considered to have an unresolved result. + + +{{note|Be aware that some early versions of AutoTest reported some unresolved test results as failing tests. }} + +This behavior can be helpful to us as testers. A failing test indicates that there is something amiss in the target routine. The routine has not completed in a state that satisfies its postcondition and class invariant, or is dealing with an unresolved exception from some routine that it has called. An unresolved test result indicates that something is amiss in our test. Something went wrong in the setup or cleanup of the test or perhaps the test called a target routine from a state that did not satisfy the target routine's precondition. + + +==The AutoTest tool== + +In the last section, we created a manual test. The AutoTest tool shows us the new test in the '''Tests''' column. So, now the tool should look something like this: + + +[[Image:AutoTest tool with test]] + + +==Test execution== + +You see under "Tests" the project cluster accounts, the test cluster tests, the test class TEST_BANK_ACCOUNT, and the test test_deposit_01. You might have to expand some of the elements to see everything as shown above. + +You see that the '''Status''' of test_deposit is "not tested", and that the '''Last executed''' date is empty. + +To execute tests we use the "Run" button ( [[Image:debug-run-icon]] ) on the interface toolbar. By default, the Run button will run all tests matching the tags in the '''Filter''' box. However, there is a list of run options that you can access by clicking the black triangle just to the right of Run. You can choose to run all tests, only those with failing status, a filtered set of tests, or only those tests that you have selected in the tree below. We'll cover filtering a little later. For now, life is simple, we have only one test so just selecting '''Run all''' should execute it. + +==Examining test results== + +The test runs in background and the AutoTest interface now looks like this: + + +[[Image:AutoTest tool with failed test]] + + +It's pretty clear that our test has failed. Its status is now marked with the Failing icon ( [[Image:general-error-icon]] ) and in the box below the '''Execution''' tab we see that the status also includes a tag: balance_increased. More detail is provided in the Testing pane of the Outputs tool, as shown below. + + +[[Image:AutoTest Outputs tool after run 01]] + + +We see that balance_increased is a postcondition tag on the target routine {BANK_ACCOUNT}.deposit. Upon examination of the code: + + + deposit (an_amount: INTEGER) + -- Deposit `an_amount'. + require + amount_large_enough: an_amount > 0 + do + ensure + balance_increased: balance > old balance + deposited: balance = old balance + an_amount + end + + +we realize that there is no implementation here. So we add the code to implement deposit: + + + ... + do + balance := balance + an_amount + ensure + ... + + +After compiling, we can execute the test again. We could do this by selecting '''Run all''' as we did last time, or by selecting '''Run failing'''. Once the test executes we see now that it was successful: + + +[[Image:AutoTest tool with passed test]] + + +This time we see that the test is successful, as indicated by the Success icon ( [[Image:general-tick-icon]] ) in the Status column. + +==The beginnings of a test suite== + +Of course we would not have had to use AutoTest to find that bug in {BANK_ACCOUNT}.deposit. We could have just written a simple class to exercise instances of BANK_ACCOUNT and truth would have come out. + +The advantage of using AutoTest is that the test that we wrote to cover {BANK_ACCOUNT}.deposit can stay with us throughout the lifecycle of class BANK_ACCOUNT. We can expand the TEST_BANK_ACCOUNT with additional manual tests and run them after every development increment to ensure that all tests that were once successful are still successful. + +==Manual test summary== + +We have seen how to create and execute a manual test. You will find that manual tests form the backbone of your test suite. But there are two other types of tests available in AutoTest. Next let's take a look at these test types and in what ways they can be used. + + diff --git a/documentation/18.11/eiffelstudio/Tutorials/using-autotest/index.wiki b/documentation/18.11/eiffelstudio/Tutorials/using-autotest/index.wiki new file mode 100644 index 00000000..e248bd75 --- /dev/null +++ b/documentation/18.11/eiffelstudio/Tutorials/using-autotest/index.wiki @@ -0,0 +1,30 @@ +[[Property:title|Using AutoTest]] +[[Property:weight|-1]] +[[Property:uuid|6b900a65-85c6-9cd6-ef57-ccd4b8decbef]] +{{note|The following few pages contain the AutoTest tutorial. This tutorial uses a different software example than the bulk of the EiffelStudio Guided Tour. If this is your first time through, you may want to delay the AutoTest tutorial until you have completed the rest of the Guided Tour, then come back to it when you're feeling more familiar with EiffelStudio.}} + + +{{note| '''To users of V6.6 and later:''' As of V6.6, the New Eiffel test wizard panes have changed somewhat from this documentation. V6.6 introduces the ability to store certain preferred values for creating tests. The advantage is that one need not enter this information on wizard panes each time a test is created. Because preferred values can be stored, the panes containing the values more likely to change between test creations are presented earlier than other panes. In previous versions, these panes were presented later, as shown in this documentation. The documentation will be updated in the future to reflect the newer wizard sequences and pane layouts. }} + + +==Introduction== + +AutoTest is a tool that helps you to create, manage, and run tests against your software. AutoTest is accessible directly as a part of EiffelStudio, but works to a large extent behind the scenes so that it doesn't get in the way of your development activities. In other words, even though you may be accumulating a substantial collection of test software along with your project software, you can still run and deliver your project software without going to a lot of trouble to separate the two. Tests managed by AutoTest stay handy and can be run any time to help make sure everything always stands up to the scrutiny of testing. + +This tutorial will guide you through the use of AutoTest. A [[AutoTest|reference section]] for AutoTest is also available. + + +{{Recommended|At least on your first viewing of this tutorial, take the sections in the order in which they are presented. There are three different types of tests supported by AutoTest. Each type of test is discussed on its own page. But to avoid repetition, the pages for the second and third types of tests omit some of the detail in the first and assume a familiarity with the example. }} + + +{{Caution|
1) At this time, AutoTest will work '''only''' for project targets in the '''classic Eiffel''' environment. This means that projects targeted to Microsoft .NET will not be able to use AutoTest.
2) Currently, the use of AutoTest should be '''restricted to projects built without void-safe settings'''.}} + + +{{Recommended|During the transition to void-safe Eiffel, projects can be built using '''experimental''' mode. This mode is as stable as '''non-experimental''' mode, but includes some facilities that might break existing code in a few circumstances. However, since version 6.5, EiffelStudio itself is built in experimental mode, so '''we recommend that you use AutoTest only on projects also built using experimental mode'''. Experimental mode can be invoked by using the "-experiment" option from the command line, or on Microsoft Windows by following the '''Start''' menu path to EiffelStudio and selecting experimental mode. As of version 6.6, the mode that was '''experimental''' in previous versions, becomes the '''default''' mode.}} + + +{{SeeAlso|
[[AutoTest]] reference }} + + + + diff --git a/documentation/18.11/eiffelstudio/Tutorials/using-autotest/managing-tests.wiki b/documentation/18.11/eiffelstudio/Tutorials/using-autotest/managing-tests.wiki new file mode 100644 index 00000000..a44f4b22 --- /dev/null +++ b/documentation/18.11/eiffelstudio/Tutorials/using-autotest/managing-tests.wiki @@ -0,0 +1,104 @@ +[[Property:title|Managing tests]] +[[Property:weight|9]] +[[Property:uuid|f1e7f63a-dc86-fefb-e669-3e3ea178c596]] +The previous sections cover the basics of testing and what it takes to create and use each of the test types supported by AutoTest. This section will finish things up with some miscellaneous information about testing strategy and hints on using AutoTest. + + + +==Favor manual tests== + + +It is worth repeating that currently, manual tests should form the majority of your testing suite. As you have seen, extracted and synthesized tests use more complex setup and execution mechanisms. These mechanisms make tests less robust and readable than manual tests. So using extracted and synthesized tests as a guide to produce manual tests with the same coverage is, at this time, the best way to work. You will probably be able to do this easily enough with synthesized tests. Extracted tests attempt to recreate the context at a specific point in time, which may make it more difficult to write a manual test that is equivalent an extracted test. + +Because manual tests are more easily readable than either of the automatically generated test types, you should be able to understand more quickly what has happened when a test produces failing results. + + +==Deleting uneeded tests== + + +At some point and for various reasons, you will probably want to delete tests from your test suite. This is easy enough to do. Remember that test sets are actually just classes with certain characteristics, and that tests are actually just specialized routines of test classes. + +If you want to delete a single test, you can delete that feature from its test class. + +If you want to remove a whole test set, then [[Removing a class|delete the class]] that defines that test set. + + +==Using Filters== + +Filtering is provided to help view, manage, and run the tests in a test suite. + +Filtering controls which tests are visible in the AutoTest interface how the view is organized. You can display tests organized by the test classes that contain them, by the classes they target, by their type, by their most recent results, or by any system you set up using a system of [[Create a manual test#About tags|tags]]. + +Filtering helps you manage which tests get run during a give execution. You can select certain tests to be run from those visible in the AutoTest interface, or you can choose to run all tests visible through a filter. + + +===The Filter box=== + +The Filter box in the AutoTest interface can be used to enter filter text which will allow only certain tests to be visible. + +Filter text can be a string of characters occurring in specific test class name or test routine name, or it can be a [[Create a manual test#About tags|tag]] or a portion of a tag hierarchy. The Filter box supports regular expressions, so you can filter with more granularity. + +It is important to bear in mind that the View box works with the system of [[Create a manual test#About tags|tags]] described in the section on creating manual tests. Tags are hierarchically structured names that are applied to tests through the note clause. When you use the View box to display a set of tests, you specify that set by the tags on the tests. Some of the tags are implicit, in the sense that AutoTest accounts for them, and they are not explicitly coded in note clauses. This should become clear when we look at some examples. + +When the filter text is cleared, the AutoTest interface will display tests accessible through all tag roots. + +As of version 6.5 of EiffelStudio, the tag root words used are: + + +{| border="2" +|- +| class || Tests organized by test classes +|- +| covers || Tests organized by target classes/routines +|- +| result || Tests organized by the results of their most recent execution +|- +| user || Tests organized by type (manual, extracted, generated) and by user-added tag hierachies +|} + + +{{note|The tag roots will appear only if there are tests that can be categorized under them. For example, if you have not run any tests, then '''result''' will not appear. }} + + +Notice that the Filter box has a drop-down with a list of options: + + +[[Image:AutoTest filter drop down]] + + +These options are shortcuts to the various tag roots listed above: + +#'''Test classes''' displays the sub-tree under the tag root '''class''' +#'''Classes under test''' displays the sub-tree under the tag root '''covers''' +#'''Results''' displays the sub-tree under the tag root '''result''' +#'''User-defined tags''' displays the sub-tree under the tag root '''user''' + + +Any tagging system that you devise will show up under the '''user''' tag root. + +For example, consider a manual test containing a '''testing:''' note name with a user-defined tag as in the following code. + + + test_deposit_01 + -- New test routine + note + testing: "covers/{BANK_ACCOUNT}.deposit" + testing: "my_tag_root" -- My new tag root + local + l_ba: BANK_ACCOUNT + do + create l_ba + l_ba.deposit (500) + end + + +This will cause the new user-defined tag and its associated tests to be visible in the AutoTest interface. + +[[Image:AutoTest user defined tag root]] + + +{{seealso|The [[The AutoTest Interface#Filtering|Filtering]] section in [[The AutoTest interface]].}} + + + + diff --git a/documentation/18.11/eiffelstudio/Tutorials/using-autotest/testing-background-and-basics.wiki b/documentation/18.11/eiffelstudio/Tutorials/using-autotest/testing-background-and-basics.wiki new file mode 100644 index 00000000..20fe5719 --- /dev/null +++ b/documentation/18.11/eiffelstudio/Tutorials/using-autotest/testing-background-and-basics.wiki @@ -0,0 +1,149 @@ +[[Property:modification_date|Tue, 30 Oct 2018 14:59:36 GMT]] +[[Property:publication_date|Tue, 30 Oct 2018 14:59:36 GMT]] +[[Property:title|Testing: Background and basics]] +[[Property:weight|0]] +[[Property:uuid|12c2a2d4-9bf2-ba73-6647-cb9900666de1]] +==Background and motivation for testing tools== + +Developers test software in the hope that the testing process will expose faults in the software they've developed. Most developers also realize that no amount of testing will ever prove software to be bug free. So while testing is a virtuous activity that we dare not neglect, we are wise to temper our expectation of the practical value of testing. + +A test is designed to exercise a software element given certain inputs and execution state. The state is observed after the test execution to see if the software element has behaved in a manner that is consistent with its specification. + +As a body of software is developed and tested, a large number of tests may accumulate. This large suite of tests can be run at any time in order to ensure that a change or the addition of a new software element does not cause a previously successful test now to fail. Some software development processes call for running a whole suite of tests after every increment of development activity. This type of testing is often referred to as ''regression testing'', because it tends to expose software which had been satisfying its tests at one time, but because of some development activity has regressed to a failing state. + +Creating, managing and running a large number of tests manually can be time-consuming, messy, and error-prone, thus the motivation for automated testing tools. Testing tools help programmers to create, maintain, and execute a suite of tests by automating the activity. During the last few years, both testing methods and tools have become more sophisticated. + + +==The Eiffel advantage in testing== + +Some of today's development methods require tests to be written before the software elements they test. Then the tests are included as a part of the software specification. But tests can only reflect a very small subset of the possible execution cases. Testing can never replace a comprehensive software specification. + +The great advantage you have with Eiffel, of course, is that the specification for a software element exists in its contract. Like the tests mentioned above, contracts for software are written prior to implementation. So, importantly, tests are ''not'' a part of a software specification in Eiffel. + +With contract checking enabled at run time, the running software's behavior is constantly monitored against the contract's expectations. In other words, for routines, the precondition defines an acceptable state in which the routine can execute, and the postcondition defines an acceptable state after successful execution. The class invariant defines the constraints necessary for instances of a class to be valid. + +A term commonly used in software testing is "oracle". Tests are generally looked at as having two parts, the first part is a mechanism that exercises (runs or calls) a particular software element in a given context. The second part is the "oracle" whose responsibility it is to determine whether the software element passes or fails the test. Not surprisingly, test oracles in other testing frameworks often look a lot like assertions in Eiffel. So the advantage for Eiffel is that the test oracles for all routines are already written as the postconditions on routines and class invariants. + +The presence of preconditions provides another advantage. Preconditions make it possible to automate testing in ways unavailable in other environments. Because of preconditions, we already have information about the limits of valid inputs to routines. So it's possible to generate a call to a routine we want to test automatically and with a context that meets the routine's precondition. + + +==AutoTest== + +AutoTest attempts to capitalize on the testing advantages inherent in Eiffel due to Design by Contract. AutoTest consists of an interactive interface, and a library of classes which support testing activity. + +The testing support classes are distributed with EiffelStudio and exist in the ''testing'' subfolder of the ''libraries'' folder. With the exception of one class which we will discuss soon, the classes in "testing" are not intended to be used directly by developers. They exist to support the functionality of AutoTest. + +The interface for AutoTest is accessible through the EiffelStudio development environment. You may find it already resident as a tab in the right hand pane next to Clusters, Features, and Favorites. If it's not there, then you can bring it up by following the menu path: + + +View --> Tools --> AutoTest + + +==Test classes and tests== + +The AutoTest interface helps you to create and execute tests on the software you develop. The interface contains a wizard called the '''New Eiffel Test Wizard''' which helps you create or generate the types of tests you need. We'll learn more about the interface and the wizard as we go along. But first, let's look at what constitutes a ''test''. For AutoTest, we define the term ''test'' in the context of some other testing terminology: + + +{{definition|Test class|An effective class that inherits from the class EQA_TEST_SET. }} + + +{{definition|Test|Any procedure of a test class that satisfies all of the following conditions:
1) Is exported to ANY
2) Is immediate (i.e., introduced within the text of the test class)
3) Takes no arguments }} + + +{{definition|Test set|The set of tests in a test class. }} + + +{{definition|Test suite|A set of test classes (and by implication the tests contained therein) which is designed to test some particular software system or library. }} + + +Whenever you use AutoTest, it will find your test classes, those classes that inherit from EQA_TEST_SET. When you run tests, it will execute all the tests in those classes, or a subset of tests that you choose. So, you have probably figured out that the one class from the testing library that you may need to know a little about is EQA_TEST_SET. But you don't have to know very much, because AutoTest can help you construct your test classes. + + +==Types of tests== + +There are three different types of tests supported by AutoTest: +* Manual tests +* Extracted tests +* Generated tests + +Each test of any of these types ultimately is a feature of class that inherits from EQA_TEST_SET. Ordinarily, though, the three types of tests won't be mixed in a test class. That is, any one particular test class will contain only one type of test. But from the point of view of AutoTest, all types of tests are managed and run the same way. We will discuss these types of tests in more detail later, but for right now, let's just establish some definitions. + + +{{definition|Manual test|A test manually coded within a test class. }} + + +Manual tests are features, procedures in fact, of classes that inherit from EQA_TEST_SET. In many simple cases, test classes containing manual tests inherit directly from EQA_TEST_SET, but that's not a requirement. Occasionally it can be useful for test classes to inherit from a descendant of EQA_TEST_SET that provides additional functionality. + +A manual test is "manual" in the sense that you code the essential procedural part of the test by hand. But you really don't have to deal with the more mundane business of creating the whole test class and ensuring the proper inheritance. The ''New Eiffel Test Wizard'' helps out by automatically creating the shell of a test class and the shell of a test for you to fill in. Then it's pretty easy to add new tests manually to an existing test class. + + +{{definition|Extracted test|A test that has been created during the execution of a system as a result of a developer request or a failure of the system. Extracted with the test is the current runtime state. When run, the test will attempt to recreate the runtime context. }} + + +Extracted tests are convenient because they allow you to accumulate tests that are based on actual failures of your software (good for the software, not so good for your ego!). Once these tests are in your suite of tests, they are available from then on. + + +{{definition|Generated test|A test that is the product of generating and running a series of randomly generated invocations of target routines. }} + + +The process of creating generated tests is sometimes known in the community as creating via ''AutoTest''. The randomly generated calls to target routines which were created and run are discarded at the completion of the creation. But from the results of these calls, a set of permanent tests is distilled. These are the generated tests. + +Generated tests are made possible by Design by Contract. Hopefully, you remember that one thing that DbC gives us is the handy ability to assign blame when something goes wrong. When a test makes a call to a routine we want to test, if a contract violation occurs, it may be the fault of the called routine or it may be the fault of the caller ... and that depends upon what type of contract violation has occurred. The contract violations that are interesting to AutoTest in the process of synthesizing tests are only those in which the called routine is at fault. That is, postcondition and invariant violations. AutoTest will then create a generated test for every ''unique'' failure in which the called routine being tested was to blame. + + + +==Anatomy of a test== + +Here are two more definitions: + +{{definition|Target routine|A routine that is to be tested by a test. Sometimes called a "routine under test." }} + + +{{definition|Target class|A class that contains target routines. Sometimes called a "class under test." }} + + +In its simplest form, a test is a routine that issues a call to some routine you've developed in some class you've developed. + +So the tests and the test classes are in the realm of testing and are used to test the target routines in target classes which are the real product of your software development project. + +AutoTest will manage and run the tests in any test class whether or not they actually test any target routines. Even though the test shown below doesn't test anything, it still qualifies as a test. Naturally, it would seem silly to keep a test around that doesn't test anything, but the important thing to understand is that AutoTest will work with anything that matches the definitions of test and test class above. That is, once tests are created, AutoTest doesn't really have a stake in what you are trying to test. + + + + +note + description: "[ + Eiffel tests that can be executed by testing tool. + + ]" + author: "EiffelStudio test wizard" + date: "$Date$" + revision: "$Revision$" + testing: "type/manual" + +class + MY_TEST_CLASS + +inherit + EQA_TEST_SET + +feature -- Test routines + + my_test + -- New test routine + do + assert ("not_implemented", False) + end + +end + + +This test class was created by AutoTest's New Eiffel Test Wizard. It is about as simple a test class as there can be. Its only value is to illustrate the basic form of AutoTest tests. So, let's look at that form. + +It is clear that MY_TEST_CLASS is an effective class that inherits from EQA_TEST_SET, so that makes it fit the definition of a test class. And, it's also clear the my_test is a feature of MY_TEST_CLASS, specifically a procedure, exported to ANY, requiring no arguments. That qualifies my_test as a test. If MY_TEST_CLASS is located in a test cluster of your project, then AutoTest will find it and be able to run it whenever you request. + +This test would always fail because of the assert that the wizard put in the implementation. So if you asked AutoTest to run your tests, it would tell you that my_test was a failed test, for the reason: "not_implemented". The assert is not a necessary part of a test. The wizard puts it there to remind you that the test has not been implemented. If you removed the assert line from the test, then the test would always succeed, which would be nice, but it would be succeeding at testing nothing! We'll see more later about what it means for tests to succeed and fail. + +But first let's get some exposure to the AutoTest interface, by building a manual test for a routine in a simple class. + + diff --git a/documentation/18.11/eiffelstudio/Tutorials/using-autotest/using-extracted-tests.wiki b/documentation/18.11/eiffelstudio/Tutorials/using-autotest/using-extracted-tests.wiki new file mode 100644 index 00000000..696be15c --- /dev/null +++ b/documentation/18.11/eiffelstudio/Tutorials/using-autotest/using-extracted-tests.wiki @@ -0,0 +1,146 @@ +[[Property:title|Using extracted tests]] +[[Property:weight|5]] +[[Property:uuid|bebd4f28-9818-80f0-a69a-e9ce867723f4]] +==About extracted tests== + +At any time that you are running a system in EiffelStudio debugger and your system is paused, you can ask AutoTest to extract a new test class and test from the current executable context. Most often you would use this capability in the case in which you experienced an unexpected failure or exception in one of your routines. It is possible, though, to extract at any point at which the system is paused. + +The value of extracted tests is that they provide a kind of a snapshot in testing form that will reproduce the unexpected failure. An extracted test attempts to reproduce the context in which the offending routine executed. So, extracted tests supplement your manual tests. They serve to cover situations which you just may not have written manual tests to cover. + +Extracted tests are intended to supplement the suite of manual tests that you have created to do the bulk of your testing. So, usually when you create an extracted test, it happens as a result of your being surprised. You will notice that each time you create an extracted test, you get a new test class, too. This is in contrast to manual tests, in which you might use the wizard to create a new test class and one new test to cover a particular target class and target routine. Then you might manually create, in that same test class, many additional tests covering the routine behavior of the same or other target routines in the same target class. + + +==Creating an extracted test== + +Let's use the same test system we used for manual tests to demonstrate the creation of an extracted test. The example will be slightly contrived because it will find a problem that certainly we would already have discovered had we written a comprehensive set of manual tests against the BANK_ACCOUNT class. Still, the simplicity should help keep things clear. + +If you remember, the root class for the example application was not very interesting, just a root procedure with a single instruction and a declaration my_account of type BANK_ACCOUNT: + + + + make + -- Run application. + do + create my_account + end + + my_account: BANK_ACCOUNT + + + +Now, let's add some code into the make procedure that will make use of my_account: + + + make + -- Run application. + do + create my_account + my_account.deposit (500) + my_account.withdraw (100) + end + + + +If we run the application from EiffelStudio, we see that it stops when it incurs a postcondition violation in {BANK_ACCOUNT}.withdraw: + + +[[Image:AutoTest extracted 01]] + + +When we look at the feature pane, it's pretty easy to see where the problem is: + + +[[Image:AutoTest extracted 02]] + + +There is an error in the specification for withdraw. In the postcondition tagged withdrawn, the plus sign should have been a minus sign. Therefore, the assertion should read like this: + + + withdrawn: balance = old balance - an_amount + + +Certainly we will fix this, but AutoTest gives us the opportunity to extract a test based on this particular failure. So, let's do that. + +So, we go to the AutoTest tool and click triangle next to ''Create new tests'' button and select the '''Extract tests from debugger''' from the drop-down menu. Because we are paused in the debugger, the drop-down menu appears with the '''Extract tests from debugger''' choice enabled this time: + + +[[Image:AutoTest create new test 02]] + + +When we select '''Extract tests from debugger''', we are presented with the New Eiffel Test Wizard's '''Test Extraction''' pane. This wizard pane shows a depiction of the current call stack and asks us for which feature(s) on the stack we want to create the test: + + +[[Image:AutoTest test extraction pane|Test extraction pane]] + + +The choice for withdraw is the selection we want. We can deselect the stack frame for make if it is pre-selected. If we click '''Next''' at this point we would be taken to the '''Tags''' pane, and from there to the '''General''' pane. But we really don't need to do this. AutoTest will sense that we are extracting a test for {BANK_ACCOUNT}.withdraw and tag the test properly. It will use the same test class name from the '''General''' pane, but add a numerical suffix. So, all we need to do now is to click '''Launch''' from the '''Text Extraction''' pane. + +AutoTest creates the new test and returns us to the debugger, where our system is still on hold. We can stop execution and compile to include the new test. + +Now we see the new test class and test in the AutoTest tool windows. + + +==Run the tests, fix a problem, run the tests== + +We run our tests using '''Run all''', and we see that the test on withdraw is still failing: + + +[[Image:AutoTest tool after run]] + + +If we fix the error in the postcondition in withdraw, recompile, and then re-execute the test, we find that it is successful. + + +==A closer look at an extracted test== + +Look at the code that was generated for the extracted test after the assertion violation occurred: + + +note + description: "Regression tests reproducing application state of a previous execution." + author: "Testing tool" + +class + TEST_BANK_ACCOUNT_EXTRACTED_WITHDRAW_01 + +inherit + EQA_EXTRACTED_TEST_SET + +feature -- Test routines + + test_withdraw + note + testing: "type/extracted" + testing: "covers/{BANK_ACCOUNT}.withdraw" + do + run_extracted_test (agent {BANK_ACCOUNT}.withdraw, ["#1", {INTEGER_32} 100]) + end + +feature {NONE} -- Access + + context: !ARRAY [!TUPLE [type: !TYPE [ANY]; attributes: !TUPLE; inv: BOOLEAN]] + -- + do + Result := << + [{BANK_ACCOUNT}, [ + "balance", {INTEGER_32} 400 + ], False] + >> + end + +end + + + +You probably noticed immediately that it doesn't look much like the code that we wrote for our manual test in the previous section. + +One reason for the difference is that the class does not inherit directly from EQA_TEST_SET as our manual test did. Instead, it inherits from EQA_EXTRACTED_TEST_SET which itself is a descendant of EQA_TEST_SET. EQA_EXTRACTED_TEST_SET provides additional functionality for extracted tests. + +Notice that the call to the target routine {BANK_ACCOUNT}.withdraw is effected in the routine test_withdraw which passes an agent representing {BANK_ACCOUNT}.withdraw to the procedure run_extracted_test. The second argument to run_extracted_test is a TUPLE with the argument values which were used in the call to withdraw which caused the original assertion violation. + +Another thing worth noting is the function context. This is how AutoTest recreates the state of the instance of BANK_ACCOUNT at the time of the assertion violation. + +{{caution|The extracted test recreates the state at the point at which execution has halted. So, in the case of a postcondition or invariant violation, the values of the attributes will reflect any changes that have been made during the execution of the routine. (In the example, the value of balance is set to 400, rather than 500 as it would have been when routine withdraw began execution.) This could make a difference in whether the test extracted after an exception is a valid recreation of the original failure. One way of dealing with this, at least in simple cases like this, is to change the test class code to reflect the proper value. A safer way would be rather than extracting the test after the exception, restart the system and stop execution as it enters the failing routine, then extract the test at that point. }} + + + diff --git a/documentation/18.11/eiffelstudio/Tutorials/using-autotest/using-generated-tests.wiki b/documentation/18.11/eiffelstudio/Tutorials/using-autotest/using-generated-tests.wiki new file mode 100644 index 00000000..79d09660 --- /dev/null +++ b/documentation/18.11/eiffelstudio/Tutorials/using-autotest/using-generated-tests.wiki @@ -0,0 +1,142 @@ +[[Property:title|Using generated tests]] +[[Property:weight|7]] +[[Property:uuid|c17ebddf-5d35-76c1-4912-d9f1ca3770a5]] +==About generated tests== + +Generated tests fill a different role from either extracted or manual tests. The idea behind generated tests is that because we specify software through its contracts, and because compliance of the software to those contracts can be actively monitored at runtime, we can know two things necessary for building tests: +#For any routine, what argument values are valid +#For the execution of any routine, what resulting states are acceptable + +The first bit of knowledge comes from the ''preconditions'' of target routines. The second comes from ''postconditions'' of target routines and the ''invariants'' of target classes. Armed with this knowledge, we should be able to generate a series of invocations of target routines using random argument values, and evaluate the results. This is what is done by an internal facility of AutoTest that builds generated tests (this facility is often also referred to itself as AutoTest). After many of these randomly generated invocations, AutoTest attempts to synthesize the results of these feature calls into new test classes. The tests in these new test classes contain the calls leading up and including calls that fail. AutoTest will attempt to create only one test from each unique type of failure, so that your test directory doesn't get loaded with lots of duplicate tests. + +You may look at a generated test class and think that it seems to be very long and to contain lots of stuff that you doubt is relevant. This is a fair assessment. The processes that AutoTest uses to build and minimize generated tests are constantly being improved. But for now, generated tests, although useful, retain a certain amount of that randomness that was used in their creation. + +So for the time being, unlike manual and extracted tests, you should not make generated tests a part of your permanent test suite. Rather, you should consider them a disposable means to an end. Use each generated test as a guide for building an effective and readable manual test. + + +==Creating generated tests== + + +If you've been through the discussion of the creation of [[Create a manual test|manual]] and [[Using extracted tests|extracted]] tests, then it should come as no surprise to learn that you use the '''New Eiffel test wizard''' to create generated tests. And much of this process will seem familiar now. + +In the drop-down menu for the '''Create new test''' button, choose the item '''Generate tests for custom types'''. + + +[[Image:AutoTest create new test]] + + +At this point, you'll see the '''Test Generation''' wizard pane. This pane allows you to specify which classes you want to generate tests for. You can also adjust the values of certain parameters used in the test generation. + +Let's type the class name BANK_ACCOUNT into the box labeled '''Class or type name''' and click the "'''+'''" button to added it to the list. Of course you can remove an item from the list by selecting it and clicking "'''-'''". + + +[[Image:AutoTest Test Generation pane]] + + +The rest of the pane is used to configure certain options for the test generation process. + +'''Cutoff (minutes)''' lets you specify a number of minutes for AutoTest to run random invocations of the routines in your target class(es). + +'''Cutoff (invocations)''' lets you control how long AutoTest will run random invocations by declaring a specific number of invocations. + +'''Routine timeout''' sets an upper limit on how long AutoTest will wait for a random feature call to complete. + +'''Random number generation seed''' provides a way for you to control the seeding of the random number generator used by AutoTest. When the value is '''0''', as shown here, the seed is created from the system clock. This is adequate in most cases, but this option is provided because there might be some cases in which you would want to try to reproduce a previous test generation run. And to do that, you would have to set the seed to the same value for multiple runs. + +The two check boxes '''Slice minimization''' and '''DDmin for minimization''' allow you to select the approach that you want to use for minimizing the size of generated tests. Generally, the default value here is adequate. '''Slicing''' and '''ddmin''' are two different ways of doing minimization. Tests are generated after running many randomly generated calls to routines in your target class. Tests are generated for calls that fail. So, there may have been many randomized calls leading up to the failed call. Minimization helps to eliminate the majority of the unrelated randomly generated calls, leaving the test code as short as possible. You will notice that minimization processing is memory and processor intensive. + +The last check box, '''HTML statistics''' gives you the option of having AutoTest record the results of a test generation run in a set of files that you can review with a web browser. + +We can allow all these to remain their default values, with one exception. Let's check the '''HTML statistics''' box. + + + +During the test generation you can watch the random invocations of your class's routines being logged in the Testing pane of the Outputs tool. When the generation completes, AutoTest directs you to the location of the results: + + +[[Image:AutoTest testing pane after generation]] + + +The file statistics.txt contains a summary of the generation run. If you enabled '''Create HTML output''' you can open the file index.html with your browser and view formatted summary and detail information. + + +{{note|The '''result''' directory includes files that summarize the whole generated testing process. Some of these are lengthy because they contain information on test cases used for each target routine. }} + + +If we try to generate tests on the class BANK_ACCOUNT in which we have already fixed two bugs after the manual and extracted tests, we will see something about like the following results: + + +[[Image:AutoTest generated results pass]] + + +The important thing to notice here is the status: '''pass'''. There were no randomly generated cases that failed. So every valid invocation of a routine for class BANK_ACCOUNT completed satisfactorily. Therefore, no generated test class was created. + +If we re-introduce the bug into the deposit procedure of class BANK_ACCOUNT (i.e., Remove this line of code: balance := balance + an_amount), and then request generated tests again, we get different results: + + +[[Image:AutoTest generated results fail]] + + +This time, as we expected, failures were encountered. And a generated test class was created. + + +==A look at a generated test== + + +The generated test class looks like this: + + + +note + description: "Generated test created by AutoTest." + author: "Testing tool" + +class + TEST_BANK_ACCOUNT_GENERATED_001 + +inherit + EQA_SYNTHESIZED_TEST_SET + +feature -- Test routines + + generated_test_1 + note + testing: "type/generated" + testing: "covers/{BANK_ACCOUNT}.deposit" + local + v_6: BANK_ACCOUNT + v_7: INTEGER_32 + do + execute_safe (agent: BANK_ACCOUNT + do + create {BANK_ACCOUNT} Result + end) + if {l_ot1: BANK_ACCOUNT} last_object then + v_6 := l_ot1 + end + v_7 := {INTEGER_32} 3 + + -- Final routine call + set_is_recovery_enabled (False) + execute_safe (agent v_6.deposit (v_7)) + end + +end + + + +{{note|If you've been following along by the doing these examples in EiffelStudio, you may notice that your generated class looks slightly different. }} + + +This test is written in a way that is a little different from both the manual test we wrote and the extracted test. But it's not too hard to figure out what's going on. An object of type BANK_ACCOUNT will be created (local v_6) and the deposit feature will be applied to it with an argument value of 3 (local v_7). + +You can see that this test, although it is implemented differently, is about the same as the manual test we wrote covering {BANK_ACCOUNT}.deposit. Because we have re-introduced the bug in BANK_ACCOUNT, if we run all tests, we see that both our manual test and the generated test are failing ... only the extracted test covering {BANK_ACCOUNT}.withdraw is successful: + + +[[Image:AutoTest interface after run 05]] + + +If we replace the implementation for {BANK_ACCOUNT}.deposit that we had removed, and then re-execute the tests, all are successful. + + + diff --git a/documentation/18.11/eiffelstudio/Tutorials/viewing-classes.wiki b/documentation/18.11/eiffelstudio/Tutorials/viewing-classes.wiki new file mode 100644 index 00000000..746479cf --- /dev/null +++ b/documentation/18.11/eiffelstudio/Tutorials/viewing-classes.wiki @@ -0,0 +1,120 @@ +[[Property:title|Viewing Classes]] +[[Property:weight|-9]] +[[Property:uuid|78136af1-5d7a-f3d2-9619-17f4c0541f1e]] +__FORCETOC__ +We haven't really looked at the text of a class yet. It's important anyway to see how EiffelStudio provides you with numerous, complementary '''views''' of your software. The Class tool and Feature tool are where the bulk of these views will be displayed, although the Editor tool does support some special views. For now we will concentrate on the views available in the Class tool. + + +==Making some room== + +We'll need just one development window for the moment, the one that was targeted to LIST. You should still have that window available from the previous Tour topic, and it should look about like this: + +[[Image:es gt development window targeted to list 01]] + +{{note| If you don't see a development window targeted to LIST, just retarget one, as you know how to do this now, for example by typing the name followed by Enter in the Class Field at the top left. }} + +First let's give ourselves more space. Right now we don't need the Groups tool or any of the other tools sharing that pane. We could get rid of them by clicking the close buttons on the top right corner of the panes. Then we could get them back later by following the menu path: + +View --> Tools --> x + +where "x" is the name of a tool we want restored. But there is an easier way. Let's just hide them away until later. + +We do this by setting the pane containing the tools to '''Auto Hide'''. On the bar at the top of the pane, you'll see the Auto Hide icon ([[Image:auto-hide-icon]]) which looks like a pushpin. + +[[Image:es gt auto hide 01]] + +Click the icon and you'll see the pane shrink into a set of tabs on the right window margin and the remaining panes will expand to fill the abandoned space. The tools in the pane will temporarily expand back out if you move your mouse cursor over their tabs. Try it with one. When you want the pane back in its original place permanently, you just expand one of the tabs by mousing over it, then click the Disable Auto Hide icon, which is the pushpin again, just horizontal this time. + +Two panes remain, showing the Editor tool and the lower pane containing the Outputs tool and others. You can resize the panes by dragging the border between them. Make sure there's plenty of room in the lower pane. + + +==The Class tool== + +Before we look at the Class tool, let's make sure that we set [[Change data share mode|linked data share mode]] which will always display information about the current target. Go to the main menu bar and expand the menu item View. If you see a choice marked with the link context icon ([[Image:context-link-icon]]) and labeled Link Context Tool, then select it. After it has been selected, or if it has already been selected, then the label will read: Unlink Context Tool. + +At the bottom of the lower pane you'll find a tab labeled '''Class'''. This gives you access to many forms of information about the current class -- the target of the development window. Click on the Class tab to bring up the Class tool. A set of buttons at the top enables you to display a number of '''views''' of the class. The currently highlighted button indicates the default view: Ancestors. You can see the others' names by moving your cursor over the various view icons, and reading the tooltips. + +The view currently displayed, Ancestors, shows the inheritance structure that leads to the current target, LIST : + +[[Image:es gt class tool 01]] + +This shows that LIST is an heir of CHAIN which itself, as an example of multiple inheritance, is an heir of CURSOR_STRUCTURE, INDEXABLE, and -- twice, as an example of repeated inheritance -- SEQUENCE. If, because of direct or indirect repeated inheritance, a class appears more than once, the display doesn't repeat its ancestry the second and subsequent times; the omitted repetition appears as just three dots, '''...''', as illustrated here for the second occurrences of BAG, ACTIVE and others. + +As you may have guessed, all the class names that appear on this display, by default in blue, can function as hyperlinks: you can use any one of them to retarget the Development Window to the corresponding class. This will be another major retargeting mechanism. But let's not pursue it for the moment and instead continue looking at the documentation views. + +Next to Ancestors button is Descendants, which will give you the descendants of a class in a similar format: + +[[Image:es gt class tool descendants 01]] + +The progeny of LIST, as you can see, is just as impressive as its ancestry. + +Let's now look at the other formats, starting from the left. The first button, Clickable, gives the class text. It's essentially the same information as appears in the top Editing Tool (whose pane was reduced to its bare minimum in the last few pictures, showing only the first three lines or so), but with some differences: +* The Text view in the Editor is editable. In fact it's EiffelStudio's primary tool for entering software texts. The Class tool's Clickable view is just a view; you can't change it. +* The Text view retains the formatting of the class text the way it was typed in; the Clickable view is automatically formatted -- "pretty-printed" -- according to the standard Eiffel layout rules. +* The Clickable view does not include comments inside routine implementations ( do and once clauses), although it does retain features' header comments. +* As part of the pretty-printing, the Clickable view uses colors and fonts to distinguish keywords, identifiers, comments and other syntactical elements. You can change the fonts and colors, like many other elements of the interface, through Tools --> Preferences. (Now is not the time.) + +This view is called "Clickable" because, as we'll see later, every syntactical element on it is a hyperlink, which you can use for browsing. + +After Clickable comes the Flat view button. The layout of the result is similar. The flat form of a class is the reconstructed class text including not only what's declared in the class itself but also everything that it inherits from its ancestors, direct or indirect. This applies to the flat form's features, which include ancestor features, but also to contracts: the flat form's invariant includes all clauses from ancestors' invariants, and the preconditions are expanded to take require else and ensure then clauses into consideration. (The [[An Eiffel Tutorial (ET)|Eiffel Tutorial]] explains these notions in detail.) + + +[[Image:es gt class tool flat 01]] + + +As a result, the Flat view shows the class text as it might have come out had inheritance (what a horrible thought even to contemplate!) ''not'' been available to write it. + +The first two features appearing in the above display, cursor and first, are indeed inherited from ancestors, rather than declared in LIST itself. Note how EiffelStudio, when producing the flat form, adds a line of the form + + -- (from CLASS_OF_ORIGIN) + + +to the header comments of inherited routines, to document where they come from. + +The flat form is an important notion of object technology, making it possible to understand a class by itself, regardless of the possibly rich inheritance structure that led to it. Looking at the Flat view of LIST, you may note how few of its properties come from the class itself; most of the interesting work has been done in ancestors, and LIST just adds a few details. + +{{note|If at any time you want to search for a certain pattern in the views displayed, you can type CTRL-F. A Find bar will come up at the bottom of the pane you are using. If you need more searching power, click the Search icon ([[Image:search-icon]]) in the development window's tool bar to invoke EiffelStudio's [[Search tool]]. }} + +Next come two essential documentation views: Contract and Interface. Based on Eiffel's principles of Design by Contract, they document the interface properties of a class. Unlike the previous two, they do not show actual Eiffel texts, but information useful for client classes. + +The contract form (also known as the '''short form''' of a class) is the class text deprived of any internal detail to retain interface information only. It discards any feature that's not exported (available to all clients); for the retained features, it discards the implementation -- do or once clause -- but retains the header (feature name, arguments, results), the header comment, and the contracts (precondition, postcondition, invariant) minus any contract clause that refers to a non-exported feature and hence would be useless to clients. + +As you will know, particularly if you have read the book [[Object-Oriented Software Construction, 2nd Edition]], the contract form is the preferred way of documenting software elements, especially reusable components, as it provides clients with just the right level of abstraction: precise enough thanks to the type signature and the contracts; clear enough thanks to the header comments; and general enough since it omits implementation details that are irrelevant to client programmers (and might lead them to write client code that won't work any more if the implementation changes). + +In practice you will often want to use, instead of the Contract view, the next one, Interface, also known as "flat-short form" and "flat contract form", which applies the same rules to the flat form rather than to the original class. This means it shows information on all the features of the class, immediate (defined in the class itself) as well as inherited, whereas the short form, non-flat, only considers immediate features. The Interface view provides the complete interface information for the class. Try it now on class LIST. + +The next two buttons are for the Ancestors and Descendants views, which we have already seen, showing classes connected with the target through one of the two inter-class relations, inheritance. After them come Clients and Suppliers, to list the classes connected through the other relation, client. Clicking the Clients button shows the list of clients of LIST. + +Now click the next button to see the Suppliers of LIST. + +The only two classes that LIST needs for its own algorithms are basic types from the Kernel Library, BOOLEAN and INTEGER_32. In Eiffel, as you may remember, all types are defined by classes, even those describing such elementary values as integers and booleans. + + +==Feature information in the Class View== + +Let's resist the natural urge to go see now what the classes INTEGER_32 and BOOLEAN look like, and instead continue our survey of views. The remaining views will all display information about the '''features''' of the class. The first of them, Attributes, lists the attributes. It's not very interesting for LIST, a deferred class with only one attribute -- you can check this for yourself by clicking the Attributes button -- so let's look at the next one. Click the Routines button now to display information about the routines of class LIST : + +[[Image:es gt class tool routines 01]] + +The sections of this display group routines according to the ancestors of LIST -- including LIST itself -- that first introduced them; for example append originally comes from CHAIN and back from BILINEAR. Much of the benefit of this display comes from its support for browsing: all the colored elements, representing classes and features, will be "clickable" hyperlinks. + +The Invariants button shows the complete class invariant for LIST. This includes all invariant clauses that have been inherited from all ancestors. + +Other Class tool buttons display information in the same format as Attributes and Routines. Each selects a specific subset of the target class's features. You can now try any of the others by clicking the corresponding button: +* Deferred features: abstract features which don't have an implementation in the current class, only in eventual descendants. Try this for LIST ; you'll see that this deferred class indeed has a number of deferred features. +* Once and constants: constant attributes, "once functions" which provide shared objects (close to the "singleton" pattern), and once procedures which provide a convenient initialization mechanism. LIST has 'Operating_environment' and 'Io' inherited from the parent class ANY. +* External features, implemented as calls to routines, macros or other elements implemented in other languages. LIST hasn't any. +* Exported features: those available to all clients. LIST has quite a few. + + +==Restoring the look of the development window== + +Once you're done looking at the different views, let's undo the changes that we made to the configuration of the development window at the beginning of this section in '''[[#Making some room|Making some room]]'''. + +Reduce the relative size of the lower pane. + +Then go to one of the tabs on the right margin of the development window, Groups, will work. Hold your cursor over it for a moment and it should expand. Then click the Disable Auto Hide icon, the horizontal pushpin, to restore the rightmost pane. + + + + diff --git a/documentation/18.11/eiffelstudio/_images/16x16--breakpoints-disable-icon.png b/documentation/18.11/eiffelstudio/_images/16x16--breakpoints-disable-icon.png new file mode 100644 index 00000000..0ed72a33 Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/16x16--breakpoints-disable-icon.png differ diff --git a/documentation/18.11/eiffelstudio/_images/16x16--breakpoints-disable-icon.png.data b/documentation/18.11/eiffelstudio/_images/16x16--breakpoints-disable-icon.png.data new file mode 100644 index 00000000..b1d8c6e3 --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/16x16--breakpoints-disable-icon.png.data @@ -0,0 +1,3 @@ +title=16x16--breakpoints-disable-icon +author=admin +path=content/16x16-breakpoints-disable-icon diff --git a/documentation/18.11/eiffelstudio/_images/16x16--breakpoints-enable-icon.png b/documentation/18.11/eiffelstudio/_images/16x16--breakpoints-enable-icon.png new file mode 100644 index 00000000..86478fed Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/16x16--breakpoints-enable-icon.png differ diff --git a/documentation/18.11/eiffelstudio/_images/16x16--breakpoints-enable-icon.png.data b/documentation/18.11/eiffelstudio/_images/16x16--breakpoints-enable-icon.png.data new file mode 100644 index 00000000..2495ee49 --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/16x16--breakpoints-enable-icon.png.data @@ -0,0 +1,3 @@ +title=16x16--breakpoints-enable-icon +author=admin +path=content/16x16-breakpoints-enable-icon diff --git a/documentation/18.11/eiffelstudio/_images/16x16--general-add-icon.png b/documentation/18.11/eiffelstudio/_images/16x16--general-add-icon.png new file mode 100644 index 00000000..efa54325 Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/16x16--general-add-icon.png differ diff --git a/documentation/18.11/eiffelstudio/_images/16x16--general-add-icon.png.data b/documentation/18.11/eiffelstudio/_images/16x16--general-add-icon.png.data new file mode 100644 index 00000000..be124ec5 --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/16x16--general-add-icon.png.data @@ -0,0 +1,3 @@ +title=16x16--general-add-icon +author=admin +path=content/16x16-general-add-icon diff --git a/documentation/18.11/eiffelstudio/_images/16x16--general-copy-icon.png b/documentation/18.11/eiffelstudio/_images/16x16--general-copy-icon.png new file mode 100644 index 00000000..88355a90 Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/16x16--general-copy-icon.png differ diff --git a/documentation/18.11/eiffelstudio/_images/16x16--general-copy-icon.png.data b/documentation/18.11/eiffelstudio/_images/16x16--general-copy-icon.png.data new file mode 100644 index 00000000..f165d2f9 --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/16x16--general-copy-icon.png.data @@ -0,0 +1,3 @@ +title=16x16--general-copy-icon +author=admin +path=content/16x16-general-copy-icon diff --git a/documentation/18.11/eiffelstudio/_images/16x16--general-delete-icon.png b/documentation/18.11/eiffelstudio/_images/16x16--general-delete-icon.png new file mode 100644 index 00000000..fb0c022d Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/16x16--general-delete-icon.png differ diff --git a/documentation/18.11/eiffelstudio/_images/16x16--general-delete-icon.png.data b/documentation/18.11/eiffelstudio/_images/16x16--general-delete-icon.png.data new file mode 100644 index 00000000..4dcba811 --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/16x16--general-delete-icon.png.data @@ -0,0 +1,3 @@ +title=16x16--general-delete-icon +author=admin +path=content/16x16-general-delete-icon diff --git a/documentation/18.11/eiffelstudio/_images/16x16--general-edit-icon.png b/documentation/18.11/eiffelstudio/_images/16x16--general-edit-icon.png new file mode 100644 index 00000000..0d10ac66 Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/16x16--general-edit-icon.png differ diff --git a/documentation/18.11/eiffelstudio/_images/16x16--general-edit-icon.png.data b/documentation/18.11/eiffelstudio/_images/16x16--general-edit-icon.png.data new file mode 100644 index 00000000..72553165 --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/16x16--general-edit-icon.png.data @@ -0,0 +1,3 @@ +title=16x16--general-edit-icon +author=admin +path=content/16x16-general-edit-icon diff --git a/documentation/18.11/eiffelstudio/_images/16x16--general-save-icon.png b/documentation/18.11/eiffelstudio/_images/16x16--general-save-icon.png new file mode 100644 index 00000000..3f6a757c Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/16x16--general-save-icon.png differ diff --git a/documentation/18.11/eiffelstudio/_images/16x16--general-save-icon.png.data b/documentation/18.11/eiffelstudio/_images/16x16--general-save-icon.png.data new file mode 100644 index 00000000..d0bfc509 --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/16x16--general-save-icon.png.data @@ -0,0 +1,3 @@ +title=16x16--general-save-icon +author=admin +path=content/16x16-general-save-icon diff --git a/documentation/18.11/eiffelstudio/_images/16x16--new-class-icon.png b/documentation/18.11/eiffelstudio/_images/16x16--new-class-icon.png new file mode 100644 index 00000000..535b36a4 Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/16x16--new-class-icon.png differ diff --git a/documentation/18.11/eiffelstudio/_images/16x16--new-class-icon.png.data b/documentation/18.11/eiffelstudio/_images/16x16--new-class-icon.png.data new file mode 100644 index 00000000..3bf483d2 --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/16x16--new-class-icon.png.data @@ -0,0 +1,3 @@ +title=16x16--new-class-icon +author=admin +path=content/16x16-new-class-icon diff --git a/documentation/18.11/eiffelstudio/_images/16x16--new-cluster-icon.png b/documentation/18.11/eiffelstudio/_images/16x16--new-cluster-icon.png new file mode 100644 index 00000000..1816187d Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/16x16--new-cluster-icon.png differ diff --git a/documentation/18.11/eiffelstudio/_images/16x16--new-cluster-icon.png.data b/documentation/18.11/eiffelstudio/_images/16x16--new-cluster-icon.png.data new file mode 100644 index 00000000..c07a204c --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/16x16--new-cluster-icon.png.data @@ -0,0 +1,3 @@ +title=16x16--new-cluster-icon +author=admin +path=content/16x16-new-cluster-icon diff --git a/documentation/18.11/eiffelstudio/_images/16x16--new-feature-icon.png b/documentation/18.11/eiffelstudio/_images/16x16--new-feature-icon.png new file mode 100644 index 00000000..e381be28 Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/16x16--new-feature-icon.png differ diff --git a/documentation/18.11/eiffelstudio/_images/16x16--new-feature-icon.png.data b/documentation/18.11/eiffelstudio/_images/16x16--new-feature-icon.png.data new file mode 100644 index 00000000..c5f3e3e9 --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/16x16--new-feature-icon.png.data @@ -0,0 +1,3 @@ +title=16x16--new-feature-icon +author=admin +path=content/16x16-new-feature-icon diff --git a/documentation/18.11/eiffelstudio/_images/56--unix-registration-error.png b/documentation/18.11/eiffelstudio/_images/56--unix-registration-error.png new file mode 100644 index 00000000..633517d8 Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/56--unix-registration-error.png differ diff --git a/documentation/18.11/eiffelstudio/_images/56--unix-registration-error.png.data b/documentation/18.11/eiffelstudio/_images/56--unix-registration-error.png.data new file mode 100644 index 00000000..0663fd3e --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/56--unix-registration-error.png.data @@ -0,0 +1,3 @@ +title=56--unix-registration-error +author=admin +path=content/56-unix-registration-error diff --git a/documentation/18.11/eiffelstudio/_images/56--unix-registration.png b/documentation/18.11/eiffelstudio/_images/56--unix-registration.png new file mode 100644 index 00000000..c9f58cac Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/56--unix-registration.png differ diff --git a/documentation/18.11/eiffelstudio/_images/56--unix-registration.png.data b/documentation/18.11/eiffelstudio/_images/56--unix-registration.png.data new file mode 100644 index 00000000..4fb7ac5c --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/56--unix-registration.png.data @@ -0,0 +1,3 @@ +title=56--unix-registration +author=admin +path=content/56-unix-registration diff --git a/documentation/18.11/eiffelstudio/_images/56--unix-setup.png b/documentation/18.11/eiffelstudio/_images/56--unix-setup.png new file mode 100644 index 00000000..9e67cae6 Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/56--unix-setup.png differ diff --git a/documentation/18.11/eiffelstudio/_images/56--unix-setup.png.data b/documentation/18.11/eiffelstudio/_images/56--unix-setup.png.data new file mode 100644 index 00000000..2c582966 --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/56--unix-setup.png.data @@ -0,0 +1,3 @@ +title=56--unix-setup +author=admin +path=content/56-unix-setup diff --git a/documentation/18.11/eiffelstudio/_images/56--windows-registration-error.png b/documentation/18.11/eiffelstudio/_images/56--windows-registration-error.png new file mode 100644 index 00000000..adb6c4f1 Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/56--windows-registration-error.png differ diff --git a/documentation/18.11/eiffelstudio/_images/56--windows-registration-error.png.data b/documentation/18.11/eiffelstudio/_images/56--windows-registration-error.png.data new file mode 100644 index 00000000..0cff57b9 --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/56--windows-registration-error.png.data @@ -0,0 +1,3 @@ +title=56--windows-registration-error +author=admin +path=content/56-windows-registration-error diff --git a/documentation/18.11/eiffelstudio/_images/56--windows-registration.png b/documentation/18.11/eiffelstudio/_images/56--windows-registration.png new file mode 100644 index 00000000..3721b801 Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/56--windows-registration.png differ diff --git a/documentation/18.11/eiffelstudio/_images/56--windows-registration.png.data b/documentation/18.11/eiffelstudio/_images/56--windows-registration.png.data new file mode 100644 index 00000000..34286628 --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/56--windows-registration.png.data @@ -0,0 +1,3 @@ +title=56--windows-registration +author=admin +path=content/56-windows-registration diff --git a/documentation/18.11/eiffelstudio/_images/Advanced_Options_main.png b/documentation/18.11/eiffelstudio/_images/Advanced_Options_main.png new file mode 100644 index 00000000..7bd4ae4f Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/Advanced_Options_main.png differ diff --git a/documentation/18.11/eiffelstudio/_images/Advanced_Options_main.png.data b/documentation/18.11/eiffelstudio/_images/Advanced_Options_main.png.data new file mode 100644 index 00000000..347fe5b6 --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/Advanced_Options_main.png.data @@ -0,0 +1,3 @@ +title=advanced-options +author=halw +path=content/advanced-options diff --git a/documentation/18.11/eiffelstudio/_images/AutoTest_General_pane.png b/documentation/18.11/eiffelstudio/_images/AutoTest_General_pane.png new file mode 100644 index 00000000..ccd9a268 Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/AutoTest_General_pane.png differ diff --git a/documentation/18.11/eiffelstudio/_images/AutoTest_General_pane.png.data b/documentation/18.11/eiffelstudio/_images/AutoTest_General_pane.png.data new file mode 100644 index 00000000..51360963 --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/AutoTest_General_pane.png.data @@ -0,0 +1,3 @@ +title=AutoTest General pane +author=halw +path=content/autotest-general-pane diff --git a/documentation/18.11/eiffelstudio/_images/AutoTest_General_pane_empty.png b/documentation/18.11/eiffelstudio/_images/AutoTest_General_pane_empty.png new file mode 100644 index 00000000..36287dd1 Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/AutoTest_General_pane_empty.png differ diff --git a/documentation/18.11/eiffelstudio/_images/AutoTest_General_pane_empty.png.data b/documentation/18.11/eiffelstudio/_images/AutoTest_General_pane_empty.png.data new file mode 100644 index 00000000..15199354 --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/AutoTest_General_pane_empty.png.data @@ -0,0 +1,3 @@ +title=AutoTest General pane empty +author=halw +path=content/autotest-general-pane-empty diff --git a/documentation/18.11/eiffelstudio/_images/AutoTest_Interface_after_run_06_0.png b/documentation/18.11/eiffelstudio/_images/AutoTest_Interface_after_run_06_0.png new file mode 100644 index 00000000..8145df7c Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/AutoTest_Interface_after_run_06_0.png differ diff --git a/documentation/18.11/eiffelstudio/_images/AutoTest_Interface_after_run_06_0.png.data b/documentation/18.11/eiffelstudio/_images/AutoTest_Interface_after_run_06_0.png.data new file mode 100644 index 00000000..cc50e305 --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/AutoTest_Interface_after_run_06_0.png.data @@ -0,0 +1,3 @@ +title=AutoTest interface after run 05 +author=halw +path=content/autotest-interface-after-run-05 diff --git a/documentation/18.11/eiffelstudio/_images/AutoTest_Interface_annotated_01.png b/documentation/18.11/eiffelstudio/_images/AutoTest_Interface_annotated_01.png new file mode 100644 index 00000000..0b5c77bb Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/AutoTest_Interface_annotated_01.png differ diff --git a/documentation/18.11/eiffelstudio/_images/AutoTest_Interface_annotated_01.png.data b/documentation/18.11/eiffelstudio/_images/AutoTest_Interface_annotated_01.png.data new file mode 100644 index 00000000..07338a43 --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/AutoTest_Interface_annotated_01.png.data @@ -0,0 +1,3 @@ +title=AutoTest interface annotated 01 +author=halw +path=content/autotest-interface-annotated-01 diff --git a/documentation/18.11/eiffelstudio/_images/AutoTest_Outputs_tool_after_run_01.png b/documentation/18.11/eiffelstudio/_images/AutoTest_Outputs_tool_after_run_01.png new file mode 100644 index 00000000..0d1b9b73 Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/AutoTest_Outputs_tool_after_run_01.png differ diff --git a/documentation/18.11/eiffelstudio/_images/AutoTest_Outputs_tool_after_run_01.png.data b/documentation/18.11/eiffelstudio/_images/AutoTest_Outputs_tool_after_run_01.png.data new file mode 100644 index 00000000..d688af0e --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/AutoTest_Outputs_tool_after_run_01.png.data @@ -0,0 +1,3 @@ +title=AutoTest Outputs tool after run 01 +author=halw +path=content/autotest-outputs-tool-after-run-01 diff --git a/documentation/18.11/eiffelstudio/_images/AutoTest_Tags_pane.png b/documentation/18.11/eiffelstudio/_images/AutoTest_Tags_pane.png new file mode 100644 index 00000000..5a06444b Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/AutoTest_Tags_pane.png differ diff --git a/documentation/18.11/eiffelstudio/_images/AutoTest_Tags_pane.png.data b/documentation/18.11/eiffelstudio/_images/AutoTest_Tags_pane.png.data new file mode 100644 index 00000000..a8a05040 --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/AutoTest_Tags_pane.png.data @@ -0,0 +1,3 @@ +title=AutoTest Tags pane +author=halw +path=content/autotest-tags-pane diff --git a/documentation/18.11/eiffelstudio/_images/AutoTest_Tags_pane_empty.png b/documentation/18.11/eiffelstudio/_images/AutoTest_Tags_pane_empty.png new file mode 100644 index 00000000..50b9f347 Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/AutoTest_Tags_pane_empty.png differ diff --git a/documentation/18.11/eiffelstudio/_images/AutoTest_Tags_pane_empty.png.data b/documentation/18.11/eiffelstudio/_images/AutoTest_Tags_pane_empty.png.data new file mode 100644 index 00000000..6bb7127a --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/AutoTest_Tags_pane_empty.png.data @@ -0,0 +1,3 @@ +title=AutoTest tags pane empty +author=halw +path=content/autotest-tags-pane-empty diff --git a/documentation/18.11/eiffelstudio/_images/AutoTest_Test_Extraction_pane.png b/documentation/18.11/eiffelstudio/_images/AutoTest_Test_Extraction_pane.png new file mode 100644 index 00000000..d3bb2a21 Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/AutoTest_Test_Extraction_pane.png differ diff --git a/documentation/18.11/eiffelstudio/_images/AutoTest_Test_Extraction_pane.png.data b/documentation/18.11/eiffelstudio/_images/AutoTest_Test_Extraction_pane.png.data new file mode 100644 index 00000000..021ecad3 --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/AutoTest_Test_Extraction_pane.png.data @@ -0,0 +1,3 @@ +title=AutoTest Test Extraction pane +author=halw +path=content/autotest-test-extraction-pane diff --git a/documentation/18.11/eiffelstudio/_images/AutoTest_Test_Generation_pane.png b/documentation/18.11/eiffelstudio/_images/AutoTest_Test_Generation_pane.png new file mode 100644 index 00000000..291edbc8 Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/AutoTest_Test_Generation_pane.png differ diff --git a/documentation/18.11/eiffelstudio/_images/AutoTest_Test_Generation_pane.png.data b/documentation/18.11/eiffelstudio/_images/AutoTest_Test_Generation_pane.png.data new file mode 100644 index 00000000..a3d2fa31 --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/AutoTest_Test_Generation_pane.png.data @@ -0,0 +1,3 @@ +title=AutoTest Test Generation pane +author=halw +path=content/autotest-test-generation-pane diff --git a/documentation/18.11/eiffelstudio/_images/AutoTest_add_cluster_dialog.png b/documentation/18.11/eiffelstudio/_images/AutoTest_add_cluster_dialog.png new file mode 100644 index 00000000..7ae45718 Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/AutoTest_add_cluster_dialog.png differ diff --git a/documentation/18.11/eiffelstudio/_images/AutoTest_add_cluster_dialog.png.data b/documentation/18.11/eiffelstudio/_images/AutoTest_add_cluster_dialog.png.data new file mode 100644 index 00000000..12d37d44 --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/AutoTest_add_cluster_dialog.png.data @@ -0,0 +1,3 @@ +title=AutoTest Add Cluster dialog +author=halw +path=content/autotest-add-cluster-dialog diff --git a/documentation/18.11/eiffelstudio/_images/AutoTest_add_testing_libraries_dialog.png b/documentation/18.11/eiffelstudio/_images/AutoTest_add_testing_libraries_dialog.png new file mode 100644 index 00000000..bbee73a9 Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/AutoTest_add_testing_libraries_dialog.png differ diff --git a/documentation/18.11/eiffelstudio/_images/AutoTest_add_testing_libraries_dialog.png.data b/documentation/18.11/eiffelstudio/_images/AutoTest_add_testing_libraries_dialog.png.data new file mode 100644 index 00000000..a0d2b5da --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/AutoTest_add_testing_libraries_dialog.png.data @@ -0,0 +1,3 @@ +title=AutoTest add testing libraries dialog +author=halw +path=content/autotest-add-testing-libraries-dialog diff --git a/documentation/18.11/eiffelstudio/_images/AutoTest_create_manual_test_pane.png b/documentation/18.11/eiffelstudio/_images/AutoTest_create_manual_test_pane.png new file mode 100644 index 00000000..30da04c5 Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/AutoTest_create_manual_test_pane.png differ diff --git a/documentation/18.11/eiffelstudio/_images/AutoTest_create_manual_test_pane.png.data b/documentation/18.11/eiffelstudio/_images/AutoTest_create_manual_test_pane.png.data new file mode 100644 index 00000000..5dd82070 --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/AutoTest_create_manual_test_pane.png.data @@ -0,0 +1,3 @@ +title=AutoTest Manual Test pane +author=halw +path=content/autotest-manual-test-pane diff --git a/documentation/18.11/eiffelstudio/_images/AutoTest_create_new_test_02.png b/documentation/18.11/eiffelstudio/_images/AutoTest_create_new_test_02.png new file mode 100644 index 00000000..40cab741 Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/AutoTest_create_new_test_02.png differ diff --git a/documentation/18.11/eiffelstudio/_images/AutoTest_create_new_test_02.png.data b/documentation/18.11/eiffelstudio/_images/AutoTest_create_new_test_02.png.data new file mode 100644 index 00000000..682de328 --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/AutoTest_create_new_test_02.png.data @@ -0,0 +1,3 @@ +title=AutoTest create new test 02 +author=halw +path=content/autotest-create-new-test-02 diff --git a/documentation/18.11/eiffelstudio/_images/AutoTest_create_new_tests.png b/documentation/18.11/eiffelstudio/_images/AutoTest_create_new_tests.png new file mode 100644 index 00000000..603f45ad Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/AutoTest_create_new_tests.png differ diff --git a/documentation/18.11/eiffelstudio/_images/AutoTest_create_new_tests.png.data b/documentation/18.11/eiffelstudio/_images/AutoTest_create_new_tests.png.data new file mode 100644 index 00000000..9ee5378f --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/AutoTest_create_new_tests.png.data @@ -0,0 +1,3 @@ +title=AutoTest create new test +author=halw +path=content/autotest-create-new-test diff --git a/documentation/18.11/eiffelstudio/_images/AutoTest_debug_all_drop_down.png b/documentation/18.11/eiffelstudio/_images/AutoTest_debug_all_drop_down.png new file mode 100644 index 00000000..7d90bc8e Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/AutoTest_debug_all_drop_down.png differ diff --git a/documentation/18.11/eiffelstudio/_images/AutoTest_debug_all_drop_down.png.data b/documentation/18.11/eiffelstudio/_images/AutoTest_debug_all_drop_down.png.data new file mode 100644 index 00000000..2c61eb98 --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/AutoTest_debug_all_drop_down.png.data @@ -0,0 +1,3 @@ +title=AutoTest debug all drop down +author=halw +path=content/autotest-debug-all-drop-down diff --git a/documentation/18.11/eiffelstudio/_images/AutoTest_debug_all_icon.png b/documentation/18.11/eiffelstudio/_images/AutoTest_debug_all_icon.png new file mode 100644 index 00000000..525c93e8 Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/AutoTest_debug_all_icon.png differ diff --git a/documentation/18.11/eiffelstudio/_images/AutoTest_debug_all_icon.png.data b/documentation/18.11/eiffelstudio/_images/AutoTest_debug_all_icon.png.data new file mode 100644 index 00000000..093c758a --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/AutoTest_debug_all_icon.png.data @@ -0,0 +1,3 @@ +title=AutoTest debug all icon +author=halw +path=content/autotest-debug-all-icon diff --git a/documentation/18.11/eiffelstudio/_images/AutoTest_empty_tool_01.png b/documentation/18.11/eiffelstudio/_images/AutoTest_empty_tool_01.png new file mode 100644 index 00000000..bb1493cd Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/AutoTest_empty_tool_01.png differ diff --git a/documentation/18.11/eiffelstudio/_images/AutoTest_empty_tool_01.png.data b/documentation/18.11/eiffelstudio/_images/AutoTest_empty_tool_01.png.data new file mode 100644 index 00000000..3898c7e6 --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/AutoTest_empty_tool_01.png.data @@ -0,0 +1,3 @@ +title=AutoTest empty tool 01 +author=halw +path=content/autotest-empty-tool-01 diff --git a/documentation/18.11/eiffelstudio/_images/AutoTest_extracted_01.png b/documentation/18.11/eiffelstudio/_images/AutoTest_extracted_01.png new file mode 100644 index 00000000..c411fbfc Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/AutoTest_extracted_01.png differ diff --git a/documentation/18.11/eiffelstudio/_images/AutoTest_extracted_01.png.data b/documentation/18.11/eiffelstudio/_images/AutoTest_extracted_01.png.data new file mode 100644 index 00000000..04a37393 --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/AutoTest_extracted_01.png.data @@ -0,0 +1,3 @@ +title=AutoTest extracted 01 +author=halw +path=content/autotest-extracted-01 diff --git a/documentation/18.11/eiffelstudio/_images/AutoTest_extracted_02.png b/documentation/18.11/eiffelstudio/_images/AutoTest_extracted_02.png new file mode 100644 index 00000000..5181a3ef Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/AutoTest_extracted_02.png differ diff --git a/documentation/18.11/eiffelstudio/_images/AutoTest_extracted_02.png.data b/documentation/18.11/eiffelstudio/_images/AutoTest_extracted_02.png.data new file mode 100644 index 00000000..f0adba46 --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/AutoTest_extracted_02.png.data @@ -0,0 +1,3 @@ +title=AutoTest extracted 02 +author=halw +path=content/autotest-extracted-02 diff --git a/documentation/18.11/eiffelstudio/_images/AutoTest_filter_drop_down.png b/documentation/18.11/eiffelstudio/_images/AutoTest_filter_drop_down.png new file mode 100644 index 00000000..368e8231 Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/AutoTest_filter_drop_down.png differ diff --git a/documentation/18.11/eiffelstudio/_images/AutoTest_filter_drop_down.png.data b/documentation/18.11/eiffelstudio/_images/AutoTest_filter_drop_down.png.data new file mode 100644 index 00000000..c97b199b --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/AutoTest_filter_drop_down.png.data @@ -0,0 +1,3 @@ +title=AutoTest filter drop down +author=halw +path=content/autotest-filter-drop-down diff --git a/documentation/18.11/eiffelstudio/_images/AutoTest_filter_result.png b/documentation/18.11/eiffelstudio/_images/AutoTest_filter_result.png new file mode 100644 index 00000000..eb32790c Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/AutoTest_filter_result.png differ diff --git a/documentation/18.11/eiffelstudio/_images/AutoTest_filter_result.png.data b/documentation/18.11/eiffelstudio/_images/AutoTest_filter_result.png.data new file mode 100644 index 00000000..4d0a02d9 --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/AutoTest_filter_result.png.data @@ -0,0 +1,3 @@ +title=AutoTest filter result +author=halw +path=content/autotest-filter-result diff --git a/documentation/18.11/eiffelstudio/_images/AutoTest_filter_result_fail.png b/documentation/18.11/eiffelstudio/_images/AutoTest_filter_result_fail.png new file mode 100644 index 00000000..178a441a Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/AutoTest_filter_result_fail.png differ diff --git a/documentation/18.11/eiffelstudio/_images/AutoTest_filter_result_fail.png.data b/documentation/18.11/eiffelstudio/_images/AutoTest_filter_result_fail.png.data new file mode 100644 index 00000000..dee4ed69 --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/AutoTest_filter_result_fail.png.data @@ -0,0 +1,3 @@ +title=AutoTest filter result fail +author=halw +path=content/autotest-filter-result-fail diff --git a/documentation/18.11/eiffelstudio/_images/AutoTest_filter_withdraw.png b/documentation/18.11/eiffelstudio/_images/AutoTest_filter_withdraw.png new file mode 100644 index 00000000..ceb2fbd6 Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/AutoTest_filter_withdraw.png differ diff --git a/documentation/18.11/eiffelstudio/_images/AutoTest_filter_withdraw.png.data b/documentation/18.11/eiffelstudio/_images/AutoTest_filter_withdraw.png.data new file mode 100644 index 00000000..99f86879 --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/AutoTest_filter_withdraw.png.data @@ -0,0 +1,3 @@ +title=AutoTest filter withdraw +author=halw +path=content/autotest-filter-withdraw diff --git a/documentation/18.11/eiffelstudio/_images/AutoTest_generated_results_fail.png b/documentation/18.11/eiffelstudio/_images/AutoTest_generated_results_fail.png new file mode 100644 index 00000000..746a0956 Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/AutoTest_generated_results_fail.png differ diff --git a/documentation/18.11/eiffelstudio/_images/AutoTest_generated_results_fail.png.data b/documentation/18.11/eiffelstudio/_images/AutoTest_generated_results_fail.png.data new file mode 100644 index 00000000..10a26473 --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/AutoTest_generated_results_fail.png.data @@ -0,0 +1,3 @@ +title=AutoTest generated results fail +author=halw +path=content/autotest-generated-results-fail diff --git a/documentation/18.11/eiffelstudio/_images/AutoTest_generated_results_pass.png b/documentation/18.11/eiffelstudio/_images/AutoTest_generated_results_pass.png new file mode 100644 index 00000000..698a8a9f Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/AutoTest_generated_results_pass.png differ diff --git a/documentation/18.11/eiffelstudio/_images/AutoTest_generated_results_pass.png.data b/documentation/18.11/eiffelstudio/_images/AutoTest_generated_results_pass.png.data new file mode 100644 index 00000000..1fc7e063 --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/AutoTest_generated_results_pass.png.data @@ -0,0 +1,3 @@ +title=AutoTest generated results pass +author=halw +path=content/autotest-generated-results-pass diff --git a/documentation/18.11/eiffelstudio/_images/AutoTest_information_icon.png b/documentation/18.11/eiffelstudio/_images/AutoTest_information_icon.png new file mode 100644 index 00000000..cf4b949c Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/AutoTest_information_icon.png differ diff --git a/documentation/18.11/eiffelstudio/_images/AutoTest_information_icon.png.data b/documentation/18.11/eiffelstudio/_images/AutoTest_information_icon.png.data new file mode 100644 index 00000000..ad705db4 --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/AutoTest_information_icon.png.data @@ -0,0 +1,3 @@ +title=AutoTest information icon +author=halw +path=content/autotest-information-icon diff --git a/documentation/18.11/eiffelstudio/_images/AutoTest_interface_results_-_Execution.png b/documentation/18.11/eiffelstudio/_images/AutoTest_interface_results_-_Execution.png new file mode 100644 index 00000000..6e3a95fb Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/AutoTest_interface_results_-_Execution.png differ diff --git a/documentation/18.11/eiffelstudio/_images/AutoTest_interface_results_-_Execution.png.data b/documentation/18.11/eiffelstudio/_images/AutoTest_interface_results_-_Execution.png.data new file mode 100644 index 00000000..445c6af4 --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/AutoTest_interface_results_-_Execution.png.data @@ -0,0 +1,3 @@ +title=AutoTest interface results execution +author=halw +path=content/autotest-interface-results-execution diff --git a/documentation/18.11/eiffelstudio/_images/AutoTest_interface_test_view_class.png b/documentation/18.11/eiffelstudio/_images/AutoTest_interface_test_view_class.png new file mode 100644 index 00000000..fde87617 Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/AutoTest_interface_test_view_class.png differ diff --git a/documentation/18.11/eiffelstudio/_images/AutoTest_interface_test_view_class.png.data b/documentation/18.11/eiffelstudio/_images/AutoTest_interface_test_view_class.png.data new file mode 100644 index 00000000..a5745bad --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/AutoTest_interface_test_view_class.png.data @@ -0,0 +1,3 @@ +title=AutoTest interface test view class +author=halw +path=content/autotest-interface-test-view-class diff --git a/documentation/18.11/eiffelstudio/_images/AutoTest_interface_test_view_covers.png b/documentation/18.11/eiffelstudio/_images/AutoTest_interface_test_view_covers.png new file mode 100644 index 00000000..d4e9d5a9 Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/AutoTest_interface_test_view_covers.png differ diff --git a/documentation/18.11/eiffelstudio/_images/AutoTest_interface_test_view_covers.png.data b/documentation/18.11/eiffelstudio/_images/AutoTest_interface_test_view_covers.png.data new file mode 100644 index 00000000..c8acff4c --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/AutoTest_interface_test_view_covers.png.data @@ -0,0 +1,3 @@ +title=AutoTest interface test view covers +author=halw +path=content/autotest-interface-test-view-covers diff --git a/documentation/18.11/eiffelstudio/_images/AutoTest_run_all_drop_down.png b/documentation/18.11/eiffelstudio/_images/AutoTest_run_all_drop_down.png new file mode 100644 index 00000000..d2c0be3e Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/AutoTest_run_all_drop_down.png differ diff --git a/documentation/18.11/eiffelstudio/_images/AutoTest_run_all_drop_down.png.data b/documentation/18.11/eiffelstudio/_images/AutoTest_run_all_drop_down.png.data new file mode 100644 index 00000000..6a37638b --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/AutoTest_run_all_drop_down.png.data @@ -0,0 +1,3 @@ +title=AutoTest run all drop down +author=halw +path=content/autotest-run-all-drop-down diff --git a/documentation/18.11/eiffelstudio/_images/AutoTest_test_coverage_tag_dialog.png b/documentation/18.11/eiffelstudio/_images/AutoTest_test_coverage_tag_dialog.png new file mode 100644 index 00000000..94b1aa1f Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/AutoTest_test_coverage_tag_dialog.png differ diff --git a/documentation/18.11/eiffelstudio/_images/AutoTest_test_coverage_tag_dialog.png.data b/documentation/18.11/eiffelstudio/_images/AutoTest_test_coverage_tag_dialog.png.data new file mode 100644 index 00000000..08b316df --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/AutoTest_test_coverage_tag_dialog.png.data @@ -0,0 +1,3 @@ +title=AutoTest test coverage tag dialog +author=halw +path=content/autotest-test-coverage-tag-dialog diff --git a/documentation/18.11/eiffelstudio/_images/AutoTest_test_results_details_0.png b/documentation/18.11/eiffelstudio/_images/AutoTest_test_results_details_0.png new file mode 100644 index 00000000..273066d6 Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/AutoTest_test_results_details_0.png differ diff --git a/documentation/18.11/eiffelstudio/_images/AutoTest_test_results_details_0.png.data b/documentation/18.11/eiffelstudio/_images/AutoTest_test_results_details_0.png.data new file mode 100644 index 00000000..397473bd --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/AutoTest_test_results_details_0.png.data @@ -0,0 +1,3 @@ +title=AutoTest test results details +author=halw +path=content/autotest-test-results-details diff --git a/documentation/18.11/eiffelstudio/_images/AutoTest_testing_pane_after_generation_01.png b/documentation/18.11/eiffelstudio/_images/AutoTest_testing_pane_after_generation_01.png new file mode 100644 index 00000000..2579d0f7 Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/AutoTest_testing_pane_after_generation_01.png differ diff --git a/documentation/18.11/eiffelstudio/_images/AutoTest_testing_pane_after_generation_01.png.data b/documentation/18.11/eiffelstudio/_images/AutoTest_testing_pane_after_generation_01.png.data new file mode 100644 index 00000000..5e21c00d --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/AutoTest_testing_pane_after_generation_01.png.data @@ -0,0 +1,3 @@ +title=AutoTest testing pane after generation +author=halw +path=content/autotest-testing-pane-after-generation diff --git a/documentation/18.11/eiffelstudio/_images/AutoTest_testing_pane_execution_results.png b/documentation/18.11/eiffelstudio/_images/AutoTest_testing_pane_execution_results.png new file mode 100644 index 00000000..474f8ed2 Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/AutoTest_testing_pane_execution_results.png differ diff --git a/documentation/18.11/eiffelstudio/_images/AutoTest_testing_pane_execution_results.png.data b/documentation/18.11/eiffelstudio/_images/AutoTest_testing_pane_execution_results.png.data new file mode 100644 index 00000000..3c026bd2 --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/AutoTest_testing_pane_execution_results.png.data @@ -0,0 +1,3 @@ +title=AutoTest testing pane execution results +author=halw +path=content/autotest-testing-pane-execution-results diff --git a/documentation/18.11/eiffelstudio/_images/AutoTest_tests_pane_null_filter.png b/documentation/18.11/eiffelstudio/_images/AutoTest_tests_pane_null_filter.png new file mode 100644 index 00000000..11586d26 Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/AutoTest_tests_pane_null_filter.png differ diff --git a/documentation/18.11/eiffelstudio/_images/AutoTest_tests_pane_null_filter.png.data b/documentation/18.11/eiffelstudio/_images/AutoTest_tests_pane_null_filter.png.data new file mode 100644 index 00000000..e57a32f1 --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/AutoTest_tests_pane_null_filter.png.data @@ -0,0 +1,3 @@ +title=AutoTest tests pane null filter +author=halw +path=content/autotest-tests-pane-null-filter diff --git a/documentation/18.11/eiffelstudio/_images/AutoTest_tool_after_run.png b/documentation/18.11/eiffelstudio/_images/AutoTest_tool_after_run.png new file mode 100644 index 00000000..14b8be91 Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/AutoTest_tool_after_run.png differ diff --git a/documentation/18.11/eiffelstudio/_images/AutoTest_tool_after_run.png.data b/documentation/18.11/eiffelstudio/_images/AutoTest_tool_after_run.png.data new file mode 100644 index 00000000..ed5ae1d6 --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/AutoTest_tool_after_run.png.data @@ -0,0 +1,3 @@ +title=AutoTest tool after run +author=halw +path=content/autotest-tool-after-run diff --git a/documentation/18.11/eiffelstudio/_images/AutoTest_tool_with_failed_test.png b/documentation/18.11/eiffelstudio/_images/AutoTest_tool_with_failed_test.png new file mode 100644 index 00000000..d9e109c1 Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/AutoTest_tool_with_failed_test.png differ diff --git a/documentation/18.11/eiffelstudio/_images/AutoTest_tool_with_failed_test.png.data b/documentation/18.11/eiffelstudio/_images/AutoTest_tool_with_failed_test.png.data new file mode 100644 index 00000000..5fb2b848 --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/AutoTest_tool_with_failed_test.png.data @@ -0,0 +1,3 @@ +title=AutoTest tool with failed test +author=halw +path=content/autotest-tool-failed-test diff --git a/documentation/18.11/eiffelstudio/_images/AutoTest_tool_with_passed_test.png b/documentation/18.11/eiffelstudio/_images/AutoTest_tool_with_passed_test.png new file mode 100644 index 00000000..071b5c4a Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/AutoTest_tool_with_passed_test.png differ diff --git a/documentation/18.11/eiffelstudio/_images/AutoTest_tool_with_passed_test.png.data b/documentation/18.11/eiffelstudio/_images/AutoTest_tool_with_passed_test.png.data new file mode 100644 index 00000000..08b32a01 --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/AutoTest_tool_with_passed_test.png.data @@ -0,0 +1,3 @@ +title=AutoTest tool with passed test +author=halw +path=content/autotest-tool-passed-test diff --git a/documentation/18.11/eiffelstudio/_images/AutoTest_tool_with_test.png b/documentation/18.11/eiffelstudio/_images/AutoTest_tool_with_test.png new file mode 100644 index 00000000..b25961ed Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/AutoTest_tool_with_test.png differ diff --git a/documentation/18.11/eiffelstudio/_images/AutoTest_tool_with_test.png.data b/documentation/18.11/eiffelstudio/_images/AutoTest_tool_with_test.png.data new file mode 100644 index 00000000..ac244d7b --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/AutoTest_tool_with_test.png.data @@ -0,0 +1,3 @@ +title=AutoTest tool with test +author=halw +path=content/autotest-tool-test diff --git a/documentation/18.11/eiffelstudio/_images/AutoTest_user_defined_tag_root.png b/documentation/18.11/eiffelstudio/_images/AutoTest_user_defined_tag_root.png new file mode 100644 index 00000000..a6f8ff3a Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/AutoTest_user_defined_tag_root.png differ diff --git a/documentation/18.11/eiffelstudio/_images/AutoTest_user_defined_tag_root.png.data b/documentation/18.11/eiffelstudio/_images/AutoTest_user_defined_tag_root.png.data new file mode 100644 index 00000000..6ad1ad45 --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/AutoTest_user_defined_tag_root.png.data @@ -0,0 +1,3 @@ +title=AutoTest user defined tag root +author=halw +path=content/autotest-user-defined-tag-root diff --git a/documentation/18.11/eiffelstudio/_images/Automatic_class_license_Eiffel_Software_directory.png b/documentation/18.11/eiffelstudio/_images/Automatic_class_license_Eiffel_Software_directory.png new file mode 100644 index 00000000..d1d8dc84 Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/Automatic_class_license_Eiffel_Software_directory.png differ diff --git a/documentation/18.11/eiffelstudio/_images/Automatic_class_license_Eiffel_Software_directory.png.data b/documentation/18.11/eiffelstudio/_images/Automatic_class_license_Eiffel_Software_directory.png.data new file mode 100644 index 00000000..63d35be1 --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/Automatic_class_license_Eiffel_Software_directory.png.data @@ -0,0 +1,3 @@ +title=Automatic class license Eiffel Software directory +author=halw +path=content/automatic-class-license-eiffel-software-directory diff --git a/documentation/18.11/eiffelstudio/_images/Automatic_class_license_project_directory.png b/documentation/18.11/eiffelstudio/_images/Automatic_class_license_project_directory.png new file mode 100644 index 00000000..353bca71 Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/Automatic_class_license_project_directory.png differ diff --git a/documentation/18.11/eiffelstudio/_images/Automatic_class_license_project_directory.png.data b/documentation/18.11/eiffelstudio/_images/Automatic_class_license_project_directory.png.data new file mode 100644 index 00000000..49a99424 --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/Automatic_class_license_project_directory.png.data @@ -0,0 +1,3 @@ +title=Automatic class license project directory +author=halw +path=content/automatic-class-license-project-directory diff --git a/documentation/18.11/eiffelstudio/_images/Automatic_class_license_user_files_directory.png b/documentation/18.11/eiffelstudio/_images/Automatic_class_license_user_files_directory.png new file mode 100644 index 00000000..7f105c19 Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/Automatic_class_license_user_files_directory.png differ diff --git a/documentation/18.11/eiffelstudio/_images/Automatic_class_license_user_files_directory.png.data b/documentation/18.11/eiffelstudio/_images/Automatic_class_license_user_files_directory.png.data new file mode 100644 index 00000000..79cad87e --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/Automatic_class_license_user_files_directory.png.data @@ -0,0 +1,3 @@ +title=Automatic class license Eiffel user files directory +author=halw +path=content/automatic-class-license-eiffel-user-files-directory diff --git a/documentation/18.11/eiffelstudio/_images/CA_Analysis_Buttons.png b/documentation/18.11/eiffelstudio/_images/CA_Analysis_Buttons.png new file mode 100644 index 00000000..8aaf732c Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/CA_Analysis_Buttons.png differ diff --git a/documentation/18.11/eiffelstudio/_images/CA_Analysis_Buttons.png.data b/documentation/18.11/eiffelstudio/_images/CA_Analysis_Buttons.png.data new file mode 100644 index 00000000..2f413625 --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/CA_Analysis_Buttons.png.data @@ -0,0 +1,2 @@ +title=CA Analysis Buttons +path=content/CA_Analysis_Buttons.png diff --git a/documentation/18.11/eiffelstudio/_images/CA_Class_Context_Menu.png b/documentation/18.11/eiffelstudio/_images/CA_Class_Context_Menu.png new file mode 100644 index 00000000..bb1360b6 Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/CA_Class_Context_Menu.png differ diff --git a/documentation/18.11/eiffelstudio/_images/CA_Class_Context_Menu.png.data b/documentation/18.11/eiffelstudio/_images/CA_Class_Context_Menu.png.data new file mode 100644 index 00000000..7a512fbe --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/CA_Class_Context_Menu.png.data @@ -0,0 +1,2 @@ +title=CA Class Context Menu +path=content/CA_Class_Context_Menu.png diff --git a/documentation/18.11/eiffelstudio/_images/CA_Cluster_Context_Menu.png b/documentation/18.11/eiffelstudio/_images/CA_Cluster_Context_Menu.png new file mode 100644 index 00000000..94a5d3cc Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/CA_Cluster_Context_Menu.png differ diff --git a/documentation/18.11/eiffelstudio/_images/CA_Cluster_Context_Menu.png.data b/documentation/18.11/eiffelstudio/_images/CA_Cluster_Context_Menu.png.data new file mode 100644 index 00000000..793c2081 --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/CA_Cluster_Context_Menu.png.data @@ -0,0 +1,2 @@ +title=CA Cluster Context Menu +path=content/CA_Cluster_Context_Menu.png diff --git a/documentation/18.11/eiffelstudio/_images/CA_Fixing.png b/documentation/18.11/eiffelstudio/_images/CA_Fixing.png new file mode 100644 index 00000000..94e2128c Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/CA_Fixing.png differ diff --git a/documentation/18.11/eiffelstudio/_images/CA_Fixing.png.data b/documentation/18.11/eiffelstudio/_images/CA_Fixing.png.data new file mode 100644 index 00000000..eb6063cb --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/CA_Fixing.png.data @@ -0,0 +1,2 @@ +title=CA Fixing Rule Violation +path=content/CA_Fixing.png diff --git a/documentation/18.11/eiffelstudio/_images/CA_Preferences_Dialog.png b/documentation/18.11/eiffelstudio/_images/CA_Preferences_Dialog.png new file mode 100644 index 00000000..13369061 Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/CA_Preferences_Dialog.png differ diff --git a/documentation/18.11/eiffelstudio/_images/CA_Preferences_Dialog.png.data b/documentation/18.11/eiffelstudio/_images/CA_Preferences_Dialog.png.data new file mode 100644 index 00000000..528a649e --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/CA_Preferences_Dialog.png.data @@ -0,0 +1,2 @@ +title=CA Preference Dialog +path=content/CA_Preferences_Dialog.png diff --git a/documentation/18.11/eiffelstudio/_images/CA_Rule_Preferences.png b/documentation/18.11/eiffelstudio/_images/CA_Rule_Preferences.png new file mode 100644 index 00000000..037d940e Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/CA_Rule_Preferences.png differ diff --git a/documentation/18.11/eiffelstudio/_images/CA_Rule_Preferences.png.data b/documentation/18.11/eiffelstudio/_images/CA_Rule_Preferences.png.data new file mode 100644 index 00000000..bdf89919 --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/CA_Rule_Preferences.png.data @@ -0,0 +1,2 @@ +title=CA Rule Preferences +path=content/CA_Rule_Preferences.png diff --git a/documentation/18.11/eiffelstudio/_images/CA_Sample_Results.png b/documentation/18.11/eiffelstudio/_images/CA_Sample_Results.png new file mode 100644 index 00000000..782eb8fd Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/CA_Sample_Results.png differ diff --git a/documentation/18.11/eiffelstudio/_images/CA_Sample_Results.png.data b/documentation/18.11/eiffelstudio/_images/CA_Sample_Results.png.data new file mode 100644 index 00000000..178c5975 --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/CA_Sample_Results.png.data @@ -0,0 +1,2 @@ +title=CA Simple Analysis +path=content/CA_Sample_Results.png diff --git a/documentation/18.11/eiffelstudio/_images/Ca_empty-tool-panel.png b/documentation/18.11/eiffelstudio/_images/Ca_empty-tool-panel.png new file mode 100644 index 00000000..542b1530 Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/Ca_empty-tool-panel.png differ diff --git a/documentation/18.11/eiffelstudio/_images/Ca_empty-tool-panel.png.data b/documentation/18.11/eiffelstudio/_images/Ca_empty-tool-panel.png.data new file mode 100644 index 00000000..9dbf267c --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/Ca_empty-tool-panel.png.data @@ -0,0 +1,2 @@ +title=Eiffel Inspector - Tool Panel +path=content/Ca_empty-tool-panel.png diff --git a/documentation/18.11/eiffelstudio/_images/Create_new_tests_2.png b/documentation/18.11/eiffelstudio/_images/Create_new_tests_2.png new file mode 100644 index 00000000..2122892d Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/Create_new_tests_2.png differ diff --git a/documentation/18.11/eiffelstudio/_images/Create_new_tests_2.png.data b/documentation/18.11/eiffelstudio/_images/Create_new_tests_2.png.data new file mode 100644 index 00000000..94a996b9 --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/Create_new_tests_2.png.data @@ -0,0 +1,3 @@ +title=Create new tests +author=halw +path=content/create-new-tests diff --git a/documentation/18.11/eiffelstudio/_images/Customize_toolbar_dialog.png b/documentation/18.11/eiffelstudio/_images/Customize_toolbar_dialog.png new file mode 100644 index 00000000..19f290e6 Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/Customize_toolbar_dialog.png differ diff --git a/documentation/18.11/eiffelstudio/_images/Customize_toolbar_dialog.png.data b/documentation/18.11/eiffelstudio/_images/Customize_toolbar_dialog.png.data new file mode 100644 index 00000000..9876424f --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/Customize_toolbar_dialog.png.data @@ -0,0 +1,3 @@ +title=Customize toolbar dialog +author=halw +path=content/customize-toolbar-dialog diff --git a/documentation/18.11/eiffelstudio/_images/EIS_add_button.png b/documentation/18.11/eiffelstudio/_images/EIS_add_button.png new file mode 100644 index 00000000..e4a32422 Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/EIS_add_button.png differ diff --git a/documentation/18.11/eiffelstudio/_images/EIS_add_button.png.data b/documentation/18.11/eiffelstudio/_images/EIS_add_button.png.data new file mode 100644 index 00000000..065fdf75 --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/EIS_add_button.png.data @@ -0,0 +1,3 @@ +title=EIS add button +author=halw +path=content/eis-add-button diff --git a/documentation/18.11/eiffelstudio/_images/EIS_affected_source.png b/documentation/18.11/eiffelstudio/_images/EIS_affected_source.png new file mode 100644 index 00000000..7107509f Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/EIS_affected_source.png differ diff --git a/documentation/18.11/eiffelstudio/_images/EIS_affected_source.png.data b/documentation/18.11/eiffelstudio/_images/EIS_affected_source.png.data new file mode 100644 index 00000000..418063be --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/EIS_affected_source.png.data @@ -0,0 +1,3 @@ +title=Information Tool change analysis +author=tedf +path=content/information-tool-change-analysis diff --git a/documentation/18.11/eiffelstudio/_images/EIS_info_tabl.png b/documentation/18.11/eiffelstudio/_images/EIS_info_tabl.png new file mode 100644 index 00000000..d87d321a Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/EIS_info_tabl.png differ diff --git a/documentation/18.11/eiffelstudio/_images/EIS_info_tabl.png.data b/documentation/18.11/eiffelstudio/_images/EIS_info_tabl.png.data new file mode 100644 index 00000000..32d6a013 --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/EIS_info_tabl.png.data @@ -0,0 +1,3 @@ +title=EIS info tab +author=halw +path=content/eis-info-tab diff --git a/documentation/18.11/eiffelstudio/_images/EIS_information_icon.png b/documentation/18.11/eiffelstudio/_images/EIS_information_icon.png new file mode 100644 index 00000000..315696c7 Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/EIS_information_icon.png differ diff --git a/documentation/18.11/eiffelstudio/_images/EIS_information_icon.png.data b/documentation/18.11/eiffelstudio/_images/EIS_information_icon.png.data new file mode 100644 index 00000000..919df111 --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/EIS_information_icon.png.data @@ -0,0 +1,3 @@ +title=EIS information icon +author=halw +path=content/eis-information-icon diff --git a/documentation/18.11/eiffelstudio/_images/EIS_locate_class_or_cluster_icon.png b/documentation/18.11/eiffelstudio/_images/EIS_locate_class_or_cluster_icon.png new file mode 100644 index 00000000..c00a79e0 Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/EIS_locate_class_or_cluster_icon.png differ diff --git a/documentation/18.11/eiffelstudio/_images/EIS_locate_class_or_cluster_icon.png.data b/documentation/18.11/eiffelstudio/_images/EIS_locate_class_or_cluster_icon.png.data new file mode 100644 index 00000000..e28d503b --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/EIS_locate_class_or_cluster_icon.png.data @@ -0,0 +1,3 @@ +title=EIS locate class or cluster icon +author=halw +path=content/eis-locate-class-or-cluster-icon diff --git a/documentation/18.11/eiffelstudio/_images/Eiffel_Inspector-command_line_0.png b/documentation/18.11/eiffelstudio/_images/Eiffel_Inspector-command_line_0.png new file mode 100644 index 00000000..4f4a4179 Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/Eiffel_Inspector-command_line_0.png differ diff --git a/documentation/18.11/eiffelstudio/_images/Eiffel_Inspector-command_line_0.png.data b/documentation/18.11/eiffelstudio/_images/Eiffel_Inspector-command_line_0.png.data new file mode 100644 index 00000000..f03e71af --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/Eiffel_Inspector-command_line_0.png.data @@ -0,0 +1,2 @@ +title=Eiffel Inspector Command Line +path=content/Eiffel_Inspector-command_line_0.png diff --git a/documentation/18.11/eiffelstudio/_images/External_commands_tools_menu_0.png b/documentation/18.11/eiffelstudio/_images/External_commands_tools_menu_0.png new file mode 100644 index 00000000..5286c907 Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/External_commands_tools_menu_0.png differ diff --git a/documentation/18.11/eiffelstudio/_images/External_commands_tools_menu_0.png.data b/documentation/18.11/eiffelstudio/_images/External_commands_tools_menu_0.png.data new file mode 100644 index 00000000..c51a372b --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/External_commands_tools_menu_0.png.data @@ -0,0 +1,3 @@ +title=External commands tools menu +author=halw +path=content/external-commands-tools-menu diff --git a/documentation/18.11/eiffelstudio/_images/External_compilation_pane_edit_feature.png b/documentation/18.11/eiffelstudio/_images/External_compilation_pane_edit_feature.png new file mode 100644 index 00000000..83afe0e1 Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/External_compilation_pane_edit_feature.png differ diff --git a/documentation/18.11/eiffelstudio/_images/External_compilation_pane_edit_feature.png.data b/documentation/18.11/eiffelstudio/_images/External_compilation_pane_edit_feature.png.data new file mode 100644 index 00000000..e7eff856 --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/External_compilation_pane_edit_feature.png.data @@ -0,0 +1,3 @@ +title=External compilation pane edit feature +author=halw +path=content/external-compilation-pane-edit-feature diff --git a/documentation/18.11/eiffelstudio/_images/External_compilation_pane_file_selection.png b/documentation/18.11/eiffelstudio/_images/External_compilation_pane_file_selection.png new file mode 100644 index 00000000..313b3eff Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/External_compilation_pane_file_selection.png differ diff --git a/documentation/18.11/eiffelstudio/_images/External_compilation_pane_file_selection.png.data b/documentation/18.11/eiffelstudio/_images/External_compilation_pane_file_selection.png.data new file mode 100644 index 00000000..929837e9 --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/External_compilation_pane_file_selection.png.data @@ -0,0 +1,3 @@ +title=External compilation pane file selection +author=halw +path=content/external-compilation-pane-file-selection diff --git a/documentation/18.11/eiffelstudio/_images/External_compilation_tool_01.png b/documentation/18.11/eiffelstudio/_images/External_compilation_tool_01.png new file mode 100644 index 00000000..2e481a85 Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/External_compilation_tool_01.png differ diff --git a/documentation/18.11/eiffelstudio/_images/External_compilation_tool_01.png.data b/documentation/18.11/eiffelstudio/_images/External_compilation_tool_01.png.data new file mode 100644 index 00000000..6263f26a --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/External_compilation_tool_01.png.data @@ -0,0 +1,3 @@ +title=External compilation pane 01 +author=halw +path=content/external-compilation-pane-01 diff --git a/documentation/18.11/eiffelstudio/_images/GenTargetOptions_Edit_Exclude_Rule_Condition.png b/documentation/18.11/eiffelstudio/_images/GenTargetOptions_Edit_Exclude_Rule_Condition.png new file mode 100644 index 00000000..86855735 Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/GenTargetOptions_Edit_Exclude_Rule_Condition.png differ diff --git a/documentation/18.11/eiffelstudio/_images/GenTargetOptions_Edit_Exclude_Rule_Condition.png.data b/documentation/18.11/eiffelstudio/_images/GenTargetOptions_Edit_Exclude_Rule_Condition.png.data new file mode 100644 index 00000000..2a0a0551 --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/GenTargetOptions_Edit_Exclude_Rule_Condition.png.data @@ -0,0 +1,3 @@ +title=condition-dialog +author=halw +path=content/condition-dialog diff --git a/documentation/18.11/eiffelstudio/_images/GenTargetOptions_Edit_Exclude_Rules.png b/documentation/18.11/eiffelstudio/_images/GenTargetOptions_Edit_Exclude_Rules.png new file mode 100644 index 00000000..b0971e8e Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/GenTargetOptions_Edit_Exclude_Rules.png differ diff --git a/documentation/18.11/eiffelstudio/_images/GenTargetOptions_Edit_Exclude_Rules.png.data b/documentation/18.11/eiffelstudio/_images/GenTargetOptions_Edit_Exclude_Rules.png.data new file mode 100644 index 00000000..c1420713 --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/GenTargetOptions_Edit_Exclude_Rules.png.data @@ -0,0 +1,3 @@ +title=exclude-dialog +author=halw +path=content/exclude-dialog diff --git a/documentation/18.11/eiffelstudio/_images/GenTargetOptions_Edit_Root.png b/documentation/18.11/eiffelstudio/_images/GenTargetOptions_Edit_Root.png new file mode 100644 index 00000000..e771bb0d Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/GenTargetOptions_Edit_Root.png differ diff --git a/documentation/18.11/eiffelstudio/_images/GenTargetOptions_Edit_Root.png.data b/documentation/18.11/eiffelstudio/_images/GenTargetOptions_Edit_Root.png.data new file mode 100644 index 00000000..2b173b11 --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/GenTargetOptions_Edit_Root.png.data @@ -0,0 +1,3 @@ +title=root-dialog +author=halw +path=content/root-dialog diff --git a/documentation/18.11/eiffelstudio/_images/GenTargetOptions_Edit_Version.png b/documentation/18.11/eiffelstudio/_images/GenTargetOptions_Edit_Version.png new file mode 100644 index 00000000..42071d1c Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/GenTargetOptions_Edit_Version.png differ diff --git a/documentation/18.11/eiffelstudio/_images/GenTargetOptions_Edit_Version.png.data b/documentation/18.11/eiffelstudio/_images/GenTargetOptions_Edit_Version.png.data new file mode 100644 index 00000000..70098e97 --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/GenTargetOptions_Edit_Version.png.data @@ -0,0 +1,3 @@ +title=version-dialog +author=halw +path=content/version-dialog diff --git a/documentation/18.11/eiffelstudio/_images/GenTargetOptions_Proj_Settings.png b/documentation/18.11/eiffelstudio/_images/GenTargetOptions_Proj_Settings.png new file mode 100644 index 00000000..4ef40d3e Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/GenTargetOptions_Proj_Settings.png differ diff --git a/documentation/18.11/eiffelstudio/_images/GenTargetOptions_Proj_Settings.png.data b/documentation/18.11/eiffelstudio/_images/GenTargetOptions_Proj_Settings.png.data new file mode 100644 index 00000000..04c4c47f --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/GenTargetOptions_Proj_Settings.png.data @@ -0,0 +1,3 @@ +title=target-options +author=halw +path=content/target-options diff --git a/documentation/18.11/eiffelstudio/_images/Group_Options_Edit_Visible_Classes.png b/documentation/18.11/eiffelstudio/_images/Group_Options_Edit_Visible_Classes.png new file mode 100644 index 00000000..88eda268 Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/Group_Options_Edit_Visible_Classes.png differ diff --git a/documentation/18.11/eiffelstudio/_images/Group_Options_Edit_Visible_Classes.png.data b/documentation/18.11/eiffelstudio/_images/Group_Options_Edit_Visible_Classes.png.data new file mode 100644 index 00000000..129a282c --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/Group_Options_Edit_Visible_Classes.png.data @@ -0,0 +1,3 @@ +title=visible-dialog +author=halw +path=content/visible-dialog diff --git a/documentation/18.11/eiffelstudio/_images/Group_Options_main.png b/documentation/18.11/eiffelstudio/_images/Group_Options_main.png new file mode 100644 index 00000000..78a2c0ff Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/Group_Options_main.png differ diff --git a/documentation/18.11/eiffelstudio/_images/Group_Options_main.png.data b/documentation/18.11/eiffelstudio/_images/Group_Options_main.png.data new file mode 100644 index 00000000..105a37b2 --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/Group_Options_main.png.data @@ -0,0 +1,3 @@ +title=group-options +author=halw +path=content/group-options diff --git a/documentation/18.11/eiffelstudio/_images/Implementation venn diagram.png b/documentation/18.11/eiffelstudio/_images/Implementation venn diagram.png new file mode 100644 index 00000000..8e60ec0a Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/Implementation venn diagram.png differ diff --git a/documentation/18.11/eiffelstudio/_images/Implementation venn diagram.png.data b/documentation/18.11/eiffelstudio/_images/Implementation venn diagram.png.data new file mode 100644 index 00000000..89a3b7f0 --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/Implementation venn diagram.png.data @@ -0,0 +1,3 @@ +title=Eiffel implementation venn diagram +author=admin +path=content/eiffel-implementation-venn-diagram diff --git a/documentation/18.11/eiffelstudio/_images/Metrics_tool_Metrics_evaluation_pane.png b/documentation/18.11/eiffelstudio/_images/Metrics_tool_Metrics_evaluation_pane.png new file mode 100644 index 00000000..0ea5bd67 Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/Metrics_tool_Metrics_evaluation_pane.png differ diff --git a/documentation/18.11/eiffelstudio/_images/Metrics_tool_Metrics_evaluation_pane.png.data b/documentation/18.11/eiffelstudio/_images/Metrics_tool_Metrics_evaluation_pane.png.data new file mode 100644 index 00000000..6a503e0e --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/Metrics_tool_Metrics_evaluation_pane.png.data @@ -0,0 +1,3 @@ +title=Metrics tool Metrics evaluation pane +author=halw +path=content/metrics-tool-metrics-evaluation-pane diff --git a/documentation/18.11/eiffelstudio/_images/Output_tool_02.png b/documentation/18.11/eiffelstudio/_images/Output_tool_02.png new file mode 100644 index 00000000..284554e3 Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/Output_tool_02.png differ diff --git a/documentation/18.11/eiffelstudio/_images/Output_tool_02.png.data b/documentation/18.11/eiffelstudio/_images/Output_tool_02.png.data new file mode 100644 index 00000000..c3e68932 --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/Output_tool_02.png.data @@ -0,0 +1,3 @@ +title=Outputs tool 02 +author=halw +path=content/outputs-tool-02 diff --git a/documentation/18.11/eiffelstudio/_images/Outputs_tool_01.png b/documentation/18.11/eiffelstudio/_images/Outputs_tool_01.png new file mode 100644 index 00000000..409c3d84 Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/Outputs_tool_01.png differ diff --git a/documentation/18.11/eiffelstudio/_images/Outputs_tool_01.png.data b/documentation/18.11/eiffelstudio/_images/Outputs_tool_01.png.data new file mode 100644 index 00000000..1ed68b62 --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/Outputs_tool_01.png.data @@ -0,0 +1,3 @@ +title=Outputs tool 01 +author=halw +path=content/outputs-tool-01 diff --git a/documentation/18.11/eiffelstudio/_images/Outputs_tool_General_pane.png b/documentation/18.11/eiffelstudio/_images/Outputs_tool_General_pane.png new file mode 100644 index 00000000..581e8db0 Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/Outputs_tool_General_pane.png differ diff --git a/documentation/18.11/eiffelstudio/_images/Outputs_tool_General_pane.png.data b/documentation/18.11/eiffelstudio/_images/Outputs_tool_General_pane.png.data new file mode 100644 index 00000000..2a09958c --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/Outputs_tool_General_pane.png.data @@ -0,0 +1,3 @@ +title=Outputs tool General pane +author=halw +path=content/outputs-tool-general-pane diff --git a/documentation/18.11/eiffelstudio/_images/Outputs_tool_Open_folder.png b/documentation/18.11/eiffelstudio/_images/Outputs_tool_Open_folder.png new file mode 100644 index 00000000..3f4b22ec Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/Outputs_tool_Open_folder.png differ diff --git a/documentation/18.11/eiffelstudio/_images/Outputs_tool_Open_folder.png.data b/documentation/18.11/eiffelstudio/_images/Outputs_tool_Open_folder.png.data new file mode 100644 index 00000000..43f450a0 --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/Outputs_tool_Open_folder.png.data @@ -0,0 +1,3 @@ +title=Outputs tool Open folder +author=halw +path=content/outputs-tool-open-folder diff --git a/documentation/18.11/eiffelstudio/_images/Outputs_tool_Transient_functionality.png b/documentation/18.11/eiffelstudio/_images/Outputs_tool_Transient_functionality.png new file mode 100644 index 00000000..d0a82756 Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/Outputs_tool_Transient_functionality.png differ diff --git a/documentation/18.11/eiffelstudio/_images/Outputs_tool_Transient_functionality.png.data b/documentation/18.11/eiffelstudio/_images/Outputs_tool_Transient_functionality.png.data new file mode 100644 index 00000000..0b062c4b --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/Outputs_tool_Transient_functionality.png.data @@ -0,0 +1,3 @@ +title=Outputs tool transient functionality +author=halw +path=content/outputs-tool-transient-functionality diff --git a/documentation/18.11/eiffelstudio/_images/Search_capture_boxes_0.png b/documentation/18.11/eiffelstudio/_images/Search_capture_boxes_0.png new file mode 100644 index 00000000..198a655e Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/Search_capture_boxes_0.png differ diff --git a/documentation/18.11/eiffelstudio/_images/Search_capture_boxes_0.png.data b/documentation/18.11/eiffelstudio/_images/Search_capture_boxes_0.png.data new file mode 100644 index 00000000..20d54bdc --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/Search_capture_boxes_0.png.data @@ -0,0 +1,3 @@ +title=Search capture boxes +author=halw +path=content/search-capture-boxes diff --git a/documentation/18.11/eiffelstudio/_images/Select_Help_Document_dialog.png b/documentation/18.11/eiffelstudio/_images/Select_Help_Document_dialog.png new file mode 100644 index 00000000..378336e7 Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/Select_Help_Document_dialog.png differ diff --git a/documentation/18.11/eiffelstudio/_images/Select_Help_Document_dialog.png.data b/documentation/18.11/eiffelstudio/_images/Select_Help_Document_dialog.png.data new file mode 100644 index 00000000..dc3ef320 --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/Select_Help_Document_dialog.png.data @@ -0,0 +1,3 @@ +title=select help document dialog +author=halw +path=content/select-help-document-dialog diff --git a/documentation/18.11/eiffelstudio/_images/Subversion_update_command_01.png b/documentation/18.11/eiffelstudio/_images/Subversion_update_command_01.png new file mode 100644 index 00000000..3b541249 Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/Subversion_update_command_01.png differ diff --git a/documentation/18.11/eiffelstudio/_images/Subversion_update_command_01.png.data b/documentation/18.11/eiffelstudio/_images/Subversion_update_command_01.png.data new file mode 100644 index 00000000..07f5ac2f --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/Subversion_update_command_01.png.data @@ -0,0 +1,3 @@ +title=subversion-update-command-01 +author=halw +path=content/subversion-update-command-01 diff --git a/documentation/18.11/eiffelstudio/_images/address-toolbar.png b/documentation/18.11/eiffelstudio/_images/address-toolbar.png new file mode 100644 index 00000000..e7c5e047 Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/address-toolbar.png differ diff --git a/documentation/18.11/eiffelstudio/_images/address-toolbar.png.data b/documentation/18.11/eiffelstudio/_images/address-toolbar.png.data new file mode 100644 index 00000000..cf65d59f --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/address-toolbar.png.data @@ -0,0 +1,3 @@ +title=address-toolbar +author=halw +path=content/address-toolbar diff --git a/documentation/18.11/eiffelstudio/_images/argument-dialog.png b/documentation/18.11/eiffelstudio/_images/argument-dialog.png new file mode 100644 index 00000000..609eb497 Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/argument-dialog.png differ diff --git a/documentation/18.11/eiffelstudio/_images/argument-dialog.png.data b/documentation/18.11/eiffelstudio/_images/argument-dialog.png.data new file mode 100644 index 00000000..fc11051d --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/argument-dialog.png.data @@ -0,0 +1,3 @@ +title=argument-dialog +author=admin +path=content/argument-dialog diff --git a/documentation/18.11/eiffelstudio/_images/assertion-options-2.png b/documentation/18.11/eiffelstudio/_images/assertion-options-2.png new file mode 100644 index 00000000..3a00d9fa Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/assertion-options-2.png differ diff --git a/documentation/18.11/eiffelstudio/_images/assertion-options-2.png.data b/documentation/18.11/eiffelstudio/_images/assertion-options-2.png.data new file mode 100644 index 00000000..94f70382 --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/assertion-options-2.png.data @@ -0,0 +1,3 @@ +title=assertion-options +author=halw +path=content/assertion-options diff --git a/documentation/18.11/eiffelstudio/_images/auto-hide-icon.png b/documentation/18.11/eiffelstudio/_images/auto-hide-icon.png new file mode 100644 index 00000000..7010127b Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/auto-hide-icon.png differ diff --git a/documentation/18.11/eiffelstudio/_images/auto-hide-icon.png.data b/documentation/18.11/eiffelstudio/_images/auto-hide-icon.png.data new file mode 100644 index 00000000..7f8b143c --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/auto-hide-icon.png.data @@ -0,0 +1,3 @@ +title=auto-hide-icon +author=halw +path=content/auto-hide-icon diff --git a/documentation/18.11/eiffelstudio/_images/automatic-sweeping.png b/documentation/18.11/eiffelstudio/_images/automatic-sweeping.png new file mode 100644 index 00000000..8e551049 Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/automatic-sweeping.png differ diff --git a/documentation/18.11/eiffelstudio/_images/automatic-sweeping.png.data b/documentation/18.11/eiffelstudio/_images/automatic-sweeping.png.data new file mode 100644 index 00000000..9355e023 --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/automatic-sweeping.png.data @@ -0,0 +1,3 @@ +title=automatic sweeping icon +author=halw +path=content/automatic-sweeping-icon diff --git a/documentation/18.11/eiffelstudio/_images/automatic_annotation_icon.png b/documentation/18.11/eiffelstudio/_images/automatic_annotation_icon.png new file mode 100644 index 00000000..77576c51 Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/automatic_annotation_icon.png differ diff --git a/documentation/18.11/eiffelstudio/_images/automatic_annotation_icon.png.data b/documentation/18.11/eiffelstudio/_images/automatic_annotation_icon.png.data new file mode 100644 index 00000000..270b6dcc --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/automatic_annotation_icon.png.data @@ -0,0 +1,3 @@ +title=automatic annotation icon +author=halw +path=content/automatic-annotation-icon diff --git a/documentation/18.11/eiffelstudio/_images/bon-agg-client.png b/documentation/18.11/eiffelstudio/_images/bon-agg-client.png new file mode 100644 index 00000000..9e9443f3 Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/bon-agg-client.png differ diff --git a/documentation/18.11/eiffelstudio/_images/bon-agg-client.png.data b/documentation/18.11/eiffelstudio/_images/bon-agg-client.png.data new file mode 100644 index 00000000..22697171 --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/bon-agg-client.png.data @@ -0,0 +1,3 @@ +title=bon-agg-client +author=admin +path=content/bon-agg-client diff --git a/documentation/18.11/eiffelstudio/_images/bon-class-deferred.png b/documentation/18.11/eiffelstudio/_images/bon-class-deferred.png new file mode 100644 index 00000000..a90bda7d Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/bon-class-deferred.png differ diff --git a/documentation/18.11/eiffelstudio/_images/bon-class-deferred.png.data b/documentation/18.11/eiffelstudio/_images/bon-class-deferred.png.data new file mode 100644 index 00000000..96a55382 --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/bon-class-deferred.png.data @@ -0,0 +1,3 @@ +title=bon-class-deferred +author=admin +path=content/bon-class-deferred diff --git a/documentation/18.11/eiffelstudio/_images/bon-class-effective.png b/documentation/18.11/eiffelstudio/_images/bon-class-effective.png new file mode 100644 index 00000000..f8cd79a3 Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/bon-class-effective.png differ diff --git a/documentation/18.11/eiffelstudio/_images/bon-class-effective.png.data b/documentation/18.11/eiffelstudio/_images/bon-class-effective.png.data new file mode 100644 index 00000000..e6dbe01a --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/bon-class-effective.png.data @@ -0,0 +1,3 @@ +title=bon-class-effective +author=admin +path=content/bon-class-effective diff --git a/documentation/18.11/eiffelstudio/_images/bon-class-interfaced.png b/documentation/18.11/eiffelstudio/_images/bon-class-interfaced.png new file mode 100644 index 00000000..7936348b Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/bon-class-interfaced.png differ diff --git a/documentation/18.11/eiffelstudio/_images/bon-class-interfaced.png.data b/documentation/18.11/eiffelstudio/_images/bon-class-interfaced.png.data new file mode 100644 index 00000000..4abd37bd --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/bon-class-interfaced.png.data @@ -0,0 +1,3 @@ +title=bon-class-interfaced +author=admin +path=content/bon-class-interfaced diff --git a/documentation/18.11/eiffelstudio/_images/bon-class-persistent.png b/documentation/18.11/eiffelstudio/_images/bon-class-persistent.png new file mode 100644 index 00000000..329375b2 Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/bon-class-persistent.png differ diff --git a/documentation/18.11/eiffelstudio/_images/bon-class-persistent.png.data b/documentation/18.11/eiffelstudio/_images/bon-class-persistent.png.data new file mode 100644 index 00000000..be6b2574 --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/bon-class-persistent.png.data @@ -0,0 +1,3 @@ +title=bon-class-persistent +author=admin +path=content/bon-class-persistent diff --git a/documentation/18.11/eiffelstudio/_images/bon-class-reused.png b/documentation/18.11/eiffelstudio/_images/bon-class-reused.png new file mode 100644 index 00000000..e661b213 Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/bon-class-reused.png differ diff --git a/documentation/18.11/eiffelstudio/_images/bon-class-reused.png.data b/documentation/18.11/eiffelstudio/_images/bon-class-reused.png.data new file mode 100644 index 00000000..d1bee886 --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/bon-class-reused.png.data @@ -0,0 +1,3 @@ +title=bon-class-reused +author=admin +path=content/bon-class-reused diff --git a/documentation/18.11/eiffelstudio/_images/bon-class-root.png b/documentation/18.11/eiffelstudio/_images/bon-class-root.png new file mode 100644 index 00000000..b32edb6e Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/bon-class-root.png differ diff --git a/documentation/18.11/eiffelstudio/_images/bon-class-root.png.data b/documentation/18.11/eiffelstudio/_images/bon-class-root.png.data new file mode 100644 index 00000000..cfe7f5f6 --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/bon-class-root.png.data @@ -0,0 +1,3 @@ +title=bon-class-root +author=admin +path=content/bon-class-root diff --git a/documentation/18.11/eiffelstudio/_images/bon-class.png b/documentation/18.11/eiffelstudio/_images/bon-class.png new file mode 100644 index 00000000..0124cd2b Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/bon-class.png differ diff --git a/documentation/18.11/eiffelstudio/_images/bon-class.png.data b/documentation/18.11/eiffelstudio/_images/bon-class.png.data new file mode 100644 index 00000000..6fa0e666 --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/bon-class.png.data @@ -0,0 +1,3 @@ +title=bon-class +author=admin +path=content/bon-class diff --git a/documentation/18.11/eiffelstudio/_images/bon-client.png b/documentation/18.11/eiffelstudio/_images/bon-client.png new file mode 100644 index 00000000..daae8acd Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/bon-client.png differ diff --git a/documentation/18.11/eiffelstudio/_images/bon-client.png.data b/documentation/18.11/eiffelstudio/_images/bon-client.png.data new file mode 100644 index 00000000..7732ce25 --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/bon-client.png.data @@ -0,0 +1,3 @@ +title=bon-client +author=admin +path=content/bon-client diff --git a/documentation/18.11/eiffelstudio/_images/bon-cluster-iconified.png b/documentation/18.11/eiffelstudio/_images/bon-cluster-iconified.png new file mode 100644 index 00000000..49df8572 Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/bon-cluster-iconified.png differ diff --git a/documentation/18.11/eiffelstudio/_images/bon-cluster-iconified.png.data b/documentation/18.11/eiffelstudio/_images/bon-cluster-iconified.png.data new file mode 100644 index 00000000..cce106cf --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/bon-cluster-iconified.png.data @@ -0,0 +1,3 @@ +title=bon-cluster-iconified +author=admin +path=content/bon-cluster-iconified diff --git a/documentation/18.11/eiffelstudio/_images/bon-cluster.png b/documentation/18.11/eiffelstudio/_images/bon-cluster.png new file mode 100644 index 00000000..8c250799 Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/bon-cluster.png differ diff --git a/documentation/18.11/eiffelstudio/_images/bon-cluster.png.data b/documentation/18.11/eiffelstudio/_images/bon-cluster.png.data new file mode 100644 index 00000000..63483ae5 --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/bon-cluster.png.data @@ -0,0 +1,3 @@ +title=bon-cluster +author=admin +path=content/bon-cluster diff --git a/documentation/18.11/eiffelstudio/_images/bon-inheritance.png b/documentation/18.11/eiffelstudio/_images/bon-inheritance.png new file mode 100644 index 00000000..ce23a911 Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/bon-inheritance.png differ diff --git a/documentation/18.11/eiffelstudio/_images/bon-inheritance.png.data b/documentation/18.11/eiffelstudio/_images/bon-inheritance.png.data new file mode 100644 index 00000000..a56b76ea --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/bon-inheritance.png.data @@ -0,0 +1,3 @@ +title=bon-inheritance +author=admin +path=content/bon-inheritance diff --git a/documentation/18.11/eiffelstudio/_images/bon-list-relations.png b/documentation/18.11/eiffelstudio/_images/bon-list-relations.png new file mode 100644 index 00000000..b83ca42b Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/bon-list-relations.png differ diff --git a/documentation/18.11/eiffelstudio/_images/bon-list-relations.png.data b/documentation/18.11/eiffelstudio/_images/bon-list-relations.png.data new file mode 100644 index 00000000..4e555afc --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/bon-list-relations.png.data @@ -0,0 +1,3 @@ +title=bon-list-relations +author=admin +path=content/bon-list-relations diff --git a/documentation/18.11/eiffelstudio/_images/bp-current-line-icon.png b/documentation/18.11/eiffelstudio/_images/bp-current-line-icon.png new file mode 100644 index 00000000..86016d4f Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/bp-current-line-icon.png differ diff --git a/documentation/18.11/eiffelstudio/_images/bp-current-line-icon.png.data b/documentation/18.11/eiffelstudio/_images/bp-current-line-icon.png.data new file mode 100644 index 00000000..6cf6aebd --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/bp-current-line-icon.png.data @@ -0,0 +1,3 @@ +title=bp-current-line-icon +author=admin +path=content/bp-current-line-icon diff --git a/documentation/18.11/eiffelstudio/_images/bp-disabled-conditional-icon.png b/documentation/18.11/eiffelstudio/_images/bp-disabled-conditional-icon.png new file mode 100644 index 00000000..e848d8c3 Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/bp-disabled-conditional-icon.png differ diff --git a/documentation/18.11/eiffelstudio/_images/bp-disabled-conditional-icon.png.data b/documentation/18.11/eiffelstudio/_images/bp-disabled-conditional-icon.png.data new file mode 100644 index 00000000..0a13ce5c --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/bp-disabled-conditional-icon.png.data @@ -0,0 +1,3 @@ +title=bp-disabled-conditional-icon +author=admin +path=content/bp-disabled-conditional-icon diff --git a/documentation/18.11/eiffelstudio/_images/bp-disabled-icon.png b/documentation/18.11/eiffelstudio/_images/bp-disabled-icon.png new file mode 100644 index 00000000..67adce91 Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/bp-disabled-icon.png differ diff --git a/documentation/18.11/eiffelstudio/_images/bp-disabled-icon.png.data b/documentation/18.11/eiffelstudio/_images/bp-disabled-icon.png.data new file mode 100644 index 00000000..31c8db3d --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/bp-disabled-icon.png.data @@ -0,0 +1,3 @@ +title=bp-disabled-icon +author=admin +path=content/bp-disabled-icon diff --git a/documentation/18.11/eiffelstudio/_images/bp-enabled-conditional-icon.png b/documentation/18.11/eiffelstudio/_images/bp-enabled-conditional-icon.png new file mode 100644 index 00000000..1c145462 Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/bp-enabled-conditional-icon.png differ diff --git a/documentation/18.11/eiffelstudio/_images/bp-enabled-conditional-icon.png.data b/documentation/18.11/eiffelstudio/_images/bp-enabled-conditional-icon.png.data new file mode 100644 index 00000000..26077080 --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/bp-enabled-conditional-icon.png.data @@ -0,0 +1,3 @@ +title=bp-enabled-conditional-icon +author=admin +path=content/bp-enabled-conditional-icon diff --git a/documentation/18.11/eiffelstudio/_images/bp-enabled-icon.png b/documentation/18.11/eiffelstudio/_images/bp-enabled-icon.png new file mode 100644 index 00000000..279a01a2 Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/bp-enabled-icon.png differ diff --git a/documentation/18.11/eiffelstudio/_images/bp-enabled-icon.png.data b/documentation/18.11/eiffelstudio/_images/bp-enabled-icon.png.data new file mode 100644 index 00000000..1a4b3e48 --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/bp-enabled-icon.png.data @@ -0,0 +1,3 @@ +title=bp-enabled-icon +author=admin +path=content/bp-enabled-icon diff --git a/documentation/18.11/eiffelstudio/_images/bp-slot-icon.png b/documentation/18.11/eiffelstudio/_images/bp-slot-icon.png new file mode 100644 index 00000000..e8330b9f Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/bp-slot-icon.png differ diff --git a/documentation/18.11/eiffelstudio/_images/bp-slot-icon.png.data b/documentation/18.11/eiffelstudio/_images/bp-slot-icon.png.data new file mode 100644 index 00000000..32827c32 --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/bp-slot-icon.png.data @@ -0,0 +1,3 @@ +title=bp-slot-icon +author=admin +path=content/bp-slot-icon diff --git a/documentation/18.11/eiffelstudio/_images/bp-slot-other-frame-icon.png b/documentation/18.11/eiffelstudio/_images/bp-slot-other-frame-icon.png new file mode 100644 index 00000000..9c440b67 Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/bp-slot-other-frame-icon.png differ diff --git a/documentation/18.11/eiffelstudio/_images/bp-slot-other-frame-icon.png.data b/documentation/18.11/eiffelstudio/_images/bp-slot-other-frame-icon.png.data new file mode 100644 index 00000000..da6d23f2 --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/bp-slot-other-frame-icon.png.data @@ -0,0 +1,3 @@ +title=bp-slot-other-frame-icon +author=admin +path=content/bp-slot-other-frame-icon diff --git a/documentation/18.11/eiffelstudio/_images/breakpoint-context-menu.png b/documentation/18.11/eiffelstudio/_images/breakpoint-context-menu.png new file mode 100644 index 00000000..64511aab Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/breakpoint-context-menu.png differ diff --git a/documentation/18.11/eiffelstudio/_images/breakpoint-context-menu.png.data b/documentation/18.11/eiffelstudio/_images/breakpoint-context-menu.png.data new file mode 100644 index 00000000..4966eb43 --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/breakpoint-context-menu.png.data @@ -0,0 +1,3 @@ +title=breakpoint-context-menu +author=admin +path=content/breakpoint-context-menu diff --git a/documentation/18.11/eiffelstudio/_images/breakpoint-dialog-condition.png b/documentation/18.11/eiffelstudio/_images/breakpoint-dialog-condition.png new file mode 100644 index 00000000..324aac6b Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/breakpoint-dialog-condition.png differ diff --git a/documentation/18.11/eiffelstudio/_images/breakpoint-dialog-condition.png.data b/documentation/18.11/eiffelstudio/_images/breakpoint-dialog-condition.png.data new file mode 100644 index 00000000..d03c8f38 --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/breakpoint-dialog-condition.png.data @@ -0,0 +1,3 @@ +title=breakpoint-dialog-condition +author=admin +path=content/breakpoint-dialog-condition diff --git a/documentation/18.11/eiffelstudio/_images/breakpoint-dialog-context.png b/documentation/18.11/eiffelstudio/_images/breakpoint-dialog-context.png new file mode 100644 index 00000000..fd8ce1af Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/breakpoint-dialog-context.png differ diff --git a/documentation/18.11/eiffelstudio/_images/breakpoint-dialog-context.png.data b/documentation/18.11/eiffelstudio/_images/breakpoint-dialog-context.png.data new file mode 100644 index 00000000..0c4e585d --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/breakpoint-dialog-context.png.data @@ -0,0 +1,3 @@ +title=breakpoint-dialog-context +author=admin +path=content/breakpoint-dialog-context diff --git a/documentation/18.11/eiffelstudio/_images/breakpoint-dialog-hit-count.png b/documentation/18.11/eiffelstudio/_images/breakpoint-dialog-hit-count.png new file mode 100644 index 00000000..cb1f72f1 Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/breakpoint-dialog-hit-count.png differ diff --git a/documentation/18.11/eiffelstudio/_images/breakpoint-dialog-hit-count.png.data b/documentation/18.11/eiffelstudio/_images/breakpoint-dialog-hit-count.png.data new file mode 100644 index 00000000..3fceb34b --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/breakpoint-dialog-hit-count.png.data @@ -0,0 +1,3 @@ +title=breakpoint-dialog-hit-count +author=admin +path=content/breakpoint-dialog-hit-count diff --git a/documentation/18.11/eiffelstudio/_images/breakpoint-dialog-when-hits-action.png b/documentation/18.11/eiffelstudio/_images/breakpoint-dialog-when-hits-action.png new file mode 100644 index 00000000..176a8258 Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/breakpoint-dialog-when-hits-action.png differ diff --git a/documentation/18.11/eiffelstudio/_images/breakpoint-dialog-when-hits-action.png.data b/documentation/18.11/eiffelstudio/_images/breakpoint-dialog-when-hits-action.png.data new file mode 100644 index 00000000..6d3adbf2 --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/breakpoint-dialog-when-hits-action.png.data @@ -0,0 +1,3 @@ +title=breakpoint-dialog-when-hits-action +author=admin +path=content/breakpoint-dialog-when-hits-action diff --git a/documentation/18.11/eiffelstudio/_images/breakpoint-dialog-when-hits.png b/documentation/18.11/eiffelstudio/_images/breakpoint-dialog-when-hits.png new file mode 100644 index 00000000..37eeccf1 Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/breakpoint-dialog-when-hits.png differ diff --git a/documentation/18.11/eiffelstudio/_images/breakpoint-dialog-when-hits.png.data b/documentation/18.11/eiffelstudio/_images/breakpoint-dialog-when-hits.png.data new file mode 100644 index 00000000..83c42e0a --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/breakpoint-dialog-when-hits.png.data @@ -0,0 +1,3 @@ +title=breakpoint-dialog-when-hits +author=admin +path=content/breakpoint-dialog-when-hits diff --git a/documentation/18.11/eiffelstudio/_images/breakpoints-delete-icon.png b/documentation/18.11/eiffelstudio/_images/breakpoints-delete-icon.png new file mode 100644 index 00000000..071e166b Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/breakpoints-delete-icon.png differ diff --git a/documentation/18.11/eiffelstudio/_images/breakpoints-delete-icon.png.data b/documentation/18.11/eiffelstudio/_images/breakpoints-delete-icon.png.data new file mode 100644 index 00000000..b62e76d4 --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/breakpoints-delete-icon.png.data @@ -0,0 +1,3 @@ +title=breakpoints-delete-icon +author=admin +path=content/breakpoints-delete-icon diff --git a/documentation/18.11/eiffelstudio/_images/breakpoints-list-filter-button.png b/documentation/18.11/eiffelstudio/_images/breakpoints-list-filter-button.png new file mode 100644 index 00000000..a4196cf0 Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/breakpoints-list-filter-button.png differ diff --git a/documentation/18.11/eiffelstudio/_images/breakpoints-list-filter-button.png.data b/documentation/18.11/eiffelstudio/_images/breakpoints-list-filter-button.png.data new file mode 100644 index 00000000..5122b028 --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/breakpoints-list-filter-button.png.data @@ -0,0 +1,3 @@ +title=breakpoints-list-filter-button +author=admin +path=content/breakpoints-list-filter-button diff --git a/documentation/18.11/eiffelstudio/_images/breakpoints-list-filter.png b/documentation/18.11/eiffelstudio/_images/breakpoints-list-filter.png new file mode 100644 index 00000000..2e1da125 Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/breakpoints-list-filter.png differ diff --git a/documentation/18.11/eiffelstudio/_images/breakpoints-list-filter.png.data b/documentation/18.11/eiffelstudio/_images/breakpoints-list-filter.png.data new file mode 100644 index 00000000..a8989bae --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/breakpoints-list-filter.png.data @@ -0,0 +1,3 @@ +title=breakpoints-list-filter +author=admin +path=content/breakpoints-list-filter diff --git a/documentation/18.11/eiffelstudio/_images/breakpoints-list-flat.png b/documentation/18.11/eiffelstudio/_images/breakpoints-list-flat.png new file mode 100644 index 00000000..c6a3e972 Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/breakpoints-list-flat.png differ diff --git a/documentation/18.11/eiffelstudio/_images/breakpoints-list-flat.png.data b/documentation/18.11/eiffelstudio/_images/breakpoints-list-flat.png.data new file mode 100644 index 00000000..1d7c18f4 --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/breakpoints-list-flat.png.data @@ -0,0 +1,3 @@ +title=breakpoints-list-flat +author=admin +path=content/breakpoints-list-flat diff --git a/documentation/18.11/eiffelstudio/_images/breakpoints-list.png b/documentation/18.11/eiffelstudio/_images/breakpoints-list.png new file mode 100644 index 00000000..b49dac1f Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/breakpoints-list.png differ diff --git a/documentation/18.11/eiffelstudio/_images/breakpoints-list.png.data b/documentation/18.11/eiffelstudio/_images/breakpoints-list.png.data new file mode 100644 index 00000000..bd7f7705 --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/breakpoints-list.png.data @@ -0,0 +1,3 @@ +title=breakpoints-list +author=admin +path=content/breakpoints-list diff --git a/documentation/18.11/eiffelstudio/_images/call-stack-tool-with-threads.png b/documentation/18.11/eiffelstudio/_images/call-stack-tool-with-threads.png new file mode 100644 index 00000000..f3687128 Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/call-stack-tool-with-threads.png differ diff --git a/documentation/18.11/eiffelstudio/_images/call-stack-tool-with-threads.png.data b/documentation/18.11/eiffelstudio/_images/call-stack-tool-with-threads.png.data new file mode 100644 index 00000000..9f654c57 --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/call-stack-tool-with-threads.png.data @@ -0,0 +1,3 @@ +title=call-stack-tool-with-threads +author=admin +path=content/call-stack-tool-threads diff --git a/documentation/18.11/eiffelstudio/_images/call-stack-tool.png b/documentation/18.11/eiffelstudio/_images/call-stack-tool.png new file mode 100644 index 00000000..5ee4a593 Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/call-stack-tool.png differ diff --git a/documentation/18.11/eiffelstudio/_images/call-stack-tool.png.data b/documentation/18.11/eiffelstudio/_images/call-stack-tool.png.data new file mode 100644 index 00000000..d6323025 --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/call-stack-tool.png.data @@ -0,0 +1,3 @@ +title=call-stack-tool +author=admin +path=content/call-stack-tool diff --git a/documentation/18.11/eiffelstudio/_images/callee-is.jpg b/documentation/18.11/eiffelstudio/_images/callee-is.jpg new file mode 100644 index 00000000..65a7ef53 Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/callee-is.jpg differ diff --git a/documentation/18.11/eiffelstudio/_images/callee-is.jpg.data b/documentation/18.11/eiffelstudio/_images/callee-is.jpg.data new file mode 100644 index 00000000..ae1f3fb4 --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/callee-is.jpg.data @@ -0,0 +1,3 @@ +title=callee-is +author=admin +path=content/callee diff --git a/documentation/18.11/eiffelstudio/_images/callstack-active-arrow-icon.png b/documentation/18.11/eiffelstudio/_images/callstack-active-arrow-icon.png new file mode 100644 index 00000000..5656bba0 Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/callstack-active-arrow-icon.png differ diff --git a/documentation/18.11/eiffelstudio/_images/callstack-active-arrow-icon.png.data b/documentation/18.11/eiffelstudio/_images/callstack-active-arrow-icon.png.data new file mode 100644 index 00000000..dab986e7 --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/callstack-active-arrow-icon.png.data @@ -0,0 +1,3 @@ +title=callstack-active-arrow-icon +author=admin +path=content/callstack-active-arrow-icon diff --git a/documentation/18.11/eiffelstudio/_images/callstack-empty-arrow-icon.png b/documentation/18.11/eiffelstudio/_images/callstack-empty-arrow-icon.png new file mode 100644 index 00000000..f22fe54a Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/callstack-empty-arrow-icon.png differ diff --git a/documentation/18.11/eiffelstudio/_images/callstack-empty-arrow-icon.png.data b/documentation/18.11/eiffelstudio/_images/callstack-empty-arrow-icon.png.data new file mode 100644 index 00000000..d33df898 --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/callstack-empty-arrow-icon.png.data @@ -0,0 +1,3 @@ +title=callstack-empty-arrow-icon +author=admin +path=content/callstack-empty-arrow-icon diff --git a/documentation/18.11/eiffelstudio/_images/class-ancestors-icon.png b/documentation/18.11/eiffelstudio/_images/class-ancestors-icon.png new file mode 100644 index 00000000..7648c871 Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/class-ancestors-icon.png differ diff --git a/documentation/18.11/eiffelstudio/_images/class-ancestors-icon.png.data b/documentation/18.11/eiffelstudio/_images/class-ancestors-icon.png.data new file mode 100644 index 00000000..eda07ff5 --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/class-ancestors-icon.png.data @@ -0,0 +1,3 @@ +title=class-ancestors-icon +author=admin +path=content/class-ancestors-icon diff --git a/documentation/18.11/eiffelstudio/_images/class-clients-icon.png b/documentation/18.11/eiffelstudio/_images/class-clients-icon.png new file mode 100644 index 00000000..79238ccc Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/class-clients-icon.png differ diff --git a/documentation/18.11/eiffelstudio/_images/class-clients-icon.png.data b/documentation/18.11/eiffelstudio/_images/class-clients-icon.png.data new file mode 100644 index 00000000..46a7acca --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/class-clients-icon.png.data @@ -0,0 +1,3 @@ +title=class-clients-icon +author=admin +path=content/class-clients-icon diff --git a/documentation/18.11/eiffelstudio/_images/class-deferred-icon.png b/documentation/18.11/eiffelstudio/_images/class-deferred-icon.png new file mode 100644 index 00000000..d351b236 Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/class-deferred-icon.png differ diff --git a/documentation/18.11/eiffelstudio/_images/class-deferred-icon.png.data b/documentation/18.11/eiffelstudio/_images/class-deferred-icon.png.data new file mode 100644 index 00000000..42a3abf1 --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/class-deferred-icon.png.data @@ -0,0 +1,3 @@ +title=class-deferred-icon +author=admin +path=content/class-deferred-icon diff --git a/documentation/18.11/eiffelstudio/_images/class-descendents-icon.png b/documentation/18.11/eiffelstudio/_images/class-descendents-icon.png new file mode 100644 index 00000000..4d47f951 Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/class-descendents-icon.png differ diff --git a/documentation/18.11/eiffelstudio/_images/class-descendents-icon.png.data b/documentation/18.11/eiffelstudio/_images/class-descendents-icon.png.data new file mode 100644 index 00000000..9fc3bf7a --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/class-descendents-icon.png.data @@ -0,0 +1,3 @@ +title=class-descendents-icon +author=admin +path=content/class-descendents-icon diff --git a/documentation/18.11/eiffelstudio/_images/class-features-attribute-icon.png b/documentation/18.11/eiffelstudio/_images/class-features-attribute-icon.png new file mode 100644 index 00000000..ded5bbf9 Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/class-features-attribute-icon.png differ diff --git a/documentation/18.11/eiffelstudio/_images/class-features-attribute-icon.png.data b/documentation/18.11/eiffelstudio/_images/class-features-attribute-icon.png.data new file mode 100644 index 00000000..65cdae0c --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/class-features-attribute-icon.png.data @@ -0,0 +1,3 @@ +title=class-features-attribute-icon +author=admin +path=content/class-features-attribute-icon diff --git a/documentation/18.11/eiffelstudio/_images/class-features-creator-icon.png b/documentation/18.11/eiffelstudio/_images/class-features-creator-icon.png new file mode 100644 index 00000000..c0539a1d Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/class-features-creator-icon.png differ diff --git a/documentation/18.11/eiffelstudio/_images/class-features-creator-icon.png.data b/documentation/18.11/eiffelstudio/_images/class-features-creator-icon.png.data new file mode 100644 index 00000000..4c3e594e --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/class-features-creator-icon.png.data @@ -0,0 +1,3 @@ +title=class-features-creator-icon +author=admin +path=content/class-features-creator-icon diff --git a/documentation/18.11/eiffelstudio/_images/class-features-deferred-icon.png b/documentation/18.11/eiffelstudio/_images/class-features-deferred-icon.png new file mode 100644 index 00000000..400a94b5 Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/class-features-deferred-icon.png differ diff --git a/documentation/18.11/eiffelstudio/_images/class-features-deferred-icon.png.data b/documentation/18.11/eiffelstudio/_images/class-features-deferred-icon.png.data new file mode 100644 index 00000000..07c6eccf --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/class-features-deferred-icon.png.data @@ -0,0 +1,3 @@ +title=class-features-deferred-icon +author=admin +path=content/class-features-deferred-icon diff --git a/documentation/18.11/eiffelstudio/_images/class-features-exported-icon.png b/documentation/18.11/eiffelstudio/_images/class-features-exported-icon.png new file mode 100644 index 00000000..9b4a23a0 Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/class-features-exported-icon.png differ diff --git a/documentation/18.11/eiffelstudio/_images/class-features-exported-icon.png.data b/documentation/18.11/eiffelstudio/_images/class-features-exported-icon.png.data new file mode 100644 index 00000000..a148cf4d --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/class-features-exported-icon.png.data @@ -0,0 +1,3 @@ +title=class-features-exported-icon +author=admin +path=content/class-features-exported-icon diff --git a/documentation/18.11/eiffelstudio/_images/class-features-external-icon.png b/documentation/18.11/eiffelstudio/_images/class-features-external-icon.png new file mode 100644 index 00000000..31b26e17 Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/class-features-external-icon.png differ diff --git a/documentation/18.11/eiffelstudio/_images/class-features-external-icon.png.data b/documentation/18.11/eiffelstudio/_images/class-features-external-icon.png.data new file mode 100644 index 00000000..d6a1f228 --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/class-features-external-icon.png.data @@ -0,0 +1,3 @@ +title=class-features-external-icon +author=admin +path=content/class-features-external-icon diff --git a/documentation/18.11/eiffelstudio/_images/class-features-invariant-icon.png b/documentation/18.11/eiffelstudio/_images/class-features-invariant-icon.png new file mode 100644 index 00000000..fdd97ec2 Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/class-features-invariant-icon.png differ diff --git a/documentation/18.11/eiffelstudio/_images/class-features-invariant-icon.png.data b/documentation/18.11/eiffelstudio/_images/class-features-invariant-icon.png.data new file mode 100644 index 00000000..2b4bfe2f --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/class-features-invariant-icon.png.data @@ -0,0 +1,3 @@ +title=class-features-invariant-icon +author=admin +path=content/class-features-invariant-icon diff --git a/documentation/18.11/eiffelstudio/_images/class-features-once-icon.png b/documentation/18.11/eiffelstudio/_images/class-features-once-icon.png new file mode 100644 index 00000000..748258f9 Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/class-features-once-icon.png differ diff --git a/documentation/18.11/eiffelstudio/_images/class-features-once-icon.png.data b/documentation/18.11/eiffelstudio/_images/class-features-once-icon.png.data new file mode 100644 index 00000000..2a95a8ca --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/class-features-once-icon.png.data @@ -0,0 +1,3 @@ +title=class-features-once-icon +author=admin +path=content/class-features-once-icon diff --git a/documentation/18.11/eiffelstudio/_images/class-features-routine-icon.png b/documentation/18.11/eiffelstudio/_images/class-features-routine-icon.png new file mode 100644 index 00000000..9f4d073a Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/class-features-routine-icon.png differ diff --git a/documentation/18.11/eiffelstudio/_images/class-features-routine-icon.png.data b/documentation/18.11/eiffelstudio/_images/class-features-routine-icon.png.data new file mode 100644 index 00000000..06d793ca --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/class-features-routine-icon.png.data @@ -0,0 +1,3 @@ +title=class-features-routine-icon +author=admin +path=content/class-features-routine-icon diff --git a/documentation/18.11/eiffelstudio/_images/class-format-bar.png b/documentation/18.11/eiffelstudio/_images/class-format-bar.png new file mode 100644 index 00000000..c4590f09 Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/class-format-bar.png differ diff --git a/documentation/18.11/eiffelstudio/_images/class-format-bar.png.data b/documentation/18.11/eiffelstudio/_images/class-format-bar.png.data new file mode 100644 index 00000000..f5ce78d7 --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/class-format-bar.png.data @@ -0,0 +1,3 @@ +title=class-format-bar +author=admin +path=content/class-format-bar diff --git a/documentation/18.11/eiffelstudio/_images/class-frozen-icon.png b/documentation/18.11/eiffelstudio/_images/class-frozen-icon.png new file mode 100644 index 00000000..409cf9d8 Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/class-frozen-icon.png differ diff --git a/documentation/18.11/eiffelstudio/_images/class-frozen-icon.png.data b/documentation/18.11/eiffelstudio/_images/class-frozen-icon.png.data new file mode 100644 index 00000000..79bf3e5f --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/class-frozen-icon.png.data @@ -0,0 +1,3 @@ +title=class-frozen-icon +author=admin +path=content/class-frozen-icon diff --git a/documentation/18.11/eiffelstudio/_images/class-hie.jpg b/documentation/18.11/eiffelstudio/_images/class-hie.jpg new file mode 100644 index 00000000..b1858a59 Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/class-hie.jpg differ diff --git a/documentation/18.11/eiffelstudio/_images/class-hie.jpg.data b/documentation/18.11/eiffelstudio/_images/class-hie.jpg.data new file mode 100644 index 00000000..c4514db1 --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/class-hie.jpg.data @@ -0,0 +1,3 @@ +title=class-hie +author=admin +path=content/class-hie diff --git a/documentation/18.11/eiffelstudio/_images/class-mini-format-bar.png b/documentation/18.11/eiffelstudio/_images/class-mini-format-bar.png new file mode 100644 index 00000000..1f2c0924 Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/class-mini-format-bar.png differ diff --git a/documentation/18.11/eiffelstudio/_images/class-mini-format-bar.png.data b/documentation/18.11/eiffelstudio/_images/class-mini-format-bar.png.data new file mode 100644 index 00000000..475f8f71 --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/class-mini-format-bar.png.data @@ -0,0 +1,3 @@ +title=class-mini-format-bar +author=admin +path=content/class-mini-format-bar diff --git a/documentation/18.11/eiffelstudio/_images/class-normal-icon.png b/documentation/18.11/eiffelstudio/_images/class-normal-icon.png new file mode 100644 index 00000000..d269b1b2 Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/class-normal-icon.png differ diff --git a/documentation/18.11/eiffelstudio/_images/class-normal-icon.png.data b/documentation/18.11/eiffelstudio/_images/class-normal-icon.png.data new file mode 100644 index 00000000..c599113e --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/class-normal-icon.png.data @@ -0,0 +1,3 @@ +title=class-normal-icon +author=admin +path=content/class-normal-icon diff --git a/documentation/18.11/eiffelstudio/_images/class-override-normal-icon.png b/documentation/18.11/eiffelstudio/_images/class-override-normal-icon.png new file mode 100644 index 00000000..1d89d80c Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/class-override-normal-icon.png differ diff --git a/documentation/18.11/eiffelstudio/_images/class-override-normal-icon.png.data b/documentation/18.11/eiffelstudio/_images/class-override-normal-icon.png.data new file mode 100644 index 00000000..34d76923 --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/class-override-normal-icon.png.data @@ -0,0 +1,3 @@ +title=class-override-normal-icon +author=admin +path=content/class-override-normal-icon diff --git a/documentation/18.11/eiffelstudio/_images/class-overriden-normal-icon.png b/documentation/18.11/eiffelstudio/_images/class-overriden-normal-icon.png new file mode 100644 index 00000000..336bbe48 Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/class-overriden-normal-icon.png differ diff --git a/documentation/18.11/eiffelstudio/_images/class-overriden-normal-icon.png.data b/documentation/18.11/eiffelstudio/_images/class-overriden-normal-icon.png.data new file mode 100644 index 00000000..8479c24f --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/class-overriden-normal-icon.png.data @@ -0,0 +1,3 @@ +title=class-overriden-normal-icon +author=admin +path=content/class-overriden-normal-icon diff --git a/documentation/18.11/eiffelstudio/_images/class-supliers-icon.png b/documentation/18.11/eiffelstudio/_images/class-supliers-icon.png new file mode 100644 index 00000000..1cfcbb9a Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/class-supliers-icon.png differ diff --git a/documentation/18.11/eiffelstudio/_images/class-supliers-icon.png.data b/documentation/18.11/eiffelstudio/_images/class-supliers-icon.png.data new file mode 100644 index 00000000..4222442a --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/class-supliers-icon.png.data @@ -0,0 +1,3 @@ +title=class-supliers-icon +author=admin +path=content/class-supliers-icon diff --git a/documentation/18.11/eiffelstudio/_images/clean_compile_dialog.png b/documentation/18.11/eiffelstudio/_images/clean_compile_dialog.png new file mode 100644 index 00000000..b751a80f Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/clean_compile_dialog.png differ diff --git a/documentation/18.11/eiffelstudio/_images/clean_compile_dialog.png.data b/documentation/18.11/eiffelstudio/_images/clean_compile_dialog.png.data new file mode 100644 index 00000000..86f762dd --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/clean_compile_dialog.png.data @@ -0,0 +1,3 @@ +title=clean compile dialog +author=halw +path=content/clean-compile-dialog diff --git a/documentation/18.11/eiffelstudio/_images/close-icon.png b/documentation/18.11/eiffelstudio/_images/close-icon.png new file mode 100644 index 00000000..c4cac921 Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/close-icon.png differ diff --git a/documentation/18.11/eiffelstudio/_images/close-icon.png.data b/documentation/18.11/eiffelstudio/_images/close-icon.png.data new file mode 100644 index 00000000..5ec9d881 --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/close-icon.png.data @@ -0,0 +1,3 @@ +title=close-icon +author=halw +path=content/close-icon diff --git a/documentation/18.11/eiffelstudio/_images/cluster-legend.png b/documentation/18.11/eiffelstudio/_images/cluster-legend.png new file mode 100644 index 00000000..bfc0f89f Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/cluster-legend.png differ diff --git a/documentation/18.11/eiffelstudio/_images/cluster-legend.png.data b/documentation/18.11/eiffelstudio/_images/cluster-legend.png.data new file mode 100644 index 00000000..a4ead217 --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/cluster-legend.png.data @@ -0,0 +1,3 @@ +title=cluster-legend +author=admin +path=content/cluster-legend diff --git a/documentation/18.11/eiffelstudio/_images/cluster-tree.png b/documentation/18.11/eiffelstudio/_images/cluster-tree.png new file mode 100644 index 00000000..3645bec7 Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/cluster-tree.png differ diff --git a/documentation/18.11/eiffelstudio/_images/cluster-tree.png.data b/documentation/18.11/eiffelstudio/_images/cluster-tree.png.data new file mode 100644 index 00000000..dfe019a4 --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/cluster-tree.png.data @@ -0,0 +1,3 @@ +title=cluster-tree +author=admin +path=content/cluster-tree diff --git a/documentation/18.11/eiffelstudio/_images/color-dialog-windows.png b/documentation/18.11/eiffelstudio/_images/color-dialog-windows.png new file mode 100644 index 00000000..05f535e2 Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/color-dialog-windows.png differ diff --git a/documentation/18.11/eiffelstudio/_images/color-dialog-windows.png.data b/documentation/18.11/eiffelstudio/_images/color-dialog-windows.png.data new file mode 100644 index 00000000..acf62bfc --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/color-dialog-windows.png.data @@ -0,0 +1,3 @@ +title=color-dialog-windows +author=admin +path=content/color-dialog-windows diff --git a/documentation/18.11/eiffelstudio/_images/command-error-info-icon.png b/documentation/18.11/eiffelstudio/_images/command-error-info-icon.png new file mode 100644 index 00000000..fa393149 Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/command-error-info-icon.png differ diff --git a/documentation/18.11/eiffelstudio/_images/command-error-info-icon.png.data b/documentation/18.11/eiffelstudio/_images/command-error-info-icon.png.data new file mode 100644 index 00000000..c500d86a --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/command-error-info-icon.png.data @@ -0,0 +1,3 @@ +title=command-error-info-icon +author=admin +path=content/command-error-info-icon diff --git a/documentation/18.11/eiffelstudio/_images/command-send-to-external-editor-icon.png b/documentation/18.11/eiffelstudio/_images/command-send-to-external-editor-icon.png new file mode 100644 index 00000000..3363cbd1 Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/command-send-to-external-editor-icon.png differ diff --git a/documentation/18.11/eiffelstudio/_images/command-send-to-external-editor-icon.png.data b/documentation/18.11/eiffelstudio/_images/command-send-to-external-editor-icon.png.data new file mode 100644 index 00000000..a6ba7bc1 --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/command-send-to-external-editor-icon.png.data @@ -0,0 +1,3 @@ +title=command-send-to-external-editor-icon +author=admin +path=content/command-send-external-editor-icon diff --git a/documentation/18.11/eiffelstudio/_images/compile-animation-6-icon.png b/documentation/18.11/eiffelstudio/_images/compile-animation-6-icon.png new file mode 100644 index 00000000..7ed09652 Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/compile-animation-6-icon.png differ diff --git a/documentation/18.11/eiffelstudio/_images/compile-animation-6-icon.png.data b/documentation/18.11/eiffelstudio/_images/compile-animation-6-icon.png.data new file mode 100644 index 00000000..57671b00 --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/compile-animation-6-icon.png.data @@ -0,0 +1,3 @@ +title=compile-animation-6-icon +author=admin +path=content/compile-animation-6-icon diff --git a/documentation/18.11/eiffelstudio/_images/compile-button-dropdown.png b/documentation/18.11/eiffelstudio/_images/compile-button-dropdown.png new file mode 100644 index 00000000..35659bfc Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/compile-button-dropdown.png differ diff --git a/documentation/18.11/eiffelstudio/_images/compile-button-dropdown.png.data b/documentation/18.11/eiffelstudio/_images/compile-button-dropdown.png.data new file mode 100644 index 00000000..d8efe823 --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/compile-button-dropdown.png.data @@ -0,0 +1,3 @@ +title=compile-button-dropdown +author=halw +path=content/compile-button-dropdown diff --git a/documentation/18.11/eiffelstudio/_images/compile-button.png b/documentation/18.11/eiffelstudio/_images/compile-button.png new file mode 100644 index 00000000..d9d84efa Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/compile-button.png differ diff --git a/documentation/18.11/eiffelstudio/_images/compile-button.png.data b/documentation/18.11/eiffelstudio/_images/compile-button.png.data new file mode 100644 index 00000000..c0cf0f00 --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/compile-button.png.data @@ -0,0 +1,3 @@ +title=compile-button +author=halw +path=content/compile-button diff --git a/documentation/18.11/eiffelstudio/_images/compile-error-icon.png b/documentation/18.11/eiffelstudio/_images/compile-error-icon.png new file mode 100644 index 00000000..9fb4f4fd Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/compile-error-icon.png differ diff --git a/documentation/18.11/eiffelstudio/_images/compile-error-icon.png.data b/documentation/18.11/eiffelstudio/_images/compile-error-icon.png.data new file mode 100644 index 00000000..fae4c3f1 --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/compile-error-icon.png.data @@ -0,0 +1,3 @@ +title=compile-error-icon +author=admin +path=content/compile-error-icon diff --git a/documentation/18.11/eiffelstudio/_images/compile-success-icon.png b/documentation/18.11/eiffelstudio/_images/compile-success-icon.png new file mode 100644 index 00000000..1306dfa4 Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/compile-success-icon.png differ diff --git a/documentation/18.11/eiffelstudio/_images/compile-success-icon.png.data b/documentation/18.11/eiffelstudio/_images/compile-success-icon.png.data new file mode 100644 index 00000000..caf1e57e --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/compile-success-icon.png.data @@ -0,0 +1,3 @@ +title=compile-success-icon +author=admin +path=content/compile-success-icon diff --git a/documentation/18.11/eiffelstudio/_images/console-auto1.jpg b/documentation/18.11/eiffelstudio/_images/console-auto1.jpg new file mode 100644 index 00000000..d35622e4 Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/console-auto1.jpg differ diff --git a/documentation/18.11/eiffelstudio/_images/console-auto1.jpg.data b/documentation/18.11/eiffelstudio/_images/console-auto1.jpg.data new file mode 100644 index 00000000..5ad04598 --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/console-auto1.jpg.data @@ -0,0 +1,3 @@ +title=console-auto1 +author=admin +path=content/console-auto1 diff --git a/documentation/18.11/eiffelstudio/_images/console-auto2.jpg b/documentation/18.11/eiffelstudio/_images/console-auto2.jpg new file mode 100644 index 00000000..74198a96 Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/console-auto2.jpg differ diff --git a/documentation/18.11/eiffelstudio/_images/console-auto2.jpg.data b/documentation/18.11/eiffelstudio/_images/console-auto2.jpg.data new file mode 100644 index 00000000..00e1ab9a --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/console-auto2.jpg.data @@ -0,0 +1,3 @@ +title=console-auto2 +author=admin +path=content/console-auto2 diff --git a/documentation/18.11/eiffelstudio/_images/console-auto3.jpg b/documentation/18.11/eiffelstudio/_images/console-auto3.jpg new file mode 100644 index 00000000..7f7ca2c8 Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/console-auto3.jpg differ diff --git a/documentation/18.11/eiffelstudio/_images/console-auto3.jpg.data b/documentation/18.11/eiffelstudio/_images/console-auto3.jpg.data new file mode 100644 index 00000000..e0aa3e34 --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/console-auto3.jpg.data @@ -0,0 +1,3 @@ +title=console-auto3 +author=admin +path=content/console-auto3 diff --git a/documentation/18.11/eiffelstudio/_images/console1.png b/documentation/18.11/eiffelstudio/_images/console1.png new file mode 100644 index 00000000..ba6fd87c Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/console1.png differ diff --git a/documentation/18.11/eiffelstudio/_images/console1.png.data b/documentation/18.11/eiffelstudio/_images/console1.png.data new file mode 100644 index 00000000..3489877d --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/console1.png.data @@ -0,0 +1,3 @@ +title=console1 +author=admin +path=content/console1 diff --git a/documentation/18.11/eiffelstudio/_images/context-address-bar.png b/documentation/18.11/eiffelstudio/_images/context-address-bar.png new file mode 100644 index 00000000..1f48553b Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/context-address-bar.png differ diff --git a/documentation/18.11/eiffelstudio/_images/context-address-bar.png.data b/documentation/18.11/eiffelstudio/_images/context-address-bar.png.data new file mode 100644 index 00000000..f1fdba7a --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/context-address-bar.png.data @@ -0,0 +1,3 @@ +title=context-address-bar +author=admin +path=content/context-address-bar diff --git a/documentation/18.11/eiffelstudio/_images/context-address-window.png b/documentation/18.11/eiffelstudio/_images/context-address-window.png new file mode 100644 index 00000000..fa46f2ee Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/context-address-window.png differ diff --git a/documentation/18.11/eiffelstudio/_images/context-address-window.png.data b/documentation/18.11/eiffelstudio/_images/context-address-window.png.data new file mode 100644 index 00000000..7ee99370 --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/context-address-window.png.data @@ -0,0 +1,3 @@ +title=context-address-window +author=admin +path=content/context-address-window diff --git a/documentation/18.11/eiffelstudio/_images/context-class-cursor_0.png b/documentation/18.11/eiffelstudio/_images/context-class-cursor_0.png new file mode 100644 index 00000000..fc7f7ac5 Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/context-class-cursor_0.png differ diff --git a/documentation/18.11/eiffelstudio/_images/context-class-cursor_0.png.data b/documentation/18.11/eiffelstudio/_images/context-class-cursor_0.png.data new file mode 100644 index 00000000..35de7828 --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/context-class-cursor_0.png.data @@ -0,0 +1,3 @@ +title=context-class-cursor +author=halw +path=content/context-class-cursor diff --git a/documentation/18.11/eiffelstudio/_images/context-dialog-class.png b/documentation/18.11/eiffelstudio/_images/context-dialog-class.png new file mode 100644 index 00000000..97d7142c Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/context-dialog-class.png differ diff --git a/documentation/18.11/eiffelstudio/_images/context-dialog-class.png.data b/documentation/18.11/eiffelstudio/_images/context-dialog-class.png.data new file mode 100644 index 00000000..86d40395 --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/context-dialog-class.png.data @@ -0,0 +1,3 @@ +title=context-dialog-class +author=admin +path=content/context-dialog-class diff --git a/documentation/18.11/eiffelstudio/_images/context-dialog-cluster.png b/documentation/18.11/eiffelstudio/_images/context-dialog-cluster.png new file mode 100644 index 00000000..63375a1b Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/context-dialog-cluster.png differ diff --git a/documentation/18.11/eiffelstudio/_images/context-dialog-cluster.png.data b/documentation/18.11/eiffelstudio/_images/context-dialog-cluster.png.data new file mode 100644 index 00000000..3d32e47c --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/context-dialog-cluster.png.data @@ -0,0 +1,3 @@ +title=context-dialog-cluster +author=admin +path=content/context-dialog-cluster diff --git a/documentation/18.11/eiffelstudio/_images/context-disabled-class-cursor_2.png b/documentation/18.11/eiffelstudio/_images/context-disabled-class-cursor_2.png new file mode 100644 index 00000000..85479182 Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/context-disabled-class-cursor_2.png differ diff --git a/documentation/18.11/eiffelstudio/_images/context-disabled-class-cursor_2.png.data b/documentation/18.11/eiffelstudio/_images/context-disabled-class-cursor_2.png.data new file mode 100644 index 00000000..c6e9e30c --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/context-disabled-class-cursor_2.png.data @@ -0,0 +1,3 @@ +title=context-disabled-class-cursor +author=halw +path=content/context-disabled-class-cursor diff --git a/documentation/18.11/eiffelstudio/_images/context-link-icon.png b/documentation/18.11/eiffelstudio/_images/context-link-icon.png new file mode 100644 index 00000000..a794d906 Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/context-link-icon.png differ diff --git a/documentation/18.11/eiffelstudio/_images/context-link-icon.png.data b/documentation/18.11/eiffelstudio/_images/context-link-icon.png.data new file mode 100644 index 00000000..b74f708e --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/context-link-icon.png.data @@ -0,0 +1,3 @@ +title=context-link-icon +author=admin +path=content/context-link-icon diff --git a/documentation/18.11/eiffelstudio/_images/context-sync-icon.png b/documentation/18.11/eiffelstudio/_images/context-sync-icon.png new file mode 100644 index 00000000..c8ffa1cc Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/context-sync-icon.png differ diff --git a/documentation/18.11/eiffelstudio/_images/context-sync-icon.png.data b/documentation/18.11/eiffelstudio/_images/context-sync-icon.png.data new file mode 100644 index 00000000..ca91bd57 --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/context-sync-icon.png.data @@ -0,0 +1,3 @@ +title=context-sync-icon +author=admin +path=content/context-sync-icon diff --git a/documentation/18.11/eiffelstudio/_images/continued-icon.png b/documentation/18.11/eiffelstudio/_images/continued-icon.png new file mode 100644 index 00000000..9aabb621 Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/continued-icon.png differ diff --git a/documentation/18.11/eiffelstudio/_images/continued-icon.png.data b/documentation/18.11/eiffelstudio/_images/continued-icon.png.data new file mode 100644 index 00000000..32e80176 --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/continued-icon.png.data @@ -0,0 +1,3 @@ +title=continued-icon +author=halw +path=content/continued-icon diff --git a/documentation/18.11/eiffelstudio/_images/contract-editor-edit-icon.png b/documentation/18.11/eiffelstudio/_images/contract-editor-edit-icon.png new file mode 100644 index 00000000..4c8bd978 Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/contract-editor-edit-icon.png differ diff --git a/documentation/18.11/eiffelstudio/_images/contract-editor-edit-icon.png.data b/documentation/18.11/eiffelstudio/_images/contract-editor-edit-icon.png.data new file mode 100644 index 00000000..b10a36a6 --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/contract-editor-edit-icon.png.data @@ -0,0 +1,3 @@ +title=contract-editor-edit-icon +author=halw +path=content/contract-editor-edit-icon diff --git a/documentation/18.11/eiffelstudio/_images/contract-icon.png b/documentation/18.11/eiffelstudio/_images/contract-icon.png new file mode 100644 index 00000000..d9dd26d8 Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/contract-icon.png differ diff --git a/documentation/18.11/eiffelstudio/_images/contract-icon.png.data b/documentation/18.11/eiffelstudio/_images/contract-icon.png.data new file mode 100644 index 00000000..87ced1b3 --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/contract-icon.png.data @@ -0,0 +1,3 @@ +title=contract-icon +author=halw +path=content/contract-icon diff --git a/documentation/18.11/eiffelstudio/_images/create-a-project.png b/documentation/18.11/eiffelstudio/_images/create-a-project.png new file mode 100644 index 00000000..33d4a330 Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/create-a-project.png differ diff --git a/documentation/18.11/eiffelstudio/_images/create-a-project.png.data b/documentation/18.11/eiffelstudio/_images/create-a-project.png.data new file mode 100644 index 00000000..0e197699 --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/create-a-project.png.data @@ -0,0 +1,3 @@ +title=create-a-project +author=admin +path=content/create-project diff --git a/documentation/18.11/eiffelstudio/_images/debug-exception-dialog-icon.png b/documentation/18.11/eiffelstudio/_images/debug-exception-dialog-icon.png new file mode 100644 index 00000000..dc788b0f Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/debug-exception-dialog-icon.png differ diff --git a/documentation/18.11/eiffelstudio/_images/debug-exception-dialog-icon.png.data b/documentation/18.11/eiffelstudio/_images/debug-exception-dialog-icon.png.data new file mode 100644 index 00000000..6a6fd7ba --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/debug-exception-dialog-icon.png.data @@ -0,0 +1,3 @@ +title=debug-exception-dialog-icon +author=admin +path=content/debug-exception-dialog-icon diff --git a/documentation/18.11/eiffelstudio/_images/debug-options.png b/documentation/18.11/eiffelstudio/_images/debug-options.png new file mode 100644 index 00000000..50e4b922 Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/debug-options.png differ diff --git a/documentation/18.11/eiffelstudio/_images/debug-options.png.data b/documentation/18.11/eiffelstudio/_images/debug-options.png.data new file mode 100644 index 00000000..a509b487 --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/debug-options.png.data @@ -0,0 +1,3 @@ +title=debug-options +author=admin +path=content/debug-options diff --git a/documentation/18.11/eiffelstudio/_images/debug-pause-icon.png b/documentation/18.11/eiffelstudio/_images/debug-pause-icon.png new file mode 100644 index 00000000..b5ff990a Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/debug-pause-icon.png differ diff --git a/documentation/18.11/eiffelstudio/_images/debug-pause-icon.png.data b/documentation/18.11/eiffelstudio/_images/debug-pause-icon.png.data new file mode 100644 index 00000000..91ef6199 --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/debug-pause-icon.png.data @@ -0,0 +1,3 @@ +title=debug-pause-icon +author=admin +path=content/debug-pause-icon diff --git a/documentation/18.11/eiffelstudio/_images/debug-run-finalized-icon.png b/documentation/18.11/eiffelstudio/_images/debug-run-finalized-icon.png new file mode 100644 index 00000000..f457a5cc Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/debug-run-finalized-icon.png differ diff --git a/documentation/18.11/eiffelstudio/_images/debug-run-finalized-icon.png.data b/documentation/18.11/eiffelstudio/_images/debug-run-finalized-icon.png.data new file mode 100644 index 00000000..581466db --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/debug-run-finalized-icon.png.data @@ -0,0 +1,3 @@ +title=debug-run-finalized-icon +author=admin +path=content/debug-run-finalized-icon diff --git a/documentation/18.11/eiffelstudio/_images/debug-run-icon.png b/documentation/18.11/eiffelstudio/_images/debug-run-icon.png new file mode 100644 index 00000000..c19fa0fb Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/debug-run-icon.png differ diff --git a/documentation/18.11/eiffelstudio/_images/debug-run-icon.png.data b/documentation/18.11/eiffelstudio/_images/debug-run-icon.png.data new file mode 100644 index 00000000..ab083fed --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/debug-run-icon.png.data @@ -0,0 +1,3 @@ +title=debug-run-icon +author=admin +path=content/debug-run-icon diff --git a/documentation/18.11/eiffelstudio/_images/debug-run-without-breakpoint-icon.png b/documentation/18.11/eiffelstudio/_images/debug-run-without-breakpoint-icon.png new file mode 100644 index 00000000..424bd08a Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/debug-run-without-breakpoint-icon.png differ diff --git a/documentation/18.11/eiffelstudio/_images/debug-run-without-breakpoint-icon.png.data b/documentation/18.11/eiffelstudio/_images/debug-run-without-breakpoint-icon.png.data new file mode 100644 index 00000000..5bea7e73 --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/debug-run-without-breakpoint-icon.png.data @@ -0,0 +1,3 @@ +title=debug-run-without-breakpoint-icon +author=admin +path=content/debug-run-without-breakpoint-icon diff --git a/documentation/18.11/eiffelstudio/_images/debug-show-breakpoints-tool.png b/documentation/18.11/eiffelstudio/_images/debug-show-breakpoints-tool.png new file mode 100644 index 00000000..57749f8e Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/debug-show-breakpoints-tool.png differ diff --git a/documentation/18.11/eiffelstudio/_images/debug-show-breakpoints-tool.png.data b/documentation/18.11/eiffelstudio/_images/debug-show-breakpoints-tool.png.data new file mode 100644 index 00000000..d2ac1719 --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/debug-show-breakpoints-tool.png.data @@ -0,0 +1,3 @@ +title=debug-show-breakpoints-tool +author=halw +path=content/debug-show-breakpoints-tool diff --git a/documentation/18.11/eiffelstudio/_images/debug-step-into-icon.png b/documentation/18.11/eiffelstudio/_images/debug-step-into-icon.png new file mode 100644 index 00000000..93bedf88 Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/debug-step-into-icon.png differ diff --git a/documentation/18.11/eiffelstudio/_images/debug-step-into-icon.png.data b/documentation/18.11/eiffelstudio/_images/debug-step-into-icon.png.data new file mode 100644 index 00000000..d83d3eba --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/debug-step-into-icon.png.data @@ -0,0 +1,3 @@ +title=debug-step-into-icon +author=admin +path=content/debug-step-icon diff --git a/documentation/18.11/eiffelstudio/_images/debug-step-out-icon.png b/documentation/18.11/eiffelstudio/_images/debug-step-out-icon.png new file mode 100644 index 00000000..3debd7af Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/debug-step-out-icon.png differ diff --git a/documentation/18.11/eiffelstudio/_images/debug-step-out-icon.png.data b/documentation/18.11/eiffelstudio/_images/debug-step-out-icon.png.data new file mode 100644 index 00000000..920ec253 --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/debug-step-out-icon.png.data @@ -0,0 +1,3 @@ +title=debug-step-out-icon +author=admin +path=content/debug-step-out-icon diff --git a/documentation/18.11/eiffelstudio/_images/debug-step-over-icon.png b/documentation/18.11/eiffelstudio/_images/debug-step-over-icon.png new file mode 100644 index 00000000..f1918233 Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/debug-step-over-icon.png differ diff --git a/documentation/18.11/eiffelstudio/_images/debug-step-over-icon.png.data b/documentation/18.11/eiffelstudio/_images/debug-step-over-icon.png.data new file mode 100644 index 00000000..bbd4f7f3 --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/debug-step-over-icon.png.data @@ -0,0 +1,3 @@ +title=debug-step-over-icon +author=admin +path=content/debug-step-over-icon diff --git a/documentation/18.11/eiffelstudio/_images/debug-stop-icon.png b/documentation/18.11/eiffelstudio/_images/debug-stop-icon.png new file mode 100644 index 00000000..8120249f Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/debug-stop-icon.png differ diff --git a/documentation/18.11/eiffelstudio/_images/debug-stop-icon.png.data b/documentation/18.11/eiffelstudio/_images/debug-stop-icon.png.data new file mode 100644 index 00000000..eb89d19c --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/debug-stop-icon.png.data @@ -0,0 +1,3 @@ +title=debug-stop-icon +author=admin +path=content/debug-stop-icon diff --git a/documentation/18.11/eiffelstudio/_images/debug-stopped-on-breakpoint-icon.png b/documentation/18.11/eiffelstudio/_images/debug-stopped-on-breakpoint-icon.png new file mode 100644 index 00000000..0ede1b24 Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/debug-stopped-on-breakpoint-icon.png differ diff --git a/documentation/18.11/eiffelstudio/_images/debug-stopped-on-breakpoint-icon.png.data b/documentation/18.11/eiffelstudio/_images/debug-stopped-on-breakpoint-icon.png.data new file mode 100644 index 00000000..4412741f --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/debug-stopped-on-breakpoint-icon.png.data @@ -0,0 +1,3 @@ +title=debug-stopped-on-breakpoint-icon +author=halw +path=content/debug-stopped-breakpoint-icon diff --git a/documentation/18.11/eiffelstudio/_images/debuggee-object-storage-load.png b/documentation/18.11/eiffelstudio/_images/debuggee-object-storage-load.png new file mode 100644 index 00000000..e7165155 Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/debuggee-object-storage-load.png differ diff --git a/documentation/18.11/eiffelstudio/_images/debuggee-object-storage-load.png.data b/documentation/18.11/eiffelstudio/_images/debuggee-object-storage-load.png.data new file mode 100644 index 00000000..0ff3a76b --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/debuggee-object-storage-load.png.data @@ -0,0 +1,3 @@ +title=debuggee-object-storage-load +author=admin +path=content/debuggee-object-storage-load diff --git a/documentation/18.11/eiffelstudio/_images/debuggee-object-storage-save.png b/documentation/18.11/eiffelstudio/_images/debuggee-object-storage-save.png new file mode 100644 index 00000000..781f7f05 Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/debuggee-object-storage-save.png differ diff --git a/documentation/18.11/eiffelstudio/_images/debuggee-object-storage-save.png.data b/documentation/18.11/eiffelstudio/_images/debuggee-object-storage-save.png.data new file mode 100644 index 00000000..4439a622 --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/debuggee-object-storage-save.png.data @@ -0,0 +1,3 @@ +title=debuggee-object-storage-save +author=admin +path=content/debuggee-object-storage-save diff --git a/documentation/18.11/eiffelstudio/_images/debugger-auto-values.png b/documentation/18.11/eiffelstudio/_images/debugger-auto-values.png new file mode 100644 index 00000000..bfc8a520 Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/debugger-auto-values.png differ diff --git a/documentation/18.11/eiffelstudio/_images/debugger-auto-values.png.data b/documentation/18.11/eiffelstudio/_images/debugger-auto-values.png.data new file mode 100644 index 00000000..eba2a92e --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/debugger-auto-values.png.data @@ -0,0 +1,3 @@ +title=debugger-auto-values +author=admin +path=content/debugger-auto-values diff --git a/documentation/18.11/eiffelstudio/_images/debugger-callstack-depth-icon.png b/documentation/18.11/eiffelstudio/_images/debugger-callstack-depth-icon.png new file mode 100644 index 00000000..a5e719b2 Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/debugger-callstack-depth-icon.png differ diff --git a/documentation/18.11/eiffelstudio/_images/debugger-callstack-depth-icon.png.data b/documentation/18.11/eiffelstudio/_images/debugger-callstack-depth-icon.png.data new file mode 100644 index 00000000..3359cb69 --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/debugger-callstack-depth-icon.png.data @@ -0,0 +1,3 @@ +title=debugger-callstack-depth-icon +author=admin +path=content/debugger-callstack-depth-icon diff --git a/documentation/18.11/eiffelstudio/_images/debugger-expand-info-icon.png b/documentation/18.11/eiffelstudio/_images/debugger-expand-info-icon.png new file mode 100644 index 00000000..0dfd5549 Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/debugger-expand-info-icon.png differ diff --git a/documentation/18.11/eiffelstudio/_images/debugger-expand-info-icon.png.data b/documentation/18.11/eiffelstudio/_images/debugger-expand-info-icon.png.data new file mode 100644 index 00000000..3f715887 --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/debugger-expand-info-icon.png.data @@ -0,0 +1,3 @@ +title=debugger-expand-info-icon +author=admin +path=content/debugger-expand-info-icon diff --git a/documentation/18.11/eiffelstudio/_images/debugger-object-dotnet-icon.png b/documentation/18.11/eiffelstudio/_images/debugger-object-dotnet-icon.png new file mode 100644 index 00000000..7ac5d567 Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/debugger-object-dotnet-icon.png differ diff --git a/documentation/18.11/eiffelstudio/_images/debugger-object-dotnet-icon.png.data b/documentation/18.11/eiffelstudio/_images/debugger-object-dotnet-icon.png.data new file mode 100644 index 00000000..60b8ee06 --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/debugger-object-dotnet-icon.png.data @@ -0,0 +1,3 @@ +title=debugger-object-dotnet-icon +author=admin +path=content/debugger-object-dotnet-icon diff --git a/documentation/18.11/eiffelstudio/_images/debugger-object-dotnet-static-icon.png b/documentation/18.11/eiffelstudio/_images/debugger-object-dotnet-static-icon.png new file mode 100644 index 00000000..f048aef9 Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/debugger-object-dotnet-static-icon.png differ diff --git a/documentation/18.11/eiffelstudio/_images/debugger-object-dotnet-static-icon.png.data b/documentation/18.11/eiffelstudio/_images/debugger-object-dotnet-static-icon.png.data new file mode 100644 index 00000000..7a372480 --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/debugger-object-dotnet-static-icon.png.data @@ -0,0 +1,3 @@ +title=debugger-object-dotnet-static-icon +author=admin +path=content/debugger-object-dotnet-static-icon diff --git a/documentation/18.11/eiffelstudio/_images/debugger-object-eiffel-icon.png b/documentation/18.11/eiffelstudio/_images/debugger-object-eiffel-icon.png new file mode 100644 index 00000000..34b7adc8 Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/debugger-object-eiffel-icon.png differ diff --git a/documentation/18.11/eiffelstudio/_images/debugger-object-eiffel-icon.png.data b/documentation/18.11/eiffelstudio/_images/debugger-object-eiffel-icon.png.data new file mode 100644 index 00000000..905f1624 --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/debugger-object-eiffel-icon.png.data @@ -0,0 +1,3 @@ +title=debugger-object-eiffel-icon +author=admin +path=content/debugger-object-eiffel-icon diff --git a/documentation/18.11/eiffelstudio/_images/debugger-object-expand-icon.png b/documentation/18.11/eiffelstudio/_images/debugger-object-expand-icon.png new file mode 100644 index 00000000..021dfd40 Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/debugger-object-expand-icon.png differ diff --git a/documentation/18.11/eiffelstudio/_images/debugger-object-expand-icon.png.data b/documentation/18.11/eiffelstudio/_images/debugger-object-expand-icon.png.data new file mode 100644 index 00000000..69ddef16 --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/debugger-object-expand-icon.png.data @@ -0,0 +1,3 @@ +title=debugger-object-expand-icon +author=admin +path=content/debugger-object-expand-icon diff --git a/documentation/18.11/eiffelstudio/_images/debugger-object-expanded-icon.png b/documentation/18.11/eiffelstudio/_images/debugger-object-expanded-icon.png new file mode 100644 index 00000000..27ce4f5f Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/debugger-object-expanded-icon.png differ diff --git a/documentation/18.11/eiffelstudio/_images/debugger-object-expanded-icon.png.data b/documentation/18.11/eiffelstudio/_images/debugger-object-expanded-icon.png.data new file mode 100644 index 00000000..458224c1 --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/debugger-object-expanded-icon.png.data @@ -0,0 +1,3 @@ +title=debugger-object-expanded-icon +author=admin +path=content/debugger-object-expanded-icon diff --git a/documentation/18.11/eiffelstudio/_images/debugger-object-immediate-icon.png b/documentation/18.11/eiffelstudio/_images/debugger-object-immediate-icon.png new file mode 100644 index 00000000..f69d8d31 Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/debugger-object-immediate-icon.png differ diff --git a/documentation/18.11/eiffelstudio/_images/debugger-object-immediate-icon.png.data b/documentation/18.11/eiffelstudio/_images/debugger-object-immediate-icon.png.data new file mode 100644 index 00000000..21e37241 --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/debugger-object-immediate-icon.png.data @@ -0,0 +1,3 @@ +title=debugger-object-immediate-icon +author=admin +path=content/debugger-object-immediate-icon diff --git a/documentation/18.11/eiffelstudio/_images/debugger-object-static-icon.png b/documentation/18.11/eiffelstudio/_images/debugger-object-static-icon.png new file mode 100644 index 00000000..dd095688 Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/debugger-object-static-icon.png differ diff --git a/documentation/18.11/eiffelstudio/_images/debugger-object-static-icon.png.data b/documentation/18.11/eiffelstudio/_images/debugger-object-static-icon.png.data new file mode 100644 index 00000000..8a6a15de --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/debugger-object-static-icon.png.data @@ -0,0 +1,3 @@ +title=debugger-object-static-icon +author=admin +path=content/debugger-object-static-icon diff --git a/documentation/18.11/eiffelstudio/_images/debugger-object-void-icon.png b/documentation/18.11/eiffelstudio/_images/debugger-object-void-icon.png new file mode 100644 index 00000000..3f8440b7 Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/debugger-object-void-icon.png differ diff --git a/documentation/18.11/eiffelstudio/_images/debugger-object-void-icon.png.data b/documentation/18.11/eiffelstudio/_images/debugger-object-void-icon.png.data new file mode 100644 index 00000000..640623f5 --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/debugger-object-void-icon.png.data @@ -0,0 +1,3 @@ +title=debugger-object-void-icon +author=admin +path=content/debugger-object-void-icon diff --git a/documentation/18.11/eiffelstudio/_images/debugger-set-sizes-icon.png b/documentation/18.11/eiffelstudio/_images/debugger-set-sizes-icon.png new file mode 100644 index 00000000..4ea36d5e Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/debugger-set-sizes-icon.png differ diff --git a/documentation/18.11/eiffelstudio/_images/debugger-set-sizes-icon.png.data b/documentation/18.11/eiffelstudio/_images/debugger-set-sizes-icon.png.data new file mode 100644 index 00000000..b160d4ce --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/debugger-set-sizes-icon.png.data @@ -0,0 +1,3 @@ +title=debugger-set-sizes-icon +author=admin +path=content/debugger-set-sizes-icon diff --git a/documentation/18.11/eiffelstudio/_images/debugger-show-hex-value-icon.png b/documentation/18.11/eiffelstudio/_images/debugger-show-hex-value-icon.png new file mode 100644 index 00000000..46ba2005 Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/debugger-show-hex-value-icon.png differ diff --git a/documentation/18.11/eiffelstudio/_images/debugger-show-hex-value-icon.png.data b/documentation/18.11/eiffelstudio/_images/debugger-show-hex-value-icon.png.data new file mode 100644 index 00000000..4d6466b7 --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/debugger-show-hex-value-icon.png.data @@ -0,0 +1,3 @@ +title=debugger-show-hex-value-icon +author=admin +path=content/debugger-show-hex-value-icon diff --git a/documentation/18.11/eiffelstudio/_images/debugging-tools-preferences.png b/documentation/18.11/eiffelstudio/_images/debugging-tools-preferences.png new file mode 100644 index 00000000..cabf2b88 Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/debugging-tools-preferences.png differ diff --git a/documentation/18.11/eiffelstudio/_images/debugging-tools-preferences.png.data b/documentation/18.11/eiffelstudio/_images/debugging-tools-preferences.png.data new file mode 100644 index 00000000..e553087d --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/debugging-tools-preferences.png.data @@ -0,0 +1,3 @@ +title=debugging-tools-preferences +author=admin +path=content/debugging-tools-preferences diff --git a/documentation/18.11/eiffelstudio/_images/deselect-all.png b/documentation/18.11/eiffelstudio/_images/deselect-all.png new file mode 100644 index 00000000..3811e88b Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/deselect-all.png differ diff --git a/documentation/18.11/eiffelstudio/_images/deselect-all.png.data b/documentation/18.11/eiffelstudio/_images/deselect-all.png.data new file mode 100644 index 00000000..98ffc028 --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/deselect-all.png.data @@ -0,0 +1,3 @@ +title=deselect-all +author=admin +path=content/deselect-all diff --git a/documentation/18.11/eiffelstudio/_images/deselect-recalculatable.png b/documentation/18.11/eiffelstudio/_images/deselect-recalculatable.png new file mode 100644 index 00000000..0dc43769 Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/deselect-recalculatable.png differ diff --git a/documentation/18.11/eiffelstudio/_images/deselect-recalculatable.png.data b/documentation/18.11/eiffelstudio/_images/deselect-recalculatable.png.data new file mode 100644 index 00000000..c8a7d2a9 --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/deselect-recalculatable.png.data @@ -0,0 +1,3 @@ +title=deselect-recalculatable +author=admin +path=content/deselect-recalculatable diff --git a/documentation/18.11/eiffelstudio/_images/devel-diagram.png b/documentation/18.11/eiffelstudio/_images/devel-diagram.png new file mode 100644 index 00000000..7bfa0e0d Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/devel-diagram.png differ diff --git a/documentation/18.11/eiffelstudio/_images/devel-diagram.png.data b/documentation/18.11/eiffelstudio/_images/devel-diagram.png.data new file mode 100644 index 00000000..2b2f87ae --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/devel-diagram.png.data @@ -0,0 +1,3 @@ +title=devel-diagram +author=admin +path=content/devel-diagram diff --git a/documentation/18.11/eiffelstudio/_images/diagram-anchor-icon.png b/documentation/18.11/eiffelstudio/_images/diagram-anchor-icon.png new file mode 100644 index 00000000..0f5cd3f5 Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/diagram-anchor-icon.png differ diff --git a/documentation/18.11/eiffelstudio/_images/diagram-anchor-icon.png.data b/documentation/18.11/eiffelstudio/_images/diagram-anchor-icon.png.data new file mode 100644 index 00000000..c609d16b --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/diagram-anchor-icon.png.data @@ -0,0 +1,3 @@ +title=diagram-anchor-icon +author=admin +path=content/diagram-anchor-icon diff --git a/documentation/18.11/eiffelstudio/_images/diagram-choose-color-icon.png b/documentation/18.11/eiffelstudio/_images/diagram-choose-color-icon.png new file mode 100644 index 00000000..05f61449 Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/diagram-choose-color-icon.png differ diff --git a/documentation/18.11/eiffelstudio/_images/diagram-choose-color-icon.png.data b/documentation/18.11/eiffelstudio/_images/diagram-choose-color-icon.png.data new file mode 100644 index 00000000..268c3624 --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/diagram-choose-color-icon.png.data @@ -0,0 +1,3 @@ +title=diagram-choose-color-icon +author=admin +path=content/diagram-choose-color-icon diff --git a/documentation/18.11/eiffelstudio/_images/diagram-defaultview.png b/documentation/18.11/eiffelstudio/_images/diagram-defaultview.png new file mode 100644 index 00000000..dd690b1f Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/diagram-defaultview.png differ diff --git a/documentation/18.11/eiffelstudio/_images/diagram-defaultview.png.data b/documentation/18.11/eiffelstudio/_images/diagram-defaultview.png.data new file mode 100644 index 00000000..1d714aab --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/diagram-defaultview.png.data @@ -0,0 +1,3 @@ +title=diagram-defaultview +author=admin +path=content/diagram-defaultview diff --git a/documentation/18.11/eiffelstudio/_images/diagram-depth-of-relations-icon.png b/documentation/18.11/eiffelstudio/_images/diagram-depth-of-relations-icon.png new file mode 100644 index 00000000..49aa6ca8 Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/diagram-depth-of-relations-icon.png differ diff --git a/documentation/18.11/eiffelstudio/_images/diagram-depth-of-relations-icon.png.data b/documentation/18.11/eiffelstudio/_images/diagram-depth-of-relations-icon.png.data new file mode 100644 index 00000000..900e159f --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/diagram-depth-of-relations-icon.png.data @@ -0,0 +1,3 @@ +title=diagram-depth-of-relations-icon +author=admin +path=content/diagram-depth-relations-icon diff --git a/documentation/18.11/eiffelstudio/_images/diagram-export-to-png-icon.png b/documentation/18.11/eiffelstudio/_images/diagram-export-to-png-icon.png new file mode 100644 index 00000000..a11274d8 Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/diagram-export-to-png-icon.png differ diff --git a/documentation/18.11/eiffelstudio/_images/diagram-export-to-png-icon.png.data b/documentation/18.11/eiffelstudio/_images/diagram-export-to-png-icon.png.data new file mode 100644 index 00000000..262fda2d --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/diagram-export-to-png-icon.png.data @@ -0,0 +1,3 @@ +title=diagram-export-to-png-icon +author=admin +path=content/diagram-export-png-icon diff --git a/documentation/18.11/eiffelstudio/_images/diagram-fill-cluster-icon.png b/documentation/18.11/eiffelstudio/_images/diagram-fill-cluster-icon.png new file mode 100644 index 00000000..a89c2211 Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/diagram-fill-cluster-icon.png differ diff --git a/documentation/18.11/eiffelstudio/_images/diagram-fill-cluster-icon.png.data b/documentation/18.11/eiffelstudio/_images/diagram-fill-cluster-icon.png.data new file mode 100644 index 00000000..28a13566 --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/diagram-fill-cluster-icon.png.data @@ -0,0 +1,3 @@ +title=diagram-fill-cluster-icon +author=admin +path=content/diagram-fill-cluster-icon diff --git a/documentation/18.11/eiffelstudio/_images/diagram-fit-to-screen-icon.png b/documentation/18.11/eiffelstudio/_images/diagram-fit-to-screen-icon.png new file mode 100644 index 00000000..e43d03f7 Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/diagram-fit-to-screen-icon.png differ diff --git a/documentation/18.11/eiffelstudio/_images/diagram-fit-to-screen-icon.png.data b/documentation/18.11/eiffelstudio/_images/diagram-fit-to-screen-icon.png.data new file mode 100644 index 00000000..ad0a7722 --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/diagram-fit-to-screen-icon.png.data @@ -0,0 +1,3 @@ +title=diagram-fit-to-screen-icon +author=admin +path=content/diagram-fit-screen-icon diff --git a/documentation/18.11/eiffelstudio/_images/diagram-force-right-angles-icon.png b/documentation/18.11/eiffelstudio/_images/diagram-force-right-angles-icon.png new file mode 100644 index 00000000..ff1174b2 Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/diagram-force-right-angles-icon.png differ diff --git a/documentation/18.11/eiffelstudio/_images/diagram-force-right-angles-icon.png.data b/documentation/18.11/eiffelstudio/_images/diagram-force-right-angles-icon.png.data new file mode 100644 index 00000000..87bb6b00 --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/diagram-force-right-angles-icon.png.data @@ -0,0 +1,3 @@ +title=diagram-force-right-angles-icon +author=admin +path=content/diagram-force-right-angles-icon diff --git a/documentation/18.11/eiffelstudio/_images/diagram-inheritance-link-icon.png b/documentation/18.11/eiffelstudio/_images/diagram-inheritance-link-icon.png new file mode 100644 index 00000000..267f832a Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/diagram-inheritance-link-icon.png differ diff --git a/documentation/18.11/eiffelstudio/_images/diagram-inheritance-link-icon.png.data b/documentation/18.11/eiffelstudio/_images/diagram-inheritance-link-icon.png.data new file mode 100644 index 00000000..8d214c9c --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/diagram-inheritance-link-icon.png.data @@ -0,0 +1,3 @@ +title=diagram-inheritance-link-icon +author=admin +path=content/diagram-inheritance-link-icon diff --git a/documentation/18.11/eiffelstudio/_images/diagram-myview.png b/documentation/18.11/eiffelstudio/_images/diagram-myview.png new file mode 100644 index 00000000..0e1cac92 Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/diagram-myview.png differ diff --git a/documentation/18.11/eiffelstudio/_images/diagram-myview.png.data b/documentation/18.11/eiffelstudio/_images/diagram-myview.png.data new file mode 100644 index 00000000..f4e66a38 --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/diagram-myview.png.data @@ -0,0 +1,3 @@ +title=diagram-myview +author=admin +path=content/diagram-myview diff --git a/documentation/18.11/eiffelstudio/_images/diagram-new-conforming-inheritance-link-icon.png b/documentation/18.11/eiffelstudio/_images/diagram-new-conforming-inheritance-link-icon.png new file mode 100644 index 00000000..e2dc666f Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/diagram-new-conforming-inheritance-link-icon.png differ diff --git a/documentation/18.11/eiffelstudio/_images/diagram-new-conforming-inheritance-link-icon.png.data b/documentation/18.11/eiffelstudio/_images/diagram-new-conforming-inheritance-link-icon.png.data new file mode 100644 index 00000000..da1feb3d --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/diagram-new-conforming-inheritance-link-icon.png.data @@ -0,0 +1,3 @@ +title=diagram-new-conforming-inheritance-link-icon +author=halw +path=content/diagram-new-conforming-inheritance-link-icon diff --git a/documentation/18.11/eiffelstudio/_images/diagram-new-supplier-link-icon.png b/documentation/18.11/eiffelstudio/_images/diagram-new-supplier-link-icon.png new file mode 100644 index 00000000..276508db Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/diagram-new-supplier-link-icon.png differ diff --git a/documentation/18.11/eiffelstudio/_images/diagram-new-supplier-link-icon.png.data b/documentation/18.11/eiffelstudio/_images/diagram-new-supplier-link-icon.png.data new file mode 100644 index 00000000..d225cff8 --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/diagram-new-supplier-link-icon.png.data @@ -0,0 +1,3 @@ +title=diagram-new-supplier-link-icon +author=halw +path=content/diagram-new-supplier-link-icon diff --git a/documentation/18.11/eiffelstudio/_images/diagram-physics-settings-icon.png b/documentation/18.11/eiffelstudio/_images/diagram-physics-settings-icon.png new file mode 100644 index 00000000..83f3582f Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/diagram-physics-settings-icon.png differ diff --git a/documentation/18.11/eiffelstudio/_images/diagram-physics-settings-icon.png.data b/documentation/18.11/eiffelstudio/_images/diagram-physics-settings-icon.png.data new file mode 100644 index 00000000..50bc15eb --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/diagram-physics-settings-icon.png.data @@ -0,0 +1,3 @@ +title=diagram-physics-settings-icon +author=admin +path=content/diagram-physics-settings-icon diff --git a/documentation/18.11/eiffelstudio/_images/diagram-show-labels-icon.png b/documentation/18.11/eiffelstudio/_images/diagram-show-labels-icon.png new file mode 100644 index 00000000..34140a8d Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/diagram-show-labels-icon.png differ diff --git a/documentation/18.11/eiffelstudio/_images/diagram-show-labels-icon.png.data b/documentation/18.11/eiffelstudio/_images/diagram-show-labels-icon.png.data new file mode 100644 index 00000000..1eb290cb --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/diagram-show-labels-icon.png.data @@ -0,0 +1,3 @@ +title=diagram-show-labels-icon +author=admin +path=content/diagram-show-labels-icon diff --git a/documentation/18.11/eiffelstudio/_images/diagram-show-legend-icon.png b/documentation/18.11/eiffelstudio/_images/diagram-show-legend-icon.png new file mode 100644 index 00000000..95bdeacc Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/diagram-show-legend-icon.png differ diff --git a/documentation/18.11/eiffelstudio/_images/diagram-show-legend-icon.png.data b/documentation/18.11/eiffelstudio/_images/diagram-show-legend-icon.png.data new file mode 100644 index 00000000..9820a0eb --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/diagram-show-legend-icon.png.data @@ -0,0 +1,3 @@ +title=diagram-show-legend-icon +author=admin +path=content/diagram-show-legend-icon diff --git a/documentation/18.11/eiffelstudio/_images/diagram-supplier-link-icon.png b/documentation/18.11/eiffelstudio/_images/diagram-supplier-link-icon.png new file mode 100644 index 00000000..fe4125b2 Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/diagram-supplier-link-icon.png differ diff --git a/documentation/18.11/eiffelstudio/_images/diagram-supplier-link-icon.png.data b/documentation/18.11/eiffelstudio/_images/diagram-supplier-link-icon.png.data new file mode 100644 index 00000000..14a4cb08 --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/diagram-supplier-link-icon.png.data @@ -0,0 +1,3 @@ +title=diagram-supplier-link-icon +author=admin +path=content/diagram-supplier-link-icon diff --git a/documentation/18.11/eiffelstudio/_images/diagram-target-cluster-or-class-icon.png b/documentation/18.11/eiffelstudio/_images/diagram-target-cluster-or-class-icon.png new file mode 100644 index 00000000..0b902e4e Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/diagram-target-cluster-or-class-icon.png differ diff --git a/documentation/18.11/eiffelstudio/_images/diagram-target-cluster-or-class-icon.png.data b/documentation/18.11/eiffelstudio/_images/diagram-target-cluster-or-class-icon.png.data new file mode 100644 index 00000000..1597da1c --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/diagram-target-cluster-or-class-icon.png.data @@ -0,0 +1,3 @@ +title=diagram-target-cluster-or-class-icon +author=admin +path=content/diagram-target-cluster-or-class-icon diff --git a/documentation/18.11/eiffelstudio/_images/diagram-toggle-quality-icon.png b/documentation/18.11/eiffelstudio/_images/diagram-toggle-quality-icon.png new file mode 100644 index 00000000..a3e92fae Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/diagram-toggle-quality-icon.png differ diff --git a/documentation/18.11/eiffelstudio/_images/diagram-toggle-quality-icon.png.data b/documentation/18.11/eiffelstudio/_images/diagram-toggle-quality-icon.png.data new file mode 100644 index 00000000..5bbe6ba1 --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/diagram-toggle-quality-icon.png.data @@ -0,0 +1,3 @@ +title=diagram-toggle-quality-icon +author=admin +path=content/diagram-toggle-quality-icon diff --git a/documentation/18.11/eiffelstudio/_images/diagram-toogle-physics-icon.png b/documentation/18.11/eiffelstudio/_images/diagram-toogle-physics-icon.png new file mode 100644 index 00000000..bd46e040 Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/diagram-toogle-physics-icon.png differ diff --git a/documentation/18.11/eiffelstudio/_images/diagram-toogle-physics-icon.png.data b/documentation/18.11/eiffelstudio/_images/diagram-toogle-physics-icon.png.data new file mode 100644 index 00000000..e91a871c --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/diagram-toogle-physics-icon.png.data @@ -0,0 +1,3 @@ +title=diagram-toogle-physics-icon +author=admin +path=content/diagram-toogle-physics-icon diff --git a/documentation/18.11/eiffelstudio/_images/diagram-tool-tab.png b/documentation/18.11/eiffelstudio/_images/diagram-tool-tab.png new file mode 100644 index 00000000..e011bab5 Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/diagram-tool-tab.png differ diff --git a/documentation/18.11/eiffelstudio/_images/diagram-tool-tab.png.data b/documentation/18.11/eiffelstudio/_images/diagram-tool-tab.png.data new file mode 100644 index 00000000..607c0438 --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/diagram-tool-tab.png.data @@ -0,0 +1,3 @@ +title=diagram-tool-tab +author=halw +path=content/diagram-tool-tab diff --git a/documentation/18.11/eiffelstudio/_images/diagram-view-combo.png b/documentation/18.11/eiffelstudio/_images/diagram-view-combo.png new file mode 100644 index 00000000..f781da2f Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/diagram-view-combo.png differ diff --git a/documentation/18.11/eiffelstudio/_images/diagram-view-combo.png.data b/documentation/18.11/eiffelstudio/_images/diagram-view-combo.png.data new file mode 100644 index 00000000..abb344c7 --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/diagram-view-combo.png.data @@ -0,0 +1,3 @@ +title=diagram-view-combo +author=admin +path=content/diagram-view-combo diff --git a/documentation/18.11/eiffelstudio/_images/diagram-view-uml-icon.png b/documentation/18.11/eiffelstudio/_images/diagram-view-uml-icon.png new file mode 100644 index 00000000..f1e15b5b Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/diagram-view-uml-icon.png differ diff --git a/documentation/18.11/eiffelstudio/_images/diagram-view-uml-icon.png.data b/documentation/18.11/eiffelstudio/_images/diagram-view-uml-icon.png.data new file mode 100644 index 00000000..623d129a --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/diagram-view-uml-icon.png.data @@ -0,0 +1,3 @@ +title=diagram-view-uml-icon +author=admin +path=content/diagram-view-uml-icon diff --git a/documentation/18.11/eiffelstudio/_images/diagram-zoom-in-icon.png b/documentation/18.11/eiffelstudio/_images/diagram-zoom-in-icon.png new file mode 100644 index 00000000..37c8a648 Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/diagram-zoom-in-icon.png differ diff --git a/documentation/18.11/eiffelstudio/_images/diagram-zoom-in-icon.png.data b/documentation/18.11/eiffelstudio/_images/diagram-zoom-in-icon.png.data new file mode 100644 index 00000000..07e01fdc --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/diagram-zoom-in-icon.png.data @@ -0,0 +1,3 @@ +title=diagram-zoom-in-icon +author=admin +path=content/diagram-zoom-icon diff --git a/documentation/18.11/eiffelstudio/_images/diagram-zoom-out-icon.png b/documentation/18.11/eiffelstudio/_images/diagram-zoom-out-icon.png new file mode 100644 index 00000000..f283d595 Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/diagram-zoom-out-icon.png differ diff --git a/documentation/18.11/eiffelstudio/_images/diagram-zoom-out-icon.png.data b/documentation/18.11/eiffelstudio/_images/diagram-zoom-out-icon.png.data new file mode 100644 index 00000000..106ac5d5 --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/diagram-zoom-out-icon.png.data @@ -0,0 +1,3 @@ +title=diagram-zoom-out-icon +author=admin +path=content/diagram-zoom-out-icon diff --git a/documentation/18.11/eiffelstudio/_images/dialogs-and-wizards--preferences-dialog.png b/documentation/18.11/eiffelstudio/_images/dialogs-and-wizards--preferences-dialog.png new file mode 100644 index 00000000..00f69141 Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/dialogs-and-wizards--preferences-dialog.png differ diff --git a/documentation/18.11/eiffelstudio/_images/dialogs-and-wizards--preferences-dialog.png.data b/documentation/18.11/eiffelstudio/_images/dialogs-and-wizards--preferences-dialog.png.data new file mode 100644 index 00000000..fc85fe1b --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/dialogs-and-wizards--preferences-dialog.png.data @@ -0,0 +1,3 @@ +title=dialogs-and-wizards--preferences-dialog +author=admin +path=content/dialogs-and-wizards-preferences-dialog diff --git a/documentation/18.11/eiffelstudio/_images/disambiguated-name-icon.png b/documentation/18.11/eiffelstudio/_images/disambiguated-name-icon.png new file mode 100644 index 00000000..f004e07b Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/disambiguated-name-icon.png differ diff --git a/documentation/18.11/eiffelstudio/_images/disambiguated-name-icon.png.data b/documentation/18.11/eiffelstudio/_images/disambiguated-name-icon.png.data new file mode 100644 index 00000000..a2aebe33 --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/disambiguated-name-icon.png.data @@ -0,0 +1,3 @@ +title=disambiguated name icon +author=halw +path=content/disambiguated-name-icon diff --git a/documentation/18.11/eiffelstudio/_images/docking-target-bottom.png b/documentation/18.11/eiffelstudio/_images/docking-target-bottom.png new file mode 100644 index 00000000..18a76c1f Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/docking-target-bottom.png differ diff --git a/documentation/18.11/eiffelstudio/_images/docking-target-bottom.png.data b/documentation/18.11/eiffelstudio/_images/docking-target-bottom.png.data new file mode 100644 index 00000000..56ecb39f --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/docking-target-bottom.png.data @@ -0,0 +1,3 @@ +title=docking-target-bottom +author=halw +path=content/docking-target-bottom diff --git a/documentation/18.11/eiffelstudio/_images/docking-target-left.png b/documentation/18.11/eiffelstudio/_images/docking-target-left.png new file mode 100644 index 00000000..e935af68 Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/docking-target-left.png differ diff --git a/documentation/18.11/eiffelstudio/_images/docking-target-left.png.data b/documentation/18.11/eiffelstudio/_images/docking-target-left.png.data new file mode 100644 index 00000000..d6418053 --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/docking-target-left.png.data @@ -0,0 +1,3 @@ +title=docking-target-left +author=halw +path=content/docking-target-left diff --git a/documentation/18.11/eiffelstudio/_images/docking-target-right.png b/documentation/18.11/eiffelstudio/_images/docking-target-right.png new file mode 100644 index 00000000..a39bfb01 Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/docking-target-right.png differ diff --git a/documentation/18.11/eiffelstudio/_images/docking-target-right.png.data b/documentation/18.11/eiffelstudio/_images/docking-target-right.png.data new file mode 100644 index 00000000..0b28c69c --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/docking-target-right.png.data @@ -0,0 +1,3 @@ +title=docking-target-right +author=halw +path=content/docking-target-right diff --git a/documentation/18.11/eiffelstudio/_images/docking-target-top.png b/documentation/18.11/eiffelstudio/_images/docking-target-top.png new file mode 100644 index 00000000..5e8830ca Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/docking-target-top.png differ diff --git a/documentation/18.11/eiffelstudio/_images/docking-target-top.png.data b/documentation/18.11/eiffelstudio/_images/docking-target-top.png.data new file mode 100644 index 00000000..f19e5562 --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/docking-target-top.png.data @@ -0,0 +1,3 @@ +title=docking-target-top +author=halw +path=content/docking-target-top diff --git a/documentation/18.11/eiffelstudio/_images/docking-target.png b/documentation/18.11/eiffelstudio/_images/docking-target.png new file mode 100644 index 00000000..12c9cab7 Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/docking-target.png differ diff --git a/documentation/18.11/eiffelstudio/_images/docking-target.png.data b/documentation/18.11/eiffelstudio/_images/docking-target.png.data new file mode 100644 index 00000000..5b1382eb --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/docking-target.png.data @@ -0,0 +1,3 @@ +title=docking-target +author=halw +path=content/docking-target diff --git a/documentation/18.11/eiffelstudio/_images/domain-example1.png b/documentation/18.11/eiffelstudio/_images/domain-example1.png new file mode 100644 index 00000000..4316e85b Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/domain-example1.png differ diff --git a/documentation/18.11/eiffelstudio/_images/domain-example1.png.data b/documentation/18.11/eiffelstudio/_images/domain-example1.png.data new file mode 100644 index 00000000..ada3ea87 --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/domain-example1.png.data @@ -0,0 +1,3 @@ +title=domain-example1 +author=admin +path=content/domain-example1 diff --git a/documentation/18.11/eiffelstudio/_images/domain-example2.png b/documentation/18.11/eiffelstudio/_images/domain-example2.png new file mode 100644 index 00000000..c966db12 Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/domain-example2.png differ diff --git a/documentation/18.11/eiffelstudio/_images/domain-example2.png.data b/documentation/18.11/eiffelstudio/_images/domain-example2.png.data new file mode 100644 index 00000000..c7617998 --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/domain-example2.png.data @@ -0,0 +1,3 @@ +title=domain-example2 +author=admin +path=content/domain-example2 diff --git a/documentation/18.11/eiffelstudio/_images/domain-example3.png b/documentation/18.11/eiffelstudio/_images/domain-example3.png new file mode 100644 index 00000000..a01690d1 Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/domain-example3.png differ diff --git a/documentation/18.11/eiffelstudio/_images/domain-example3.png.data b/documentation/18.11/eiffelstudio/_images/domain-example3.png.data new file mode 100644 index 00000000..442b97e1 --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/domain-example3.png.data @@ -0,0 +1,3 @@ +title=domain-example3 +author=admin +path=content/domain-example3 diff --git a/documentation/18.11/eiffelstudio/_images/domain-example4.png b/documentation/18.11/eiffelstudio/_images/domain-example4.png new file mode 100644 index 00000000..3b1e0b17 Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/domain-example4.png differ diff --git a/documentation/18.11/eiffelstudio/_images/domain-example4.png.data b/documentation/18.11/eiffelstudio/_images/domain-example4.png.data new file mode 100644 index 00000000..b88188ee --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/domain-example4.png.data @@ -0,0 +1,3 @@ +title=domain-example4 +author=admin +path=content/domain-example4 diff --git a/documentation/18.11/eiffelstudio/_images/domain-example5.png b/documentation/18.11/eiffelstudio/_images/domain-example5.png new file mode 100644 index 00000000..0ab9e1f8 Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/domain-example5.png differ diff --git a/documentation/18.11/eiffelstudio/_images/domain-example5.png.data b/documentation/18.11/eiffelstudio/_images/domain-example5.png.data new file mode 100644 index 00000000..77ad56a4 --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/domain-example5.png.data @@ -0,0 +1,3 @@ +title=domain-example5 +author=admin +path=content/domain-example5 diff --git a/documentation/18.11/eiffelstudio/_images/domain-example6.png b/documentation/18.11/eiffelstudio/_images/domain-example6.png new file mode 100644 index 00000000..55c896ab Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/domain-example6.png differ diff --git a/documentation/18.11/eiffelstudio/_images/domain-example6.png.data b/documentation/18.11/eiffelstudio/_images/domain-example6.png.data new file mode 100644 index 00000000..0aefabf1 --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/domain-example6.png.data @@ -0,0 +1,3 @@ +title=domain-example6 +author=admin +path=content/domain-example6 diff --git a/documentation/18.11/eiffelstudio/_images/edit_automatic_eis_entry_dialog.png b/documentation/18.11/eiffelstudio/_images/edit_automatic_eis_entry_dialog.png new file mode 100644 index 00000000..63446acd Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/edit_automatic_eis_entry_dialog.png differ diff --git a/documentation/18.11/eiffelstudio/_images/edit_automatic_eis_entry_dialog.png.data b/documentation/18.11/eiffelstudio/_images/edit_automatic_eis_entry_dialog.png.data new file mode 100644 index 00000000..a73c6db5 --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/edit_automatic_eis_entry_dialog.png.data @@ -0,0 +1,3 @@ +title=edit automatic eis entry dialog +author=halw +path=content/edit-automatic-eis-entry-dialog diff --git a/documentation/18.11/eiffelstudio/_images/editor-class-auto-completion-window.png b/documentation/18.11/eiffelstudio/_images/editor-class-auto-completion-window.png new file mode 100644 index 00000000..fdc67150 Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/editor-class-auto-completion-window.png differ diff --git a/documentation/18.11/eiffelstudio/_images/editor-class-auto-completion-window.png.data b/documentation/18.11/eiffelstudio/_images/editor-class-auto-completion-window.png.data new file mode 100644 index 00000000..97cd1a09 --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/editor-class-auto-completion-window.png.data @@ -0,0 +1,3 @@ +title=editor-class-auto-completion-window +author=halw +path=content/editor-class-auto-completion-window diff --git a/documentation/18.11/eiffelstudio/_images/editor-feature-auto-completion-window.png b/documentation/18.11/eiffelstudio/_images/editor-feature-auto-completion-window.png new file mode 100644 index 00000000..7cfdd324 Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/editor-feature-auto-completion-window.png differ diff --git a/documentation/18.11/eiffelstudio/_images/editor-feature-auto-completion-window.png.data b/documentation/18.11/eiffelstudio/_images/editor-feature-auto-completion-window.png.data new file mode 100644 index 00000000..716dbbb6 --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/editor-feature-auto-completion-window.png.data @@ -0,0 +1,3 @@ +title=editor feature auto-completion window +author=halw +path=content/editor-feature-auto-completion-window diff --git a/documentation/18.11/eiffelstudio/_images/editor-pick-and-drop.png b/documentation/18.11/eiffelstudio/_images/editor-pick-and-drop.png new file mode 100644 index 00000000..cbc36be9 Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/editor-pick-and-drop.png differ diff --git a/documentation/18.11/eiffelstudio/_images/editor-pick-and-drop.png.data b/documentation/18.11/eiffelstudio/_images/editor-pick-and-drop.png.data new file mode 100644 index 00000000..a0de5a40 --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/editor-pick-and-drop.png.data @@ -0,0 +1,3 @@ +title=editor-pick-and-drop +author=admin +path=content/editor-pick-and-drop diff --git a/documentation/18.11/eiffelstudio/_images/error-cursor-disabled_0.png b/documentation/18.11/eiffelstudio/_images/error-cursor-disabled_0.png new file mode 100644 index 00000000..e7894186 Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/error-cursor-disabled_0.png differ diff --git a/documentation/18.11/eiffelstudio/_images/error-cursor-disabled_0.png.data b/documentation/18.11/eiffelstudio/_images/error-cursor-disabled_0.png.data new file mode 100644 index 00000000..c461c16b --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/error-cursor-disabled_0.png.data @@ -0,0 +1,3 @@ +title=error-cursor-disabled +author=halw +path=content/error-cursor-disabled diff --git a/documentation/18.11/eiffelstudio/_images/error-cursor_0.png b/documentation/18.11/eiffelstudio/_images/error-cursor_0.png new file mode 100644 index 00000000..b882ac23 Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/error-cursor_0.png differ diff --git a/documentation/18.11/eiffelstudio/_images/error-cursor_0.png.data b/documentation/18.11/eiffelstudio/_images/error-cursor_0.png.data new file mode 100644 index 00000000..503ddd3f --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/error-cursor_0.png.data @@ -0,0 +1,3 @@ +title=error-cursor +author=halw +path=content/error-cursor diff --git a/documentation/18.11/eiffelstudio/_images/error-description-dialog.png b/documentation/18.11/eiffelstudio/_images/error-description-dialog.png new file mode 100644 index 00000000..7e29f0b4 Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/error-description-dialog.png differ diff --git a/documentation/18.11/eiffelstudio/_images/error-description-dialog.png.data b/documentation/18.11/eiffelstudio/_images/error-description-dialog.png.data new file mode 100644 index 00000000..58f0705b --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/error-description-dialog.png.data @@ -0,0 +1,3 @@ +title=error-description-dialog +author=admin +path=content/error-description-dialog diff --git a/documentation/18.11/eiffelstudio/_images/error-info.png b/documentation/18.11/eiffelstudio/_images/error-info.png new file mode 100644 index 00000000..fa393149 Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/error-info.png differ diff --git a/documentation/18.11/eiffelstudio/_images/error-info.png.data b/documentation/18.11/eiffelstudio/_images/error-info.png.data new file mode 100644 index 00000000..93bbc08a --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/error-info.png.data @@ -0,0 +1,3 @@ +title=error-info +author=admin +path=content/error-info diff --git a/documentation/18.11/eiffelstudio/_images/error-message.png b/documentation/18.11/eiffelstudio/_images/error-message.png new file mode 100644 index 00000000..3d492093 Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/error-message.png differ diff --git a/documentation/18.11/eiffelstudio/_images/error-message.png.data b/documentation/18.11/eiffelstudio/_images/error-message.png.data new file mode 100644 index 00000000..b54367f9 --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/error-message.png.data @@ -0,0 +1,3 @@ +title=error-message +author=admin +path=content/error-message diff --git a/documentation/18.11/eiffelstudio/_images/error.png b/documentation/18.11/eiffelstudio/_images/error.png new file mode 100644 index 00000000..92faae99 Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/error.png differ diff --git a/documentation/18.11/eiffelstudio/_images/error.png.data b/documentation/18.11/eiffelstudio/_images/error.png.data new file mode 100644 index 00000000..c19b8e59 --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/error.png.data @@ -0,0 +1,3 @@ +title=error +author=admin +path=content/error diff --git a/documentation/18.11/eiffelstudio/_images/es_gt_a_development_window_01a_0.png b/documentation/18.11/eiffelstudio/_images/es_gt_a_development_window_01a_0.png new file mode 100644 index 00000000..cdfffb3c Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/es_gt_a_development_window_01a_0.png differ diff --git a/documentation/18.11/eiffelstudio/_images/es_gt_a_development_window_01a_0.png.data b/documentation/18.11/eiffelstudio/_images/es_gt_a_development_window_01a_0.png.data new file mode 100644 index 00000000..e5e04ce4 --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/es_gt_a_development_window_01a_0.png.data @@ -0,0 +1,3 @@ +title=es gt a development window 01 +author=halw +path=content/es-gt-development-window-01 diff --git a/documentation/18.11/eiffelstudio/_images/es_gt_a_development_window_02.png b/documentation/18.11/eiffelstudio/_images/es_gt_a_development_window_02.png new file mode 100644 index 00000000..33bf0ce8 Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/es_gt_a_development_window_02.png differ diff --git a/documentation/18.11/eiffelstudio/_images/es_gt_a_development_window_02.png.data b/documentation/18.11/eiffelstudio/_images/es_gt_a_development_window_02.png.data new file mode 100644 index 00000000..fb86f5f5 --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/es_gt_a_development_window_02.png.data @@ -0,0 +1,3 @@ +title=es gt a development window 02 +author=halw +path=content/es-gt-development-window-02 diff --git a/documentation/18.11/eiffelstudio/_images/es_gt_active_windows_tool_01.png b/documentation/18.11/eiffelstudio/_images/es_gt_active_windows_tool_01.png new file mode 100644 index 00000000..474c9553 Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/es_gt_active_windows_tool_01.png differ diff --git a/documentation/18.11/eiffelstudio/_images/es_gt_active_windows_tool_01.png.data b/documentation/18.11/eiffelstudio/_images/es_gt_active_windows_tool_01.png.data new file mode 100644 index 00000000..e1aa18ab --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/es_gt_active_windows_tool_01.png.data @@ -0,0 +1,3 @@ +title=es gt active windows tool 01 +author=halw +path=content/es-gt-active-windows-tool-01 diff --git a/documentation/18.11/eiffelstudio/_images/es_gt_add_cluster_dialog.png b/documentation/18.11/eiffelstudio/_images/es_gt_add_cluster_dialog.png new file mode 100644 index 00000000..521b5b66 Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/es_gt_add_cluster_dialog.png differ diff --git a/documentation/18.11/eiffelstudio/_images/es_gt_add_cluster_dialog.png.data b/documentation/18.11/eiffelstudio/_images/es_gt_add_cluster_dialog.png.data new file mode 100644 index 00000000..3b2d78ba --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/es_gt_add_cluster_dialog.png.data @@ -0,0 +1,3 @@ +title=es gt add cluster dialog +author=halw +path=content/es-gt-add-cluster-dialog diff --git a/documentation/18.11/eiffelstudio/_images/es_gt_add_tab_to_pane.png b/documentation/18.11/eiffelstudio/_images/es_gt_add_tab_to_pane.png new file mode 100644 index 00000000..ce5e30b4 Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/es_gt_add_tab_to_pane.png differ diff --git a/documentation/18.11/eiffelstudio/_images/es_gt_add_tab_to_pane.png.data b/documentation/18.11/eiffelstudio/_images/es_gt_add_tab_to_pane.png.data new file mode 100644 index 00000000..f3963778 --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/es_gt_add_tab_to_pane.png.data @@ -0,0 +1,3 @@ +title=es gt add tab to pane +author=halw +path=content/es-gt-add-tab-pane diff --git a/documentation/18.11/eiffelstudio/_images/es_gt_add_to_favorites_01.png b/documentation/18.11/eiffelstudio/_images/es_gt_add_to_favorites_01.png new file mode 100644 index 00000000..3ad5cbdf Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/es_gt_add_to_favorites_01.png differ diff --git a/documentation/18.11/eiffelstudio/_images/es_gt_add_to_favorites_01.png.data b/documentation/18.11/eiffelstudio/_images/es_gt_add_to_favorites_01.png.data new file mode 100644 index 00000000..0956b58d --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/es_gt_add_to_favorites_01.png.data @@ -0,0 +1,3 @@ +title=es gt add to favorites 01 +author=halw +path=content/es-gt-add-favorites-01 diff --git a/documentation/18.11/eiffelstudio/_images/es_gt_auto_complete_argument_01.png b/documentation/18.11/eiffelstudio/_images/es_gt_auto_complete_argument_01.png new file mode 100644 index 00000000..ad6b97d7 Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/es_gt_auto_complete_argument_01.png differ diff --git a/documentation/18.11/eiffelstudio/_images/es_gt_auto_complete_argument_01.png.data b/documentation/18.11/eiffelstudio/_images/es_gt_auto_complete_argument_01.png.data new file mode 100644 index 00000000..59b94fff --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/es_gt_auto_complete_argument_01.png.data @@ -0,0 +1,3 @@ +title=es gt auto complete argument 01 +author=halw +path=content/es-gt-auto-complete-argument-01 diff --git a/documentation/18.11/eiffelstudio/_images/es_gt_auto_complete_feature_01.png b/documentation/18.11/eiffelstudio/_images/es_gt_auto_complete_feature_01.png new file mode 100644 index 00000000..8a7670af Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/es_gt_auto_complete_feature_01.png differ diff --git a/documentation/18.11/eiffelstudio/_images/es_gt_auto_complete_feature_01.png.data b/documentation/18.11/eiffelstudio/_images/es_gt_auto_complete_feature_01.png.data new file mode 100644 index 00000000..f16cb511 --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/es_gt_auto_complete_feature_01.png.data @@ -0,0 +1,3 @@ +title=es gt auto complete feature 01 +author=halw +path=content/es-gt-auto-complete-feature-01 diff --git a/documentation/18.11/eiffelstudio/_images/es_gt_auto_hide_01.png b/documentation/18.11/eiffelstudio/_images/es_gt_auto_hide_01.png new file mode 100644 index 00000000..92bf6160 Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/es_gt_auto_hide_01.png differ diff --git a/documentation/18.11/eiffelstudio/_images/es_gt_auto_hide_01.png.data b/documentation/18.11/eiffelstudio/_images/es_gt_auto_hide_01.png.data new file mode 100644 index 00000000..6232b76a --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/es_gt_auto_hide_01.png.data @@ -0,0 +1,3 @@ +title=es gt auto hide 01 +author=halw +path=content/es-gt-auto-hide-01 diff --git a/documentation/18.11/eiffelstudio/_images/es_gt_autocomplete_from_01.png b/documentation/18.11/eiffelstudio/_images/es_gt_autocomplete_from_01.png new file mode 100644 index 00000000..b69d776c Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/es_gt_autocomplete_from_01.png differ diff --git a/documentation/18.11/eiffelstudio/_images/es_gt_autocomplete_from_01.png.data b/documentation/18.11/eiffelstudio/_images/es_gt_autocomplete_from_01.png.data new file mode 100644 index 00000000..4d9daf7a --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/es_gt_autocomplete_from_01.png.data @@ -0,0 +1,3 @@ +title=es gt auto complete from 01 +author=halw +path=content/es-gt-auto-complete-01 diff --git a/documentation/18.11/eiffelstudio/_images/es_gt_breakpoint_context_menu.png b/documentation/18.11/eiffelstudio/_images/es_gt_breakpoint_context_menu.png new file mode 100644 index 00000000..da6c89ad Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/es_gt_breakpoint_context_menu.png differ diff --git a/documentation/18.11/eiffelstudio/_images/es_gt_breakpoint_context_menu.png.data b/documentation/18.11/eiffelstudio/_images/es_gt_breakpoint_context_menu.png.data new file mode 100644 index 00000000..6307a986 --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/es_gt_breakpoint_context_menu.png.data @@ -0,0 +1,3 @@ +title=es gt breakpoint context menu 01 +author=halw +path=content/es-gt-breakpoint-context-menu-01 diff --git a/documentation/18.11/eiffelstudio/_images/es_gt_breakpoints_tool_01.png b/documentation/18.11/eiffelstudio/_images/es_gt_breakpoints_tool_01.png new file mode 100644 index 00000000..c0552d0e Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/es_gt_breakpoints_tool_01.png differ diff --git a/documentation/18.11/eiffelstudio/_images/es_gt_breakpoints_tool_01.png.data b/documentation/18.11/eiffelstudio/_images/es_gt_breakpoints_tool_01.png.data new file mode 100644 index 00000000..7e14b8dd --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/es_gt_breakpoints_tool_01.png.data @@ -0,0 +1,3 @@ +title=es gt breakpoints tool 01 +author=halw +path=content/es-gt-breakpoints-tool-01 diff --git a/documentation/18.11/eiffelstudio/_images/es_gt_class_HEIR2_moved_to_new_cluster.png b/documentation/18.11/eiffelstudio/_images/es_gt_class_HEIR2_moved_to_new_cluster.png new file mode 100644 index 00000000..b22ec622 Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/es_gt_class_HEIR2_moved_to_new_cluster.png differ diff --git a/documentation/18.11/eiffelstudio/_images/es_gt_class_HEIR2_moved_to_new_cluster.png.data b/documentation/18.11/eiffelstudio/_images/es_gt_class_HEIR2_moved_to_new_cluster.png.data new file mode 100644 index 00000000..d1fdc445 --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/es_gt_class_HEIR2_moved_to_new_cluster.png.data @@ -0,0 +1,3 @@ +title=es gt class HEIR2 moved to new cluster +author=halw +path=content/es-gt-class-heir2-moved-new-cluster diff --git a/documentation/18.11/eiffelstudio/_images/es_gt_class_field_01.png b/documentation/18.11/eiffelstudio/_images/es_gt_class_field_01.png new file mode 100644 index 00000000..a475de0c Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/es_gt_class_field_01.png differ diff --git a/documentation/18.11/eiffelstudio/_images/es_gt_class_field_01.png.data b/documentation/18.11/eiffelstudio/_images/es_gt_class_field_01.png.data new file mode 100644 index 00000000..e6209046 --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/es_gt_class_field_01.png.data @@ -0,0 +1,3 @@ +title=es gt class field 01 +author=halw +path=content/es-gt-class-field-01 diff --git a/documentation/18.11/eiffelstudio/_images/es_gt_class_heir2_created.png b/documentation/18.11/eiffelstudio/_images/es_gt_class_heir2_created.png new file mode 100644 index 00000000..d381ca28 Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/es_gt_class_heir2_created.png differ diff --git a/documentation/18.11/eiffelstudio/_images/es_gt_class_heir2_created.png.data b/documentation/18.11/eiffelstudio/_images/es_gt_class_heir2_created.png.data new file mode 100644 index 00000000..de5f6012 --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/es_gt_class_heir2_created.png.data @@ -0,0 +1,3 @@ +title=es gt class heir2 created +author=halw +path=content/es-gt-class-heir2-created diff --git a/documentation/18.11/eiffelstudio/_images/es_gt_class_heir2_relocated.png b/documentation/18.11/eiffelstudio/_images/es_gt_class_heir2_relocated.png new file mode 100644 index 00000000..ebc5c62c Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/es_gt_class_heir2_relocated.png differ diff --git a/documentation/18.11/eiffelstudio/_images/es_gt_class_heir2_relocated.png.data b/documentation/18.11/eiffelstudio/_images/es_gt_class_heir2_relocated.png.data new file mode 100644 index 00000000..e3e570ad --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/es_gt_class_heir2_relocated.png.data @@ -0,0 +1,3 @@ +title=es gt class heir2 relocated +author=halw +path=content/es-gt-class-heir2-relocated diff --git a/documentation/18.11/eiffelstudio/_images/es_gt_class_heir2_text.png b/documentation/18.11/eiffelstudio/_images/es_gt_class_heir2_text.png new file mode 100644 index 00000000..23a63d16 Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/es_gt_class_heir2_text.png differ diff --git a/documentation/18.11/eiffelstudio/_images/es_gt_class_heir2_text.png.data b/documentation/18.11/eiffelstudio/_images/es_gt_class_heir2_text.png.data new file mode 100644 index 00000000..21608ace --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/es_gt_class_heir2_text.png.data @@ -0,0 +1,3 @@ +title=es gt class heir2 text +author=halw +path=content/es-gt-class-heir2-text diff --git a/documentation/18.11/eiffelstudio/_images/es_gt_class_invalid_is_hidden.png b/documentation/18.11/eiffelstudio/_images/es_gt_class_invalid_is_hidden.png new file mode 100644 index 00000000..b96708a9 Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/es_gt_class_invalid_is_hidden.png differ diff --git a/documentation/18.11/eiffelstudio/_images/es_gt_class_invalid_is_hidden.png.data b/documentation/18.11/eiffelstudio/_images/es_gt_class_invalid_is_hidden.png.data new file mode 100644 index 00000000..65f278df --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/es_gt_class_invalid_is_hidden.png.data @@ -0,0 +1,3 @@ +title=es gt class invalid is hidden +author=halw +path=content/es-gt-class-invalid-hidden diff --git a/documentation/18.11/eiffelstudio/_images/es_gt_class_tool_01.png b/documentation/18.11/eiffelstudio/_images/es_gt_class_tool_01.png new file mode 100644 index 00000000..99be7a0b Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/es_gt_class_tool_01.png differ diff --git a/documentation/18.11/eiffelstudio/_images/es_gt_class_tool_01.png.data b/documentation/18.11/eiffelstudio/_images/es_gt_class_tool_01.png.data new file mode 100644 index 00000000..ae7ac221 --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/es_gt_class_tool_01.png.data @@ -0,0 +1,3 @@ +title=es gt class tool 01 +author=halw +path=content/es-gt-class-tool-01 diff --git a/documentation/18.11/eiffelstudio/_images/es_gt_class_tool_descendants_01.png b/documentation/18.11/eiffelstudio/_images/es_gt_class_tool_descendants_01.png new file mode 100644 index 00000000..807bf44e Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/es_gt_class_tool_descendants_01.png differ diff --git a/documentation/18.11/eiffelstudio/_images/es_gt_class_tool_descendants_01.png.data b/documentation/18.11/eiffelstudio/_images/es_gt_class_tool_descendants_01.png.data new file mode 100644 index 00000000..ba265066 --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/es_gt_class_tool_descendants_01.png.data @@ -0,0 +1,3 @@ +title=es gt class tool descendants 01 +author=halw +path=content/es-gt-class-tool-descendants-01 diff --git a/documentation/18.11/eiffelstudio/_images/es_gt_class_tool_flat_01.png b/documentation/18.11/eiffelstudio/_images/es_gt_class_tool_flat_01.png new file mode 100644 index 00000000..2204972d Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/es_gt_class_tool_flat_01.png differ diff --git a/documentation/18.11/eiffelstudio/_images/es_gt_class_tool_flat_01.png.data b/documentation/18.11/eiffelstudio/_images/es_gt_class_tool_flat_01.png.data new file mode 100644 index 00000000..108168fb --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/es_gt_class_tool_flat_01.png.data @@ -0,0 +1,3 @@ +title=es gt class tool flat 01 +author=halw +path=content/es-gt-class-tool-flat-01 diff --git a/documentation/18.11/eiffelstudio/_images/es_gt_class_tool_routines_01.png b/documentation/18.11/eiffelstudio/_images/es_gt_class_tool_routines_01.png new file mode 100644 index 00000000..93c6b18e Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/es_gt_class_tool_routines_01.png differ diff --git a/documentation/18.11/eiffelstudio/_images/es_gt_class_tool_routines_01.png.data b/documentation/18.11/eiffelstudio/_images/es_gt_class_tool_routines_01.png.data new file mode 100644 index 00000000..8c77289d --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/es_gt_class_tool_routines_01.png.data @@ -0,0 +1,3 @@ +title=es gt class tool routines 01 +author=halw +path=content/es-gt-class-tool-routines-01 diff --git a/documentation/18.11/eiffelstudio/_images/es_gt_close_favorites_01.png b/documentation/18.11/eiffelstudio/_images/es_gt_close_favorites_01.png new file mode 100644 index 00000000..e9c7f000 Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/es_gt_close_favorites_01.png differ diff --git a/documentation/18.11/eiffelstudio/_images/es_gt_close_favorites_01.png.data b/documentation/18.11/eiffelstudio/_images/es_gt_close_favorites_01.png.data new file mode 100644 index 00000000..9575ea82 --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/es_gt_close_favorites_01.png.data @@ -0,0 +1,3 @@ +title=es gt close favorites 01 +author=halw +path=content/es-gt-close-favorites-01 diff --git a/documentation/18.11/eiffelstudio/_images/es_gt_compilation_wizard_01.png b/documentation/18.11/eiffelstudio/_images/es_gt_compilation_wizard_01.png new file mode 100644 index 00000000..3589efd3 Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/es_gt_compilation_wizard_01.png differ diff --git a/documentation/18.11/eiffelstudio/_images/es_gt_compilation_wizard_01.png.data b/documentation/18.11/eiffelstudio/_images/es_gt_compilation_wizard_01.png.data new file mode 100644 index 00000000..5b95651e --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/es_gt_compilation_wizard_01.png.data @@ -0,0 +1,3 @@ +title=es gt compilation error wizard 01 +author=halw +path=content/es-gt-compilation-error-wizard-01 diff --git a/documentation/18.11/eiffelstudio/_images/es_gt_create_new_class_button.png b/documentation/18.11/eiffelstudio/_images/es_gt_create_new_class_button.png new file mode 100644 index 00000000..dc8bf7bd Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/es_gt_create_new_class_button.png differ diff --git a/documentation/18.11/eiffelstudio/_images/es_gt_create_new_class_button.png.data b/documentation/18.11/eiffelstudio/_images/es_gt_create_new_class_button.png.data new file mode 100644 index 00000000..79688499 --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/es_gt_create_new_class_button.png.data @@ -0,0 +1,3 @@ +title=es gt create new class button +author=halw +path=content/es-gt-create-new-class-button diff --git a/documentation/18.11/eiffelstudio/_images/es_gt_debug_buttons_0.png b/documentation/18.11/eiffelstudio/_images/es_gt_debug_buttons_0.png new file mode 100644 index 00000000..bb746896 Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/es_gt_debug_buttons_0.png differ diff --git a/documentation/18.11/eiffelstudio/_images/es_gt_debug_buttons_0.png.data b/documentation/18.11/eiffelstudio/_images/es_gt_debug_buttons_0.png.data new file mode 100644 index 00000000..d3974a9f --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/es_gt_debug_buttons_0.png.data @@ -0,0 +1,3 @@ +title=es gt debug buttons +author=halw +path=content/es-gt-debug-buttons diff --git a/documentation/18.11/eiffelstudio/_images/es_gt_debug_step_by_step_01.png b/documentation/18.11/eiffelstudio/_images/es_gt_debug_step_by_step_01.png new file mode 100644 index 00000000..af723575 Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/es_gt_debug_step_by_step_01.png differ diff --git a/documentation/18.11/eiffelstudio/_images/es_gt_debug_step_by_step_01.png.data b/documentation/18.11/eiffelstudio/_images/es_gt_debug_step_by_step_01.png.data new file mode 100644 index 00000000..e2e79d9d --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/es_gt_debug_step_by_step_01.png.data @@ -0,0 +1,3 @@ +title=es gt debug step by step 01 +author=halw +path=content/es-gt-debug-step-step-01 diff --git a/documentation/18.11/eiffelstudio/_images/es_gt_debug_step_into_01.png b/documentation/18.11/eiffelstudio/_images/es_gt_debug_step_into_01.png new file mode 100644 index 00000000..e55ed14f Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/es_gt_debug_step_into_01.png differ diff --git a/documentation/18.11/eiffelstudio/_images/es_gt_debug_step_into_01.png.data b/documentation/18.11/eiffelstudio/_images/es_gt_debug_step_into_01.png.data new file mode 100644 index 00000000..a77d8b6e --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/es_gt_debug_step_into_01.png.data @@ -0,0 +1,3 @@ +title=es gt debug step into 01 +author=halw +path=content/es-gt-debug-step-01 diff --git a/documentation/18.11/eiffelstudio/_images/es_gt_default_pane_tabs.png b/documentation/18.11/eiffelstudio/_images/es_gt_default_pane_tabs.png new file mode 100644 index 00000000..0b99ccb0 Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/es_gt_default_pane_tabs.png differ diff --git a/documentation/18.11/eiffelstudio/_images/es_gt_default_pane_tabs.png.data b/documentation/18.11/eiffelstudio/_images/es_gt_default_pane_tabs.png.data new file mode 100644 index 00000000..c4ee0d4e --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/es_gt_default_pane_tabs.png.data @@ -0,0 +1,3 @@ +title=es gt default pane tabs +author=halw +path=content/es-gt-default-pane-tabs diff --git a/documentation/18.11/eiffelstudio/_images/es_gt_development_window_breakpoint_reached_01.png b/documentation/18.11/eiffelstudio/_images/es_gt_development_window_breakpoint_reached_01.png new file mode 100644 index 00000000..346265cf Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/es_gt_development_window_breakpoint_reached_01.png differ diff --git a/documentation/18.11/eiffelstudio/_images/es_gt_development_window_breakpoint_reached_01.png.data b/documentation/18.11/eiffelstudio/_images/es_gt_development_window_breakpoint_reached_01.png.data new file mode 100644 index 00000000..ecf2e97a --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/es_gt_development_window_breakpoint_reached_01.png.data @@ -0,0 +1,3 @@ +title=es gt debug breakpoint reached 01 +author=halw +path=content/es-gt-debug-breakpoint-reached-01 diff --git a/documentation/18.11/eiffelstudio/_images/es_gt_development_window_breakpoints_01.png b/documentation/18.11/eiffelstudio/_images/es_gt_development_window_breakpoints_01.png new file mode 100644 index 00000000..81147418 Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/es_gt_development_window_breakpoints_01.png differ diff --git a/documentation/18.11/eiffelstudio/_images/es_gt_development_window_breakpoints_01.png.data b/documentation/18.11/eiffelstudio/_images/es_gt_development_window_breakpoints_01.png.data new file mode 100644 index 00000000..aaaa48d9 --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/es_gt_development_window_breakpoints_01.png.data @@ -0,0 +1,3 @@ +title=es gt development window breakpoints 01 +author=halw +path=content/es-gt-development-window-breakpoints-01 diff --git a/documentation/18.11/eiffelstudio/_images/es_gt_development_window_breakpoints_02.png b/documentation/18.11/eiffelstudio/_images/es_gt_development_window_breakpoints_02.png new file mode 100644 index 00000000..51202e69 Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/es_gt_development_window_breakpoints_02.png differ diff --git a/documentation/18.11/eiffelstudio/_images/es_gt_development_window_breakpoints_02.png.data b/documentation/18.11/eiffelstudio/_images/es_gt_development_window_breakpoints_02.png.data new file mode 100644 index 00000000..9a4d57c8 --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/es_gt_development_window_breakpoints_02.png.data @@ -0,0 +1,3 @@ +title=es gt development window breakpoints 02 +author=halw +path=content/es-gt-development-window-breakpoints-02 diff --git a/documentation/18.11/eiffelstudio/_images/es_gt_development_window_foth_descendants_01.png b/documentation/18.11/eiffelstudio/_images/es_gt_development_window_foth_descendants_01.png new file mode 100644 index 00000000..83ed2588 Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/es_gt_development_window_foth_descendants_01.png differ diff --git a/documentation/18.11/eiffelstudio/_images/es_gt_development_window_foth_descendants_01.png.data b/documentation/18.11/eiffelstudio/_images/es_gt_development_window_foth_descendants_01.png.data new file mode 100644 index 00000000..120955ab --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/es_gt_development_window_foth_descendants_01.png.data @@ -0,0 +1,3 @@ +title=es gt development window feature descendants 01 +author=halw +path=content/es-gt-development-window-feature-descendants-01 diff --git a/documentation/18.11/eiffelstudio/_images/es_gt_development_window_multi_array_list_forth_01.png b/documentation/18.11/eiffelstudio/_images/es_gt_development_window_multi_array_list_forth_01.png new file mode 100644 index 00000000..d64e0a39 Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/es_gt_development_window_multi_array_list_forth_01.png differ diff --git a/documentation/18.11/eiffelstudio/_images/es_gt_development_window_multi_array_list_forth_01.png.data b/documentation/18.11/eiffelstudio/_images/es_gt_development_window_multi_array_list_forth_01.png.data new file mode 100644 index 00000000..9467238b --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/es_gt_development_window_multi_array_list_forth_01.png.data @@ -0,0 +1,3 @@ +title=es gt development window multi array list forth 01 +author=halw +path=content/es-gt-development-window-multi-array-list-forth-01 diff --git a/documentation/18.11/eiffelstudio/_images/es_gt_development_window_multiple_tabs_01.png b/documentation/18.11/eiffelstudio/_images/es_gt_development_window_multiple_tabs_01.png new file mode 100644 index 00000000..15a88ce3 Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/es_gt_development_window_multiple_tabs_01.png differ diff --git a/documentation/18.11/eiffelstudio/_images/es_gt_development_window_multiple_tabs_01.png.data b/documentation/18.11/eiffelstudio/_images/es_gt_development_window_multiple_tabs_01.png.data new file mode 100644 index 00000000..dc0ed7af --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/es_gt_development_window_multiple_tabs_01.png.data @@ -0,0 +1,3 @@ +title=es gt development window multiple tabs 01 +author=halw +path=content/es-gt-development-window-multiple-tabs-01 diff --git a/documentation/18.11/eiffelstudio/_images/es_gt_development_window_syntax_error_01_0.png b/documentation/18.11/eiffelstudio/_images/es_gt_development_window_syntax_error_01_0.png new file mode 100644 index 00000000..eef03016 Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/es_gt_development_window_syntax_error_01_0.png differ diff --git a/documentation/18.11/eiffelstudio/_images/es_gt_development_window_syntax_error_01_0.png.data b/documentation/18.11/eiffelstudio/_images/es_gt_development_window_syntax_error_01_0.png.data new file mode 100644 index 00000000..5161bc06 --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/es_gt_development_window_syntax_error_01_0.png.data @@ -0,0 +1,3 @@ +title=es gt development window syntax error 01 +author=halw +path=content/es-gt-development-window-syntax-error-01 diff --git a/documentation/18.11/eiffelstudio/_images/es_gt_development_window_targeted_to_list_01.png b/documentation/18.11/eiffelstudio/_images/es_gt_development_window_targeted_to_list_01.png new file mode 100644 index 00000000..46ec7eb4 Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/es_gt_development_window_targeted_to_list_01.png differ diff --git a/documentation/18.11/eiffelstudio/_images/es_gt_development_window_targeted_to_list_01.png.data b/documentation/18.11/eiffelstudio/_images/es_gt_development_window_targeted_to_list_01.png.data new file mode 100644 index 00000000..84c3a0a6 --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/es_gt_development_window_targeted_to_list_01.png.data @@ -0,0 +1,3 @@ +title=es gt development window targeted to list 01 +author=halw +path=content/es-gt-development-window-targeted-list-01 diff --git a/documentation/18.11/eiffelstudio/_images/es_gt_development_window_targeted_to_parent_01.png b/documentation/18.11/eiffelstudio/_images/es_gt_development_window_targeted_to_parent_01.png new file mode 100644 index 00000000..f04912f7 Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/es_gt_development_window_targeted_to_parent_01.png differ diff --git a/documentation/18.11/eiffelstudio/_images/es_gt_development_window_targeted_to_parent_01.png.data b/documentation/18.11/eiffelstudio/_images/es_gt_development_window_targeted_to_parent_01.png.data new file mode 100644 index 00000000..27ffac64 --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/es_gt_development_window_targeted_to_parent_01.png.data @@ -0,0 +1,3 @@ +title=es gt development window targeted to parent 01 +author=halw +path=content/es-gt-development-window-targeted-parent-01 diff --git a/documentation/18.11/eiffelstudio/_images/es_gt_development_window_targeted_to_parent_02.png b/documentation/18.11/eiffelstudio/_images/es_gt_development_window_targeted_to_parent_02.png new file mode 100644 index 00000000..53b7c1d1 Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/es_gt_development_window_targeted_to_parent_02.png differ diff --git a/documentation/18.11/eiffelstudio/_images/es_gt_development_window_targeted_to_parent_02.png.data b/documentation/18.11/eiffelstudio/_images/es_gt_development_window_targeted_to_parent_02.png.data new file mode 100644 index 00000000..467ce090 --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/es_gt_development_window_targeted_to_parent_02.png.data @@ -0,0 +1,3 @@ +title=es gt development window targeted to parent 02 +author=halw +path=content/es-gt-development-window-targeted-parent-02 diff --git a/documentation/18.11/eiffelstudio/_images/es_gt_development_window_validity_error_01.png b/documentation/18.11/eiffelstudio/_images/es_gt_development_window_validity_error_01.png new file mode 100644 index 00000000..a37239c3 Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/es_gt_development_window_validity_error_01.png differ diff --git a/documentation/18.11/eiffelstudio/_images/es_gt_development_window_validity_error_01.png.data b/documentation/18.11/eiffelstudio/_images/es_gt_development_window_validity_error_01.png.data new file mode 100644 index 00000000..be07d3ac --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/es_gt_development_window_validity_error_01.png.data @@ -0,0 +1,3 @@ +title=es gt development window validity error 01 +author=halw +path=content/es-gt-development-window-validity-error-01 diff --git a/documentation/18.11/eiffelstudio/_images/es_gt_development_window_validity_error_02.png b/documentation/18.11/eiffelstudio/_images/es_gt_development_window_validity_error_02.png new file mode 100644 index 00000000..e05154be Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/es_gt_development_window_validity_error_02.png differ diff --git a/documentation/18.11/eiffelstudio/_images/es_gt_development_window_validity_error_02.png.data b/documentation/18.11/eiffelstudio/_images/es_gt_development_window_validity_error_02.png.data new file mode 100644 index 00000000..6bfecd26 --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/es_gt_development_window_validity_error_02.png.data @@ -0,0 +1,3 @@ +title=es gt development window validity error 02 +author=halw +path=content/es-gt-development-window-validity-error-02 diff --git a/documentation/18.11/eiffelstudio/_images/es_gt_development_window_validity_error_03.png b/documentation/18.11/eiffelstudio/_images/es_gt_development_window_validity_error_03.png new file mode 100644 index 00000000..a8bc848d Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/es_gt_development_window_validity_error_03.png differ diff --git a/documentation/18.11/eiffelstudio/_images/es_gt_development_window_validity_error_03.png.data b/documentation/18.11/eiffelstudio/_images/es_gt_development_window_validity_error_03.png.data new file mode 100644 index 00000000..0ce444ab --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/es_gt_development_window_validity_error_03.png.data @@ -0,0 +1,3 @@ +title=es gt development window validity error 03 +author=halw +path=content/es-gt-development-window-validity-error-03 diff --git a/documentation/18.11/eiffelstudio/_images/es_gt_diagram_delete_confirmation.png b/documentation/18.11/eiffelstudio/_images/es_gt_diagram_delete_confirmation.png new file mode 100644 index 00000000..89c12a3b Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/es_gt_diagram_delete_confirmation.png differ diff --git a/documentation/18.11/eiffelstudio/_images/es_gt_diagram_delete_confirmation.png.data b/documentation/18.11/eiffelstudio/_images/es_gt_diagram_delete_confirmation.png.data new file mode 100644 index 00000000..9aed4909 --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/es_gt_diagram_delete_confirmation.png.data @@ -0,0 +1,3 @@ +title=es gt diagram delete confirmation +author=halw +path=content/es-gt-diagram-delete-confirmation diff --git a/documentation/18.11/eiffelstudio/_images/es_gt_diagram_tool_pane_floating_01.png b/documentation/18.11/eiffelstudio/_images/es_gt_diagram_tool_pane_floating_01.png new file mode 100644 index 00000000..9f6ff0a1 Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/es_gt_diagram_tool_pane_floating_01.png differ diff --git a/documentation/18.11/eiffelstudio/_images/es_gt_diagram_tool_pane_floating_01.png.data b/documentation/18.11/eiffelstudio/_images/es_gt_diagram_tool_pane_floating_01.png.data new file mode 100644 index 00000000..b0d77d12 --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/es_gt_diagram_tool_pane_floating_01.png.data @@ -0,0 +1,3 @@ +title=es gt diagram tool pane floating 01 +author=halw +path=content/es-gt-diagram-tool-pane-floating-01 diff --git a/documentation/18.11/eiffelstudio/_images/es_gt_diagram_tool_pane_pinned_01.png b/documentation/18.11/eiffelstudio/_images/es_gt_diagram_tool_pane_pinned_01.png new file mode 100644 index 00000000..e5989857 Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/es_gt_diagram_tool_pane_pinned_01.png differ diff --git a/documentation/18.11/eiffelstudio/_images/es_gt_diagram_tool_pane_pinned_01.png.data b/documentation/18.11/eiffelstudio/_images/es_gt_diagram_tool_pane_pinned_01.png.data new file mode 100644 index 00000000..c3e3b286 --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/es_gt_diagram_tool_pane_pinned_01.png.data @@ -0,0 +1,3 @@ +title=es gt diagram tool pane pinned 01 +author=halw +path=content/es-gt-diagram-tool-pane-pinned-01 diff --git a/documentation/18.11/eiffelstudio/_images/es_gt_diagram_tool_unhidden.png b/documentation/18.11/eiffelstudio/_images/es_gt_diagram_tool_unhidden.png new file mode 100644 index 00000000..2ef95cbf Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/es_gt_diagram_tool_unhidden.png differ diff --git a/documentation/18.11/eiffelstudio/_images/es_gt_diagram_tool_unhidden.png.data b/documentation/18.11/eiffelstudio/_images/es_gt_diagram_tool_unhidden.png.data new file mode 100644 index 00000000..3eaad271 --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/es_gt_diagram_tool_unhidden.png.data @@ -0,0 +1,3 @@ +title=es gt development window diagram tool unhidden +author=halw +path=content/es-gt-development-window-diagram-tool-unhidden diff --git a/documentation/18.11/eiffelstudio/_images/es_gt_docking_in_progress_01.png b/documentation/18.11/eiffelstudio/_images/es_gt_docking_in_progress_01.png new file mode 100644 index 00000000..7bbedf19 Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/es_gt_docking_in_progress_01.png differ diff --git a/documentation/18.11/eiffelstudio/_images/es_gt_docking_in_progress_01.png.data b/documentation/18.11/eiffelstudio/_images/es_gt_docking_in_progress_01.png.data new file mode 100644 index 00000000..f5f0dc50 --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/es_gt_docking_in_progress_01.png.data @@ -0,0 +1,3 @@ +title=es gt docking in progress 01 +author=halw +path=content/es-gt-docking-progress-01 diff --git a/documentation/18.11/eiffelstudio/_images/es_gt_error_list_tool_pnd_validity_error.png b/documentation/18.11/eiffelstudio/_images/es_gt_error_list_tool_pnd_validity_error.png new file mode 100644 index 00000000..9225c621 Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/es_gt_error_list_tool_pnd_validity_error.png differ diff --git a/documentation/18.11/eiffelstudio/_images/es_gt_error_list_tool_pnd_validity_error.png.data b/documentation/18.11/eiffelstudio/_images/es_gt_error_list_tool_pnd_validity_error.png.data new file mode 100644 index 00000000..e262f1ea --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/es_gt_error_list_tool_pnd_validity_error.png.data @@ -0,0 +1,3 @@ +title=es gt error list tool pnd validity error +author=halw +path=content/es-gt-error-list-tool-pnd-validity-error diff --git a/documentation/18.11/eiffelstudio/_images/es_gt_execute_01.png b/documentation/18.11/eiffelstudio/_images/es_gt_execute_01.png new file mode 100644 index 00000000..49c75875 Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/es_gt_execute_01.png differ diff --git a/documentation/18.11/eiffelstudio/_images/es_gt_execute_01.png.data b/documentation/18.11/eiffelstudio/_images/es_gt_execute_01.png.data new file mode 100644 index 00000000..6954ea86 --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/es_gt_execute_01.png.data @@ -0,0 +1,3 @@ +title=es gt execute 01 +author=halw +path=content/es-gt-execute-01 diff --git a/documentation/18.11/eiffelstudio/_images/es_gt_execution_menu_01.png b/documentation/18.11/eiffelstudio/_images/es_gt_execution_menu_01.png new file mode 100644 index 00000000..587ea9ed Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/es_gt_execution_menu_01.png differ diff --git a/documentation/18.11/eiffelstudio/_images/es_gt_execution_menu_01.png.data b/documentation/18.11/eiffelstudio/_images/es_gt_execution_menu_01.png.data new file mode 100644 index 00000000..7c3697d6 --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/es_gt_execution_menu_01.png.data @@ -0,0 +1,3 @@ +title=es gt execution menu 01 +author=halw +path=content/es-gt-execution-menu-01 diff --git a/documentation/18.11/eiffelstudio/_images/es_gt_favorites_01.png b/documentation/18.11/eiffelstudio/_images/es_gt_favorites_01.png new file mode 100644 index 00000000..caeaa3c3 Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/es_gt_favorites_01.png differ diff --git a/documentation/18.11/eiffelstudio/_images/es_gt_favorites_01.png.data b/documentation/18.11/eiffelstudio/_images/es_gt_favorites_01.png.data new file mode 100644 index 00000000..39feee38 --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/es_gt_favorites_01.png.data @@ -0,0 +1,3 @@ +title=es gt favorites 01 +author=halw +path=content/es-gt-favorites-01 diff --git a/documentation/18.11/eiffelstudio/_images/es_gt_feature_tool_01.png b/documentation/18.11/eiffelstudio/_images/es_gt_feature_tool_01.png new file mode 100644 index 00000000..e6150337 Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/es_gt_feature_tool_01.png differ diff --git a/documentation/18.11/eiffelstudio/_images/es_gt_feature_tool_01.png.data b/documentation/18.11/eiffelstudio/_images/es_gt_feature_tool_01.png.data new file mode 100644 index 00000000..cd2d688a --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/es_gt_feature_tool_01.png.data @@ -0,0 +1,3 @@ +title=es gt feature tool 01 +author=halw +path=content/es-gt-feature-tool-01 diff --git a/documentation/18.11/eiffelstudio/_images/es_gt_feature_tool_callers_01.png b/documentation/18.11/eiffelstudio/_images/es_gt_feature_tool_callers_01.png new file mode 100644 index 00000000..3e2e31cc Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/es_gt_feature_tool_callers_01.png differ diff --git a/documentation/18.11/eiffelstudio/_images/es_gt_feature_tool_callers_01.png.data b/documentation/18.11/eiffelstudio/_images/es_gt_feature_tool_callers_01.png.data new file mode 100644 index 00000000..c8513038 --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/es_gt_feature_tool_callers_01.png.data @@ -0,0 +1,3 @@ +title=es gt feature tool callers 01 +author=halw +path=content/es-gt-feature-tool-callers-01 diff --git a/documentation/18.11/eiffelstudio/_images/es_gt_feature_tool_toolbar_buttons_01.png b/documentation/18.11/eiffelstudio/_images/es_gt_feature_tool_toolbar_buttons_01.png new file mode 100644 index 00000000..2222da35 Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/es_gt_feature_tool_toolbar_buttons_01.png differ diff --git a/documentation/18.11/eiffelstudio/_images/es_gt_feature_tool_toolbar_buttons_01.png.data b/documentation/18.11/eiffelstudio/_images/es_gt_feature_tool_toolbar_buttons_01.png.data new file mode 100644 index 00000000..099e5716 --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/es_gt_feature_tool_toolbar_buttons_01.png.data @@ -0,0 +1,3 @@ +title=es gt feature tool toolbar buttons 01 +author=halw +path=content/es-gt-feature-tool-toolbar-buttons-01 diff --git a/documentation/18.11/eiffelstudio/_images/es_gt_features_tool_01.png b/documentation/18.11/eiffelstudio/_images/es_gt_features_tool_01.png new file mode 100644 index 00000000..0a45dd33 Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/es_gt_features_tool_01.png differ diff --git a/documentation/18.11/eiffelstudio/_images/es_gt_features_tool_01.png.data b/documentation/18.11/eiffelstudio/_images/es_gt_features_tool_01.png.data new file mode 100644 index 00000000..bd72f910 --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/es_gt_features_tool_01.png.data @@ -0,0 +1,3 @@ +title=es gt features tool 01 +author=halw +path=content/es-gt-features-tool-01 diff --git a/documentation/18.11/eiffelstudio/_images/es_gt_features_tool_02.png b/documentation/18.11/eiffelstudio/_images/es_gt_features_tool_02.png new file mode 100644 index 00000000..67234afb Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/es_gt_features_tool_02.png differ diff --git a/documentation/18.11/eiffelstudio/_images/es_gt_features_tool_02.png.data b/documentation/18.11/eiffelstudio/_images/es_gt_features_tool_02.png.data new file mode 100644 index 00000000..c2e6a70f --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/es_gt_features_tool_02.png.data @@ -0,0 +1,3 @@ +title=es gt features tool 02 +author=halw +path=content/es-gt-features-tool-02 diff --git a/documentation/18.11/eiffelstudio/_images/es_gt_freeze_warning.png b/documentation/18.11/eiffelstudio/_images/es_gt_freeze_warning.png new file mode 100644 index 00000000..08577ceb Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/es_gt_freeze_warning.png differ diff --git a/documentation/18.11/eiffelstudio/_images/es_gt_freeze_warning.png.data b/documentation/18.11/eiffelstudio/_images/es_gt_freeze_warning.png.data new file mode 100644 index 00000000..f42d9b50 --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/es_gt_freeze_warning.png.data @@ -0,0 +1,3 @@ +title=es gt freeze warning +author=halw +path=content/es-gt-freeze-warning diff --git a/documentation/18.11/eiffelstudio/_images/es_gt_go_back_01.png b/documentation/18.11/eiffelstudio/_images/es_gt_go_back_01.png new file mode 100644 index 00000000..5c22f1d0 Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/es_gt_go_back_01.png differ diff --git a/documentation/18.11/eiffelstudio/_images/es_gt_go_back_01.png.data b/documentation/18.11/eiffelstudio/_images/es_gt_go_back_01.png.data new file mode 100644 index 00000000..4b44439d --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/es_gt_go_back_01.png.data @@ -0,0 +1,3 @@ +title=es gt go back 01 +author=halw +path=content/es-gt-go-back-01 diff --git a/documentation/18.11/eiffelstudio/_images/es_gt_graphics_based_design_starting_point.png b/documentation/18.11/eiffelstudio/_images/es_gt_graphics_based_design_starting_point.png new file mode 100644 index 00000000..888c9247 Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/es_gt_graphics_based_design_starting_point.png differ diff --git a/documentation/18.11/eiffelstudio/_images/es_gt_graphics_based_design_starting_point.png.data b/documentation/18.11/eiffelstudio/_images/es_gt_graphics_based_design_starting_point.png.data new file mode 100644 index 00000000..d264f3c0 --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/es_gt_graphics_based_design_starting_point.png.data @@ -0,0 +1,3 @@ +title=es gt graphics based design starting point +author=halw +path=content/es-gt-graphics-based-design-starting-point diff --git a/documentation/18.11/eiffelstudio/_images/es_gt_groups_tool_01.png b/documentation/18.11/eiffelstudio/_images/es_gt_groups_tool_01.png new file mode 100644 index 00000000..d13f2d97 Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/es_gt_groups_tool_01.png differ diff --git a/documentation/18.11/eiffelstudio/_images/es_gt_groups_tool_01.png.data b/documentation/18.11/eiffelstudio/_images/es_gt_groups_tool_01.png.data new file mode 100644 index 00000000..026172fe --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/es_gt_groups_tool_01.png.data @@ -0,0 +1,3 @@ +title=es gt groups tool 01 +author=halw +path=content/es-gt-groups-tool-01 diff --git a/documentation/18.11/eiffelstudio/_images/es_gt_groups_tool_02.png b/documentation/18.11/eiffelstudio/_images/es_gt_groups_tool_02.png new file mode 100644 index 00000000..17a02aa4 Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/es_gt_groups_tool_02.png differ diff --git a/documentation/18.11/eiffelstudio/_images/es_gt_groups_tool_02.png.data b/documentation/18.11/eiffelstudio/_images/es_gt_groups_tool_02.png.data new file mode 100644 index 00000000..f4bd1380 --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/es_gt_groups_tool_02.png.data @@ -0,0 +1,3 @@ +title=es gt groups tool 02 +author=halw +path=content/es-gt-groups-tool-02 diff --git a/documentation/18.11/eiffelstudio/_images/es_gt_groups_tool_03.png b/documentation/18.11/eiffelstudio/_images/es_gt_groups_tool_03.png new file mode 100644 index 00000000..4117354f Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/es_gt_groups_tool_03.png differ diff --git a/documentation/18.11/eiffelstudio/_images/es_gt_groups_tool_03.png.data b/documentation/18.11/eiffelstudio/_images/es_gt_groups_tool_03.png.data new file mode 100644 index 00000000..32abe1d6 --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/es_gt_groups_tool_03.png.data @@ -0,0 +1,3 @@ +title=es gt groups tool 03 +author=halw +path=content/es-gt-groups-tool-03 diff --git a/documentation/18.11/eiffelstudio/_images/es_gt_heir2_inheriting_parent.png b/documentation/18.11/eiffelstudio/_images/es_gt_heir2_inheriting_parent.png new file mode 100644 index 00000000..ef89cf72 Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/es_gt_heir2_inheriting_parent.png differ diff --git a/documentation/18.11/eiffelstudio/_images/es_gt_heir2_inheriting_parent.png.data b/documentation/18.11/eiffelstudio/_images/es_gt_heir2_inheriting_parent.png.data new file mode 100644 index 00000000..7acfd4f3 --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/es_gt_heir2_inheriting_parent.png.data @@ -0,0 +1,3 @@ +title=es gt class heir2 inheriting parent +author=halw +path=content/es-gt-class-heir2-inheriting-parent diff --git a/documentation/18.11/eiffelstudio/_images/es_gt_list_added_to_favorites_01.png b/documentation/18.11/eiffelstudio/_images/es_gt_list_added_to_favorites_01.png new file mode 100644 index 00000000..b8a11ad4 Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/es_gt_list_added_to_favorites_01.png differ diff --git a/documentation/18.11/eiffelstudio/_images/es_gt_list_added_to_favorites_01.png.data b/documentation/18.11/eiffelstudio/_images/es_gt_list_added_to_favorites_01.png.data new file mode 100644 index 00000000..26cf8864 --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/es_gt_list_added_to_favorites_01.png.data @@ -0,0 +1,3 @@ +title=es gt list added to favorites 01 +author=halw +path=content/es-gt-list-added-favorites-01 diff --git a/documentation/18.11/eiffelstudio/_images/es_gt_new_class_dialog.png b/documentation/18.11/eiffelstudio/_images/es_gt_new_class_dialog.png new file mode 100644 index 00000000..59f8a733 Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/es_gt_new_class_dialog.png differ diff --git a/documentation/18.11/eiffelstudio/_images/es_gt_new_class_dialog.png.data b/documentation/18.11/eiffelstudio/_images/es_gt_new_class_dialog.png.data new file mode 100644 index 00000000..99b25dd1 --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/es_gt_new_class_dialog.png.data @@ -0,0 +1,3 @@ +title=es gt new class dialog +author=halw +path=content/es-gt-new-class-dialog diff --git a/documentation/18.11/eiffelstudio/_images/es_gt_new_cluster_added.png b/documentation/18.11/eiffelstudio/_images/es_gt_new_cluster_added.png new file mode 100644 index 00000000..0b5260a1 Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/es_gt_new_cluster_added.png differ diff --git a/documentation/18.11/eiffelstudio/_images/es_gt_new_cluster_added.png.data b/documentation/18.11/eiffelstudio/_images/es_gt_new_cluster_added.png.data new file mode 100644 index 00000000..ea3f86c1 --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/es_gt_new_cluster_added.png.data @@ -0,0 +1,3 @@ +title=es gt new cluster added +author=halw +path=content/es-gt-new-cluster-added diff --git a/documentation/18.11/eiffelstudio/_images/es_gt_new_feature_dialog.png b/documentation/18.11/eiffelstudio/_images/es_gt_new_feature_dialog.png new file mode 100644 index 00000000..a194a443 Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/es_gt_new_feature_dialog.png differ diff --git a/documentation/18.11/eiffelstudio/_images/es_gt_new_feature_dialog.png.data b/documentation/18.11/eiffelstudio/_images/es_gt_new_feature_dialog.png.data new file mode 100644 index 00000000..57b3deba --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/es_gt_new_feature_dialog.png.data @@ -0,0 +1,3 @@ +title=es gt new feature dialog +author=halw +path=content/es-gt-new-feature-dialog diff --git a/documentation/18.11/eiffelstudio/_images/es_gt_open_01.png b/documentation/18.11/eiffelstudio/_images/es_gt_open_01.png new file mode 100644 index 00000000..59e476d4 Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/es_gt_open_01.png differ diff --git a/documentation/18.11/eiffelstudio/_images/es_gt_open_01.png.data b/documentation/18.11/eiffelstudio/_images/es_gt_open_01.png.data new file mode 100644 index 00000000..1a7b51e5 --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/es_gt_open_01.png.data @@ -0,0 +1,3 @@ +title=es gt open 01 +author=halw +path=content/es-gt-open-01 diff --git a/documentation/18.11/eiffelstudio/_images/es_gt_open_02.png b/documentation/18.11/eiffelstudio/_images/es_gt_open_02.png new file mode 100644 index 00000000..e34c4c36 Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/es_gt_open_02.png differ diff --git a/documentation/18.11/eiffelstudio/_images/es_gt_open_02.png.data b/documentation/18.11/eiffelstudio/_images/es_gt_open_02.png.data new file mode 100644 index 00000000..a3399aaf --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/es_gt_open_02.png.data @@ -0,0 +1,3 @@ +title=es gt open 02 +author=halw +path=content/es-gt-open-02 diff --git a/documentation/18.11/eiffelstudio/_images/es_gt_picked_forth_01.png b/documentation/18.11/eiffelstudio/_images/es_gt_picked_forth_01.png new file mode 100644 index 00000000..8b9d6ade Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/es_gt_picked_forth_01.png differ diff --git a/documentation/18.11/eiffelstudio/_images/es_gt_picked_forth_01.png.data b/documentation/18.11/eiffelstudio/_images/es_gt_picked_forth_01.png.data new file mode 100644 index 00000000..f872bcb4 --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/es_gt_picked_forth_01.png.data @@ -0,0 +1,3 @@ +title=es gt picked forth 01 +author=halw +path=content/es-gt-picked-forth-01 diff --git a/documentation/18.11/eiffelstudio/_images/es_gt_pnd_context_menu_01.png b/documentation/18.11/eiffelstudio/_images/es_gt_pnd_context_menu_01.png new file mode 100644 index 00000000..153463a5 Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/es_gt_pnd_context_menu_01.png differ diff --git a/documentation/18.11/eiffelstudio/_images/es_gt_pnd_context_menu_01.png.data b/documentation/18.11/eiffelstudio/_images/es_gt_pnd_context_menu_01.png.data new file mode 100644 index 00000000..1a0b85e4 --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/es_gt_pnd_context_menu_01.png.data @@ -0,0 +1,3 @@ +title=es gt pnd context menu 01 +author=halw +path=content/es-gt-pnd-context-menu-01 diff --git a/documentation/18.11/eiffelstudio/_images/es_gt_project_directory_01_0.png b/documentation/18.11/eiffelstudio/_images/es_gt_project_directory_01_0.png new file mode 100644 index 00000000..cd417e58 Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/es_gt_project_directory_01_0.png differ diff --git a/documentation/18.11/eiffelstudio/_images/es_gt_project_directory_01_0.png.data b/documentation/18.11/eiffelstudio/_images/es_gt_project_directory_01_0.png.data new file mode 100644 index 00000000..1c138b46 --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/es_gt_project_directory_01_0.png.data @@ -0,0 +1,3 @@ +title=es gt project directory 01 +author=halw +path=content/es-gt-project-directory-01 diff --git a/documentation/18.11/eiffelstudio/_images/es_gt_redocking_project_toolbar.png b/documentation/18.11/eiffelstudio/_images/es_gt_redocking_project_toolbar.png new file mode 100644 index 00000000..21a00868 Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/es_gt_redocking_project_toolbar.png differ diff --git a/documentation/18.11/eiffelstudio/_images/es_gt_redocking_project_toolbar.png.data b/documentation/18.11/eiffelstudio/_images/es_gt_redocking_project_toolbar.png.data new file mode 100644 index 00000000..85a44c1b --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/es_gt_redocking_project_toolbar.png.data @@ -0,0 +1,3 @@ +title=es gt redocking project toolbar +author=halw +path=content/es-gt-redocking-project-toolbar diff --git a/documentation/18.11/eiffelstudio/_images/es_gt_redocking_project_toolbar_new_row.png b/documentation/18.11/eiffelstudio/_images/es_gt_redocking_project_toolbar_new_row.png new file mode 100644 index 00000000..0cab1cff Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/es_gt_redocking_project_toolbar_new_row.png differ diff --git a/documentation/18.11/eiffelstudio/_images/es_gt_redocking_project_toolbar_new_row.png.data b/documentation/18.11/eiffelstudio/_images/es_gt_redocking_project_toolbar_new_row.png.data new file mode 100644 index 00000000..6d28a845 --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/es_gt_redocking_project_toolbar_new_row.png.data @@ -0,0 +1,3 @@ +title=es gt redocking project toolbar new row +author=halw +path=content/es-gt-redocking-project-toolbar-new-row diff --git a/documentation/18.11/eiffelstudio/_images/es_gt_relation_depth_dialog.png b/documentation/18.11/eiffelstudio/_images/es_gt_relation_depth_dialog.png new file mode 100644 index 00000000..5f191ab1 Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/es_gt_relation_depth_dialog.png differ diff --git a/documentation/18.11/eiffelstudio/_images/es_gt_relation_depth_dialog.png.data b/documentation/18.11/eiffelstudio/_images/es_gt_relation_depth_dialog.png.data new file mode 100644 index 00000000..4d4e8c8e --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/es_gt_relation_depth_dialog.png.data @@ -0,0 +1,3 @@ +title=es gt relation depth dialog +author=halw +path=content/es-gt-relation-depth-dialog diff --git a/documentation/18.11/eiffelstudio/_images/es_gt_reordered_pane_tabs.png b/documentation/18.11/eiffelstudio/_images/es_gt_reordered_pane_tabs.png new file mode 100644 index 00000000..e9c71fd9 Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/es_gt_reordered_pane_tabs.png differ diff --git a/documentation/18.11/eiffelstudio/_images/es_gt_reordered_pane_tabs.png.data b/documentation/18.11/eiffelstudio/_images/es_gt_reordered_pane_tabs.png.data new file mode 100644 index 00000000..ed8f3654 --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/es_gt_reordered_pane_tabs.png.data @@ -0,0 +1,3 @@ +title=es gt reordered pane tabs +author=halw +path=content/es-gt-reordered-pane-tabs diff --git a/documentation/18.11/eiffelstudio/_images/es_gt_reset_tools_layout_01.png b/documentation/18.11/eiffelstudio/_images/es_gt_reset_tools_layout_01.png new file mode 100644 index 00000000..44b06a18 Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/es_gt_reset_tools_layout_01.png differ diff --git a/documentation/18.11/eiffelstudio/_images/es_gt_reset_tools_layout_01.png.data b/documentation/18.11/eiffelstudio/_images/es_gt_reset_tools_layout_01.png.data new file mode 100644 index 00000000..c2c74a7a --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/es_gt_reset_tools_layout_01.png.data @@ -0,0 +1,3 @@ +title=es gt reset tools layout 01 +author=halw +path=content/es-gt-reset-tools-layout-01 diff --git a/documentation/18.11/eiffelstudio/_images/es_gt_select_conforming_inheritance_link_creation_mode.png b/documentation/18.11/eiffelstudio/_images/es_gt_select_conforming_inheritance_link_creation_mode.png new file mode 100644 index 00000000..96c68f4d Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/es_gt_select_conforming_inheritance_link_creation_mode.png differ diff --git a/documentation/18.11/eiffelstudio/_images/es_gt_select_conforming_inheritance_link_creation_mode.png.data b/documentation/18.11/eiffelstudio/_images/es_gt_select_conforming_inheritance_link_creation_mode.png.data new file mode 100644 index 00000000..7719168d --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/es_gt_select_conforming_inheritance_link_creation_mode.png.data @@ -0,0 +1,3 @@ +title=es gt select conforming inheritance link creation mode +author=halw +path=content/es-gt-select-conforming-inheritance-link-creation-mode diff --git a/documentation/18.11/eiffelstudio/_images/es_gt_side_by_side_editing.png b/documentation/18.11/eiffelstudio/_images/es_gt_side_by_side_editing.png new file mode 100644 index 00000000..9007690c Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/es_gt_side_by_side_editing.png differ diff --git a/documentation/18.11/eiffelstudio/_images/es_gt_side_by_side_editing.png.data b/documentation/18.11/eiffelstudio/_images/es_gt_side_by_side_editing.png.data new file mode 100644 index 00000000..d0249609 --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/es_gt_side_by_side_editing.png.data @@ -0,0 +1,3 @@ +title=es gt side by side editing +author=halw +path=content/es-gt-side-side-editing diff --git a/documentation/18.11/eiffelstudio/_images/es_gt_split_pane.png b/documentation/18.11/eiffelstudio/_images/es_gt_split_pane.png new file mode 100644 index 00000000..83d10fbb Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/es_gt_split_pane.png differ diff --git a/documentation/18.11/eiffelstudio/_images/es_gt_split_pane.png.data b/documentation/18.11/eiffelstudio/_images/es_gt_split_pane.png.data new file mode 100644 index 00000000..d501174d --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/es_gt_split_pane.png.data @@ -0,0 +1,3 @@ +title=es gt split pane right +author=halw +path=content/es-gt-split-pane-right diff --git a/documentation/18.11/eiffelstudio/_images/es_gt_string_01.png b/documentation/18.11/eiffelstudio/_images/es_gt_string_01.png new file mode 100644 index 00000000..5d2e9e5a Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/es_gt_string_01.png differ diff --git a/documentation/18.11/eiffelstudio/_images/es_gt_string_01.png.data b/documentation/18.11/eiffelstudio/_images/es_gt_string_01.png.data new file mode 100644 index 00000000..b8eba76b --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/es_gt_string_01.png.data @@ -0,0 +1,3 @@ +title=es gt string 01 +author=halw +path=content/es-gt-string-01 diff --git a/documentation/18.11/eiffelstudio/_images/es_gt_target_history_01.png b/documentation/18.11/eiffelstudio/_images/es_gt_target_history_01.png new file mode 100644 index 00000000..725de5de Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/es_gt_target_history_01.png differ diff --git a/documentation/18.11/eiffelstudio/_images/es_gt_target_history_01.png.data b/documentation/18.11/eiffelstudio/_images/es_gt_target_history_01.png.data new file mode 100644 index 00000000..667e13f2 --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/es_gt_target_history_01.png.data @@ -0,0 +1,3 @@ +title=es gt target history 01 +author=halw +path=content/es-gt-target-history-01 diff --git a/documentation/18.11/eiffelstudio/_images/es_gt_testroot_class_diagram.png b/documentation/18.11/eiffelstudio/_images/es_gt_testroot_class_diagram.png new file mode 100644 index 00000000..6c9dcd7b Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/es_gt_testroot_class_diagram.png differ diff --git a/documentation/18.11/eiffelstudio/_images/es_gt_testroot_class_diagram.png.data b/documentation/18.11/eiffelstudio/_images/es_gt_testroot_class_diagram.png.data new file mode 100644 index 00000000..e2ecb9ce --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/es_gt_testroot_class_diagram.png.data @@ -0,0 +1,3 @@ +title=es gt testroot class diagram +author=halw +path=content/es-gt-testroot-class-diagram diff --git a/documentation/18.11/eiffelstudio/_images/es_gt_testroot_cluster.png b/documentation/18.11/eiffelstudio/_images/es_gt_testroot_cluster.png new file mode 100644 index 00000000..75a6bc3d Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/es_gt_testroot_cluster.png differ diff --git a/documentation/18.11/eiffelstudio/_images/es_gt_testroot_cluster.png.data b/documentation/18.11/eiffelstudio/_images/es_gt_testroot_cluster.png.data new file mode 100644 index 00000000..2e33b7ce --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/es_gt_testroot_cluster.png.data @@ -0,0 +1,3 @@ +title=es gt testroot cluster diagram +author=halw +path=content/es-gt-testroot-cluster-diagram diff --git a/documentation/18.11/eiffelstudio/_images/es_gt_testroot_is_client_of_heir.png b/documentation/18.11/eiffelstudio/_images/es_gt_testroot_is_client_of_heir.png new file mode 100644 index 00000000..e61b40e4 Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/es_gt_testroot_is_client_of_heir.png differ diff --git a/documentation/18.11/eiffelstudio/_images/es_gt_testroot_is_client_of_heir.png.data b/documentation/18.11/eiffelstudio/_images/es_gt_testroot_is_client_of_heir.png.data new file mode 100644 index 00000000..95599a5d --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/es_gt_testroot_is_client_of_heir.png.data @@ -0,0 +1,3 @@ +title=es gt testroot is client of heir +author=halw +path=content/es-gt-testroot-client-heir diff --git a/documentation/18.11/eiffelstudio/_images/es_gt_testroot_is_client_of_heir2.png b/documentation/18.11/eiffelstudio/_images/es_gt_testroot_is_client_of_heir2.png new file mode 100644 index 00000000..4c0ea80a Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/es_gt_testroot_is_client_of_heir2.png differ diff --git a/documentation/18.11/eiffelstudio/_images/es_gt_testroot_is_client_of_heir2.png.data b/documentation/18.11/eiffelstudio/_images/es_gt_testroot_is_client_of_heir2.png.data new file mode 100644 index 00000000..5a13edbe --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/es_gt_testroot_is_client_of_heir2.png.data @@ -0,0 +1,3 @@ +title=es gt testroot is client of heir2 +author=halw +path=content/es-gt-testroot-client-heir2 diff --git a/documentation/18.11/eiffelstudio/_images/es_ref_add_attached_contract_template_01.png b/documentation/18.11/eiffelstudio/_images/es_ref_add_attached_contract_template_01.png new file mode 100644 index 00000000..f7e4e58e Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/es_ref_add_attached_contract_template_01.png differ diff --git a/documentation/18.11/eiffelstudio/_images/es_ref_add_attached_contract_template_01.png.data b/documentation/18.11/eiffelstudio/_images/es_ref_add_attached_contract_template_01.png.data new file mode 100644 index 00000000..eda1eaa3 --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/es_ref_add_attached_contract_template_01.png.data @@ -0,0 +1,3 @@ +title=es ref add attached contract template 01 +author=halw +path=content/es-ref-add-attached-contract-template-01 diff --git a/documentation/18.11/eiffelstudio/_images/es_ref_add_attached_contract_template_02.png b/documentation/18.11/eiffelstudio/_images/es_ref_add_attached_contract_template_02.png new file mode 100644 index 00000000..d7a99ede Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/es_ref_add_attached_contract_template_02.png differ diff --git a/documentation/18.11/eiffelstudio/_images/es_ref_add_attached_contract_template_02.png.data b/documentation/18.11/eiffelstudio/_images/es_ref_add_attached_contract_template_02.png.data new file mode 100644 index 00000000..a7c858ec --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/es_ref_add_attached_contract_template_02.png.data @@ -0,0 +1,3 @@ +title=es ref add attached contract template 02 +author=halw +path=content/es-ref-add-attached-contract-template-02 diff --git a/documentation/18.11/eiffelstudio/_images/es_ref_contract_editor_01.png b/documentation/18.11/eiffelstudio/_images/es_ref_contract_editor_01.png new file mode 100644 index 00000000..63ee0136 Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/es_ref_contract_editor_01.png differ diff --git a/documentation/18.11/eiffelstudio/_images/es_ref_contract_editor_01.png.data b/documentation/18.11/eiffelstudio/_images/es_ref_contract_editor_01.png.data new file mode 100644 index 00000000..532656d5 --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/es_ref_contract_editor_01.png.data @@ -0,0 +1,3 @@ +title=es ref contract editor 01 +author=halw +path=content/es-ref-contract-editor-01 diff --git a/documentation/18.11/eiffelstudio/_images/es_ref_contract_editor_02.png b/documentation/18.11/eiffelstudio/_images/es_ref_contract_editor_02.png new file mode 100644 index 00000000..8fd3274f Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/es_ref_contract_editor_02.png differ diff --git a/documentation/18.11/eiffelstudio/_images/es_ref_contract_editor_02.png.data b/documentation/18.11/eiffelstudio/_images/es_ref_contract_editor_02.png.data new file mode 100644 index 00000000..4c646ddc --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/es_ref_contract_editor_02.png.data @@ -0,0 +1,3 @@ +title=es ref contract editor 02 +author=halw +path=content/es-ref-contract-editor-02 diff --git a/documentation/18.11/eiffelstudio/_images/es_ref_contract_editor_03.png b/documentation/18.11/eiffelstudio/_images/es_ref_contract_editor_03.png new file mode 100644 index 00000000..4f1c2ccc Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/es_ref_contract_editor_03.png differ diff --git a/documentation/18.11/eiffelstudio/_images/es_ref_contract_editor_03.png.data b/documentation/18.11/eiffelstudio/_images/es_ref_contract_editor_03.png.data new file mode 100644 index 00000000..bcf1f077 --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/es_ref_contract_editor_03.png.data @@ -0,0 +1,3 @@ +title=es ref contract editor 03 +author=halw +path=content/es-ref-contract-editor-03 diff --git a/documentation/18.11/eiffelstudio/_images/es_ref_contract_editor_add_01.png b/documentation/18.11/eiffelstudio/_images/es_ref_contract_editor_add_01.png new file mode 100644 index 00000000..e06b0f56 Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/es_ref_contract_editor_add_01.png differ diff --git a/documentation/18.11/eiffelstudio/_images/es_ref_contract_editor_add_01.png.data b/documentation/18.11/eiffelstudio/_images/es_ref_contract_editor_add_01.png.data new file mode 100644 index 00000000..8cad7917 --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/es_ref_contract_editor_add_01.png.data @@ -0,0 +1,3 @@ +title=es ref contract editor add 01 +author=halw +path=content/es-ref-contract-editor-add-01 diff --git a/documentation/18.11/eiffelstudio/_images/es_ref_contract_editor_add_02.png b/documentation/18.11/eiffelstudio/_images/es_ref_contract_editor_add_02.png new file mode 100644 index 00000000..e7ed1343 Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/es_ref_contract_editor_add_02.png differ diff --git a/documentation/18.11/eiffelstudio/_images/es_ref_contract_editor_add_02.png.data b/documentation/18.11/eiffelstudio/_images/es_ref_contract_editor_add_02.png.data new file mode 100644 index 00000000..2bcc872a --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/es_ref_contract_editor_add_02.png.data @@ -0,0 +1,3 @@ +title=es ref contract editor add 02 +author=halw +path=content/es-ref-contract-editor-add-02 diff --git a/documentation/18.11/eiffelstudio/_images/es_ref_edit_contract_dialog_01.png b/documentation/18.11/eiffelstudio/_images/es_ref_edit_contract_dialog_01.png new file mode 100644 index 00000000..0b5526e8 Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/es_ref_edit_contract_dialog_01.png differ diff --git a/documentation/18.11/eiffelstudio/_images/es_ref_edit_contract_dialog_01.png.data b/documentation/18.11/eiffelstudio/_images/es_ref_edit_contract_dialog_01.png.data new file mode 100644 index 00000000..ea83f3d8 --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/es_ref_edit_contract_dialog_01.png.data @@ -0,0 +1,3 @@ +title=es ref edit contract dialog 01 +author=halw +path=content/es-ref-edit-contract-dialog-01 diff --git a/documentation/18.11/eiffelstudio/_images/exception-dialog.png b/documentation/18.11/eiffelstudio/_images/exception-dialog.png new file mode 100644 index 00000000..e18d6aa0 Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/exception-dialog.png differ diff --git a/documentation/18.11/eiffelstudio/_images/exception-dialog.png.data b/documentation/18.11/eiffelstudio/_images/exception-dialog.png.data new file mode 100644 index 00000000..b6b38595 --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/exception-dialog.png.data @@ -0,0 +1,3 @@ +title=exception-dialog +author=admin +path=content/exception-dialog diff --git a/documentation/18.11/eiffelstudio/_images/exceptions-handling-tool.png b/documentation/18.11/eiffelstudio/_images/exceptions-handling-tool.png new file mode 100644 index 00000000..4bb23a48 Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/exceptions-handling-tool.png differ diff --git a/documentation/18.11/eiffelstudio/_images/exceptions-handling-tool.png.data b/documentation/18.11/eiffelstudio/_images/exceptions-handling-tool.png.data new file mode 100644 index 00000000..fb4cc716 --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/exceptions-handling-tool.png.data @@ -0,0 +1,3 @@ +title=exceptions-handling-tool +author=admin +path=content/exceptions-handling-tool diff --git a/documentation/18.11/eiffelstudio/_images/exec-replay-00-1.png b/documentation/18.11/eiffelstudio/_images/exec-replay-00-1.png new file mode 100644 index 00000000..13537cc4 Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/exec-replay-00-1.png differ diff --git a/documentation/18.11/eiffelstudio/_images/exec-replay-00-1.png.data b/documentation/18.11/eiffelstudio/_images/exec-replay-00-1.png.data new file mode 100644 index 00000000..b4a1f3d0 --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/exec-replay-00-1.png.data @@ -0,0 +1,3 @@ +title=exec-replay-00-1 +author=admin +path=content/exec-replay-00-1 diff --git a/documentation/18.11/eiffelstudio/_images/exec-replay-00.png b/documentation/18.11/eiffelstudio/_images/exec-replay-00.png new file mode 100644 index 00000000..c7090bff Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/exec-replay-00.png differ diff --git a/documentation/18.11/eiffelstudio/_images/exec-replay-00.png.data b/documentation/18.11/eiffelstudio/_images/exec-replay-00.png.data new file mode 100644 index 00000000..59af4719 --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/exec-replay-00.png.data @@ -0,0 +1,3 @@ +title=exec-replay-00 +author=admin +path=content/exec-replay-00 diff --git a/documentation/18.11/eiffelstudio/_images/exec-replay-01.png b/documentation/18.11/eiffelstudio/_images/exec-replay-01.png new file mode 100644 index 00000000..e5be9c29 Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/exec-replay-01.png differ diff --git a/documentation/18.11/eiffelstudio/_images/exec-replay-01.png.data b/documentation/18.11/eiffelstudio/_images/exec-replay-01.png.data new file mode 100644 index 00000000..f87cd516 --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/exec-replay-01.png.data @@ -0,0 +1,3 @@ +title=exec-replay-01 +author=admin +path=content/exec-replay-01 diff --git a/documentation/18.11/eiffelstudio/_images/exec-replay-02-1.png b/documentation/18.11/eiffelstudio/_images/exec-replay-02-1.png new file mode 100644 index 00000000..d214199f Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/exec-replay-02-1.png differ diff --git a/documentation/18.11/eiffelstudio/_images/exec-replay-02-1.png.data b/documentation/18.11/eiffelstudio/_images/exec-replay-02-1.png.data new file mode 100644 index 00000000..5f1a1e44 --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/exec-replay-02-1.png.data @@ -0,0 +1,3 @@ +title=exec-replay-02-1 +author=admin +path=content/exec-replay-02-1 diff --git a/documentation/18.11/eiffelstudio/_images/exec-replay-02.png b/documentation/18.11/eiffelstudio/_images/exec-replay-02.png new file mode 100644 index 00000000..84092b66 Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/exec-replay-02.png differ diff --git a/documentation/18.11/eiffelstudio/_images/exec-replay-02.png.data b/documentation/18.11/eiffelstudio/_images/exec-replay-02.png.data new file mode 100644 index 00000000..7740d073 --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/exec-replay-02.png.data @@ -0,0 +1,3 @@ +title=exec-replay-02 +author=admin +path=content/exec-replay-02 diff --git a/documentation/18.11/eiffelstudio/_images/exec-replay-03.png b/documentation/18.11/eiffelstudio/_images/exec-replay-03.png new file mode 100644 index 00000000..466301d4 Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/exec-replay-03.png differ diff --git a/documentation/18.11/eiffelstudio/_images/exec-replay-03.png.data b/documentation/18.11/eiffelstudio/_images/exec-replay-03.png.data new file mode 100644 index 00000000..bc36b056 --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/exec-replay-03.png.data @@ -0,0 +1,3 @@ +title=exec-replay-03 +author=admin +path=content/exec-replay-03 diff --git a/documentation/18.11/eiffelstudio/_images/exec-replay-04.png b/documentation/18.11/eiffelstudio/_images/exec-replay-04.png new file mode 100644 index 00000000..c1a8b64c Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/exec-replay-04.png differ diff --git a/documentation/18.11/eiffelstudio/_images/exec-replay-04.png.data b/documentation/18.11/eiffelstudio/_images/exec-replay-04.png.data new file mode 100644 index 00000000..2c2e437d --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/exec-replay-04.png.data @@ -0,0 +1,3 @@ +title=exec-replay-04 +author=admin +path=content/exec-replay-04 diff --git a/documentation/18.11/eiffelstudio/_images/execution-object-storage-icon.png b/documentation/18.11/eiffelstudio/_images/execution-object-storage-icon.png new file mode 100644 index 00000000..fa3da8fa Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/execution-object-storage-icon.png differ diff --git a/documentation/18.11/eiffelstudio/_images/execution-object-storage-icon.png.data b/documentation/18.11/eiffelstudio/_images/execution-object-storage-icon.png.data new file mode 100644 index 00000000..1ac082ed --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/execution-object-storage-icon.png.data @@ -0,0 +1,3 @@ +title=execution-object-storage-icon +author=admin +path=content/execution-object-storage-icon diff --git a/documentation/18.11/eiffelstudio/_images/expand-errors.png b/documentation/18.11/eiffelstudio/_images/expand-errors.png new file mode 100644 index 00000000..cd8185f1 Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/expand-errors.png differ diff --git a/documentation/18.11/eiffelstudio/_images/expand-errors.png.data b/documentation/18.11/eiffelstudio/_images/expand-errors.png.data new file mode 100644 index 00000000..a1c829b2 --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/expand-errors.png.data @@ -0,0 +1,3 @@ +title=expand-errors +author=admin +path=content/expand-errors diff --git a/documentation/18.11/eiffelstudio/_images/expanded-display-default.png b/documentation/18.11/eiffelstudio/_images/expanded-display-default.png new file mode 100644 index 00000000..d25bcc5e Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/expanded-display-default.png differ diff --git a/documentation/18.11/eiffelstudio/_images/expanded-display-default.png.data b/documentation/18.11/eiffelstudio/_images/expanded-display-default.png.data new file mode 100644 index 00000000..0028f737 --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/expanded-display-default.png.data @@ -0,0 +1,3 @@ +title=expanded-display-default +author=admin +path=content/expanded-display-default diff --git a/documentation/18.11/eiffelstudio/_images/expanded-normal-icon.png b/documentation/18.11/eiffelstudio/_images/expanded-normal-icon.png new file mode 100644 index 00000000..80475168 Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/expanded-normal-icon.png differ diff --git a/documentation/18.11/eiffelstudio/_images/expanded-normal-icon.png.data b/documentation/18.11/eiffelstudio/_images/expanded-normal-icon.png.data new file mode 100644 index 00000000..41f62931 --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/expanded-normal-icon.png.data @@ -0,0 +1,3 @@ +title=expanded-normal-icon +author=admin +path=content/expanded-normal-icon diff --git a/documentation/18.11/eiffelstudio/_images/expression-evaluation-tool.png b/documentation/18.11/eiffelstudio/_images/expression-evaluation-tool.png new file mode 100644 index 00000000..1a7db80b Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/expression-evaluation-tool.png differ diff --git a/documentation/18.11/eiffelstudio/_images/expression-evaluation-tool.png.data b/documentation/18.11/eiffelstudio/_images/expression-evaluation-tool.png.data new file mode 100644 index 00000000..f94d8feb --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/expression-evaluation-tool.png.data @@ -0,0 +1,3 @@ +title=expression-evaluation-tool +author=admin +path=content/expression-evaluation-tool diff --git a/documentation/18.11/eiffelstudio/_images/external-commands-dialog-editor.png b/documentation/18.11/eiffelstudio/_images/external-commands-dialog-editor.png new file mode 100644 index 00000000..83c01162 Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/external-commands-dialog-editor.png differ diff --git a/documentation/18.11/eiffelstudio/_images/external-commands-dialog-editor.png.data b/documentation/18.11/eiffelstudio/_images/external-commands-dialog-editor.png.data new file mode 100644 index 00000000..3bda6b95 --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/external-commands-dialog-editor.png.data @@ -0,0 +1,3 @@ +title=external-commands-dialog-editor +author=admin +path=content/external-commands-dialog-editor diff --git a/documentation/18.11/eiffelstudio/_images/external-commands-dialog.png b/documentation/18.11/eiffelstudio/_images/external-commands-dialog.png new file mode 100644 index 00000000..1e1c8ff3 Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/external-commands-dialog.png differ diff --git a/documentation/18.11/eiffelstudio/_images/external-commands-dialog.png.data b/documentation/18.11/eiffelstudio/_images/external-commands-dialog.png.data new file mode 100644 index 00000000..9f9bc0b9 --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/external-commands-dialog.png.data @@ -0,0 +1,3 @@ +title=external-commands-dialog +author=admin +path=content/external-commands-dialog diff --git a/documentation/18.11/eiffelstudio/_images/external-options.png b/documentation/18.11/eiffelstudio/_images/external-options.png new file mode 100644 index 00000000..ac4ac343 Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/external-options.png differ diff --git a/documentation/18.11/eiffelstudio/_images/external-options.png.data b/documentation/18.11/eiffelstudio/_images/external-options.png.data new file mode 100644 index 00000000..8d507759 --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/external-options.png.data @@ -0,0 +1,3 @@ +title=external-options +author=admin +path=content/external-options diff --git a/documentation/18.11/eiffelstudio/_images/fake-callee-is.jpg b/documentation/18.11/eiffelstudio/_images/fake-callee-is.jpg new file mode 100644 index 00000000..7c172b36 Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/fake-callee-is.jpg differ diff --git a/documentation/18.11/eiffelstudio/_images/fake-callee-is.jpg.data b/documentation/18.11/eiffelstudio/_images/fake-callee-is.jpg.data new file mode 100644 index 00000000..69330a1d --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/fake-callee-is.jpg.data @@ -0,0 +1,3 @@ +title=fake-callee-is +author=admin +path=content/fake-callee diff --git a/documentation/18.11/eiffelstudio/_images/favorites-choose-folder-dialog.png b/documentation/18.11/eiffelstudio/_images/favorites-choose-folder-dialog.png new file mode 100644 index 00000000..582f3b40 Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/favorites-choose-folder-dialog.png differ diff --git a/documentation/18.11/eiffelstudio/_images/favorites-choose-folder-dialog.png.data b/documentation/18.11/eiffelstudio/_images/favorites-choose-folder-dialog.png.data new file mode 100644 index 00000000..d2cfb304 --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/favorites-choose-folder-dialog.png.data @@ -0,0 +1,3 @@ +title=favorites-choose-folder-dialog +author=admin +path=content/favorites-choose-folder-dialog diff --git a/documentation/18.11/eiffelstudio/_images/favorites-dialog-move-to.png b/documentation/18.11/eiffelstudio/_images/favorites-dialog-move-to.png new file mode 100644 index 00000000..ca496bbe Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/favorites-dialog-move-to.png differ diff --git a/documentation/18.11/eiffelstudio/_images/favorites-dialog-move-to.png.data b/documentation/18.11/eiffelstudio/_images/favorites-dialog-move-to.png.data new file mode 100644 index 00000000..a677a94d --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/favorites-dialog-move-to.png.data @@ -0,0 +1,3 @@ +title=favorites-dialog-move-to +author=admin +path=content/favorites-dialog-move diff --git a/documentation/18.11/eiffelstudio/_images/favorites-dialog-new-class.png b/documentation/18.11/eiffelstudio/_images/favorites-dialog-new-class.png new file mode 100644 index 00000000..d1da8475 Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/favorites-dialog-new-class.png differ diff --git a/documentation/18.11/eiffelstudio/_images/favorites-dialog-new-class.png.data b/documentation/18.11/eiffelstudio/_images/favorites-dialog-new-class.png.data new file mode 100644 index 00000000..4731f55d --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/favorites-dialog-new-class.png.data @@ -0,0 +1,3 @@ +title=favorites-dialog-new-class +author=admin +path=content/favorites-dialog-new-class diff --git a/documentation/18.11/eiffelstudio/_images/favorites-dialog-new-folder.png b/documentation/18.11/eiffelstudio/_images/favorites-dialog-new-folder.png new file mode 100644 index 00000000..22ac8b8e Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/favorites-dialog-new-folder.png differ diff --git a/documentation/18.11/eiffelstudio/_images/favorites-dialog-new-folder.png.data b/documentation/18.11/eiffelstudio/_images/favorites-dialog-new-folder.png.data new file mode 100644 index 00000000..a07f74e1 --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/favorites-dialog-new-folder.png.data @@ -0,0 +1,3 @@ +title=favorites-dialog-new-folder +author=admin +path=content/favorites-dialog-new-folder diff --git a/documentation/18.11/eiffelstudio/_images/favorites-dialog-remove.png b/documentation/18.11/eiffelstudio/_images/favorites-dialog-remove.png new file mode 100644 index 00000000..e8179190 Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/favorites-dialog-remove.png differ diff --git a/documentation/18.11/eiffelstudio/_images/favorites-dialog-remove.png.data b/documentation/18.11/eiffelstudio/_images/favorites-dialog-remove.png.data new file mode 100644 index 00000000..84ec5c98 --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/favorites-dialog-remove.png.data @@ -0,0 +1,3 @@ +title=favorites-dialog-remove +author=admin +path=content/favorites-dialog-remove diff --git a/documentation/18.11/eiffelstudio/_images/favorites-dialog.png b/documentation/18.11/eiffelstudio/_images/favorites-dialog.png new file mode 100644 index 00000000..fa673ceb Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/favorites-dialog.png differ diff --git a/documentation/18.11/eiffelstudio/_images/favorites-dialog.png.data b/documentation/18.11/eiffelstudio/_images/favorites-dialog.png.data new file mode 100644 index 00000000..1480cf4b --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/favorites-dialog.png.data @@ -0,0 +1,3 @@ +title=favorites-dialog +author=admin +path=content/favorites-dialog diff --git a/documentation/18.11/eiffelstudio/_images/favorites-new-class-dialog.png b/documentation/18.11/eiffelstudio/_images/favorites-new-class-dialog.png new file mode 100644 index 00000000..0405d8cd Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/favorites-new-class-dialog.png differ diff --git a/documentation/18.11/eiffelstudio/_images/favorites-new-class-dialog.png.data b/documentation/18.11/eiffelstudio/_images/favorites-new-class-dialog.png.data new file mode 100644 index 00000000..fc48a686 --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/favorites-new-class-dialog.png.data @@ -0,0 +1,3 @@ +title=favorites-new-class-dialog +author=admin +path=content/favorites-new-class-dialog diff --git a/documentation/18.11/eiffelstudio/_images/favorites-new-folder-dialog.png b/documentation/18.11/eiffelstudio/_images/favorites-new-folder-dialog.png new file mode 100644 index 00000000..5fe49cc9 Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/favorites-new-folder-dialog.png differ diff --git a/documentation/18.11/eiffelstudio/_images/favorites-new-folder-dialog.png.data b/documentation/18.11/eiffelstudio/_images/favorites-new-folder-dialog.png.data new file mode 100644 index 00000000..250b42af --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/favorites-new-folder-dialog.png.data @@ -0,0 +1,3 @@ +title=favorites-new-folder-dialog +author=admin +path=content/favorites-new-folder-dialog diff --git a/documentation/18.11/eiffelstudio/_images/favorites-tool.png b/documentation/18.11/eiffelstudio/_images/favorites-tool.png new file mode 100644 index 00000000..ed4fe7e8 Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/favorites-tool.png differ diff --git a/documentation/18.11/eiffelstudio/_images/favorites-tool.png.data b/documentation/18.11/eiffelstudio/_images/favorites-tool.png.data new file mode 100644 index 00000000..b8ba059c --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/favorites-tool.png.data @@ -0,0 +1,3 @@ +title=favorites-tool +author=admin +path=content/favorites-tool diff --git a/documentation/18.11/eiffelstudio/_images/favorites-tree.png b/documentation/18.11/eiffelstudio/_images/favorites-tree.png new file mode 100644 index 00000000..db29a873 Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/favorites-tree.png differ diff --git a/documentation/18.11/eiffelstudio/_images/favorites-tree.png.data b/documentation/18.11/eiffelstudio/_images/favorites-tree.png.data new file mode 100644 index 00000000..7c2c990d --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/favorites-tree.png.data @@ -0,0 +1,3 @@ +title=favorites-tree +author=admin +path=content/favorites-tree diff --git a/documentation/18.11/eiffelstudio/_images/feature-ancestors-icon.png b/documentation/18.11/eiffelstudio/_images/feature-ancestors-icon.png new file mode 100644 index 00000000..f53576bb Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/feature-ancestors-icon.png differ diff --git a/documentation/18.11/eiffelstudio/_images/feature-ancestors-icon.png.data b/documentation/18.11/eiffelstudio/_images/feature-ancestors-icon.png.data new file mode 100644 index 00000000..1fe999d8 --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/feature-ancestors-icon.png.data @@ -0,0 +1,3 @@ +title=feature-ancestors-icon +author=admin +path=content/feature-ancestors-icon diff --git a/documentation/18.11/eiffelstudio/_images/feature-assignees-icon.png b/documentation/18.11/eiffelstudio/_images/feature-assignees-icon.png new file mode 100644 index 00000000..0e313f9d Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/feature-assignees-icon.png differ diff --git a/documentation/18.11/eiffelstudio/_images/feature-assignees-icon.png.data b/documentation/18.11/eiffelstudio/_images/feature-assignees-icon.png.data new file mode 100644 index 00000000..21297657 --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/feature-assignees-icon.png.data @@ -0,0 +1,3 @@ +title=feature-assignees-icon +author=admin +path=content/feature-assignees-icon diff --git a/documentation/18.11/eiffelstudio/_images/feature-assigners-icon.png b/documentation/18.11/eiffelstudio/_images/feature-assigners-icon.png new file mode 100644 index 00000000..b67a055d Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/feature-assigners-icon.png differ diff --git a/documentation/18.11/eiffelstudio/_images/feature-assigners-icon.png.data b/documentation/18.11/eiffelstudio/_images/feature-assigners-icon.png.data new file mode 100644 index 00000000..31626188 --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/feature-assigners-icon.png.data @@ -0,0 +1,3 @@ +title=feature-assigners-icon +author=admin +path=content/feature-assigners-icon diff --git a/documentation/18.11/eiffelstudio/_images/feature-attribute-icon.png b/documentation/18.11/eiffelstudio/_images/feature-attribute-icon.png new file mode 100644 index 00000000..ded5bbf9 Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/feature-attribute-icon.png differ diff --git a/documentation/18.11/eiffelstudio/_images/feature-attribute-icon.png.data b/documentation/18.11/eiffelstudio/_images/feature-attribute-icon.png.data new file mode 100644 index 00000000..cf1a3f87 --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/feature-attribute-icon.png.data @@ -0,0 +1,3 @@ +title=feature-attribute-icon +author=admin +path=content/feature-attribute-icon diff --git a/documentation/18.11/eiffelstudio/_images/feature-callees-icon.png b/documentation/18.11/eiffelstudio/_images/feature-callees-icon.png new file mode 100644 index 00000000..9767cbf6 Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/feature-callees-icon.png differ diff --git a/documentation/18.11/eiffelstudio/_images/feature-callees-icon.png.data b/documentation/18.11/eiffelstudio/_images/feature-callees-icon.png.data new file mode 100644 index 00000000..2576d4ed --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/feature-callees-icon.png.data @@ -0,0 +1,3 @@ +title=feature-callees-icon +author=admin +path=content/feature-callees-icon diff --git a/documentation/18.11/eiffelstudio/_images/feature-callers-icon.png b/documentation/18.11/eiffelstudio/_images/feature-callers-icon.png new file mode 100644 index 00000000..a6b35062 Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/feature-callers-icon.png differ diff --git a/documentation/18.11/eiffelstudio/_images/feature-callers-icon.png.data b/documentation/18.11/eiffelstudio/_images/feature-callers-icon.png.data new file mode 100644 index 00000000..ccb46345 --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/feature-callers-icon.png.data @@ -0,0 +1,3 @@ +title=feature-callers-icon +author=admin +path=content/feature-callers-icon diff --git a/documentation/18.11/eiffelstudio/_images/feature-creaters-icon.png b/documentation/18.11/eiffelstudio/_images/feature-creaters-icon.png new file mode 100644 index 00000000..4faf3af4 Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/feature-creaters-icon.png differ diff --git a/documentation/18.11/eiffelstudio/_images/feature-creaters-icon.png.data b/documentation/18.11/eiffelstudio/_images/feature-creaters-icon.png.data new file mode 100644 index 00000000..d09a5ec3 --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/feature-creaters-icon.png.data @@ -0,0 +1,3 @@ +title=feature-creations-icon +author=halw +path=content/feature-creations-icon diff --git a/documentation/18.11/eiffelstudio/_images/feature-creators-icon.png b/documentation/18.11/eiffelstudio/_images/feature-creators-icon.png new file mode 100644 index 00000000..84e0781f Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/feature-creators-icon.png differ diff --git a/documentation/18.11/eiffelstudio/_images/feature-creators-icon.png.data b/documentation/18.11/eiffelstudio/_images/feature-creators-icon.png.data new file mode 100644 index 00000000..761eefbe --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/feature-creators-icon.png.data @@ -0,0 +1,3 @@ +title=feature-creators-icon +author=admin +path=content/feature-creators-icon diff --git a/documentation/18.11/eiffelstudio/_images/feature-deferred-icon.png b/documentation/18.11/eiffelstudio/_images/feature-deferred-icon.png new file mode 100644 index 00000000..400a94b5 Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/feature-deferred-icon.png differ diff --git a/documentation/18.11/eiffelstudio/_images/feature-deferred-icon.png.data b/documentation/18.11/eiffelstudio/_images/feature-deferred-icon.png.data new file mode 100644 index 00000000..1d1f167f --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/feature-deferred-icon.png.data @@ -0,0 +1,3 @@ +title=feature-deferred-icon +author=admin +path=content/feature-deferred-icon diff --git a/documentation/18.11/eiffelstudio/_images/feature-descendents-icon.png b/documentation/18.11/eiffelstudio/_images/feature-descendents-icon.png new file mode 100644 index 00000000..72fc38a6 Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/feature-descendents-icon.png differ diff --git a/documentation/18.11/eiffelstudio/_images/feature-descendents-icon.png.data b/documentation/18.11/eiffelstudio/_images/feature-descendents-icon.png.data new file mode 100644 index 00000000..4ee66339 --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/feature-descendents-icon.png.data @@ -0,0 +1,3 @@ +title=feature-descendents-icon +author=admin +path=content/feature-descendents-icon diff --git a/documentation/18.11/eiffelstudio/_images/feature-external-icon.png b/documentation/18.11/eiffelstudio/_images/feature-external-icon.png new file mode 100644 index 00000000..31b26e17 Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/feature-external-icon.png differ diff --git a/documentation/18.11/eiffelstudio/_images/feature-external-icon.png.data b/documentation/18.11/eiffelstudio/_images/feature-external-icon.png.data new file mode 100644 index 00000000..08a6b220 --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/feature-external-icon.png.data @@ -0,0 +1,3 @@ +title=feature-external-icon +author=admin +path=content/feature-external-icon diff --git a/documentation/18.11/eiffelstudio/_images/feature-format-bar.png b/documentation/18.11/eiffelstudio/_images/feature-format-bar.png new file mode 100644 index 00000000..7823a97b Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/feature-format-bar.png differ diff --git a/documentation/18.11/eiffelstudio/_images/feature-format-bar.png.data b/documentation/18.11/eiffelstudio/_images/feature-format-bar.png.data new file mode 100644 index 00000000..e6edb1e6 --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/feature-format-bar.png.data @@ -0,0 +1,3 @@ +title=feature-format-bar +author=admin +path=content/feature-format-bar diff --git a/documentation/18.11/eiffelstudio/_images/feature-frozen-routine-icon.png b/documentation/18.11/eiffelstudio/_images/feature-frozen-routine-icon.png new file mode 100644 index 00000000..62fb6bd4 Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/feature-frozen-routine-icon.png differ diff --git a/documentation/18.11/eiffelstudio/_images/feature-frozen-routine-icon.png.data b/documentation/18.11/eiffelstudio/_images/feature-frozen-routine-icon.png.data new file mode 100644 index 00000000..5101decf --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/feature-frozen-routine-icon.png.data @@ -0,0 +1,3 @@ +title=feature-frozen-routine-icon +author=admin +path=content/feature-frozen-routine-icon diff --git a/documentation/18.11/eiffelstudio/_images/feature-homonyms-icon.png b/documentation/18.11/eiffelstudio/_images/feature-homonyms-icon.png new file mode 100644 index 00000000..1aa93098 Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/feature-homonyms-icon.png differ diff --git a/documentation/18.11/eiffelstudio/_images/feature-homonyms-icon.png.data b/documentation/18.11/eiffelstudio/_images/feature-homonyms-icon.png.data new file mode 100644 index 00000000..5f85cb58 --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/feature-homonyms-icon.png.data @@ -0,0 +1,3 @@ +title=feature-homonyms-icon +author=admin +path=content/feature-homonyms-icon diff --git a/documentation/18.11/eiffelstudio/_images/feature-implementers-icon.png b/documentation/18.11/eiffelstudio/_images/feature-implementers-icon.png new file mode 100644 index 00000000..0f9c76c7 Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/feature-implementers-icon.png differ diff --git a/documentation/18.11/eiffelstudio/_images/feature-implementers-icon.png.data b/documentation/18.11/eiffelstudio/_images/feature-implementers-icon.png.data new file mode 100644 index 00000000..b3ce3146 --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/feature-implementers-icon.png.data @@ -0,0 +1,3 @@ +title=feature-implementers-icon +author=admin +path=content/feature-implementers-icon diff --git a/documentation/18.11/eiffelstudio/_images/feature-once-icon.png b/documentation/18.11/eiffelstudio/_images/feature-once-icon.png new file mode 100644 index 00000000..748258f9 Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/feature-once-icon.png differ diff --git a/documentation/18.11/eiffelstudio/_images/feature-once-icon.png.data b/documentation/18.11/eiffelstudio/_images/feature-once-icon.png.data new file mode 100644 index 00000000..3eba596a --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/feature-once-icon.png.data @@ -0,0 +1,3 @@ +title=feature-once-icon +author=admin +path=content/feature-once-icon diff --git a/documentation/18.11/eiffelstudio/_images/feature-routine-icon.png b/documentation/18.11/eiffelstudio/_images/feature-routine-icon.png new file mode 100644 index 00000000..966c9c96 Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/feature-routine-icon.png differ diff --git a/documentation/18.11/eiffelstudio/_images/feature-routine-icon.png.data b/documentation/18.11/eiffelstudio/_images/feature-routine-icon.png.data new file mode 100644 index 00000000..eab74d2c --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/feature-routine-icon.png.data @@ -0,0 +1,3 @@ +title=feature-routine-icon +author=admin +path=content/feature-routine-icon diff --git a/documentation/18.11/eiffelstudio/_images/feature-signatures-icon.png b/documentation/18.11/eiffelstudio/_images/feature-signatures-icon.png new file mode 100644 index 00000000..ffaea53f Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/feature-signatures-icon.png differ diff --git a/documentation/18.11/eiffelstudio/_images/feature-signatures-icon.png.data b/documentation/18.11/eiffelstudio/_images/feature-signatures-icon.png.data new file mode 100644 index 00000000..ea61119c --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/feature-signatures-icon.png.data @@ -0,0 +1,3 @@ +title=feature signatures icon +author=halw +path=content/feature-signatures-icon diff --git a/documentation/18.11/eiffelstudio/_images/feature-tab_0.png b/documentation/18.11/eiffelstudio/_images/feature-tab_0.png new file mode 100644 index 00000000..5e942329 Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/feature-tab_0.png differ diff --git a/documentation/18.11/eiffelstudio/_images/feature-tab_0.png.data b/documentation/18.11/eiffelstudio/_images/feature-tab_0.png.data new file mode 100644 index 00000000..73d00fb2 --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/feature-tab_0.png.data @@ -0,0 +1,3 @@ +title=feature-tab +author=halw +path=content/feature-tab diff --git a/documentation/18.11/eiffelstudio/_images/feature-tool-signature-button.png b/documentation/18.11/eiffelstudio/_images/feature-tool-signature-button.png new file mode 100644 index 00000000..a9e77c36 Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/feature-tool-signature-button.png differ diff --git a/documentation/18.11/eiffelstudio/_images/feature-tool-signature-button.png.data b/documentation/18.11/eiffelstudio/_images/feature-tool-signature-button.png.data new file mode 100644 index 00000000..158f0472 --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/feature-tool-signature-button.png.data @@ -0,0 +1,3 @@ +title=feature-tool-signature-button +author=admin +path=content/feature-tool-signature-button diff --git a/documentation/18.11/eiffelstudio/_images/feature-tool-signature.png b/documentation/18.11/eiffelstudio/_images/feature-tool-signature.png new file mode 100644 index 00000000..045421fe Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/feature-tool-signature.png differ diff --git a/documentation/18.11/eiffelstudio/_images/feature-tool-signature.png.data b/documentation/18.11/eiffelstudio/_images/feature-tool-signature.png.data new file mode 100644 index 00000000..4eb96601 --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/feature-tool-signature.png.data @@ -0,0 +1,3 @@ +title=feature-tool-signature +author=admin +path=content/feature-tool-signature diff --git a/documentation/18.11/eiffelstudio/_images/feature-tool.png b/documentation/18.11/eiffelstudio/_images/feature-tool.png new file mode 100644 index 00000000..603b857c Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/feature-tool.png differ diff --git a/documentation/18.11/eiffelstudio/_images/feature-tool.png.data b/documentation/18.11/eiffelstudio/_images/feature-tool.png.data new file mode 100644 index 00000000..87dc32a3 --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/feature-tool.png.data @@ -0,0 +1,3 @@ +title=feature-tool +author=admin +path=content/feature-tool diff --git a/documentation/18.11/eiffelstudio/_images/feature-tree.png b/documentation/18.11/eiffelstudio/_images/feature-tree.png new file mode 100644 index 00000000..acf4df46 Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/feature-tree.png differ diff --git a/documentation/18.11/eiffelstudio/_images/feature-tree.png.data b/documentation/18.11/eiffelstudio/_images/feature-tree.png.data new file mode 100644 index 00000000..1914a1c4 --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/feature-tree.png.data @@ -0,0 +1,3 @@ +title=feature-tree +author=admin +path=content/feature-tree diff --git a/documentation/18.11/eiffelstudio/_images/feature-wizard-1-argument.png b/documentation/18.11/eiffelstudio/_images/feature-wizard-1-argument.png new file mode 100644 index 00000000..29905ade Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/feature-wizard-1-argument.png differ diff --git a/documentation/18.11/eiffelstudio/_images/feature-wizard-1-argument.png.data b/documentation/18.11/eiffelstudio/_images/feature-wizard-1-argument.png.data new file mode 100644 index 00000000..756dbaf5 --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/feature-wizard-1-argument.png.data @@ -0,0 +1,3 @@ +title=feature-wizard-1-argument +author=admin +path=content/feature-wizard-1-argument diff --git a/documentation/18.11/eiffelstudio/_images/feature-wizard-3-arguments.png b/documentation/18.11/eiffelstudio/_images/feature-wizard-3-arguments.png new file mode 100644 index 00000000..d2ecf6c1 Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/feature-wizard-3-arguments.png differ diff --git a/documentation/18.11/eiffelstudio/_images/feature-wizard-3-arguments.png.data b/documentation/18.11/eiffelstudio/_images/feature-wizard-3-arguments.png.data new file mode 100644 index 00000000..5d7e31c3 --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/feature-wizard-3-arguments.png.data @@ -0,0 +1,3 @@ +title=feature-wizard-3-arguments +author=admin +path=content/feature-wizard-3-arguments diff --git a/documentation/18.11/eiffelstudio/_images/feature-wizard-attribute-example.png b/documentation/18.11/eiffelstudio/_images/feature-wizard-attribute-example.png new file mode 100644 index 00000000..df3508a1 Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/feature-wizard-attribute-example.png differ diff --git a/documentation/18.11/eiffelstudio/_images/feature-wizard-attribute-example.png.data b/documentation/18.11/eiffelstudio/_images/feature-wizard-attribute-example.png.data new file mode 100644 index 00000000..c9379ffb --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/feature-wizard-attribute-example.png.data @@ -0,0 +1,3 @@ +title=feature-wizard-attribute-example +author=admin +path=content/feature-wizard-attribute-example diff --git a/documentation/18.11/eiffelstudio/_images/feature-wizard-attribute.png b/documentation/18.11/eiffelstudio/_images/feature-wizard-attribute.png new file mode 100644 index 00000000..7363fc7b Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/feature-wizard-attribute.png differ diff --git a/documentation/18.11/eiffelstudio/_images/feature-wizard-attribute.png.data b/documentation/18.11/eiffelstudio/_images/feature-wizard-attribute.png.data new file mode 100644 index 00000000..5cfe9d5c --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/feature-wizard-attribute.png.data @@ -0,0 +1,3 @@ +title=feature-wizard-attribute +author=admin +path=content/feature-wizard-attribute diff --git a/documentation/18.11/eiffelstudio/_images/feature-wizard-clausenames.png b/documentation/18.11/eiffelstudio/_images/feature-wizard-clausenames.png new file mode 100644 index 00000000..306ba0ee Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/feature-wizard-clausenames.png differ diff --git a/documentation/18.11/eiffelstudio/_images/feature-wizard-clausenames.png.data b/documentation/18.11/eiffelstudio/_images/feature-wizard-clausenames.png.data new file mode 100644 index 00000000..124688e3 --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/feature-wizard-clausenames.png.data @@ -0,0 +1,3 @@ +title=feature-wizard-clausenames +author=admin +path=content/feature-wizard-clausenames diff --git a/documentation/18.11/eiffelstudio/_images/feature-wizard-comment.png b/documentation/18.11/eiffelstudio/_images/feature-wizard-comment.png new file mode 100644 index 00000000..fffd3b24 Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/feature-wizard-comment.png differ diff --git a/documentation/18.11/eiffelstudio/_images/feature-wizard-comment.png.data b/documentation/18.11/eiffelstudio/_images/feature-wizard-comment.png.data new file mode 100644 index 00000000..bb66bcc6 --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/feature-wizard-comment.png.data @@ -0,0 +1,3 @@ +title=feature-wizard-comment +author=admin +path=content/feature-wizard-comment diff --git a/documentation/18.11/eiffelstudio/_images/feature-wizard-complextype.png b/documentation/18.11/eiffelstudio/_images/feature-wizard-complextype.png new file mode 100644 index 00000000..11b35e1f Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/feature-wizard-complextype.png differ diff --git a/documentation/18.11/eiffelstudio/_images/feature-wizard-complextype.png.data b/documentation/18.11/eiffelstudio/_images/feature-wizard-complextype.png.data new file mode 100644 index 00000000..0cd63d8c --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/feature-wizard-complextype.png.data @@ -0,0 +1,3 @@ +title=feature-wizard-complextype +author=admin +path=content/feature-wizard-complextype diff --git a/documentation/18.11/eiffelstudio/_images/feature-wizard-export.png b/documentation/18.11/eiffelstudio/_images/feature-wizard-export.png new file mode 100644 index 00000000..8349c8bf Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/feature-wizard-export.png differ diff --git a/documentation/18.11/eiffelstudio/_images/feature-wizard-export.png.data b/documentation/18.11/eiffelstudio/_images/feature-wizard-export.png.data new file mode 100644 index 00000000..2aec7341 --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/feature-wizard-export.png.data @@ -0,0 +1,3 @@ +title=feature-wizard-export +author=admin +path=content/feature-wizard-export diff --git a/documentation/18.11/eiffelstudio/_images/feature-wizard-function-example.png b/documentation/18.11/eiffelstudio/_images/feature-wizard-function-example.png new file mode 100644 index 00000000..2da833e3 Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/feature-wizard-function-example.png differ diff --git a/documentation/18.11/eiffelstudio/_images/feature-wizard-function-example.png.data b/documentation/18.11/eiffelstudio/_images/feature-wizard-function-example.png.data new file mode 100644 index 00000000..4dddb826 --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/feature-wizard-function-example.png.data @@ -0,0 +1,3 @@ +title=feature-wizard-function-example +author=admin +path=content/feature-wizard-function-example diff --git a/documentation/18.11/eiffelstudio/_images/feature-wizard-function.png b/documentation/18.11/eiffelstudio/_images/feature-wizard-function.png new file mode 100644 index 00000000..64d8a685 Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/feature-wizard-function.png differ diff --git a/documentation/18.11/eiffelstudio/_images/feature-wizard-function.png.data b/documentation/18.11/eiffelstudio/_images/feature-wizard-function.png.data new file mode 100644 index 00000000..5c4ef629 --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/feature-wizard-function.png.data @@ -0,0 +1,3 @@ +title=feature-wizard-function +author=admin +path=content/feature-wizard-function diff --git a/documentation/18.11/eiffelstudio/_images/feature-wizard-generictype.png b/documentation/18.11/eiffelstudio/_images/feature-wizard-generictype.png new file mode 100644 index 00000000..df5ff938 Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/feature-wizard-generictype.png differ diff --git a/documentation/18.11/eiffelstudio/_images/feature-wizard-generictype.png.data b/documentation/18.11/eiffelstudio/_images/feature-wizard-generictype.png.data new file mode 100644 index 00000000..67f5d5f3 --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/feature-wizard-generictype.png.data @@ -0,0 +1,3 @@ +title=feature-wizard-generictype +author=admin +path=content/feature-wizard-generictype diff --git a/documentation/18.11/eiffelstudio/_images/feature-wizard-generictyperec.png b/documentation/18.11/eiffelstudio/_images/feature-wizard-generictyperec.png new file mode 100644 index 00000000..70ea00a5 Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/feature-wizard-generictyperec.png differ diff --git a/documentation/18.11/eiffelstudio/_images/feature-wizard-generictyperec.png.data b/documentation/18.11/eiffelstudio/_images/feature-wizard-generictyperec.png.data new file mode 100644 index 00000000..56fa1bba --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/feature-wizard-generictyperec.png.data @@ -0,0 +1,3 @@ +title=feature-wizard-generictyperec +author=admin +path=content/feature-wizard-generictyperec diff --git a/documentation/18.11/eiffelstudio/_images/feature-wizard-invariant-selected.png b/documentation/18.11/eiffelstudio/_images/feature-wizard-invariant-selected.png new file mode 100644 index 00000000..58e62577 Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/feature-wizard-invariant-selected.png differ diff --git a/documentation/18.11/eiffelstudio/_images/feature-wizard-invariant-selected.png.data b/documentation/18.11/eiffelstudio/_images/feature-wizard-invariant-selected.png.data new file mode 100644 index 00000000..b9b5f17c --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/feature-wizard-invariant-selected.png.data @@ -0,0 +1,3 @@ +title=feature-wizard-invariant-selected +author=admin +path=content/feature-wizard-invariant-selected diff --git a/documentation/18.11/eiffelstudio/_images/feature-wizard-invariant.png b/documentation/18.11/eiffelstudio/_images/feature-wizard-invariant.png new file mode 100644 index 00000000..02723887 Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/feature-wizard-invariant.png differ diff --git a/documentation/18.11/eiffelstudio/_images/feature-wizard-invariant.png.data b/documentation/18.11/eiffelstudio/_images/feature-wizard-invariant.png.data new file mode 100644 index 00000000..0aa0db74 --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/feature-wizard-invariant.png.data @@ -0,0 +1,3 @@ +title=feature-wizard-invariant +author=admin +path=content/feature-wizard-invariant diff --git a/documentation/18.11/eiffelstudio/_images/feature-wizard-procedure-example.png b/documentation/18.11/eiffelstudio/_images/feature-wizard-procedure-example.png new file mode 100644 index 00000000..010822c7 Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/feature-wizard-procedure-example.png differ diff --git a/documentation/18.11/eiffelstudio/_images/feature-wizard-procedure-example.png.data b/documentation/18.11/eiffelstudio/_images/feature-wizard-procedure-example.png.data new file mode 100644 index 00000000..77a1e118 --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/feature-wizard-procedure-example.png.data @@ -0,0 +1,3 @@ +title=feature-wizard-procedure-example +author=admin +path=content/feature-wizard-procedure-example diff --git a/documentation/18.11/eiffelstudio/_images/feature-wizard-procedure.png b/documentation/18.11/eiffelstudio/_images/feature-wizard-procedure.png new file mode 100644 index 00000000..de43fad8 Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/feature-wizard-procedure.png differ diff --git a/documentation/18.11/eiffelstudio/_images/feature-wizard-procedure.png.data b/documentation/18.11/eiffelstudio/_images/feature-wizard-procedure.png.data new file mode 100644 index 00000000..58ef1574 --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/feature-wizard-procedure.png.data @@ -0,0 +1,3 @@ +title=feature-wizard-procedure +author=admin +path=content/feature-wizard-procedure diff --git a/documentation/18.11/eiffelstudio/_images/feature-wizard-setprocedure-example.png b/documentation/18.11/eiffelstudio/_images/feature-wizard-setprocedure-example.png new file mode 100644 index 00000000..165b1e86 Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/feature-wizard-setprocedure-example.png differ diff --git a/documentation/18.11/eiffelstudio/_images/feature-wizard-setprocedure-example.png.data b/documentation/18.11/eiffelstudio/_images/feature-wizard-setprocedure-example.png.data new file mode 100644 index 00000000..ba29ae5e --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/feature-wizard-setprocedure-example.png.data @@ -0,0 +1,3 @@ +title=feature-wizard-setprocedure-example +author=admin +path=content/feature-wizard-setprocedure-example diff --git a/documentation/18.11/eiffelstudio/_images/feature-wizard-setprocedure.png b/documentation/18.11/eiffelstudio/_images/feature-wizard-setprocedure.png new file mode 100644 index 00000000..37cedd89 Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/feature-wizard-setprocedure.png differ diff --git a/documentation/18.11/eiffelstudio/_images/feature-wizard-setprocedure.png.data b/documentation/18.11/eiffelstudio/_images/feature-wizard-setprocedure.png.data new file mode 100644 index 00000000..16a3ccea --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/feature-wizard-setprocedure.png.data @@ -0,0 +1,3 @@ +title=feature-wizard-setprocedure +author=admin +path=content/feature-wizard-setprocedure diff --git a/documentation/18.11/eiffelstudio/_images/feature-wizard-tupletype2.png b/documentation/18.11/eiffelstudio/_images/feature-wizard-tupletype2.png new file mode 100644 index 00000000..de9722c8 Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/feature-wizard-tupletype2.png differ diff --git a/documentation/18.11/eiffelstudio/_images/feature-wizard-tupletype2.png.data b/documentation/18.11/eiffelstudio/_images/feature-wizard-tupletype2.png.data new file mode 100644 index 00000000..a81d1b22 --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/feature-wizard-tupletype2.png.data @@ -0,0 +1,3 @@ +title=feature-wizard-tupletype2 +author=admin +path=content/feature-wizard-tupletype2 diff --git a/documentation/18.11/eiffelstudio/_images/feature-wizard-typeselection.png b/documentation/18.11/eiffelstudio/_images/feature-wizard-typeselection.png new file mode 100644 index 00000000..66707440 Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/feature-wizard-typeselection.png differ diff --git a/documentation/18.11/eiffelstudio/_images/feature-wizard-typeselection.png.data b/documentation/18.11/eiffelstudio/_images/feature-wizard-typeselection.png.data new file mode 100644 index 00000000..93855d35 --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/feature-wizard-typeselection.png.data @@ -0,0 +1,3 @@ +title=feature-wizard-typeselection +author=admin +path=content/feature-wizard-typeselection diff --git a/documentation/18.11/eiffelstudio/_images/feature-wizard.png b/documentation/18.11/eiffelstudio/_images/feature-wizard.png new file mode 100644 index 00000000..17b80399 Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/feature-wizard.png differ diff --git a/documentation/18.11/eiffelstudio/_images/feature-wizard.png.data b/documentation/18.11/eiffelstudio/_images/feature-wizard.png.data new file mode 100644 index 00000000..21e23500 --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/feature-wizard.png.data @@ -0,0 +1,3 @@ +title=feature-wizard +author=admin +path=content/feature-wizard diff --git a/documentation/18.11/eiffelstudio/_images/feature_call_auto-complete_example_1.png b/documentation/18.11/eiffelstudio/_images/feature_call_auto-complete_example_1.png new file mode 100644 index 00000000..b79f57c0 Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/feature_call_auto-complete_example_1.png differ diff --git a/documentation/18.11/eiffelstudio/_images/feature_call_auto-complete_example_1.png.data b/documentation/18.11/eiffelstudio/_images/feature_call_auto-complete_example_1.png.data new file mode 100644 index 00000000..bce1e88d --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/feature_call_auto-complete_example_1.png.data @@ -0,0 +1,3 @@ +title=feature call auto complete example 1 +author=halw +path=content/feature-call-auto-complete-example-1 diff --git a/documentation/18.11/eiffelstudio/_images/features-tab-icon.png b/documentation/18.11/eiffelstudio/_images/features-tab-icon.png new file mode 100644 index 00000000..d39b5dda Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/features-tab-icon.png differ diff --git a/documentation/18.11/eiffelstudio/_images/features-tab-icon.png.data b/documentation/18.11/eiffelstudio/_images/features-tab-icon.png.data new file mode 100644 index 00000000..a9dfe7e2 --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/features-tab-icon.png.data @@ -0,0 +1,3 @@ +title=features-tab +author=halw +path=content/features-tab diff --git a/documentation/18.11/eiffelstudio/_images/filter-active.png b/documentation/18.11/eiffelstudio/_images/filter-active.png new file mode 100644 index 00000000..315e9201 Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/filter-active.png differ diff --git a/documentation/18.11/eiffelstudio/_images/filter-active.png.data b/documentation/18.11/eiffelstudio/_images/filter-active.png.data new file mode 100644 index 00000000..98fb33d9 --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/filter-active.png.data @@ -0,0 +1,3 @@ +title=filter-active +author=admin +path=content/filter-active diff --git a/documentation/18.11/eiffelstudio/_images/filter.png b/documentation/18.11/eiffelstudio/_images/filter.png new file mode 100644 index 00000000..aed10c99 Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/filter.png differ diff --git a/documentation/18.11/eiffelstudio/_images/filter.png.data b/documentation/18.11/eiffelstudio/_images/filter.png.data new file mode 100644 index 00000000..70af0f2d --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/filter.png.data @@ -0,0 +1,3 @@ +title=filter +author=admin +path=content/filter diff --git a/documentation/18.11/eiffelstudio/_images/folder-assembly-icon.png b/documentation/18.11/eiffelstudio/_images/folder-assembly-icon.png new file mode 100644 index 00000000..3793b09e Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/folder-assembly-icon.png differ diff --git a/documentation/18.11/eiffelstudio/_images/folder-assembly-icon.png.data b/documentation/18.11/eiffelstudio/_images/folder-assembly-icon.png.data new file mode 100644 index 00000000..784c5a26 --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/folder-assembly-icon.png.data @@ -0,0 +1,3 @@ +title=folder-assembly-icon +author=admin +path=content/folder-assembly-icon diff --git a/documentation/18.11/eiffelstudio/_images/folder-blank-icon.png b/documentation/18.11/eiffelstudio/_images/folder-blank-icon.png new file mode 100644 index 00000000..6c64b73b Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/folder-blank-icon.png differ diff --git a/documentation/18.11/eiffelstudio/_images/folder-blank-icon.png.data b/documentation/18.11/eiffelstudio/_images/folder-blank-icon.png.data new file mode 100644 index 00000000..cb0f4708 --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/folder-blank-icon.png.data @@ -0,0 +1,3 @@ +title=folder-blank-icon +author=admin +path=content/folder-blank-icon diff --git a/documentation/18.11/eiffelstudio/_images/folder-cluster-icon.png b/documentation/18.11/eiffelstudio/_images/folder-cluster-icon.png new file mode 100644 index 00000000..03d4a06b Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/folder-cluster-icon.png differ diff --git a/documentation/18.11/eiffelstudio/_images/folder-cluster-icon.png.data b/documentation/18.11/eiffelstudio/_images/folder-cluster-icon.png.data new file mode 100644 index 00000000..5b6558fb --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/folder-cluster-icon.png.data @@ -0,0 +1,3 @@ +title=folder-cluster-icon +author=admin +path=content/folder-cluster-icon diff --git a/documentation/18.11/eiffelstudio/_images/folder-cluster-readonly-icon.png b/documentation/18.11/eiffelstudio/_images/folder-cluster-readonly-icon.png new file mode 100644 index 00000000..6a339c4b Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/folder-cluster-readonly-icon.png differ diff --git a/documentation/18.11/eiffelstudio/_images/folder-cluster-readonly-icon.png.data b/documentation/18.11/eiffelstudio/_images/folder-cluster-readonly-icon.png.data new file mode 100644 index 00000000..3e4e1dcf --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/folder-cluster-readonly-icon.png.data @@ -0,0 +1,3 @@ +title=folder-cluster-readonly-icon +author=admin +path=content/folder-cluster-readonly-icon diff --git a/documentation/18.11/eiffelstudio/_images/folder-features-all-icon.png b/documentation/18.11/eiffelstudio/_images/folder-features-all-icon.png new file mode 100644 index 00000000..cb54a51d Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/folder-features-all-icon.png differ diff --git a/documentation/18.11/eiffelstudio/_images/folder-features-all-icon.png.data b/documentation/18.11/eiffelstudio/_images/folder-features-all-icon.png.data new file mode 100644 index 00000000..5b2fd3d7 --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/folder-features-all-icon.png.data @@ -0,0 +1,3 @@ +title=folder-features-all-icon +author=admin +path=content/folder-features-all-icon diff --git a/documentation/18.11/eiffelstudio/_images/folder-features-none-icon.png b/documentation/18.11/eiffelstudio/_images/folder-features-none-icon.png new file mode 100644 index 00000000..d4cc1f9a Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/folder-features-none-icon.png differ diff --git a/documentation/18.11/eiffelstudio/_images/folder-features-none-icon.png.data b/documentation/18.11/eiffelstudio/_images/folder-features-none-icon.png.data new file mode 100644 index 00000000..ffbd7a14 --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/folder-features-none-icon.png.data @@ -0,0 +1,3 @@ +title=folder-features-none-icon +author=admin +path=content/folder-features-none-icon diff --git a/documentation/18.11/eiffelstudio/_images/folder-features-some-icon.png b/documentation/18.11/eiffelstudio/_images/folder-features-some-icon.png new file mode 100644 index 00000000..e14effa8 Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/folder-features-some-icon.png differ diff --git a/documentation/18.11/eiffelstudio/_images/folder-features-some-icon.png.data b/documentation/18.11/eiffelstudio/_images/folder-features-some-icon.png.data new file mode 100644 index 00000000..58629b89 --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/folder-features-some-icon.png.data @@ -0,0 +1,3 @@ +title=folder-features-some-icon +author=admin +path=content/folder-features-some-icon diff --git a/documentation/18.11/eiffelstudio/_images/folder-hidden-cluster-icon.png b/documentation/18.11/eiffelstudio/_images/folder-hidden-cluster-icon.png new file mode 100644 index 00000000..cba561a0 Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/folder-hidden-cluster-icon.png differ diff --git a/documentation/18.11/eiffelstudio/_images/folder-hidden-cluster-icon.png.data b/documentation/18.11/eiffelstudio/_images/folder-hidden-cluster-icon.png.data new file mode 100644 index 00000000..f34ea101 --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/folder-hidden-cluster-icon.png.data @@ -0,0 +1,3 @@ +title=folder-hidden-cluster-icon +author=admin +path=content/folder-hidden-cluster-icon diff --git a/documentation/18.11/eiffelstudio/_images/folder-library-icon.png b/documentation/18.11/eiffelstudio/_images/folder-library-icon.png new file mode 100644 index 00000000..9cc3f552 Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/folder-library-icon.png differ diff --git a/documentation/18.11/eiffelstudio/_images/folder-library-icon.png.data b/documentation/18.11/eiffelstudio/_images/folder-library-icon.png.data new file mode 100644 index 00000000..08ae32c6 --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/folder-library-icon.png.data @@ -0,0 +1,3 @@ +title=folder-library-icon +author=admin +path=content/folder-library-icon diff --git a/documentation/18.11/eiffelstudio/_images/folder-namespace-icon.png b/documentation/18.11/eiffelstudio/_images/folder-namespace-icon.png new file mode 100644 index 00000000..f88368d6 Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/folder-namespace-icon.png differ diff --git a/documentation/18.11/eiffelstudio/_images/folder-namespace-icon.png.data b/documentation/18.11/eiffelstudio/_images/folder-namespace-icon.png.data new file mode 100644 index 00000000..08eb7100 --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/folder-namespace-icon.png.data @@ -0,0 +1,3 @@ +title=folder-namespace-icon +author=admin +path=content/folder-namespace-icon diff --git a/documentation/18.11/eiffelstudio/_images/folder-override-cluster-icon.png b/documentation/18.11/eiffelstudio/_images/folder-override-cluster-icon.png new file mode 100644 index 00000000..cbb5f5e8 Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/folder-override-cluster-icon.png differ diff --git a/documentation/18.11/eiffelstudio/_images/folder-override-cluster-icon.png.data b/documentation/18.11/eiffelstudio/_images/folder-override-cluster-icon.png.data new file mode 100644 index 00000000..a88555d1 --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/folder-override-cluster-icon.png.data @@ -0,0 +1,3 @@ +title=folder-override-cluster-icon +author=admin +path=content/folder-override-cluster-icon diff --git a/documentation/18.11/eiffelstudio/_images/folder-target-icon.png b/documentation/18.11/eiffelstudio/_images/folder-target-icon.png new file mode 100644 index 00000000..6f565f8b Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/folder-target-icon.png differ diff --git a/documentation/18.11/eiffelstudio/_images/folder-target-icon.png.data b/documentation/18.11/eiffelstudio/_images/folder-target-icon.png.data new file mode 100644 index 00000000..b62be2de --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/folder-target-icon.png.data @@ -0,0 +1,3 @@ +title=folder-target-icon +author=admin +path=content/folder-target-icon diff --git a/documentation/18.11/eiffelstudio/_images/general-copy-icon.png b/documentation/18.11/eiffelstudio/_images/general-copy-icon.png new file mode 100644 index 00000000..13cd4b7a Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/general-copy-icon.png differ diff --git a/documentation/18.11/eiffelstudio/_images/general-copy-icon.png.data b/documentation/18.11/eiffelstudio/_images/general-copy-icon.png.data new file mode 100644 index 00000000..0a086e44 --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/general-copy-icon.png.data @@ -0,0 +1,3 @@ +title=general-copy-icon +author=admin +path=content/general-copy-icon diff --git a/documentation/18.11/eiffelstudio/_images/general-cut-icon.png b/documentation/18.11/eiffelstudio/_images/general-cut-icon.png new file mode 100644 index 00000000..541562df Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/general-cut-icon.png differ diff --git a/documentation/18.11/eiffelstudio/_images/general-cut-icon.png.data b/documentation/18.11/eiffelstudio/_images/general-cut-icon.png.data new file mode 100644 index 00000000..9bb11ddc --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/general-cut-icon.png.data @@ -0,0 +1,3 @@ +title=general-cut-icon +author=admin +path=content/general-cut-icon diff --git a/documentation/18.11/eiffelstudio/_images/general-debug-mode.png b/documentation/18.11/eiffelstudio/_images/general-debug-mode.png new file mode 100644 index 00000000..034cdef5 Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/general-debug-mode.png differ diff --git a/documentation/18.11/eiffelstudio/_images/general-debug-mode.png.data b/documentation/18.11/eiffelstudio/_images/general-debug-mode.png.data new file mode 100644 index 00000000..a8b33bc8 --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/general-debug-mode.png.data @@ -0,0 +1,3 @@ +title=general-debug-mode +author=admin +path=content/general-debug-mode diff --git a/documentation/18.11/eiffelstudio/_images/general-delete-icon.png b/documentation/18.11/eiffelstudio/_images/general-delete-icon.png new file mode 100644 index 00000000..76f179e0 Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/general-delete-icon.png differ diff --git a/documentation/18.11/eiffelstudio/_images/general-delete-icon.png.data b/documentation/18.11/eiffelstudio/_images/general-delete-icon.png.data new file mode 100644 index 00000000..b68850b8 --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/general-delete-icon.png.data @@ -0,0 +1,3 @@ +title=general-delete-icon +author=admin +path=content/general-delete-icon diff --git a/documentation/18.11/eiffelstudio/_images/general-edit-icon.png b/documentation/18.11/eiffelstudio/_images/general-edit-icon.png new file mode 100644 index 00000000..661b2c20 Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/general-edit-icon.png differ diff --git a/documentation/18.11/eiffelstudio/_images/general-edit-icon.png.data b/documentation/18.11/eiffelstudio/_images/general-edit-icon.png.data new file mode 100644 index 00000000..8b985e4a --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/general-edit-icon.png.data @@ -0,0 +1,3 @@ +title=general-edit-icon +author=admin +path=content/general-edit-icon diff --git a/documentation/18.11/eiffelstudio/_images/general-edition-mode.png b/documentation/18.11/eiffelstudio/_images/general-edition-mode.png new file mode 100644 index 00000000..d31763ec Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/general-edition-mode.png differ diff --git a/documentation/18.11/eiffelstudio/_images/general-edition-mode.png.data b/documentation/18.11/eiffelstudio/_images/general-edition-mode.png.data new file mode 100644 index 00000000..bc65b530 --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/general-edition-mode.png.data @@ -0,0 +1,3 @@ +title=general-edition-mode +author=admin +path=content/general-edition-mode diff --git a/documentation/18.11/eiffelstudio/_images/general-error-icon.png b/documentation/18.11/eiffelstudio/_images/general-error-icon.png new file mode 100644 index 00000000..92faae99 Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/general-error-icon.png differ diff --git a/documentation/18.11/eiffelstudio/_images/general-error-icon.png.data b/documentation/18.11/eiffelstudio/_images/general-error-icon.png.data new file mode 100644 index 00000000..dc5d1946 --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/general-error-icon.png.data @@ -0,0 +1,3 @@ +title=general-error-icon +author=admin +path=content/general-error-icon diff --git a/documentation/18.11/eiffelstudio/_images/general-open-icon.png b/documentation/18.11/eiffelstudio/_images/general-open-icon.png new file mode 100644 index 00000000..df37ed22 Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/general-open-icon.png differ diff --git a/documentation/18.11/eiffelstudio/_images/general-open-icon.png.data b/documentation/18.11/eiffelstudio/_images/general-open-icon.png.data new file mode 100644 index 00000000..f6d9bb26 --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/general-open-icon.png.data @@ -0,0 +1,3 @@ +title=general-open-icon +author=admin +path=content/general-open-icon diff --git a/documentation/18.11/eiffelstudio/_images/general-paste-icon.png b/documentation/18.11/eiffelstudio/_images/general-paste-icon.png new file mode 100644 index 00000000..bf047fe7 Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/general-paste-icon.png differ diff --git a/documentation/18.11/eiffelstudio/_images/general-paste-icon.png.data b/documentation/18.11/eiffelstudio/_images/general-paste-icon.png.data new file mode 100644 index 00000000..b9c51e26 --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/general-paste-icon.png.data @@ -0,0 +1,3 @@ +title=general-paste-icon +author=admin +path=content/general-paste-icon diff --git a/documentation/18.11/eiffelstudio/_images/general-redo-icon.png b/documentation/18.11/eiffelstudio/_images/general-redo-icon.png new file mode 100644 index 00000000..8631cce4 Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/general-redo-icon.png differ diff --git a/documentation/18.11/eiffelstudio/_images/general-redo-icon.png.data b/documentation/18.11/eiffelstudio/_images/general-redo-icon.png.data new file mode 100644 index 00000000..8ecd8750 --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/general-redo-icon.png.data @@ -0,0 +1,3 @@ +title=general-redo-icon +author=admin +path=content/general-redo-icon diff --git a/documentation/18.11/eiffelstudio/_images/general-reset-icon.png b/documentation/18.11/eiffelstudio/_images/general-reset-icon.png new file mode 100644 index 00000000..8ebc3e87 Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/general-reset-icon.png differ diff --git a/documentation/18.11/eiffelstudio/_images/general-reset-icon.png.data b/documentation/18.11/eiffelstudio/_images/general-reset-icon.png.data new file mode 100644 index 00000000..3746248a --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/general-reset-icon.png.data @@ -0,0 +1,3 @@ +title=general-reset-icon +author=admin +path=content/general-reset-icon diff --git a/documentation/18.11/eiffelstudio/_images/general-save-icon.png b/documentation/18.11/eiffelstudio/_images/general-save-icon.png new file mode 100644 index 00000000..49e231b5 Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/general-save-icon.png differ diff --git a/documentation/18.11/eiffelstudio/_images/general-save-icon.png.data b/documentation/18.11/eiffelstudio/_images/general-save-icon.png.data new file mode 100644 index 00000000..01af72ba --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/general-save-icon.png.data @@ -0,0 +1,3 @@ +title=general-save-icon +author=admin +path=content/general-save-icon diff --git a/documentation/18.11/eiffelstudio/_images/general-search-icon.png b/documentation/18.11/eiffelstudio/_images/general-search-icon.png new file mode 100644 index 00000000..e2b072a8 Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/general-search-icon.png differ diff --git a/documentation/18.11/eiffelstudio/_images/general-search-icon.png.data b/documentation/18.11/eiffelstudio/_images/general-search-icon.png.data new file mode 100644 index 00000000..9aab3b05 --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/general-search-icon.png.data @@ -0,0 +1,3 @@ +title=general-search-icon +author=admin +path=content/general-search-icon diff --git a/documentation/18.11/eiffelstudio/_images/general-tick-icon.png b/documentation/18.11/eiffelstudio/_images/general-tick-icon.png new file mode 100644 index 00000000..a7665664 Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/general-tick-icon.png differ diff --git a/documentation/18.11/eiffelstudio/_images/general-tick-icon.png.data b/documentation/18.11/eiffelstudio/_images/general-tick-icon.png.data new file mode 100644 index 00000000..54cefcd0 --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/general-tick-icon.png.data @@ -0,0 +1,3 @@ +title=general-tick-icon +author=admin +path=content/general-tick-icon diff --git a/documentation/18.11/eiffelstudio/_images/general-toogle-icon.png b/documentation/18.11/eiffelstudio/_images/general-toogle-icon.png new file mode 100644 index 00000000..14d4e15d Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/general-toogle-icon.png differ diff --git a/documentation/18.11/eiffelstudio/_images/general-toogle-icon.png.data b/documentation/18.11/eiffelstudio/_images/general-toogle-icon.png.data new file mode 100644 index 00000000..1149b6d1 --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/general-toogle-icon.png.data @@ -0,0 +1,3 @@ +title=general-toogle-icon +author=admin +path=content/general-toogle-icon diff --git a/documentation/18.11/eiffelstudio/_images/general-undo-history-icon.png b/documentation/18.11/eiffelstudio/_images/general-undo-history-icon.png new file mode 100644 index 00000000..7923d165 Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/general-undo-history-icon.png differ diff --git a/documentation/18.11/eiffelstudio/_images/general-undo-history-icon.png.data b/documentation/18.11/eiffelstudio/_images/general-undo-history-icon.png.data new file mode 100644 index 00000000..4d9f13b8 --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/general-undo-history-icon.png.data @@ -0,0 +1,3 @@ +title=general-undo-history-icon +author=admin +path=content/general-undo-history-icon diff --git a/documentation/18.11/eiffelstudio/_images/general-undo-icon.png b/documentation/18.11/eiffelstudio/_images/general-undo-icon.png new file mode 100644 index 00000000..373a8ed4 Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/general-undo-icon.png differ diff --git a/documentation/18.11/eiffelstudio/_images/general-undo-icon.png.data b/documentation/18.11/eiffelstudio/_images/general-undo-icon.png.data new file mode 100644 index 00000000..96d3ed92 --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/general-undo-icon.png.data @@ -0,0 +1,3 @@ +title=general-undo-icon +author=admin +path=content/general-undo-icon diff --git a/documentation/18.11/eiffelstudio/_images/general-word-wrap-icon.png b/documentation/18.11/eiffelstudio/_images/general-word-wrap-icon.png new file mode 100644 index 00000000..1e0237f9 Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/general-word-wrap-icon.png differ diff --git a/documentation/18.11/eiffelstudio/_images/general-word-wrap-icon.png.data b/documentation/18.11/eiffelstudio/_images/general-word-wrap-icon.png.data new file mode 100644 index 00000000..215c5af9 --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/general-word-wrap-icon.png.data @@ -0,0 +1,3 @@ +title=general-word-wrap-icon +author=admin +path=content/general-word-wrap-icon diff --git a/documentation/18.11/eiffelstudio/_images/groups-tool_1.png b/documentation/18.11/eiffelstudio/_images/groups-tool_1.png new file mode 100644 index 00000000..3f8a7d07 Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/groups-tool_1.png differ diff --git a/documentation/18.11/eiffelstudio/_images/groups-tool_1.png.data b/documentation/18.11/eiffelstudio/_images/groups-tool_1.png.data new file mode 100644 index 00000000..9030165e --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/groups-tool_1.png.data @@ -0,0 +1,3 @@ +title=groups-tool +author=halw +path=content/groups-tool diff --git a/documentation/18.11/eiffelstudio/_images/hide-non-matching-entries-icon.png b/documentation/18.11/eiffelstudio/_images/hide-non-matching-entries-icon.png new file mode 100644 index 00000000..953835a7 Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/hide-non-matching-entries-icon.png differ diff --git a/documentation/18.11/eiffelstudio/_images/hide-non-matching-entries-icon.png.data b/documentation/18.11/eiffelstudio/_images/hide-non-matching-entries-icon.png.data new file mode 100644 index 00000000..77296650 --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/hide-non-matching-entries-icon.png.data @@ -0,0 +1,3 @@ +title=hide non-matching entries icon +author=halw +path=content/hide-non-matching-entries-icon diff --git a/documentation/18.11/eiffelstudio/_images/history-tool.png b/documentation/18.11/eiffelstudio/_images/history-tool.png new file mode 100644 index 00000000..b656c44c Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/history-tool.png differ diff --git a/documentation/18.11/eiffelstudio/_images/history-tool.png.data b/documentation/18.11/eiffelstudio/_images/history-tool.png.data new file mode 100644 index 00000000..df4d8c2c --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/history-tool.png.data @@ -0,0 +1,3 @@ +title=history-tool +author=admin +path=content/history-tool diff --git a/documentation/18.11/eiffelstudio/_images/hood1.png b/documentation/18.11/eiffelstudio/_images/hood1.png new file mode 100644 index 00000000..a9fcedcb Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/hood1.png differ diff --git a/documentation/18.11/eiffelstudio/_images/hood1.png.data b/documentation/18.11/eiffelstudio/_images/hood1.png.data new file mode 100644 index 00000000..113f95b7 --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/hood1.png.data @@ -0,0 +1,3 @@ +title=hood1 +author=admin +path=content/hood1 diff --git a/documentation/18.11/eiffelstudio/_images/hood2.png b/documentation/18.11/eiffelstudio/_images/hood2.png new file mode 100644 index 00000000..a022a90b Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/hood2.png differ diff --git a/documentation/18.11/eiffelstudio/_images/hood2.png.data b/documentation/18.11/eiffelstudio/_images/hood2.png.data new file mode 100644 index 00000000..45f80108 --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/hood2.png.data @@ -0,0 +1,3 @@ +title=hood2 +author=admin +path=content/hood2 diff --git a/documentation/18.11/eiffelstudio/_images/hood3.jpg b/documentation/18.11/eiffelstudio/_images/hood3.jpg new file mode 100644 index 00000000..78cc1c6e Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/hood3.jpg differ diff --git a/documentation/18.11/eiffelstudio/_images/hood3.jpg.data b/documentation/18.11/eiffelstudio/_images/hood3.jpg.data new file mode 100644 index 00000000..d8f4cbd5 --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/hood3.jpg.data @@ -0,0 +1,3 @@ +title=hood3 +author=admin +path=content/hood3 diff --git a/documentation/18.11/eiffelstudio/_images/ildasm-dotnet-naming.png b/documentation/18.11/eiffelstudio/_images/ildasm-dotnet-naming.png new file mode 100644 index 00000000..8fe0d173 Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/ildasm-dotnet-naming.png differ diff --git a/documentation/18.11/eiffelstudio/_images/ildasm-dotnet-naming.png.data b/documentation/18.11/eiffelstudio/_images/ildasm-dotnet-naming.png.data new file mode 100644 index 00000000..ac687fd5 --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/ildasm-dotnet-naming.png.data @@ -0,0 +1,3 @@ +title=ildasm-dotnet-naming +author=admin +path=content/ildasm-dotnet-naming diff --git a/documentation/18.11/eiffelstudio/_images/ildasm-no-dotnet-naming.png b/documentation/18.11/eiffelstudio/_images/ildasm-no-dotnet-naming.png new file mode 100644 index 00000000..93533168 Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/ildasm-no-dotnet-naming.png differ diff --git a/documentation/18.11/eiffelstudio/_images/ildasm-no-dotnet-naming.png.data b/documentation/18.11/eiffelstudio/_images/ildasm-no-dotnet-naming.png.data new file mode 100644 index 00000000..0f474a53 --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/ildasm-no-dotnet-naming.png.data @@ -0,0 +1,3 @@ +title=ildasm-no-dotnet-naming +author=admin +path=content/ildasm-no-dotnet-naming diff --git a/documentation/18.11/eiffelstudio/_images/index-140.png b/documentation/18.11/eiffelstudio/_images/index-140.png new file mode 100644 index 00000000..0867d157 Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/index-140.png differ diff --git a/documentation/18.11/eiffelstudio/_images/index-140.png.data b/documentation/18.11/eiffelstudio/_images/index-140.png.data new file mode 100644 index 00000000..9f819877 --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/index-140.png.data @@ -0,0 +1,3 @@ +title=index-140 +author=admin +path=content/index-140 diff --git a/documentation/18.11/eiffelstudio/_images/index-141.png b/documentation/18.11/eiffelstudio/_images/index-141.png new file mode 100644 index 00000000..eae703c7 Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/index-141.png differ diff --git a/documentation/18.11/eiffelstudio/_images/index-141.png.data b/documentation/18.11/eiffelstudio/_images/index-141.png.data new file mode 100644 index 00000000..32eb48f0 --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/index-141.png.data @@ -0,0 +1,3 @@ +title=index-141 +author=admin +path=content/index-141 diff --git a/documentation/18.11/eiffelstudio/_images/index-37.png b/documentation/18.11/eiffelstudio/_images/index-37.png new file mode 100644 index 00000000..4317b89e Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/index-37.png differ diff --git a/documentation/18.11/eiffelstudio/_images/index-37.png.data b/documentation/18.11/eiffelstudio/_images/index-37.png.data new file mode 100644 index 00000000..65464203 --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/index-37.png.data @@ -0,0 +1,3 @@ +title=index-37 +author=halw +path=content/index-37 diff --git a/documentation/18.11/eiffelstudio/_images/index-38.png b/documentation/18.11/eiffelstudio/_images/index-38.png new file mode 100644 index 00000000..42b6febc Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/index-38.png differ diff --git a/documentation/18.11/eiffelstudio/_images/index-38.png.data b/documentation/18.11/eiffelstudio/_images/index-38.png.data new file mode 100644 index 00000000..a1fc9793 --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/index-38.png.data @@ -0,0 +1,3 @@ +title=index-38 +author=halw +path=content/index-38 diff --git a/documentation/18.11/eiffelstudio/_images/index-39.png b/documentation/18.11/eiffelstudio/_images/index-39.png new file mode 100644 index 00000000..9b31e6d3 Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/index-39.png differ diff --git a/documentation/18.11/eiffelstudio/_images/index-39.png.data b/documentation/18.11/eiffelstudio/_images/index-39.png.data new file mode 100644 index 00000000..1e7f153e --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/index-39.png.data @@ -0,0 +1,3 @@ +title=index-39 +author=halw +path=content/index-39 diff --git a/documentation/18.11/eiffelstudio/_images/index-40.png b/documentation/18.11/eiffelstudio/_images/index-40.png new file mode 100644 index 00000000..1a7a5b9a Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/index-40.png differ diff --git a/documentation/18.11/eiffelstudio/_images/index-40.png.data b/documentation/18.11/eiffelstudio/_images/index-40.png.data new file mode 100644 index 00000000..fb09c89c --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/index-40.png.data @@ -0,0 +1,3 @@ +title=index-40 +author=halw +path=content/index-40 diff --git a/documentation/18.11/eiffelstudio/_images/index-41.png b/documentation/18.11/eiffelstudio/_images/index-41.png new file mode 100644 index 00000000..b0cceaf0 Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/index-41.png differ diff --git a/documentation/18.11/eiffelstudio/_images/index-41.png.data b/documentation/18.11/eiffelstudio/_images/index-41.png.data new file mode 100644 index 00000000..ff38abfe --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/index-41.png.data @@ -0,0 +1,3 @@ +title=index-41 +author=halw +path=content/index-41 diff --git a/documentation/18.11/eiffelstudio/_images/index-42.png b/documentation/18.11/eiffelstudio/_images/index-42.png new file mode 100644 index 00000000..940620f6 Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/index-42.png differ diff --git a/documentation/18.11/eiffelstudio/_images/index-42.png.data b/documentation/18.11/eiffelstudio/_images/index-42.png.data new file mode 100644 index 00000000..d882afc1 --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/index-42.png.data @@ -0,0 +1,3 @@ +title=index-42 +author=halw +path=content/index-42 diff --git a/documentation/18.11/eiffelstudio/_images/index-43.png b/documentation/18.11/eiffelstudio/_images/index-43.png new file mode 100644 index 00000000..81f4dd86 Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/index-43.png differ diff --git a/documentation/18.11/eiffelstudio/_images/index-43.png.data b/documentation/18.11/eiffelstudio/_images/index-43.png.data new file mode 100644 index 00000000..99ed8ae9 --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/index-43.png.data @@ -0,0 +1,3 @@ +title=index-43 +author=halw +path=content/index-43 diff --git a/documentation/18.11/eiffelstudio/_images/index-44.png b/documentation/18.11/eiffelstudio/_images/index-44.png new file mode 100644 index 00000000..4d738ba2 Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/index-44.png differ diff --git a/documentation/18.11/eiffelstudio/_images/index-44.png.data b/documentation/18.11/eiffelstudio/_images/index-44.png.data new file mode 100644 index 00000000..0d4b55f8 --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/index-44.png.data @@ -0,0 +1,3 @@ +title=index-44 +author=halw +path=content/index-44 diff --git a/documentation/18.11/eiffelstudio/_images/index-45.png b/documentation/18.11/eiffelstudio/_images/index-45.png new file mode 100644 index 00000000..9a824b49 Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/index-45.png differ diff --git a/documentation/18.11/eiffelstudio/_images/index-45.png.data b/documentation/18.11/eiffelstudio/_images/index-45.png.data new file mode 100644 index 00000000..77e5b501 --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/index-45.png.data @@ -0,0 +1,3 @@ +title=index-45 +author=halw +path=content/index-45 diff --git a/documentation/18.11/eiffelstudio/_images/index-46.png b/documentation/18.11/eiffelstudio/_images/index-46.png new file mode 100644 index 00000000..466fa450 Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/index-46.png differ diff --git a/documentation/18.11/eiffelstudio/_images/index-46.png.data b/documentation/18.11/eiffelstudio/_images/index-46.png.data new file mode 100644 index 00000000..7b575a97 --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/index-46.png.data @@ -0,0 +1,3 @@ +title=index-46 +author=halw +path=content/index-46 diff --git a/documentation/18.11/eiffelstudio/_images/index-47.png b/documentation/18.11/eiffelstudio/_images/index-47.png new file mode 100644 index 00000000..61fd8c97 Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/index-47.png differ diff --git a/documentation/18.11/eiffelstudio/_images/index-47.png.data b/documentation/18.11/eiffelstudio/_images/index-47.png.data new file mode 100644 index 00000000..85afddce --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/index-47.png.data @@ -0,0 +1,3 @@ +title=index-47 +author=halw +path=content/index-47 diff --git a/documentation/18.11/eiffelstudio/_images/index-48.png b/documentation/18.11/eiffelstudio/_images/index-48.png new file mode 100644 index 00000000..873e1f8c Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/index-48.png differ diff --git a/documentation/18.11/eiffelstudio/_images/index-48.png.data b/documentation/18.11/eiffelstudio/_images/index-48.png.data new file mode 100644 index 00000000..bc407d32 --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/index-48.png.data @@ -0,0 +1,3 @@ +title=index-48 +author=halw +path=content/index-48 diff --git a/documentation/18.11/eiffelstudio/_images/index-49.png b/documentation/18.11/eiffelstudio/_images/index-49.png new file mode 100644 index 00000000..5838b991 Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/index-49.png differ diff --git a/documentation/18.11/eiffelstudio/_images/index-49.png.data b/documentation/18.11/eiffelstudio/_images/index-49.png.data new file mode 100644 index 00000000..46bc4df3 --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/index-49.png.data @@ -0,0 +1,3 @@ +title=index-49 +author=halw +path=content/index-49 diff --git a/documentation/18.11/eiffelstudio/_images/information-tool-v71.png b/documentation/18.11/eiffelstudio/_images/information-tool-v71.png new file mode 100644 index 00000000..413e4ea8 Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/information-tool-v71.png differ diff --git a/documentation/18.11/eiffelstudio/_images/information-tool-v71.png.data b/documentation/18.11/eiffelstudio/_images/information-tool-v71.png.data new file mode 100644 index 00000000..6a8e0363 --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/information-tool-v71.png.data @@ -0,0 +1,3 @@ +title=information tool v71 +author=halw +path=content/information-tool-v71 diff --git a/documentation/18.11/eiffelstudio/_images/interface1.png b/documentation/18.11/eiffelstudio/_images/interface1.png new file mode 100644 index 00000000..c89486a3 Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/interface1.png differ diff --git a/documentation/18.11/eiffelstudio/_images/interface1.png.data b/documentation/18.11/eiffelstudio/_images/interface1.png.data new file mode 100644 index 00000000..3720f16b --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/interface1.png.data @@ -0,0 +1,3 @@ +title=interface1 +author=admin +path=content/interface1 diff --git a/documentation/18.11/eiffelstudio/_images/interface10.png b/documentation/18.11/eiffelstudio/_images/interface10.png new file mode 100644 index 00000000..e189b0c8 Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/interface10.png differ diff --git a/documentation/18.11/eiffelstudio/_images/interface10.png.data b/documentation/18.11/eiffelstudio/_images/interface10.png.data new file mode 100644 index 00000000..945dc67e --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/interface10.png.data @@ -0,0 +1,3 @@ +title=interface10 +author=admin +path=content/interface10 diff --git a/documentation/18.11/eiffelstudio/_images/interface11.png b/documentation/18.11/eiffelstudio/_images/interface11.png new file mode 100644 index 00000000..a74839b0 Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/interface11.png differ diff --git a/documentation/18.11/eiffelstudio/_images/interface11.png.data b/documentation/18.11/eiffelstudio/_images/interface11.png.data new file mode 100644 index 00000000..15efbdd7 --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/interface11.png.data @@ -0,0 +1,3 @@ +title=interface11 +author=admin +path=content/interface11 diff --git a/documentation/18.11/eiffelstudio/_images/interface12.png b/documentation/18.11/eiffelstudio/_images/interface12.png new file mode 100644 index 00000000..1c8eb9a9 Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/interface12.png differ diff --git a/documentation/18.11/eiffelstudio/_images/interface12.png.data b/documentation/18.11/eiffelstudio/_images/interface12.png.data new file mode 100644 index 00000000..16ad44dd --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/interface12.png.data @@ -0,0 +1,3 @@ +title=interface12 +author=admin +path=content/interface12 diff --git a/documentation/18.11/eiffelstudio/_images/interface13.png b/documentation/18.11/eiffelstudio/_images/interface13.png new file mode 100644 index 00000000..fb937f3d Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/interface13.png differ diff --git a/documentation/18.11/eiffelstudio/_images/interface13.png.data b/documentation/18.11/eiffelstudio/_images/interface13.png.data new file mode 100644 index 00000000..174c63a0 --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/interface13.png.data @@ -0,0 +1,3 @@ +title=interface13 +author=admin +path=content/interface13 diff --git a/documentation/18.11/eiffelstudio/_images/interface14.png b/documentation/18.11/eiffelstudio/_images/interface14.png new file mode 100644 index 00000000..23f48c5a Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/interface14.png differ diff --git a/documentation/18.11/eiffelstudio/_images/interface14.png.data b/documentation/18.11/eiffelstudio/_images/interface14.png.data new file mode 100644 index 00000000..6d41f07b --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/interface14.png.data @@ -0,0 +1,3 @@ +title=interface14 +author=admin +path=content/interface14 diff --git a/documentation/18.11/eiffelstudio/_images/interface16.png b/documentation/18.11/eiffelstudio/_images/interface16.png new file mode 100644 index 00000000..7aae82ec Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/interface16.png differ diff --git a/documentation/18.11/eiffelstudio/_images/interface16.png.data b/documentation/18.11/eiffelstudio/_images/interface16.png.data new file mode 100644 index 00000000..1d3daf6d --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/interface16.png.data @@ -0,0 +1,3 @@ +title=interface16 +author=admin +path=content/interface16 diff --git a/documentation/18.11/eiffelstudio/_images/interface17.png b/documentation/18.11/eiffelstudio/_images/interface17.png new file mode 100644 index 00000000..e39b08ac Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/interface17.png differ diff --git a/documentation/18.11/eiffelstudio/_images/interface17.png.data b/documentation/18.11/eiffelstudio/_images/interface17.png.data new file mode 100644 index 00000000..ea54b1a6 --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/interface17.png.data @@ -0,0 +1,3 @@ +title=interface17 +author=admin +path=content/interface17 diff --git a/documentation/18.11/eiffelstudio/_images/interface18.png b/documentation/18.11/eiffelstudio/_images/interface18.png new file mode 100644 index 00000000..4f243468 Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/interface18.png differ diff --git a/documentation/18.11/eiffelstudio/_images/interface18.png.data b/documentation/18.11/eiffelstudio/_images/interface18.png.data new file mode 100644 index 00000000..dea3eb11 --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/interface18.png.data @@ -0,0 +1,3 @@ +title=interface18 +author=admin +path=content/interface18 diff --git a/documentation/18.11/eiffelstudio/_images/interface19.png b/documentation/18.11/eiffelstudio/_images/interface19.png new file mode 100644 index 00000000..ccb55de6 Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/interface19.png differ diff --git a/documentation/18.11/eiffelstudio/_images/interface19.png.data b/documentation/18.11/eiffelstudio/_images/interface19.png.data new file mode 100644 index 00000000..2bb25ae4 --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/interface19.png.data @@ -0,0 +1,3 @@ +title=interface19 +author=admin +path=content/interface19 diff --git a/documentation/18.11/eiffelstudio/_images/interface2.png b/documentation/18.11/eiffelstudio/_images/interface2.png new file mode 100644 index 00000000..7922abc2 Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/interface2.png differ diff --git a/documentation/18.11/eiffelstudio/_images/interface2.png.data b/documentation/18.11/eiffelstudio/_images/interface2.png.data new file mode 100644 index 00000000..8e84a6ce --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/interface2.png.data @@ -0,0 +1,3 @@ +title=interface2 +author=admin +path=content/interface2 diff --git a/documentation/18.11/eiffelstudio/_images/interface20.png b/documentation/18.11/eiffelstudio/_images/interface20.png new file mode 100644 index 00000000..24abc021 Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/interface20.png differ diff --git a/documentation/18.11/eiffelstudio/_images/interface20.png.data b/documentation/18.11/eiffelstudio/_images/interface20.png.data new file mode 100644 index 00000000..3e9f0c79 --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/interface20.png.data @@ -0,0 +1,3 @@ +title=interface20 +author=admin +path=content/interface20 diff --git a/documentation/18.11/eiffelstudio/_images/interface21.png b/documentation/18.11/eiffelstudio/_images/interface21.png new file mode 100644 index 00000000..36f5d9c6 Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/interface21.png differ diff --git a/documentation/18.11/eiffelstudio/_images/interface21.png.data b/documentation/18.11/eiffelstudio/_images/interface21.png.data new file mode 100644 index 00000000..0a7f6fd8 --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/interface21.png.data @@ -0,0 +1,3 @@ +title=interface21 +author=admin +path=content/interface21 diff --git a/documentation/18.11/eiffelstudio/_images/interface22.png b/documentation/18.11/eiffelstudio/_images/interface22.png new file mode 100644 index 00000000..4d56bfb9 Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/interface22.png differ diff --git a/documentation/18.11/eiffelstudio/_images/interface22.png.data b/documentation/18.11/eiffelstudio/_images/interface22.png.data new file mode 100644 index 00000000..42812626 --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/interface22.png.data @@ -0,0 +1,3 @@ +title=interface22 +author=admin +path=content/interface22 diff --git a/documentation/18.11/eiffelstudio/_images/interface23.png b/documentation/18.11/eiffelstudio/_images/interface23.png new file mode 100644 index 00000000..7267cb01 Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/interface23.png differ diff --git a/documentation/18.11/eiffelstudio/_images/interface23.png.data b/documentation/18.11/eiffelstudio/_images/interface23.png.data new file mode 100644 index 00000000..427b021e --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/interface23.png.data @@ -0,0 +1,3 @@ +title=interface23 +author=admin +path=content/interface23 diff --git a/documentation/18.11/eiffelstudio/_images/interface24.png b/documentation/18.11/eiffelstudio/_images/interface24.png new file mode 100644 index 00000000..0472bc2c Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/interface24.png differ diff --git a/documentation/18.11/eiffelstudio/_images/interface24.png.data b/documentation/18.11/eiffelstudio/_images/interface24.png.data new file mode 100644 index 00000000..45cdf25d --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/interface24.png.data @@ -0,0 +1,3 @@ +title=interface24 +author=admin +path=content/interface24 diff --git a/documentation/18.11/eiffelstudio/_images/interface25.png b/documentation/18.11/eiffelstudio/_images/interface25.png new file mode 100644 index 00000000..c4c9a6d6 Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/interface25.png differ diff --git a/documentation/18.11/eiffelstudio/_images/interface25.png.data b/documentation/18.11/eiffelstudio/_images/interface25.png.data new file mode 100644 index 00000000..62678d79 --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/interface25.png.data @@ -0,0 +1,3 @@ +title=interface25 +author=admin +path=content/interface25 diff --git a/documentation/18.11/eiffelstudio/_images/interface3.png b/documentation/18.11/eiffelstudio/_images/interface3.png new file mode 100644 index 00000000..de0f2f46 Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/interface3.png differ diff --git a/documentation/18.11/eiffelstudio/_images/interface3.png.data b/documentation/18.11/eiffelstudio/_images/interface3.png.data new file mode 100644 index 00000000..314d1a24 --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/interface3.png.data @@ -0,0 +1,3 @@ +title=interface3 +author=admin +path=content/interface3 diff --git a/documentation/18.11/eiffelstudio/_images/interface4.png b/documentation/18.11/eiffelstudio/_images/interface4.png new file mode 100644 index 00000000..8562f7ec Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/interface4.png differ diff --git a/documentation/18.11/eiffelstudio/_images/interface4.png.data b/documentation/18.11/eiffelstudio/_images/interface4.png.data new file mode 100644 index 00000000..00ade667 --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/interface4.png.data @@ -0,0 +1,3 @@ +title=interface4 +author=admin +path=content/interface4 diff --git a/documentation/18.11/eiffelstudio/_images/interface5.png b/documentation/18.11/eiffelstudio/_images/interface5.png new file mode 100644 index 00000000..4412638d Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/interface5.png differ diff --git a/documentation/18.11/eiffelstudio/_images/interface5.png.data b/documentation/18.11/eiffelstudio/_images/interface5.png.data new file mode 100644 index 00000000..d66c9b05 --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/interface5.png.data @@ -0,0 +1,3 @@ +title=interface5 +author=admin +path=content/interface5 diff --git a/documentation/18.11/eiffelstudio/_images/interface6.png b/documentation/18.11/eiffelstudio/_images/interface6.png new file mode 100644 index 00000000..97ad3cfc Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/interface6.png differ diff --git a/documentation/18.11/eiffelstudio/_images/interface6.png.data b/documentation/18.11/eiffelstudio/_images/interface6.png.data new file mode 100644 index 00000000..0b85fd71 --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/interface6.png.data @@ -0,0 +1,3 @@ +title=interface6 +author=admin +path=content/interface6 diff --git a/documentation/18.11/eiffelstudio/_images/interface7.png b/documentation/18.11/eiffelstudio/_images/interface7.png new file mode 100644 index 00000000..60f4a89b Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/interface7.png differ diff --git a/documentation/18.11/eiffelstudio/_images/interface7.png.data b/documentation/18.11/eiffelstudio/_images/interface7.png.data new file mode 100644 index 00000000..0493aeb3 --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/interface7.png.data @@ -0,0 +1,3 @@ +title=interface7 +author=admin +path=content/interface7 diff --git a/documentation/18.11/eiffelstudio/_images/interface8.png b/documentation/18.11/eiffelstudio/_images/interface8.png new file mode 100644 index 00000000..87fe4706 Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/interface8.png differ diff --git a/documentation/18.11/eiffelstudio/_images/interface8.png.data b/documentation/18.11/eiffelstudio/_images/interface8.png.data new file mode 100644 index 00000000..db4cb7ab --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/interface8.png.data @@ -0,0 +1,3 @@ +title=interface8 +author=admin +path=content/interface8 diff --git a/documentation/18.11/eiffelstudio/_images/interface9.png b/documentation/18.11/eiffelstudio/_images/interface9.png new file mode 100644 index 00000000..c667d42c Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/interface9.png differ diff --git a/documentation/18.11/eiffelstudio/_images/interface9.png.data b/documentation/18.11/eiffelstudio/_images/interface9.png.data new file mode 100644 index 00000000..104ddd51 --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/interface9.png.data @@ -0,0 +1,3 @@ +title=interface9 +author=admin +path=content/interface9 diff --git a/documentation/18.11/eiffelstudio/_images/is-satisfied-by.png b/documentation/18.11/eiffelstudio/_images/is-satisfied-by.png new file mode 100644 index 00000000..01f15b23 Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/is-satisfied-by.png differ diff --git a/documentation/18.11/eiffelstudio/_images/is-satisfied-by.png.data b/documentation/18.11/eiffelstudio/_images/is-satisfied-by.png.data new file mode 100644 index 00000000..c2ae8ad4 --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/is-satisfied-by.png.data @@ -0,0 +1,3 @@ +title=is-satisfied-by +author=admin +path=content/satisfied diff --git a/documentation/18.11/eiffelstudio/_images/link-tool-left.png b/documentation/18.11/eiffelstudio/_images/link-tool-left.png new file mode 100644 index 00000000..2e28d66a Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/link-tool-left.png differ diff --git a/documentation/18.11/eiffelstudio/_images/link-tool-left.png.data b/documentation/18.11/eiffelstudio/_images/link-tool-left.png.data new file mode 100644 index 00000000..2d2e0bc8 --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/link-tool-left.png.data @@ -0,0 +1,3 @@ +title=link-tool-left +author=admin +path=content/link-tool-left diff --git a/documentation/18.11/eiffelstudio/_images/link-tool-no-handles.png b/documentation/18.11/eiffelstudio/_images/link-tool-no-handles.png new file mode 100644 index 00000000..770a34be Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/link-tool-no-handles.png differ diff --git a/documentation/18.11/eiffelstudio/_images/link-tool-no-handles.png.data b/documentation/18.11/eiffelstudio/_images/link-tool-no-handles.png.data new file mode 100644 index 00000000..6abc2489 --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/link-tool-no-handles.png.data @@ -0,0 +1,3 @@ +title=link-tool-no-handles +author=admin +path=content/link-tool-no-handles diff --git a/documentation/18.11/eiffelstudio/_images/link-tool-right.png b/documentation/18.11/eiffelstudio/_images/link-tool-right.png new file mode 100644 index 00000000..4862789d Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/link-tool-right.png differ diff --git a/documentation/18.11/eiffelstudio/_images/link-tool-right.png.data b/documentation/18.11/eiffelstudio/_images/link-tool-right.png.data new file mode 100644 index 00000000..3ab6e135 --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/link-tool-right.png.data @@ -0,0 +1,3 @@ +title=link-tool-right +author=admin +path=content/link-tool-right diff --git a/documentation/18.11/eiffelstudio/_images/link-tool-two-left.png b/documentation/18.11/eiffelstudio/_images/link-tool-two-left.png new file mode 100644 index 00000000..5453b648 Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/link-tool-two-left.png differ diff --git a/documentation/18.11/eiffelstudio/_images/link-tool-two-left.png.data b/documentation/18.11/eiffelstudio/_images/link-tool-two-left.png.data new file mode 100644 index 00000000..a60a2de9 --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/link-tool-two-left.png.data @@ -0,0 +1,3 @@ +title=link-tool-two-left +author=admin +path=content/link-tool-two-left diff --git a/documentation/18.11/eiffelstudio/_images/link-tool-two-right.png b/documentation/18.11/eiffelstudio/_images/link-tool-two-right.png new file mode 100644 index 00000000..88d11a68 Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/link-tool-two-right.png differ diff --git a/documentation/18.11/eiffelstudio/_images/link-tool-two-right.png.data b/documentation/18.11/eiffelstudio/_images/link-tool-two-right.png.data new file mode 100644 index 00000000..89abfcd2 --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/link-tool-two-right.png.data @@ -0,0 +1,3 @@ +title=link-tool-two-right +author=admin +path=content/link-tool-two-right diff --git a/documentation/18.11/eiffelstudio/_images/link-tool.png b/documentation/18.11/eiffelstudio/_images/link-tool.png new file mode 100644 index 00000000..cbd5b953 Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/link-tool.png differ diff --git a/documentation/18.11/eiffelstudio/_images/link-tool.png.data b/documentation/18.11/eiffelstudio/_images/link-tool.png.data new file mode 100644 index 00000000..779c3861 --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/link-tool.png.data @@ -0,0 +1,3 @@ +title=link-tool +author=admin +path=content/link-tool diff --git a/documentation/18.11/eiffelstudio/_images/main-address-bar.png b/documentation/18.11/eiffelstudio/_images/main-address-bar.png new file mode 100644 index 00000000..f2139357 Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/main-address-bar.png differ diff --git a/documentation/18.11/eiffelstudio/_images/main-address-bar.png.data b/documentation/18.11/eiffelstudio/_images/main-address-bar.png.data new file mode 100644 index 00000000..292a7f51 --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/main-address-bar.png.data @@ -0,0 +1,3 @@ +title=main-address-bar +author=halw +path=content/main-address-bar diff --git a/documentation/18.11/eiffelstudio/_images/main-toolbars_0.png b/documentation/18.11/eiffelstudio/_images/main-toolbars_0.png new file mode 100644 index 00000000..ba058783 Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/main-toolbars_0.png differ diff --git a/documentation/18.11/eiffelstudio/_images/main-toolbars_0.png.data b/documentation/18.11/eiffelstudio/_images/main-toolbars_0.png.data new file mode 100644 index 00000000..ebe84b42 --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/main-toolbars_0.png.data @@ -0,0 +1,3 @@ +title=standard-toolbars +author=halw +path=content/standard-toolbars diff --git a/documentation/18.11/eiffelstudio/_images/manual-sweep.png b/documentation/18.11/eiffelstudio/_images/manual-sweep.png new file mode 100644 index 00000000..a1dd3e99 Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/manual-sweep.png differ diff --git a/documentation/18.11/eiffelstudio/_images/manual-sweep.png.data b/documentation/18.11/eiffelstudio/_images/manual-sweep.png.data new file mode 100644 index 00000000..57432676 --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/manual-sweep.png.data @@ -0,0 +1,3 @@ +title=manual sweeping icon +author=halw +path=content/manual-sweeping-icon diff --git a/documentation/18.11/eiffelstudio/_images/mapping-options.png b/documentation/18.11/eiffelstudio/_images/mapping-options.png new file mode 100644 index 00000000..83d20832 Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/mapping-options.png differ diff --git a/documentation/18.11/eiffelstudio/_images/mapping-options.png.data b/documentation/18.11/eiffelstudio/_images/mapping-options.png.data new file mode 100644 index 00000000..ad59eddf --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/mapping-options.png.data @@ -0,0 +1,3 @@ +title=mapping-options +author=admin +path=content/mapping-options diff --git a/documentation/18.11/eiffelstudio/_images/maximize-icon.png b/documentation/18.11/eiffelstudio/_images/maximize-icon.png new file mode 100644 index 00000000..d96bf0a8 Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/maximize-icon.png differ diff --git a/documentation/18.11/eiffelstudio/_images/maximize-icon.png.data b/documentation/18.11/eiffelstudio/_images/maximize-icon.png.data new file mode 100644 index 00000000..ee34061b --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/maximize-icon.png.data @@ -0,0 +1,3 @@ +title=maximize-icon +author=halw +path=content/maximize-icon diff --git a/documentation/18.11/eiffelstudio/_images/metrics-tool--command-send-to-external-editor-icon.png b/documentation/18.11/eiffelstudio/_images/metrics-tool--command-send-to-external-editor-icon.png new file mode 100644 index 00000000..3363cbd1 Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/metrics-tool--command-send-to-external-editor-icon.png differ diff --git a/documentation/18.11/eiffelstudio/_images/metrics-tool--command-send-to-external-editor-icon.png.data b/documentation/18.11/eiffelstudio/_images/metrics-tool--command-send-to-external-editor-icon.png.data new file mode 100644 index 00000000..78c49880 --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/metrics-tool--command-send-to-external-editor-icon.png.data @@ -0,0 +1,3 @@ +title=metrics-tool--command-send-to-external-editor-icon +author=admin +path=content/metrics-tool-command-send-external-editor-icon diff --git a/documentation/18.11/eiffelstudio/_images/metrics-tool--context-sync-icon.png b/documentation/18.11/eiffelstudio/_images/metrics-tool--context-sync-icon.png new file mode 100644 index 00000000..c8ffa1cc Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/metrics-tool--context-sync-icon.png differ diff --git a/documentation/18.11/eiffelstudio/_images/metrics-tool--context-sync-icon.png.data b/documentation/18.11/eiffelstudio/_images/metrics-tool--context-sync-icon.png.data new file mode 100644 index 00000000..2d9eed21 --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/metrics-tool--context-sync-icon.png.data @@ -0,0 +1,3 @@ +title=metrics-tool--context-sync-icon +author=admin +path=content/metrics-tool-context-sync-icon diff --git a/documentation/18.11/eiffelstudio/_images/metrics-tool--debug-run-icon.png b/documentation/18.11/eiffelstudio/_images/metrics-tool--debug-run-icon.png new file mode 100644 index 00000000..c19fa0fb Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/metrics-tool--debug-run-icon.png differ diff --git a/documentation/18.11/eiffelstudio/_images/metrics-tool--debug-run-icon.png.data b/documentation/18.11/eiffelstudio/_images/metrics-tool--debug-run-icon.png.data new file mode 100644 index 00000000..ff01d80a --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/metrics-tool--debug-run-icon.png.data @@ -0,0 +1,3 @@ +title=metrics-tool--debug-run-icon +author=admin +path=content/metrics-tool-debug-run-icon diff --git a/documentation/18.11/eiffelstudio/_images/metrics-tool--debug-stop-icon.png b/documentation/18.11/eiffelstudio/_images/metrics-tool--debug-stop-icon.png new file mode 100644 index 00000000..8120249f Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/metrics-tool--debug-stop-icon.png differ diff --git a/documentation/18.11/eiffelstudio/_images/metrics-tool--debug-stop-icon.png.data b/documentation/18.11/eiffelstudio/_images/metrics-tool--debug-stop-icon.png.data new file mode 100644 index 00000000..61d6305b --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/metrics-tool--debug-stop-icon.png.data @@ -0,0 +1,3 @@ +title=metrics-tool--debug-stop-icon +author=admin +path=content/metrics-tool-debug-stop-icon diff --git a/documentation/18.11/eiffelstudio/_images/metrics-tool--general-open-icon.png b/documentation/18.11/eiffelstudio/_images/metrics-tool--general-open-icon.png new file mode 100644 index 00000000..df37ed22 Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/metrics-tool--general-open-icon.png differ diff --git a/documentation/18.11/eiffelstudio/_images/metrics-tool--general-open-icon.png.data b/documentation/18.11/eiffelstudio/_images/metrics-tool--general-open-icon.png.data new file mode 100644 index 00000000..67f00eeb --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/metrics-tool--general-open-icon.png.data @@ -0,0 +1,3 @@ +title=metrics-tool--general-open-icon +author=admin +path=content/metrics-tool-general-open-icon diff --git a/documentation/18.11/eiffelstudio/_images/metrics-tool--general-remove-icon.png b/documentation/18.11/eiffelstudio/_images/metrics-tool--general-remove-icon.png new file mode 100644 index 00000000..12f2ef76 Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/metrics-tool--general-remove-icon.png differ diff --git a/documentation/18.11/eiffelstudio/_images/metrics-tool--general-remove-icon.png.data b/documentation/18.11/eiffelstudio/_images/metrics-tool--general-remove-icon.png.data new file mode 100644 index 00000000..6d2a58a6 --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/metrics-tool--general-remove-icon.png.data @@ -0,0 +1,3 @@ +title=metrics-tool--general-remove-icon +author=admin +path=content/metrics-tool-general-remove-icon diff --git a/documentation/18.11/eiffelstudio/_images/metrics-tool--general-reset-icon.png b/documentation/18.11/eiffelstudio/_images/metrics-tool--general-reset-icon.png new file mode 100644 index 00000000..8ebc3e87 Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/metrics-tool--general-reset-icon.png differ diff --git a/documentation/18.11/eiffelstudio/_images/metrics-tool--general-reset-icon.png.data b/documentation/18.11/eiffelstudio/_images/metrics-tool--general-reset-icon.png.data new file mode 100644 index 00000000..cfc7fa3c --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/metrics-tool--general-reset-icon.png.data @@ -0,0 +1,3 @@ +title=metrics-tool--general-reset-icon +author=admin +path=content/metrics-tool-general-reset-icon diff --git a/documentation/18.11/eiffelstudio/_images/metrics-tool--general-save-icon.png b/documentation/18.11/eiffelstudio/_images/metrics-tool--general-save-icon.png new file mode 100644 index 00000000..3f6a757c Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/metrics-tool--general-save-icon.png differ diff --git a/documentation/18.11/eiffelstudio/_images/metrics-tool--general-save-icon.png.data b/documentation/18.11/eiffelstudio/_images/metrics-tool--general-save-icon.png.data new file mode 100644 index 00000000..faf53891 --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/metrics-tool--general-save-icon.png.data @@ -0,0 +1,3 @@ +title=metrics-tool--general-save-icon +author=admin +path=content/metrics-tool-general-save-icon diff --git a/documentation/18.11/eiffelstudio/_images/metrics-tool--metric-export-to-file-icon.png b/documentation/18.11/eiffelstudio/_images/metrics-tool--metric-export-to-file-icon.png new file mode 100644 index 00000000..841cc2fe Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/metrics-tool--metric-export-to-file-icon.png differ diff --git a/documentation/18.11/eiffelstudio/_images/metrics-tool--metric-export-to-file-icon.png.data b/documentation/18.11/eiffelstudio/_images/metrics-tool--metric-export-to-file-icon.png.data new file mode 100644 index 00000000..995718e7 --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/metrics-tool--metric-export-to-file-icon.png.data @@ -0,0 +1,3 @@ +title=metrics-tool--metric-export-to-file-icon +author=admin +path=content/metrics-tool-metric-export-file-icon diff --git a/documentation/18.11/eiffelstudio/_images/metrics-tool--metric-filter-icon.png b/documentation/18.11/eiffelstudio/_images/metrics-tool--metric-filter-icon.png new file mode 100644 index 00000000..aed10c99 Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/metrics-tool--metric-filter-icon.png differ diff --git a/documentation/18.11/eiffelstudio/_images/metrics-tool--metric-filter-icon.png.data b/documentation/18.11/eiffelstudio/_images/metrics-tool--metric-filter-icon.png.data new file mode 100644 index 00000000..d64c7aed --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/metrics-tool--metric-filter-icon.png.data @@ -0,0 +1,3 @@ +title=metrics-tool--metric-filter-icon +author=admin +path=content/metrics-tool-metric-filter-icon diff --git a/documentation/18.11/eiffelstudio/_images/metrics-tool--metric-group-icon.png b/documentation/18.11/eiffelstudio/_images/metrics-tool--metric-group-icon.png new file mode 100644 index 00000000..375118c3 Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/metrics-tool--metric-group-icon.png differ diff --git a/documentation/18.11/eiffelstudio/_images/metrics-tool--metric-group-icon.png.data b/documentation/18.11/eiffelstudio/_images/metrics-tool--metric-group-icon.png.data new file mode 100644 index 00000000..4e073e20 --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/metrics-tool--metric-group-icon.png.data @@ -0,0 +1,3 @@ +title=metrics-tool--metric-group-icon +author=admin +path=content/metrics-tool-metric-group-icon diff --git a/documentation/18.11/eiffelstudio/_images/metrics-tool--metric-quick-icon.png b/documentation/18.11/eiffelstudio/_images/metrics-tool--metric-quick-icon.png new file mode 100644 index 00000000..73a08231 Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/metrics-tool--metric-quick-icon.png differ diff --git a/documentation/18.11/eiffelstudio/_images/metrics-tool--metric-quick-icon.png.data b/documentation/18.11/eiffelstudio/_images/metrics-tool--metric-quick-icon.png.data new file mode 100644 index 00000000..61d7a593 --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/metrics-tool--metric-quick-icon.png.data @@ -0,0 +1,3 @@ +title=metrics-tool--metric-quick-icon +author=admin +path=content/metrics-tool-metric-quick-icon diff --git a/documentation/18.11/eiffelstudio/_images/metrics-tool--metric-run-and-show-details-icon.png b/documentation/18.11/eiffelstudio/_images/metrics-tool--metric-run-and-show-details-icon.png new file mode 100644 index 00000000..ed21fed1 Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/metrics-tool--metric-run-and-show-details-icon.png differ diff --git a/documentation/18.11/eiffelstudio/_images/metrics-tool--metric-run-and-show-details-icon.png.data b/documentation/18.11/eiffelstudio/_images/metrics-tool--metric-run-and-show-details-icon.png.data new file mode 100644 index 00000000..a031bd06 --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/metrics-tool--metric-run-and-show-details-icon.png.data @@ -0,0 +1,3 @@ +title=metrics-tool--metric-run-and-show-details-icon +author=admin +path=content/metrics-tool-metric-run-and-show-details-icon diff --git a/documentation/18.11/eiffelstudio/_images/metrics-tool--metric-send-to-archive-icon.png b/documentation/18.11/eiffelstudio/_images/metrics-tool--metric-send-to-archive-icon.png new file mode 100644 index 00000000..0bda37e7 Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/metrics-tool--metric-send-to-archive-icon.png differ diff --git a/documentation/18.11/eiffelstudio/_images/metrics-tool--metric-send-to-archive-icon.png.data b/documentation/18.11/eiffelstudio/_images/metrics-tool--metric-send-to-archive-icon.png.data new file mode 100644 index 00000000..371cab76 --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/metrics-tool--metric-send-to-archive-icon.png.data @@ -0,0 +1,3 @@ +title=metrics-tool--metric-send-to-archive-icon +author=admin +path=content/metrics-tool-metric-send-archive-icon diff --git a/documentation/18.11/eiffelstudio/_images/metrics-tool--metric-unit-assertion-icon.png b/documentation/18.11/eiffelstudio/_images/metrics-tool--metric-unit-assertion-icon.png new file mode 100644 index 00000000..4528a839 Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/metrics-tool--metric-unit-assertion-icon.png differ diff --git a/documentation/18.11/eiffelstudio/_images/metrics-tool--metric-unit-assertion-icon.png.data b/documentation/18.11/eiffelstudio/_images/metrics-tool--metric-unit-assertion-icon.png.data new file mode 100644 index 00000000..11e6b5ad --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/metrics-tool--metric-unit-assertion-icon.png.data @@ -0,0 +1,3 @@ +title=metrics-tool--metric-unit-assertion-icon +author=admin +path=content/metrics-tool-metric-unit-assertion-icon diff --git a/documentation/18.11/eiffelstudio/_images/metrics-tool--new-document-icon.png b/documentation/18.11/eiffelstudio/_images/metrics-tool--new-document-icon.png new file mode 100644 index 00000000..bfe11f37 Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/metrics-tool--new-document-icon.png differ diff --git a/documentation/18.11/eiffelstudio/_images/metrics-tool--new-document-icon.png.data b/documentation/18.11/eiffelstudio/_images/metrics-tool--new-document-icon.png.data new file mode 100644 index 00000000..68fdc3fd --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/metrics-tool--new-document-icon.png.data @@ -0,0 +1,3 @@ +title=metrics-tool--new-document-icon +author=admin +path=content/metrics-tool-new-document-icon diff --git a/documentation/18.11/eiffelstudio/_images/metrics-tool--new-metric-icon.png b/documentation/18.11/eiffelstudio/_images/metrics-tool--new-metric-icon.png new file mode 100644 index 00000000..07398ff2 Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/metrics-tool--new-metric-icon.png differ diff --git a/documentation/18.11/eiffelstudio/_images/metrics-tool--new-metric-icon.png.data b/documentation/18.11/eiffelstudio/_images/metrics-tool--new-metric-icon.png.data new file mode 100644 index 00000000..1abda108 --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/metrics-tool--new-metric-icon.png.data @@ -0,0 +1,3 @@ +title=metrics-tool--new-metric-icon +author=admin +path=content/metrics-tool-new-metric-icon diff --git a/documentation/18.11/eiffelstudio/_images/minimize-icon.png b/documentation/18.11/eiffelstudio/_images/minimize-icon.png new file mode 100644 index 00000000..9f9462c8 Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/minimize-icon.png differ diff --git a/documentation/18.11/eiffelstudio/_images/minimize-icon.png.data b/documentation/18.11/eiffelstudio/_images/minimize-icon.png.data new file mode 100644 index 00000000..85dafb46 --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/minimize-icon.png.data @@ -0,0 +1,3 @@ +title=minimize-icon +author=halw +path=content/minimize-icon diff --git a/documentation/18.11/eiffelstudio/_images/move-down-icon.png b/documentation/18.11/eiffelstudio/_images/move-down-icon.png new file mode 100644 index 00000000..6a4d7d62 Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/move-down-icon.png differ diff --git a/documentation/18.11/eiffelstudio/_images/move-down-icon.png.data b/documentation/18.11/eiffelstudio/_images/move-down-icon.png.data new file mode 100644 index 00000000..b33052dd --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/move-down-icon.png.data @@ -0,0 +1,3 @@ +title=move-down-icon +author=halw +path=content/move-down-icon diff --git a/documentation/18.11/eiffelstudio/_images/move-up-icon.png b/documentation/18.11/eiffelstudio/_images/move-up-icon.png new file mode 100644 index 00000000..32a41057 Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/move-up-icon.png differ diff --git a/documentation/18.11/eiffelstudio/_images/move-up-icon.png.data b/documentation/18.11/eiffelstudio/_images/move-up-icon.png.data new file mode 100644 index 00000000..3052edbf --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/move-up-icon.png.data @@ -0,0 +1,3 @@ +title=move-up-icon +author=halw +path=content/move-icon diff --git a/documentation/18.11/eiffelstudio/_images/new-aggregate-supplier-link-icon.png b/documentation/18.11/eiffelstudio/_images/new-aggregate-supplier-link-icon.png new file mode 100644 index 00000000..5359ea4d Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/new-aggregate-supplier-link-icon.png differ diff --git a/documentation/18.11/eiffelstudio/_images/new-aggregate-supplier-link-icon.png.data b/documentation/18.11/eiffelstudio/_images/new-aggregate-supplier-link-icon.png.data new file mode 100644 index 00000000..3700f564 --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/new-aggregate-supplier-link-icon.png.data @@ -0,0 +1,3 @@ +title=new-aggregate-supplier-link-icon +author=admin +path=content/new-aggregate-supplier-link-icon diff --git a/documentation/18.11/eiffelstudio/_images/new-class-dialog.png b/documentation/18.11/eiffelstudio/_images/new-class-dialog.png new file mode 100644 index 00000000..0522c84d Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/new-class-dialog.png differ diff --git a/documentation/18.11/eiffelstudio/_images/new-class-dialog.png.data b/documentation/18.11/eiffelstudio/_images/new-class-dialog.png.data new file mode 100644 index 00000000..3db943c5 --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/new-class-dialog.png.data @@ -0,0 +1,3 @@ +title=new-class-dialog +author=admin +path=content/new-class-dialog diff --git a/documentation/18.11/eiffelstudio/_images/new-class-icon.png b/documentation/18.11/eiffelstudio/_images/new-class-icon.png new file mode 100644 index 00000000..876bf7cc Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/new-class-icon.png differ diff --git a/documentation/18.11/eiffelstudio/_images/new-class-icon.png.data b/documentation/18.11/eiffelstudio/_images/new-class-icon.png.data new file mode 100644 index 00000000..b82f9bf9 --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/new-class-icon.png.data @@ -0,0 +1,3 @@ +title=new-class-icon +author=admin +path=content/new-class-icon diff --git a/documentation/18.11/eiffelstudio/_images/new-cluster-dialog.png b/documentation/18.11/eiffelstudio/_images/new-cluster-dialog.png new file mode 100644 index 00000000..6b102b69 Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/new-cluster-dialog.png differ diff --git a/documentation/18.11/eiffelstudio/_images/new-cluster-dialog.png.data b/documentation/18.11/eiffelstudio/_images/new-cluster-dialog.png.data new file mode 100644 index 00000000..ad2de639 --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/new-cluster-dialog.png.data @@ -0,0 +1,3 @@ +title=new-cluster-dialog +author=admin +path=content/new-cluster-dialog diff --git a/documentation/18.11/eiffelstudio/_images/new-cluster-icon.png b/documentation/18.11/eiffelstudio/_images/new-cluster-icon.png new file mode 100644 index 00000000..c65545e0 Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/new-cluster-icon.png differ diff --git a/documentation/18.11/eiffelstudio/_images/new-cluster-icon.png.data b/documentation/18.11/eiffelstudio/_images/new-cluster-icon.png.data new file mode 100644 index 00000000..b29237e0 --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/new-cluster-icon.png.data @@ -0,0 +1,3 @@ +title=new-cluster-icon +author=admin +path=content/new-cluster-icon diff --git a/documentation/18.11/eiffelstudio/_images/new-document-icon.png b/documentation/18.11/eiffelstudio/_images/new-document-icon.png new file mode 100644 index 00000000..bfe11f37 Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/new-document-icon.png differ diff --git a/documentation/18.11/eiffelstudio/_images/new-document-icon.png.data b/documentation/18.11/eiffelstudio/_images/new-document-icon.png.data new file mode 100644 index 00000000..76132429 --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/new-document-icon.png.data @@ -0,0 +1,3 @@ +title=new-document-icon +author=admin +path=content/new-document-icon diff --git a/documentation/18.11/eiffelstudio/_images/new-editor-icon.png b/documentation/18.11/eiffelstudio/_images/new-editor-icon.png new file mode 100644 index 00000000..ddd5d2bc Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/new-editor-icon.png differ diff --git a/documentation/18.11/eiffelstudio/_images/new-editor-icon.png.data b/documentation/18.11/eiffelstudio/_images/new-editor-icon.png.data new file mode 100644 index 00000000..3a53e3af --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/new-editor-icon.png.data @@ -0,0 +1,3 @@ +title=new-editor-icon +author=admin +path=content/new-editor-icon diff --git a/documentation/18.11/eiffelstudio/_images/new-exported-feature.png b/documentation/18.11/eiffelstudio/_images/new-exported-feature.png new file mode 100644 index 00000000..c36e656e Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/new-exported-feature.png differ diff --git a/documentation/18.11/eiffelstudio/_images/new-exported-feature.png.data b/documentation/18.11/eiffelstudio/_images/new-exported-feature.png.data new file mode 100644 index 00000000..f32279f5 --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/new-exported-feature.png.data @@ -0,0 +1,3 @@ +title=new-exported-feature +author=admin +path=content/new-exported-feature diff --git a/documentation/18.11/eiffelstudio/_images/new-expression-as-object-definition-dlg.png b/documentation/18.11/eiffelstudio/_images/new-expression-as-object-definition-dlg.png new file mode 100644 index 00000000..39ec93ff Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/new-expression-as-object-definition-dlg.png differ diff --git a/documentation/18.11/eiffelstudio/_images/new-expression-as-object-definition-dlg.png.data b/documentation/18.11/eiffelstudio/_images/new-expression-as-object-definition-dlg.png.data new file mode 100644 index 00000000..8b1ea615 --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/new-expression-as-object-definition-dlg.png.data @@ -0,0 +1,3 @@ +title=new-expression-as-object-definition-dlg +author=admin +path=content/new-expression-object-definition-dlg diff --git a/documentation/18.11/eiffelstudio/_images/new-expression-definition-dlg.png b/documentation/18.11/eiffelstudio/_images/new-expression-definition-dlg.png new file mode 100644 index 00000000..190682e0 Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/new-expression-definition-dlg.png differ diff --git a/documentation/18.11/eiffelstudio/_images/new-expression-definition-dlg.png.data b/documentation/18.11/eiffelstudio/_images/new-expression-definition-dlg.png.data new file mode 100644 index 00000000..ae2933ef --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/new-expression-definition-dlg.png.data @@ -0,0 +1,3 @@ +title=new-expression-definition-dlg +author=admin +path=content/new-expression-definition-dlg diff --git a/documentation/18.11/eiffelstudio/_images/new-expression-icon.png b/documentation/18.11/eiffelstudio/_images/new-expression-icon.png new file mode 100644 index 00000000..777f2790 Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/new-expression-icon.png differ diff --git a/documentation/18.11/eiffelstudio/_images/new-expression-icon.png.data b/documentation/18.11/eiffelstudio/_images/new-expression-icon.png.data new file mode 100644 index 00000000..3a4d3dcf --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/new-expression-icon.png.data @@ -0,0 +1,3 @@ +title=new-expression-icon +author=admin +path=content/new-expression-icon diff --git a/documentation/18.11/eiffelstudio/_images/new-feature-icon.png b/documentation/18.11/eiffelstudio/_images/new-feature-icon.png new file mode 100644 index 00000000..48dc7cd8 Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/new-feature-icon.png differ diff --git a/documentation/18.11/eiffelstudio/_images/new-feature-icon.png.data b/documentation/18.11/eiffelstudio/_images/new-feature-icon.png.data new file mode 100644 index 00000000..4b4afd55 --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/new-feature-icon.png.data @@ -0,0 +1,3 @@ +title=new-feature-icon +author=admin +path=content/new-feature-icon diff --git a/documentation/18.11/eiffelstudio/_images/new-inheritance-link-icon.png b/documentation/18.11/eiffelstudio/_images/new-inheritance-link-icon.png new file mode 100644 index 00000000..2cf5b308 Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/new-inheritance-link-icon.png differ diff --git a/documentation/18.11/eiffelstudio/_images/new-inheritance-link-icon.png.data b/documentation/18.11/eiffelstudio/_images/new-inheritance-link-icon.png.data new file mode 100644 index 00000000..cfbb1e3b --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/new-inheritance-link-icon.png.data @@ -0,0 +1,3 @@ +title=new-inheritance-link-icon +author=admin +path=content/new-inheritance-link-icon diff --git a/documentation/18.11/eiffelstudio/_images/new-library-dialog.png b/documentation/18.11/eiffelstudio/_images/new-library-dialog.png new file mode 100644 index 00000000..0739c06e Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/new-library-dialog.png differ diff --git a/documentation/18.11/eiffelstudio/_images/new-library-dialog.png.data b/documentation/18.11/eiffelstudio/_images/new-library-dialog.png.data new file mode 100644 index 00000000..a5397024 --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/new-library-dialog.png.data @@ -0,0 +1,3 @@ +title=new-library-dialog +author=halw +path=content/new-library-dialog diff --git a/documentation/18.11/eiffelstudio/_images/new-library-icon.png b/documentation/18.11/eiffelstudio/_images/new-library-icon.png new file mode 100644 index 00000000..2f13ba61 Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/new-library-icon.png differ diff --git a/documentation/18.11/eiffelstudio/_images/new-library-icon.png.data b/documentation/18.11/eiffelstudio/_images/new-library-icon.png.data new file mode 100644 index 00000000..326d6a8b --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/new-library-icon.png.data @@ -0,0 +1,3 @@ +title=new-library-icon +author=admin +path=content/new-library-icon diff --git a/documentation/18.11/eiffelstudio/_images/new-supplier-link-icon.png b/documentation/18.11/eiffelstudio/_images/new-supplier-link-icon.png new file mode 100644 index 00000000..8d14f4df Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/new-supplier-link-icon.png differ diff --git a/documentation/18.11/eiffelstudio/_images/new-supplier-link-icon.png.data b/documentation/18.11/eiffelstudio/_images/new-supplier-link-icon.png.data new file mode 100644 index 00000000..6db10afe --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/new-supplier-link-icon.png.data @@ -0,0 +1,3 @@ +title=new-supplier-link-icon +author=admin +path=content/new-supplier-link-icon diff --git a/documentation/18.11/eiffelstudio/_images/new-window-icon.png b/documentation/18.11/eiffelstudio/_images/new-window-icon.png new file mode 100644 index 00000000..26593fa1 Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/new-window-icon.png differ diff --git a/documentation/18.11/eiffelstudio/_images/new-window-icon.png.data b/documentation/18.11/eiffelstudio/_images/new-window-icon.png.data new file mode 100644 index 00000000..43d42120 --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/new-window-icon.png.data @@ -0,0 +1,3 @@ +title=new-window-icon +author=admin +path=content/new-window-icon diff --git a/documentation/18.11/eiffelstudio/_images/next-error.png b/documentation/18.11/eiffelstudio/_images/next-error.png new file mode 100644 index 00000000..98d7b1e7 Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/next-error.png differ diff --git a/documentation/18.11/eiffelstudio/_images/next-error.png.data b/documentation/18.11/eiffelstudio/_images/next-error.png.data new file mode 100644 index 00000000..6a3257a7 --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/next-error.png.data @@ -0,0 +1,3 @@ +title=next-error +author=admin +path=content/next-error diff --git a/documentation/18.11/eiffelstudio/_images/next-warning.png b/documentation/18.11/eiffelstudio/_images/next-warning.png new file mode 100644 index 00000000..2606fa56 Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/next-warning.png differ diff --git a/documentation/18.11/eiffelstudio/_images/next-warning.png.data b/documentation/18.11/eiffelstudio/_images/next-warning.png.data new file mode 100644 index 00000000..5d3659b2 --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/next-warning.png.data @@ -0,0 +1,3 @@ +title=next-warning +author=admin +path=content/next-warning diff --git a/documentation/18.11/eiffelstudio/_images/object-tool-layout-editor.png b/documentation/18.11/eiffelstudio/_images/object-tool-layout-editor.png new file mode 100644 index 00000000..aa98ff60 Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/object-tool-layout-editor.png differ diff --git a/documentation/18.11/eiffelstudio/_images/object-tool-layout-editor.png.data b/documentation/18.11/eiffelstudio/_images/object-tool-layout-editor.png.data new file mode 100644 index 00000000..439f912c --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/object-tool-layout-editor.png.data @@ -0,0 +1,3 @@ +title=object-tool-layout-editor +author=admin +path=content/object-tool-layout-editor diff --git a/documentation/18.11/eiffelstudio/_images/object-tool.png b/documentation/18.11/eiffelstudio/_images/object-tool.png new file mode 100644 index 00000000..1828204f Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/object-tool.png differ diff --git a/documentation/18.11/eiffelstudio/_images/object-tool.png.data b/documentation/18.11/eiffelstudio/_images/object-tool.png.data new file mode 100644 index 00000000..0e60a7cd --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/object-tool.png.data @@ -0,0 +1,3 @@ +title=object-tool +author=admin +path=content/object-tool diff --git a/documentation/18.11/eiffelstudio/_images/object-viewer-browse.png b/documentation/18.11/eiffelstudio/_images/object-viewer-browse.png new file mode 100644 index 00000000..933f2488 Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/object-viewer-browse.png differ diff --git a/documentation/18.11/eiffelstudio/_images/object-viewer-browse.png.data b/documentation/18.11/eiffelstudio/_images/object-viewer-browse.png.data new file mode 100644 index 00000000..636c569e --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/object-viewer-browse.png.data @@ -0,0 +1,3 @@ +title=object-viewer-browse +author=admin +path=content/object-viewer-browse diff --git a/documentation/18.11/eiffelstudio/_images/object-viewer-dump.png b/documentation/18.11/eiffelstudio/_images/object-viewer-dump.png new file mode 100644 index 00000000..75fbe3d5 Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/object-viewer-dump.png differ diff --git a/documentation/18.11/eiffelstudio/_images/object-viewer-dump.png.data b/documentation/18.11/eiffelstudio/_images/object-viewer-dump.png.data new file mode 100644 index 00000000..41c2e7ef --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/object-viewer-dump.png.data @@ -0,0 +1,3 @@ +title=object-viewer-dump +author=admin +path=content/object-viewer-dump diff --git a/documentation/18.11/eiffelstudio/_images/object-viewer-internal.png b/documentation/18.11/eiffelstudio/_images/object-viewer-internal.png new file mode 100644 index 00000000..35067aae Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/object-viewer-internal.png differ diff --git a/documentation/18.11/eiffelstudio/_images/object-viewer-internal.png.data b/documentation/18.11/eiffelstudio/_images/object-viewer-internal.png.data new file mode 100644 index 00000000..0e90b43e --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/object-viewer-internal.png.data @@ -0,0 +1,3 @@ +title=object-viewer-internal +author=admin +path=content/object-viewer-internal diff --git a/documentation/18.11/eiffelstudio/_images/object-viewer-xml.png b/documentation/18.11/eiffelstudio/_images/object-viewer-xml.png new file mode 100644 index 00000000..e3fbbe36 Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/object-viewer-xml.png differ diff --git a/documentation/18.11/eiffelstudio/_images/object-viewer-xml.png.data b/documentation/18.11/eiffelstudio/_images/object-viewer-xml.png.data new file mode 100644 index 00000000..7e41ac62 --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/object-viewer-xml.png.data @@ -0,0 +1,3 @@ +title=object-viewer-xml +author=admin +path=content/object-viewer-xml diff --git a/documentation/18.11/eiffelstudio/_images/objects-tool-exception.png b/documentation/18.11/eiffelstudio/_images/objects-tool-exception.png new file mode 100644 index 00000000..6b2319a0 Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/objects-tool-exception.png differ diff --git a/documentation/18.11/eiffelstudio/_images/objects-tool-exception.png.data b/documentation/18.11/eiffelstudio/_images/objects-tool-exception.png.data new file mode 100644 index 00000000..9603a997 --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/objects-tool-exception.png.data @@ -0,0 +1,3 @@ +title=objects-tool-exception +author=admin +path=content/objects-tool-exception diff --git a/documentation/18.11/eiffelstudio/_images/obsolete-items-icon.png b/documentation/18.11/eiffelstudio/_images/obsolete-items-icon.png new file mode 100644 index 00000000..dc163fa5 Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/obsolete-items-icon.png differ diff --git a/documentation/18.11/eiffelstudio/_images/obsolete-items-icon.png.data b/documentation/18.11/eiffelstudio/_images/obsolete-items-icon.png.data new file mode 100644 index 00000000..c57df0db --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/obsolete-items-icon.png.data @@ -0,0 +1,3 @@ +title=obsolete items icon +author=halw +path=content/obsolete-items-icon diff --git a/documentation/18.11/eiffelstudio/_images/previous-error.png b/documentation/18.11/eiffelstudio/_images/previous-error.png new file mode 100644 index 00000000..0123561d Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/previous-error.png differ diff --git a/documentation/18.11/eiffelstudio/_images/previous-error.png.data b/documentation/18.11/eiffelstudio/_images/previous-error.png.data new file mode 100644 index 00000000..30a9f22c --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/previous-error.png.data @@ -0,0 +1,3 @@ +title=previous-error +author=admin +path=content/previous-error diff --git a/documentation/18.11/eiffelstudio/_images/previous-warning.png b/documentation/18.11/eiffelstudio/_images/previous-warning.png new file mode 100644 index 00000000..17b64ca2 Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/previous-warning.png differ diff --git a/documentation/18.11/eiffelstudio/_images/previous-warning.png.data b/documentation/18.11/eiffelstudio/_images/previous-warning.png.data new file mode 100644 index 00000000..e7e63031 --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/previous-warning.png.data @@ -0,0 +1,3 @@ +title=previous-warning +author=admin +path=content/previous-warning diff --git a/documentation/18.11/eiffelstudio/_images/profiler-process.png b/documentation/18.11/eiffelstudio/_images/profiler-process.png new file mode 100644 index 00000000..c4028a44 Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/profiler-process.png differ diff --git a/documentation/18.11/eiffelstudio/_images/profiler-process.png.data b/documentation/18.11/eiffelstudio/_images/profiler-process.png.data new file mode 100644 index 00000000..e13a90c7 --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/profiler-process.png.data @@ -0,0 +1,3 @@ +title=profiler-process +author=admin +path=content/profiler-process diff --git a/documentation/18.11/eiffelstudio/_images/profiler-query-window.png b/documentation/18.11/eiffelstudio/_images/profiler-query-window.png new file mode 100644 index 00000000..90245054 Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/profiler-query-window.png differ diff --git a/documentation/18.11/eiffelstudio/_images/profiler-query-window.png.data b/documentation/18.11/eiffelstudio/_images/profiler-query-window.png.data new file mode 100644 index 00000000..b652c6d5 --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/profiler-query-window.png.data @@ -0,0 +1,3 @@ +title=profiler-query-window +author=admin +path=content/profiler-query-window diff --git a/documentation/18.11/eiffelstudio/_images/profiler-wizard-first-state.png b/documentation/18.11/eiffelstudio/_images/profiler-wizard-first-state.png new file mode 100644 index 00000000..f43c5c5f Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/profiler-wizard-first-state.png differ diff --git a/documentation/18.11/eiffelstudio/_images/profiler-wizard-first-state.png.data b/documentation/18.11/eiffelstudio/_images/profiler-wizard-first-state.png.data new file mode 100644 index 00000000..c2f43825 --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/profiler-wizard-first-state.png.data @@ -0,0 +1,3 @@ +title=profiler-wizard-first-state +author=admin +path=content/profiler-wizard-first-state diff --git a/documentation/18.11/eiffelstudio/_images/profiler-wizard-fourth-state.png b/documentation/18.11/eiffelstudio/_images/profiler-wizard-fourth-state.png new file mode 100644 index 00000000..fc6d761d Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/profiler-wizard-fourth-state.png differ diff --git a/documentation/18.11/eiffelstudio/_images/profiler-wizard-fourth-state.png.data b/documentation/18.11/eiffelstudio/_images/profiler-wizard-fourth-state.png.data new file mode 100644 index 00000000..632fcc2b --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/profiler-wizard-fourth-state.png.data @@ -0,0 +1,3 @@ +title=profiler-wizard-fourth-state +author=admin +path=content/profiler-wizard-fourth-state diff --git a/documentation/18.11/eiffelstudio/_images/profiler-wizard-rtir-error-state.png b/documentation/18.11/eiffelstudio/_images/profiler-wizard-rtir-error-state.png new file mode 100644 index 00000000..2ffd135a Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/profiler-wizard-rtir-error-state.png differ diff --git a/documentation/18.11/eiffelstudio/_images/profiler-wizard-rtir-error-state.png.data b/documentation/18.11/eiffelstudio/_images/profiler-wizard-rtir-error-state.png.data new file mode 100644 index 00000000..ce33cab5 --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/profiler-wizard-rtir-error-state.png.data @@ -0,0 +1,3 @@ +title=profiler-wizard-rtir-error-state +author=admin +path=content/profiler-wizard-rtir-error-state diff --git a/documentation/18.11/eiffelstudio/_images/profiler-wizard-second-state.png b/documentation/18.11/eiffelstudio/_images/profiler-wizard-second-state.png new file mode 100644 index 00000000..5609e9e6 Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/profiler-wizard-second-state.png differ diff --git a/documentation/18.11/eiffelstudio/_images/profiler-wizard-second-state.png.data b/documentation/18.11/eiffelstudio/_images/profiler-wizard-second-state.png.data new file mode 100644 index 00000000..cc8e1f51 --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/profiler-wizard-second-state.png.data @@ -0,0 +1,3 @@ +title=profiler-wizard-second-state +author=admin +path=content/profiler-wizard-second-state diff --git a/documentation/18.11/eiffelstudio/_images/profiler-wizard-third-state.png b/documentation/18.11/eiffelstudio/_images/profiler-wizard-third-state.png new file mode 100644 index 00000000..076780ac Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/profiler-wizard-third-state.png differ diff --git a/documentation/18.11/eiffelstudio/_images/profiler-wizard-third-state.png.data b/documentation/18.11/eiffelstudio/_images/profiler-wizard-third-state.png.data new file mode 100644 index 00000000..af244d6f --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/profiler-wizard-third-state.png.data @@ -0,0 +1,3 @@ +title=profiler-wizard-third-state +author=admin +path=content/profiler-wizard-third-state diff --git a/documentation/18.11/eiffelstudio/_images/project-finalize-icon.png b/documentation/18.11/eiffelstudio/_images/project-finalize-icon.png new file mode 100644 index 00000000..cdfb1d2f Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/project-finalize-icon.png differ diff --git a/documentation/18.11/eiffelstudio/_images/project-finalize-icon.png.data b/documentation/18.11/eiffelstudio/_images/project-finalize-icon.png.data new file mode 100644 index 00000000..59077302 --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/project-finalize-icon.png.data @@ -0,0 +1,3 @@ +title=project-finalize-icon +author=admin +path=content/project-finalize-icon diff --git a/documentation/18.11/eiffelstudio/_images/project-freeze-icon.png b/documentation/18.11/eiffelstudio/_images/project-freeze-icon.png new file mode 100644 index 00000000..d5dd234b Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/project-freeze-icon.png differ diff --git a/documentation/18.11/eiffelstudio/_images/project-freeze-icon.png.data b/documentation/18.11/eiffelstudio/_images/project-freeze-icon.png.data new file mode 100644 index 00000000..23c21208 --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/project-freeze-icon.png.data @@ -0,0 +1,3 @@ +title=project-freeze-icon +author=admin +path=content/project-freeze-icon diff --git a/documentation/18.11/eiffelstudio/_images/project-melt-icon.png b/documentation/18.11/eiffelstudio/_images/project-melt-icon.png new file mode 100644 index 00000000..b399dc97 Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/project-melt-icon.png differ diff --git a/documentation/18.11/eiffelstudio/_images/project-melt-icon.png.data b/documentation/18.11/eiffelstudio/_images/project-melt-icon.png.data new file mode 100644 index 00000000..b0d87fbc --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/project-melt-icon.png.data @@ -0,0 +1,3 @@ +title=project-melt-icon +author=admin +path=content/project-melt-icon diff --git a/documentation/18.11/eiffelstudio/_images/project-toolbar.png b/documentation/18.11/eiffelstudio/_images/project-toolbar.png new file mode 100644 index 00000000..bf9c53f5 Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/project-toolbar.png differ diff --git a/documentation/18.11/eiffelstudio/_images/project-toolbar.png.data b/documentation/18.11/eiffelstudio/_images/project-toolbar.png.data new file mode 100644 index 00000000..94a031cb --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/project-toolbar.png.data @@ -0,0 +1,3 @@ +title=project-toolbar +author=halw +path=content/project-toolbar diff --git a/documentation/18.11/eiffelstudio/_images/query-return-type-icon.png b/documentation/18.11/eiffelstudio/_images/query-return-type-icon.png new file mode 100644 index 00000000..6e9011ec Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/query-return-type-icon.png differ diff --git a/documentation/18.11/eiffelstudio/_images/query-return-type-icon.png.data b/documentation/18.11/eiffelstudio/_images/query-return-type-icon.png.data new file mode 100644 index 00000000..df2fd019 --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/query-return-type-icon.png.data @@ -0,0 +1,3 @@ +title=query return type icon +author=halw +path=content/query-return-type-icon diff --git a/documentation/18.11/eiffelstudio/_images/refactor-feature-up-icon.png b/documentation/18.11/eiffelstudio/_images/refactor-feature-up-icon.png new file mode 100644 index 00000000..914eab3e Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/refactor-feature-up-icon.png differ diff --git a/documentation/18.11/eiffelstudio/_images/refactor-feature-up-icon.png.data b/documentation/18.11/eiffelstudio/_images/refactor-feature-up-icon.png.data new file mode 100644 index 00000000..3c6b01de --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/refactor-feature-up-icon.png.data @@ -0,0 +1,3 @@ +title=refactor-feature-up-icon +author=admin +path=content/refactor-feature-icon diff --git a/documentation/18.11/eiffelstudio/_images/refactor-rename-icon.png b/documentation/18.11/eiffelstudio/_images/refactor-rename-icon.png new file mode 100644 index 00000000..8971a133 Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/refactor-rename-icon.png differ diff --git a/documentation/18.11/eiffelstudio/_images/refactor-rename-icon.png.data b/documentation/18.11/eiffelstudio/_images/refactor-rename-icon.png.data new file mode 100644 index 00000000..a574fded --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/refactor-rename-icon.png.data @@ -0,0 +1,3 @@ +title=refactor-rename-icon +author=admin +path=content/refactor-rename-icon diff --git a/documentation/18.11/eiffelstudio/_images/refactoring-toolbar.png b/documentation/18.11/eiffelstudio/_images/refactoring-toolbar.png new file mode 100644 index 00000000..d27edf6d Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/refactoring-toolbar.png differ diff --git a/documentation/18.11/eiffelstudio/_images/refactoring-toolbar.png.data b/documentation/18.11/eiffelstudio/_images/refactoring-toolbar.png.data new file mode 100644 index 00000000..8ac40c3d --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/refactoring-toolbar.png.data @@ -0,0 +1,3 @@ +title=refactoring-toolbar +author=halw +path=content/refactoring-toolbar diff --git a/documentation/18.11/eiffelstudio/_images/refresh-icon.png b/documentation/18.11/eiffelstudio/_images/refresh-icon.png new file mode 100644 index 00000000..1fcae4ee Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/refresh-icon.png differ diff --git a/documentation/18.11/eiffelstudio/_images/refresh-icon.png.data b/documentation/18.11/eiffelstudio/_images/refresh-icon.png.data new file mode 100644 index 00000000..f258be97 --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/refresh-icon.png.data @@ -0,0 +1,3 @@ +title=refresh-icon +author=halw +path=content/refresh-icon diff --git a/documentation/18.11/eiffelstudio/_images/remember-list-size.png b/documentation/18.11/eiffelstudio/_images/remember-list-size.png new file mode 100644 index 00000000..85fb095f Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/remember-list-size.png differ diff --git a/documentation/18.11/eiffelstudio/_images/remember-list-size.png.data b/documentation/18.11/eiffelstudio/_images/remember-list-size.png.data new file mode 100644 index 00000000..af340b3d --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/remember-list-size.png.data @@ -0,0 +1,3 @@ +title=remember list size icon +author=halw +path=content/remember-list-size-icon diff --git a/documentation/18.11/eiffelstudio/_images/restore-icon.png b/documentation/18.11/eiffelstudio/_images/restore-icon.png new file mode 100644 index 00000000..c6a5a42b Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/restore-icon.png differ diff --git a/documentation/18.11/eiffelstudio/_images/restore-icon.png.data b/documentation/18.11/eiffelstudio/_images/restore-icon.png.data new file mode 100644 index 00000000..84814b85 --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/restore-icon.png.data @@ -0,0 +1,3 @@ +title=restore-icon +author=halw +path=content/restore-icon diff --git a/documentation/18.11/eiffelstudio/_images/run-animation-4-icon.png b/documentation/18.11/eiffelstudio/_images/run-animation-4-icon.png new file mode 100644 index 00000000..e98889b3 Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/run-animation-4-icon.png differ diff --git a/documentation/18.11/eiffelstudio/_images/run-animation-4-icon.png.data b/documentation/18.11/eiffelstudio/_images/run-animation-4-icon.png.data new file mode 100644 index 00000000..046a9dfe --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/run-animation-4-icon.png.data @@ -0,0 +1,3 @@ +title=run-animation-4-icon +author=admin +path=content/run-animation-4-icon diff --git a/documentation/18.11/eiffelstudio/_images/save-button.png b/documentation/18.11/eiffelstudio/_images/save-button.png new file mode 100644 index 00000000..140bca62 Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/save-button.png differ diff --git a/documentation/18.11/eiffelstudio/_images/save-button.png.data b/documentation/18.11/eiffelstudio/_images/save-button.png.data new file mode 100644 index 00000000..df7393f8 --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/save-button.png.data @@ -0,0 +1,3 @@ +title=save-button +author=halw +path=content/save-button diff --git a/documentation/18.11/eiffelstudio/_images/search-icon.png b/documentation/18.11/eiffelstudio/_images/search-icon.png new file mode 100644 index 00000000..d7c704b6 Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/search-icon.png differ diff --git a/documentation/18.11/eiffelstudio/_images/search-icon.png.data b/documentation/18.11/eiffelstudio/_images/search-icon.png.data new file mode 100644 index 00000000..0d9a5d99 --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/search-icon.png.data @@ -0,0 +1,3 @@ +title=search-icon +author=halw +path=content/search-icon diff --git a/documentation/18.11/eiffelstudio/_images/search-report-01.png b/documentation/18.11/eiffelstudio/_images/search-report-01.png new file mode 100644 index 00000000..2d10777b Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/search-report-01.png differ diff --git a/documentation/18.11/eiffelstudio/_images/search-report-01.png.data b/documentation/18.11/eiffelstudio/_images/search-report-01.png.data new file mode 100644 index 00000000..4034024b --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/search-report-01.png.data @@ -0,0 +1,3 @@ +title=search-report-01 +author=halw +path=content/search-report-01 diff --git a/documentation/18.11/eiffelstudio/_images/search-tool-scope-tab.png b/documentation/18.11/eiffelstudio/_images/search-tool-scope-tab.png new file mode 100644 index 00000000..fca01b17 Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/search-tool-scope-tab.png differ diff --git a/documentation/18.11/eiffelstudio/_images/search-tool-scope-tab.png.data b/documentation/18.11/eiffelstudio/_images/search-tool-scope-tab.png.data new file mode 100644 index 00000000..0598921d --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/search-tool-scope-tab.png.data @@ -0,0 +1,3 @@ +title=search-tool-scope-tab +author=halw +path=content/search-tool-scope-tab diff --git a/documentation/18.11/eiffelstudio/_images/search-tool_0.png b/documentation/18.11/eiffelstudio/_images/search-tool_0.png new file mode 100644 index 00000000..bd2bb7d7 Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/search-tool_0.png differ diff --git a/documentation/18.11/eiffelstudio/_images/search-tool_0.png.data b/documentation/18.11/eiffelstudio/_images/search-tool_0.png.data new file mode 100644 index 00000000..8748e61f --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/search-tool_0.png.data @@ -0,0 +1,3 @@ +title=search-tool +author=halw +path=content/search-tool diff --git a/documentation/18.11/eiffelstudio/_images/select-all.png b/documentation/18.11/eiffelstudio/_images/select-all.png new file mode 100644 index 00000000..7c5f3bfb Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/select-all.png differ diff --git a/documentation/18.11/eiffelstudio/_images/select-all.png.data b/documentation/18.11/eiffelstudio/_images/select-all.png.data new file mode 100644 index 00000000..c19c52b1 --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/select-all.png.data @@ -0,0 +1,3 @@ +title=select-all +author=admin +path=content/select-all diff --git a/documentation/18.11/eiffelstudio/_images/select-recalculatable.png b/documentation/18.11/eiffelstudio/_images/select-recalculatable.png new file mode 100644 index 00000000..5949dd15 Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/select-recalculatable.png differ diff --git a/documentation/18.11/eiffelstudio/_images/select-recalculatable.png.data b/documentation/18.11/eiffelstudio/_images/select-recalculatable.png.data new file mode 100644 index 00000000..2bb26cf1 --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/select-recalculatable.png.data @@ -0,0 +1,3 @@ +title=select-recalculatable +author=admin +path=content/select-recalculatable diff --git a/documentation/18.11/eiffelstudio/_images/selection-cri1.png b/documentation/18.11/eiffelstudio/_images/selection-cri1.png new file mode 100644 index 00000000..51d8ae80 Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/selection-cri1.png differ diff --git a/documentation/18.11/eiffelstudio/_images/selection-cri1.png.data b/documentation/18.11/eiffelstudio/_images/selection-cri1.png.data new file mode 100644 index 00000000..d4d0da20 --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/selection-cri1.png.data @@ -0,0 +1,3 @@ +title=selection-cri1 +author=admin +path=content/selection-cri1 diff --git a/documentation/18.11/eiffelstudio/_images/selection-cri2.png b/documentation/18.11/eiffelstudio/_images/selection-cri2.png new file mode 100644 index 00000000..be7c1137 Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/selection-cri2.png differ diff --git a/documentation/18.11/eiffelstudio/_images/selection-cri2.png.data b/documentation/18.11/eiffelstudio/_images/selection-cri2.png.data new file mode 100644 index 00000000..4200b9f1 --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/selection-cri2.png.data @@ -0,0 +1,3 @@ +title=selection-cri2 +author=admin +path=content/selection-cri2 diff --git a/documentation/18.11/eiffelstudio/_images/selection-cri3.png b/documentation/18.11/eiffelstudio/_images/selection-cri3.png new file mode 100644 index 00000000..e819ac9c Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/selection-cri3.png differ diff --git a/documentation/18.11/eiffelstudio/_images/selection-cri3.png.data b/documentation/18.11/eiffelstudio/_images/selection-cri3.png.data new file mode 100644 index 00000000..5c0f6add --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/selection-cri3.png.data @@ -0,0 +1,3 @@ +title=selection-cri3 +author=admin +path=content/selection-cri3 diff --git a/documentation/18.11/eiffelstudio/_images/selection-cri4.png b/documentation/18.11/eiffelstudio/_images/selection-cri4.png new file mode 100644 index 00000000..00767026 Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/selection-cri4.png differ diff --git a/documentation/18.11/eiffelstudio/_images/selection-cri4.png.data b/documentation/18.11/eiffelstudio/_images/selection-cri4.png.data new file mode 100644 index 00000000..5c0ba0d6 --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/selection-cri4.png.data @@ -0,0 +1,3 @@ +title=selection-cri4 +author=admin +path=content/selection-cri4 diff --git a/documentation/18.11/eiffelstudio/_images/selection-cri5.png b/documentation/18.11/eiffelstudio/_images/selection-cri5.png new file mode 100644 index 00000000..5058a9da Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/selection-cri5.png differ diff --git a/documentation/18.11/eiffelstudio/_images/selection-cri5.png.data b/documentation/18.11/eiffelstudio/_images/selection-cri5.png.data new file mode 100644 index 00000000..1ee8df6e --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/selection-cri5.png.data @@ -0,0 +1,3 @@ +title=selection-cri5 +author=admin +path=content/selection-cri5 diff --git a/documentation/18.11/eiffelstudio/_images/selection-cri6.png b/documentation/18.11/eiffelstudio/_images/selection-cri6.png new file mode 100644 index 00000000..b51ddf56 Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/selection-cri6.png differ diff --git a/documentation/18.11/eiffelstudio/_images/selection-cri6.png.data b/documentation/18.11/eiffelstudio/_images/selection-cri6.png.data new file mode 100644 index 00000000..162dc74a --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/selection-cri6.png.data @@ -0,0 +1,3 @@ +title=selection-cri6 +author=admin +path=content/selection-cri6 diff --git a/documentation/18.11/eiffelstudio/_images/selection-cri7.png b/documentation/18.11/eiffelstudio/_images/selection-cri7.png new file mode 100644 index 00000000..e2de4634 Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/selection-cri7.png differ diff --git a/documentation/18.11/eiffelstudio/_images/selection-cri7.png.data b/documentation/18.11/eiffelstudio/_images/selection-cri7.png.data new file mode 100644 index 00000000..05cbc251 --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/selection-cri7.png.data @@ -0,0 +1,3 @@ +title=selection-cri7 +author=admin +path=content/selection-cri7 diff --git a/documentation/18.11/eiffelstudio/_images/selection-cri8.png b/documentation/18.11/eiffelstudio/_images/selection-cri8.png new file mode 100644 index 00000000..6a615ffb Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/selection-cri8.png differ diff --git a/documentation/18.11/eiffelstudio/_images/selection-cri8.png.data b/documentation/18.11/eiffelstudio/_images/selection-cri8.png.data new file mode 100644 index 00000000..66273652 --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/selection-cri8.png.data @@ -0,0 +1,3 @@ +title=selection-cri8 +author=admin +path=content/selection-cri8 diff --git a/documentation/18.11/eiffelstudio/_images/set-default-slice-size-dlg.png b/documentation/18.11/eiffelstudio/_images/set-default-slice-size-dlg.png new file mode 100644 index 00000000..884a5868 Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/set-default-slice-size-dlg.png differ diff --git a/documentation/18.11/eiffelstudio/_images/set-default-slice-size-dlg.png.data b/documentation/18.11/eiffelstudio/_images/set-default-slice-size-dlg.png.data new file mode 100644 index 00000000..8a289cd7 --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/set-default-slice-size-dlg.png.data @@ -0,0 +1,3 @@ +title=set-default-slice-size-dlg +author=admin +path=content/set-default-slice-size-dlg diff --git a/documentation/18.11/eiffelstudio/_images/set-slice-size-dlg.png b/documentation/18.11/eiffelstudio/_images/set-slice-size-dlg.png new file mode 100644 index 00000000..5faf479e Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/set-slice-size-dlg.png differ diff --git a/documentation/18.11/eiffelstudio/_images/set-slice-size-dlg.png.data b/documentation/18.11/eiffelstudio/_images/set-slice-size-dlg.png.data new file mode 100644 index 00000000..5491ebb4 --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/set-slice-size-dlg.png.data @@ -0,0 +1,3 @@ +title=set-slice-size-dlg +author=admin +path=content/set-slice-size-dlg diff --git a/documentation/18.11/eiffelstudio/_images/shared-library-window.png b/documentation/18.11/eiffelstudio/_images/shared-library-window.png new file mode 100644 index 00000000..82d06eb2 Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/shared-library-window.png differ diff --git a/documentation/18.11/eiffelstudio/_images/shared-library-window.png.data b/documentation/18.11/eiffelstudio/_images/shared-library-window.png.data new file mode 100644 index 00000000..59eef466 --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/shared-library-window.png.data @@ -0,0 +1,3 @@ +title=shared-library-window +author=admin +path=content/shared-library-window diff --git a/documentation/18.11/eiffelstudio/_images/show-descriptions-icon.png b/documentation/18.11/eiffelstudio/_images/show-descriptions-icon.png new file mode 100644 index 00000000..0704a548 Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/show-descriptions-icon.png differ diff --git a/documentation/18.11/eiffelstudio/_images/show-descriptions-icon.png.data b/documentation/18.11/eiffelstudio/_images/show-descriptions-icon.png.data new file mode 100644 index 00000000..292cb5a2 --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/show-descriptions-icon.png.data @@ -0,0 +1,3 @@ +title=show descriptions icon +author=halw +path=content/show-descriptions-icon diff --git a/documentation/18.11/eiffelstudio/_images/show-hide-contract-placeholders.png b/documentation/18.11/eiffelstudio/_images/show-hide-contract-placeholders.png new file mode 100644 index 00000000..69e4581d Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/show-hide-contract-placeholders.png differ diff --git a/documentation/18.11/eiffelstudio/_images/show-hide-contract-placeholders.png.data b/documentation/18.11/eiffelstudio/_images/show-hide-contract-placeholders.png.data new file mode 100644 index 00000000..517c6f87 --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/show-hide-contract-placeholders.png.data @@ -0,0 +1,3 @@ +title=show-hide-contract-placeholders-icon +author=halw +path=content/show-hide-contract-placeholders-icon diff --git a/documentation/18.11/eiffelstudio/_images/stack-overflow-dlg.png b/documentation/18.11/eiffelstudio/_images/stack-overflow-dlg.png new file mode 100644 index 00000000..2a0e2155 Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/stack-overflow-dlg.png differ diff --git a/documentation/18.11/eiffelstudio/_images/stack-overflow-dlg.png.data b/documentation/18.11/eiffelstudio/_images/stack-overflow-dlg.png.data new file mode 100644 index 00000000..2feb5a89 --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/stack-overflow-dlg.png.data @@ -0,0 +1,3 @@ +title=stack-overflow-dlg +author=admin +path=content/stack-overflow-dlg diff --git a/documentation/18.11/eiffelstudio/_images/standard-buttons-toolbar.png b/documentation/18.11/eiffelstudio/_images/standard-buttons-toolbar.png new file mode 100644 index 00000000..df7189d8 Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/standard-buttons-toolbar.png differ diff --git a/documentation/18.11/eiffelstudio/_images/standard-buttons-toolbar.png.data b/documentation/18.11/eiffelstudio/_images/standard-buttons-toolbar.png.data new file mode 100644 index 00000000..0c978c8f --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/standard-buttons-toolbar.png.data @@ -0,0 +1,3 @@ +title=standard-buttons-toolbar +author=halw +path=content/standard-buttons-toolbar diff --git a/documentation/18.11/eiffelstudio/_images/startup-dialog.png b/documentation/18.11/eiffelstudio/_images/startup-dialog.png new file mode 100644 index 00000000..36382b8a Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/startup-dialog.png differ diff --git a/documentation/18.11/eiffelstudio/_images/startup-dialog.png.data b/documentation/18.11/eiffelstudio/_images/startup-dialog.png.data new file mode 100644 index 00000000..17a58ccf --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/startup-dialog.png.data @@ -0,0 +1,3 @@ +title=startup-dialog +author=admin +path=content/startup-dialog diff --git a/documentation/18.11/eiffelstudio/_images/subversion-update-command-02_0.png b/documentation/18.11/eiffelstudio/_images/subversion-update-command-02_0.png new file mode 100644 index 00000000..4670b0f3 Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/subversion-update-command-02_0.png differ diff --git a/documentation/18.11/eiffelstudio/_images/subversion-update-command-02_0.png.data b/documentation/18.11/eiffelstudio/_images/subversion-update-command-02_0.png.data new file mode 100644 index 00000000..8e2a38ca --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/subversion-update-command-02_0.png.data @@ -0,0 +1,3 @@ +title=subversion-update-command-02 +author=halw +path=content/subversion-update-command-02 diff --git a/documentation/18.11/eiffelstudio/_images/subversion-update-console-window.png b/documentation/18.11/eiffelstudio/_images/subversion-update-console-window.png new file mode 100644 index 00000000..7f60ffe2 Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/subversion-update-console-window.png differ diff --git a/documentation/18.11/eiffelstudio/_images/subversion-update-console-window.png.data b/documentation/18.11/eiffelstudio/_images/subversion-update-console-window.png.data new file mode 100644 index 00000000..91bcfdc0 --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/subversion-update-console-window.png.data @@ -0,0 +1,3 @@ +title=subversion-update-console-tool +author=halw +path=content/subversion-update-console-tool diff --git a/documentation/18.11/eiffelstudio/_images/subversion_update_in_tools_menu.png b/documentation/18.11/eiffelstudio/_images/subversion_update_in_tools_menu.png new file mode 100644 index 00000000..5e0c79f9 Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/subversion_update_in_tools_menu.png differ diff --git a/documentation/18.11/eiffelstudio/_images/subversion_update_in_tools_menu.png.data b/documentation/18.11/eiffelstudio/_images/subversion_update_in_tools_menu.png.data new file mode 100644 index 00000000..8a5211f0 --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/subversion_update_in_tools_menu.png.data @@ -0,0 +1,3 @@ +title=subversion-update-in-tools-menu +author=halw +path=content/subversion-update-tools-menu diff --git a/documentation/18.11/eiffelstudio/_images/system-hierarchy.jpg b/documentation/18.11/eiffelstudio/_images/system-hierarchy.jpg new file mode 100644 index 00000000..d85a0a04 Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/system-hierarchy.jpg differ diff --git a/documentation/18.11/eiffelstudio/_images/system-hierarchy.jpg.data b/documentation/18.11/eiffelstudio/_images/system-hierarchy.jpg.data new file mode 100644 index 00000000..104575d1 --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/system-hierarchy.jpg.data @@ -0,0 +1,3 @@ +title=system-hierarchy +author=admin +path=content/system-hierarchy diff --git a/documentation/18.11/eiffelstudio/_images/system-options.png b/documentation/18.11/eiffelstudio/_images/system-options.png new file mode 100644 index 00000000..41cdceff Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/system-options.png differ diff --git a/documentation/18.11/eiffelstudio/_images/system-options.png.data b/documentation/18.11/eiffelstudio/_images/system-options.png.data new file mode 100644 index 00000000..0108e513 --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/system-options.png.data @@ -0,0 +1,3 @@ +title=system-options +author=admin +path=content/system-options diff --git a/documentation/18.11/eiffelstudio/_images/target_template_1_0.png b/documentation/18.11/eiffelstudio/_images/target_template_1_0.png new file mode 100644 index 00000000..a2ed9155 Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/target_template_1_0.png differ diff --git a/documentation/18.11/eiffelstudio/_images/target_template_1_1.png b/documentation/18.11/eiffelstudio/_images/target_template_1_1.png new file mode 100644 index 00000000..47880c63 Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/target_template_1_1.png differ diff --git a/documentation/18.11/eiffelstudio/_images/target_template_1_2.png b/documentation/18.11/eiffelstudio/_images/target_template_1_2.png new file mode 100644 index 00000000..d50cc3d5 Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/target_template_1_2.png differ diff --git a/documentation/18.11/eiffelstudio/_images/target_template_1_3.png b/documentation/18.11/eiffelstudio/_images/target_template_1_3.png new file mode 100644 index 00000000..970a0a28 Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/target_template_1_3.png differ diff --git a/documentation/18.11/eiffelstudio/_images/target_template_1_4.png b/documentation/18.11/eiffelstudio/_images/target_template_1_4.png new file mode 100644 index 00000000..14cf9153 Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/target_template_1_4.png differ diff --git a/documentation/18.11/eiffelstudio/_images/target_template_with_defaults_overridden_1_1.png b/documentation/18.11/eiffelstudio/_images/target_template_with_defaults_overridden_1_1.png new file mode 100644 index 00000000..c100144b Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/target_template_with_defaults_overridden_1_1.png differ diff --git a/documentation/18.11/eiffelstudio/_images/target_template_with_defaults_overridden_1_2.png b/documentation/18.11/eiffelstudio/_images/target_template_with_defaults_overridden_1_2.png new file mode 100644 index 00000000..d4b4e50a Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/target_template_with_defaults_overridden_1_2.png differ diff --git a/documentation/18.11/eiffelstudio/_images/target_template_with_input_parameters_1_0.png b/documentation/18.11/eiffelstudio/_images/target_template_with_input_parameters_1_0.png new file mode 100644 index 00000000..577825cd Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/target_template_with_input_parameters_1_0.png differ diff --git a/documentation/18.11/eiffelstudio/_images/target_template_with_input_parameters_1_1.png b/documentation/18.11/eiffelstudio/_images/target_template_with_input_parameters_1_1.png new file mode 100644 index 00000000..a9bcdd9a Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/target_template_with_input_parameters_1_1.png differ diff --git a/documentation/18.11/eiffelstudio/_images/target_template_with_input_parameters_1_2.png b/documentation/18.11/eiffelstudio/_images/target_template_with_input_parameters_1_2.png new file mode 100644 index 00000000..8db2aa86 Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/target_template_with_input_parameters_1_2.png differ diff --git a/documentation/18.11/eiffelstudio/_images/targetless_template_1_3.png b/documentation/18.11/eiffelstudio/_images/targetless_template_1_3.png new file mode 100644 index 00000000..b8362a8b Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/targetless_template_1_3.png differ diff --git a/documentation/18.11/eiffelstudio/_images/targetless_template_1_4.png b/documentation/18.11/eiffelstudio/_images/targetless_template_1_4.png new file mode 100644 index 00000000..05c72190 Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/targetless_template_1_4.png differ diff --git a/documentation/18.11/eiffelstudio/_images/task-options.png b/documentation/18.11/eiffelstudio/_images/task-options.png new file mode 100644 index 00000000..febd620b Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/task-options.png differ diff --git a/documentation/18.11/eiffelstudio/_images/task-options.png.data b/documentation/18.11/eiffelstudio/_images/task-options.png.data new file mode 100644 index 00000000..01f232e9 --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/task-options.png.data @@ -0,0 +1,3 @@ +title=task-options +author=admin +path=content/task-options diff --git a/documentation/18.11/eiffelstudio/_images/terminal-icon.png b/documentation/18.11/eiffelstudio/_images/terminal-icon.png new file mode 100644 index 00000000..bc1e9a04 Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/terminal-icon.png differ diff --git a/documentation/18.11/eiffelstudio/_images/terminal-icon.png.data b/documentation/18.11/eiffelstudio/_images/terminal-icon.png.data new file mode 100644 index 00000000..824cec51 --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/terminal-icon.png.data @@ -0,0 +1,3 @@ +title=terminal-icon +author=halw +path=content/terminal-icon diff --git a/documentation/18.11/eiffelstudio/_images/threads-tool.png b/documentation/18.11/eiffelstudio/_images/threads-tool.png new file mode 100644 index 00000000..51d81ab4 Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/threads-tool.png differ diff --git a/documentation/18.11/eiffelstudio/_images/threads-tool.png.data b/documentation/18.11/eiffelstudio/_images/threads-tool.png.data new file mode 100644 index 00000000..196ea1aa --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/threads-tool.png.data @@ -0,0 +1,3 @@ +title=threads-tool +author=admin +path=content/threads-tool diff --git a/documentation/18.11/eiffelstudio/_images/tool-breakpoints-icon.png b/documentation/18.11/eiffelstudio/_images/tool-breakpoints-icon.png new file mode 100644 index 00000000..6f4ac895 Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/tool-breakpoints-icon.png differ diff --git a/documentation/18.11/eiffelstudio/_images/tool-breakpoints-icon.png.data b/documentation/18.11/eiffelstudio/_images/tool-breakpoints-icon.png.data new file mode 100644 index 00000000..9bcb5d56 --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/tool-breakpoints-icon.png.data @@ -0,0 +1,3 @@ +title=tool-breakpoints-icon +author=admin +path=content/tool-breakpoints-icon diff --git a/documentation/18.11/eiffelstudio/_images/tool-clusters-icon.png b/documentation/18.11/eiffelstudio/_images/tool-clusters-icon.png new file mode 100644 index 00000000..03d4a06b Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/tool-clusters-icon.png differ diff --git a/documentation/18.11/eiffelstudio/_images/tool-clusters-icon.png.data b/documentation/18.11/eiffelstudio/_images/tool-clusters-icon.png.data new file mode 100644 index 00000000..21e26fb2 --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/tool-clusters-icon.png.data @@ -0,0 +1,3 @@ +title=tool-clusters-icon +author=admin +path=content/tool-clusters-icon diff --git a/documentation/18.11/eiffelstudio/_images/tool-config-icon.png b/documentation/18.11/eiffelstudio/_images/tool-config-icon.png new file mode 100644 index 00000000..32eafe67 Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/tool-config-icon.png differ diff --git a/documentation/18.11/eiffelstudio/_images/tool-config-icon.png.data b/documentation/18.11/eiffelstudio/_images/tool-config-icon.png.data new file mode 100644 index 00000000..a9a0be89 --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/tool-config-icon.png.data @@ -0,0 +1,3 @@ +title=tool-config-icon +author=admin +path=content/tool-config-icon diff --git a/documentation/18.11/eiffelstudio/_images/tool-favorites-icon.png b/documentation/18.11/eiffelstudio/_images/tool-favorites-icon.png new file mode 100644 index 00000000..d62207f3 Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/tool-favorites-icon.png differ diff --git a/documentation/18.11/eiffelstudio/_images/tool-favorites-icon.png.data b/documentation/18.11/eiffelstudio/_images/tool-favorites-icon.png.data new file mode 100644 index 00000000..70b62416 --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/tool-favorites-icon.png.data @@ -0,0 +1,3 @@ +title=tool-favorites-icon +author=admin +path=content/tool-favorites-icon diff --git a/documentation/18.11/eiffelstudio/_images/tool-search-icon.png b/documentation/18.11/eiffelstudio/_images/tool-search-icon.png new file mode 100644 index 00000000..aee620b2 Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/tool-search-icon.png differ diff --git a/documentation/18.11/eiffelstudio/_images/tool-search-icon.png.data b/documentation/18.11/eiffelstudio/_images/tool-search-icon.png.data new file mode 100644 index 00000000..05cc482d --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/tool-search-icon.png.data @@ -0,0 +1,3 @@ +title=tool-search-icon +author=admin +path=content/tool-search-icon diff --git a/documentation/18.11/eiffelstudio/_images/toolbar-close-icon.png b/documentation/18.11/eiffelstudio/_images/toolbar-close-icon.png new file mode 100644 index 00000000..48a70234 Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/toolbar-close-icon.png differ diff --git a/documentation/18.11/eiffelstudio/_images/toolbar-close-icon.png.data b/documentation/18.11/eiffelstudio/_images/toolbar-close-icon.png.data new file mode 100644 index 00000000..bd840003 --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/toolbar-close-icon.png.data @@ -0,0 +1,3 @@ +title=toolbar-close-icon +author=admin +path=content/toolbar-close-icon diff --git a/documentation/18.11/eiffelstudio/_images/toolbar-context-menu.png b/documentation/18.11/eiffelstudio/_images/toolbar-context-menu.png new file mode 100644 index 00000000..616af67c Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/toolbar-context-menu.png differ diff --git a/documentation/18.11/eiffelstudio/_images/toolbar-context-menu.png.data b/documentation/18.11/eiffelstudio/_images/toolbar-context-menu.png.data new file mode 100644 index 00000000..17a5400d --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/toolbar-context-menu.png.data @@ -0,0 +1,3 @@ +title=toolbar-context-menu +author=halw +path=content/toolbar-context-menu diff --git a/documentation/18.11/eiffelstudio/_images/toolbar-dropdown-icon.png b/documentation/18.11/eiffelstudio/_images/toolbar-dropdown-icon.png new file mode 100644 index 00000000..ab9af052 Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/toolbar-dropdown-icon.png differ diff --git a/documentation/18.11/eiffelstudio/_images/toolbar-dropdown-icon.png.data b/documentation/18.11/eiffelstudio/_images/toolbar-dropdown-icon.png.data new file mode 100644 index 00000000..2f6d8d36 --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/toolbar-dropdown-icon.png.data @@ -0,0 +1,3 @@ +title=toolbar-dropdown-icon +author=admin +path=content/toolbar-dropdown-icon diff --git a/documentation/18.11/eiffelstudio/_images/toolbar-head-icon_0.png b/documentation/18.11/eiffelstudio/_images/toolbar-head-icon_0.png new file mode 100644 index 00000000..e27df32d Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/toolbar-head-icon_0.png differ diff --git a/documentation/18.11/eiffelstudio/_images/toolbar-head-icon_0.png.data b/documentation/18.11/eiffelstudio/_images/toolbar-head-icon_0.png.data new file mode 100644 index 00000000..ea5448dd --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/toolbar-head-icon_0.png.data @@ -0,0 +1,3 @@ +title=toolbar-head-icon +author=halw +path=content/toolbar-head-icon diff --git a/documentation/18.11/eiffelstudio/_images/toolbar-maximize-icon.png b/documentation/18.11/eiffelstudio/_images/toolbar-maximize-icon.png new file mode 100644 index 00000000..6a232635 Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/toolbar-maximize-icon.png differ diff --git a/documentation/18.11/eiffelstudio/_images/toolbar-maximize-icon.png.data b/documentation/18.11/eiffelstudio/_images/toolbar-maximize-icon.png.data new file mode 100644 index 00000000..3f706ab0 --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/toolbar-maximize-icon.png.data @@ -0,0 +1,3 @@ +title=toolbar-maximize-icon +author=admin +path=content/toolbar-maximize-icon diff --git a/documentation/18.11/eiffelstudio/_images/toolbar-minimize-icon.png b/documentation/18.11/eiffelstudio/_images/toolbar-minimize-icon.png new file mode 100644 index 00000000..280bba1b Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/toolbar-minimize-icon.png differ diff --git a/documentation/18.11/eiffelstudio/_images/toolbar-minimize-icon.png.data b/documentation/18.11/eiffelstudio/_images/toolbar-minimize-icon.png.data new file mode 100644 index 00000000..e7b850cc --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/toolbar-minimize-icon.png.data @@ -0,0 +1,3 @@ +title=toolbar-minimize-icon +author=admin +path=content/toolbar-minimize-icon diff --git a/documentation/18.11/eiffelstudio/_images/toolbar-options-dropdown.png b/documentation/18.11/eiffelstudio/_images/toolbar-options-dropdown.png new file mode 100644 index 00000000..473c490c Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/toolbar-options-dropdown.png differ diff --git a/documentation/18.11/eiffelstudio/_images/toolbar-options-dropdown.png.data b/documentation/18.11/eiffelstudio/_images/toolbar-options-dropdown.png.data new file mode 100644 index 00000000..94c6aa2f --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/toolbar-options-dropdown.png.data @@ -0,0 +1,3 @@ +title=toolbar-options-dropdown +author=halw +path=content/toolbar-options-dropdown diff --git a/documentation/18.11/eiffelstudio/_images/toolbar-restore-icon.png b/documentation/18.11/eiffelstudio/_images/toolbar-restore-icon.png new file mode 100644 index 00000000..a493244f Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/toolbar-restore-icon.png differ diff --git a/documentation/18.11/eiffelstudio/_images/toolbar-restore-icon.png.data b/documentation/18.11/eiffelstudio/_images/toolbar-restore-icon.png.data new file mode 100644 index 00000000..d37c90e8 --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/toolbar-restore-icon.png.data @@ -0,0 +1,3 @@ +title=toolbar-restore-icon +author=admin +path=content/toolbar-restore-icon diff --git a/documentation/18.11/eiffelstudio/_images/trace_01_off.png b/documentation/18.11/eiffelstudio/_images/trace_01_off.png new file mode 100644 index 00000000..6cff0ebd Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/trace_01_off.png differ diff --git a/documentation/18.11/eiffelstudio/_images/trace_01_off.png.data b/documentation/18.11/eiffelstudio/_images/trace_01_off.png.data new file mode 100644 index 00000000..cc8c774d --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/trace_01_off.png.data @@ -0,0 +1,3 @@ +title=Tracing 01 off +author=halw +path=content/tracing-01 diff --git a/documentation/18.11/eiffelstudio/_images/trace_01_on.png b/documentation/18.11/eiffelstudio/_images/trace_01_on.png new file mode 100644 index 00000000..8c2691ca Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/trace_01_on.png differ diff --git a/documentation/18.11/eiffelstudio/_images/trace_01_on.png.data b/documentation/18.11/eiffelstudio/_images/trace_01_on.png.data new file mode 100644 index 00000000..c9dc2bff --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/trace_01_on.png.data @@ -0,0 +1,3 @@ +title=Tracing 01 on +author=halw +path=content/tracing-01-0 diff --git a/documentation/18.11/eiffelstudio/_images/trace_01_with_eiffelbase.png b/documentation/18.11/eiffelstudio/_images/trace_01_with_eiffelbase.png new file mode 100644 index 00000000..91208759 Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/trace_01_with_eiffelbase.png differ diff --git a/documentation/18.11/eiffelstudio/_images/trace_01_with_eiffelbase.png.data b/documentation/18.11/eiffelstudio/_images/trace_01_with_eiffelbase.png.data new file mode 100644 index 00000000..db04b133 --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/trace_01_with_eiffelbase.png.data @@ -0,0 +1,3 @@ +title=Tracing 01 with EiffelBase +author=halw +path=content/tracing-01-eiffelbase diff --git a/documentation/18.11/eiffelstudio/_images/un-auto-hide-icon.png b/documentation/18.11/eiffelstudio/_images/un-auto-hide-icon.png new file mode 100644 index 00000000..4479127e Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/un-auto-hide-icon.png differ diff --git a/documentation/18.11/eiffelstudio/_images/un-auto-hide-icon.png.data b/documentation/18.11/eiffelstudio/_images/un-auto-hide-icon.png.data new file mode 100644 index 00000000..0f3d020a --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/un-auto-hide-icon.png.data @@ -0,0 +1,3 @@ +title=auto-hide-off-icon +author=halw +path=content/auto-hide-icon-0 diff --git a/documentation/18.11/eiffelstudio/_images/unused-feature-criterion.jpg b/documentation/18.11/eiffelstudio/_images/unused-feature-criterion.jpg new file mode 100644 index 00000000..c45e153c Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/unused-feature-criterion.jpg differ diff --git a/documentation/18.11/eiffelstudio/_images/unused-feature-criterion.jpg.data b/documentation/18.11/eiffelstudio/_images/unused-feature-criterion.jpg.data new file mode 100644 index 00000000..0ab8e83b --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/unused-feature-criterion.jpg.data @@ -0,0 +1,3 @@ +title=unused-feature-criterion +author=admin +path=content/unused-feature-criterion diff --git a/documentation/18.11/eiffelstudio/_images/unused-feature.jpg b/documentation/18.11/eiffelstudio/_images/unused-feature.jpg new file mode 100644 index 00000000..994d76f1 Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/unused-feature.jpg differ diff --git a/documentation/18.11/eiffelstudio/_images/unused-feature.jpg.data b/documentation/18.11/eiffelstudio/_images/unused-feature.jpg.data new file mode 100644 index 00000000..6b14bcb3 --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/unused-feature.jpg.data @@ -0,0 +1,3 @@ +title=unused-feature +author=admin +path=content/unused-feature diff --git a/documentation/18.11/eiffelstudio/_images/use-cluster-names.png b/documentation/18.11/eiffelstudio/_images/use-cluster-names.png new file mode 100644 index 00000000..01cb1b7f Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/use-cluster-names.png differ diff --git a/documentation/18.11/eiffelstudio/_images/use-cluster-names.png.data b/documentation/18.11/eiffelstudio/_images/use-cluster-names.png.data new file mode 100644 index 00000000..95d6175a --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/use-cluster-names.png.data @@ -0,0 +1,3 @@ +title=use-cluster-names +author=admin +path=content/use-cluster-names diff --git a/documentation/18.11/eiffelstudio/_images/use-full-cluster-names.png b/documentation/18.11/eiffelstudio/_images/use-full-cluster-names.png new file mode 100644 index 00000000..d03a6dc7 Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/use-full-cluster-names.png differ diff --git a/documentation/18.11/eiffelstudio/_images/use-full-cluster-names.png.data b/documentation/18.11/eiffelstudio/_images/use-full-cluster-names.png.data new file mode 100644 index 00000000..4de1d76f --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/use-full-cluster-names.png.data @@ -0,0 +1,3 @@ +title=use-full-cluster-names +author=admin +path=content/use-full-cluster-names diff --git a/documentation/18.11/eiffelstudio/_images/use-namespace-name.png b/documentation/18.11/eiffelstudio/_images/use-namespace-name.png new file mode 100644 index 00000000..9372b40a Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/use-namespace-name.png differ diff --git a/documentation/18.11/eiffelstudio/_images/use-namespace-name.png.data b/documentation/18.11/eiffelstudio/_images/use-namespace-name.png.data new file mode 100644 index 00000000..9fc86c7e --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/use-namespace-name.png.data @@ -0,0 +1,3 @@ +title=use-namespace-name +author=admin +path=content/use-namespace-name diff --git a/documentation/18.11/eiffelstudio/_images/value-of-metric-is.jpg b/documentation/18.11/eiffelstudio/_images/value-of-metric-is.jpg new file mode 100644 index 00000000..1d8b7ba7 Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/value-of-metric-is.jpg differ diff --git a/documentation/18.11/eiffelstudio/_images/value-of-metric-is.jpg.data b/documentation/18.11/eiffelstudio/_images/value-of-metric-is.jpg.data new file mode 100644 index 00000000..15995e60 --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/value-of-metric-is.jpg.data @@ -0,0 +1,3 @@ +title=value-of-metric-is +author=admin +path=content/value-metric diff --git a/documentation/18.11/eiffelstudio/_images/value-tester.jpg b/documentation/18.11/eiffelstudio/_images/value-tester.jpg new file mode 100644 index 00000000..d3fe12a5 Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/value-tester.jpg differ diff --git a/documentation/18.11/eiffelstudio/_images/value-tester.jpg.data b/documentation/18.11/eiffelstudio/_images/value-tester.jpg.data new file mode 100644 index 00000000..a81caabe --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/value-tester.jpg.data @@ -0,0 +1,3 @@ +title=value-tester +author=admin +path=content/value-tester diff --git a/documentation/18.11/eiffelstudio/_images/variable-options.png b/documentation/18.11/eiffelstudio/_images/variable-options.png new file mode 100644 index 00000000..9f1bd83b Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/variable-options.png differ diff --git a/documentation/18.11/eiffelstudio/_images/variable-options.png.data b/documentation/18.11/eiffelstudio/_images/variable-options.png.data new file mode 100644 index 00000000..441aaa6a --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/variable-options.png.data @@ -0,0 +1,3 @@ +title=variable-options +author=admin +path=content/variable-options diff --git a/documentation/18.11/eiffelstudio/_images/view-buttons.png b/documentation/18.11/eiffelstudio/_images/view-buttons.png new file mode 100644 index 00000000..24b902ee Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/view-buttons.png differ diff --git a/documentation/18.11/eiffelstudio/_images/view-buttons.png.data b/documentation/18.11/eiffelstudio/_images/view-buttons.png.data new file mode 100644 index 00000000..b2c63183 --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/view-buttons.png.data @@ -0,0 +1,3 @@ +title=view-buttons +author=halw +path=content/view-buttons diff --git a/documentation/18.11/eiffelstudio/_images/view-clickable-feature-icon.png b/documentation/18.11/eiffelstudio/_images/view-clickable-feature-icon.png new file mode 100644 index 00000000..c7d23162 Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/view-clickable-feature-icon.png differ diff --git a/documentation/18.11/eiffelstudio/_images/view-clickable-feature-icon.png.data b/documentation/18.11/eiffelstudio/_images/view-clickable-feature-icon.png.data new file mode 100644 index 00000000..1ebba67c --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/view-clickable-feature-icon.png.data @@ -0,0 +1,3 @@ +title=view-clickable-feature-icon +author=admin +path=content/view-clickable-feature-icon diff --git a/documentation/18.11/eiffelstudio/_images/view-clickable-icon.png b/documentation/18.11/eiffelstudio/_images/view-clickable-icon.png new file mode 100644 index 00000000..d20d2c93 Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/view-clickable-icon.png differ diff --git a/documentation/18.11/eiffelstudio/_images/view-clickable-icon.png.data b/documentation/18.11/eiffelstudio/_images/view-clickable-icon.png.data new file mode 100644 index 00000000..6d86e6a4 --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/view-clickable-icon.png.data @@ -0,0 +1,3 @@ +title=view-clickable-icon +author=admin +path=content/view-clickable-icon diff --git a/documentation/18.11/eiffelstudio/_images/view-contracts-icon.png b/documentation/18.11/eiffelstudio/_images/view-contracts-icon.png new file mode 100644 index 00000000..447fcf03 Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/view-contracts-icon.png differ diff --git a/documentation/18.11/eiffelstudio/_images/view-contracts-icon.png.data b/documentation/18.11/eiffelstudio/_images/view-contracts-icon.png.data new file mode 100644 index 00000000..8147de96 --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/view-contracts-icon.png.data @@ -0,0 +1,3 @@ +title=view-contracts-icon +author=admin +path=content/view-contracts-icon diff --git a/documentation/18.11/eiffelstudio/_images/view-editor-feature-icon.png b/documentation/18.11/eiffelstudio/_images/view-editor-feature-icon.png new file mode 100644 index 00000000..002c17e1 Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/view-editor-feature-icon.png differ diff --git a/documentation/18.11/eiffelstudio/_images/view-editor-feature-icon.png.data b/documentation/18.11/eiffelstudio/_images/view-editor-feature-icon.png.data new file mode 100644 index 00000000..cb0eecf5 --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/view-editor-feature-icon.png.data @@ -0,0 +1,3 @@ +title=view-editor-feature-icon +author=admin +path=content/view-editor-feature-icon diff --git a/documentation/18.11/eiffelstudio/_images/view-editor-icon.png b/documentation/18.11/eiffelstudio/_images/view-editor-icon.png new file mode 100644 index 00000000..42fdb468 Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/view-editor-icon.png differ diff --git a/documentation/18.11/eiffelstudio/_images/view-editor-icon.png.data b/documentation/18.11/eiffelstudio/_images/view-editor-icon.png.data new file mode 100644 index 00000000..050a1a5f --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/view-editor-icon.png.data @@ -0,0 +1,3 @@ +title=view-editor-icon +author=admin +path=content/view-editor-icon diff --git a/documentation/18.11/eiffelstudio/_images/view-flat-contracts-icon.png b/documentation/18.11/eiffelstudio/_images/view-flat-contracts-icon.png new file mode 100644 index 00000000..4528a839 Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/view-flat-contracts-icon.png differ diff --git a/documentation/18.11/eiffelstudio/_images/view-flat-contracts-icon.png.data b/documentation/18.11/eiffelstudio/_images/view-flat-contracts-icon.png.data new file mode 100644 index 00000000..138adde0 --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/view-flat-contracts-icon.png.data @@ -0,0 +1,3 @@ +title=view-flat-contracts-icon +author=admin +path=content/view-flat-contracts-icon diff --git a/documentation/18.11/eiffelstudio/_images/view-flat-icon.png b/documentation/18.11/eiffelstudio/_images/view-flat-icon.png new file mode 100644 index 00000000..d8afecee Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/view-flat-icon.png differ diff --git a/documentation/18.11/eiffelstudio/_images/view-flat-icon.png.data b/documentation/18.11/eiffelstudio/_images/view-flat-icon.png.data new file mode 100644 index 00000000..f14d4545 --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/view-flat-icon.png.data @@ -0,0 +1,3 @@ +title=view-flat-icon +author=admin +path=content/view-flat-icon diff --git a/documentation/18.11/eiffelstudio/_images/view-next-icon.png b/documentation/18.11/eiffelstudio/_images/view-next-icon.png new file mode 100644 index 00000000..75804537 Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/view-next-icon.png differ diff --git a/documentation/18.11/eiffelstudio/_images/view-next-icon.png.data b/documentation/18.11/eiffelstudio/_images/view-next-icon.png.data new file mode 100644 index 00000000..a60c1a1a --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/view-next-icon.png.data @@ -0,0 +1,3 @@ +title=view-next-icon +author=admin +path=content/view-next-icon diff --git a/documentation/18.11/eiffelstudio/_images/view-previous-icon.png b/documentation/18.11/eiffelstudio/_images/view-previous-icon.png new file mode 100644 index 00000000..4c76a32c Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/view-previous-icon.png differ diff --git a/documentation/18.11/eiffelstudio/_images/view-previous-icon.png.data b/documentation/18.11/eiffelstudio/_images/view-previous-icon.png.data new file mode 100644 index 00000000..10882021 --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/view-previous-icon.png.data @@ -0,0 +1,3 @@ +title=view-previous-icon +author=admin +path=content/view-previous-icon diff --git a/documentation/18.11/eiffelstudio/_images/view-unmodified-icon.png b/documentation/18.11/eiffelstudio/_images/view-unmodified-icon.png new file mode 100644 index 00000000..57bf3d8a Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/view-unmodified-icon.png differ diff --git a/documentation/18.11/eiffelstudio/_images/view-unmodified-icon.png.data b/documentation/18.11/eiffelstudio/_images/view-unmodified-icon.png.data new file mode 100644 index 00000000..f2905272 --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/view-unmodified-icon.png.data @@ -0,0 +1,3 @@ +title=view-unmodified-icon +author=admin +path=content/view-unmodified-icon diff --git a/documentation/18.11/eiffelstudio/_images/visible-metric.jpg b/documentation/18.11/eiffelstudio/_images/visible-metric.jpg new file mode 100644 index 00000000..a075ffb0 Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/visible-metric.jpg differ diff --git a/documentation/18.11/eiffelstudio/_images/visible-metric.jpg.data b/documentation/18.11/eiffelstudio/_images/visible-metric.jpg.data new file mode 100644 index 00000000..657ad140 --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/visible-metric.jpg.data @@ -0,0 +1,3 @@ +title=visible-metric +author=admin +path=content/visible-metric diff --git a/documentation/18.11/eiffelstudio/_images/visible-metric2.jpg b/documentation/18.11/eiffelstudio/_images/visible-metric2.jpg new file mode 100644 index 00000000..37e2a175 Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/visible-metric2.jpg differ diff --git a/documentation/18.11/eiffelstudio/_images/visible-metric2.jpg.data b/documentation/18.11/eiffelstudio/_images/visible-metric2.jpg.data new file mode 100644 index 00000000..89b8dd9c --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/visible-metric2.jpg.data @@ -0,0 +1,3 @@ +title=visible-metric2 +author=admin +path=content/visible-metric2 diff --git a/documentation/18.11/eiffelstudio/_images/warning-options.png b/documentation/18.11/eiffelstudio/_images/warning-options.png new file mode 100644 index 00000000..5382e4f9 Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/warning-options.png differ diff --git a/documentation/18.11/eiffelstudio/_images/warning-options.png.data b/documentation/18.11/eiffelstudio/_images/warning-options.png.data new file mode 100644 index 00000000..2e63e694 --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/warning-options.png.data @@ -0,0 +1,3 @@ +title=warning-options +author=admin +path=content/warning-options diff --git a/documentation/18.11/eiffelstudio/_images/warning.png b/documentation/18.11/eiffelstudio/_images/warning.png new file mode 100644 index 00000000..0a0366d1 Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/warning.png differ diff --git a/documentation/18.11/eiffelstudio/_images/warning.png.data b/documentation/18.11/eiffelstudio/_images/warning.png.data new file mode 100644 index 00000000..1df19ffd --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/warning.png.data @@ -0,0 +1,3 @@ +title=warning +author=admin +path=content/warning-0 diff --git a/documentation/18.11/eiffelstudio/_images/windows-minimize-all-icon.png b/documentation/18.11/eiffelstudio/_images/windows-minimize-all-icon.png new file mode 100644 index 00000000..1e8fcdea Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/windows-minimize-all-icon.png differ diff --git a/documentation/18.11/eiffelstudio/_images/windows-minimize-all-icon.png.data b/documentation/18.11/eiffelstudio/_images/windows-minimize-all-icon.png.data new file mode 100644 index 00000000..e31b682f --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/windows-minimize-all-icon.png.data @@ -0,0 +1,3 @@ +title=windows-minimize-all-icon +author=admin +path=content/windows-minimize-all-icon diff --git a/documentation/18.11/eiffelstudio/_images/windows-raise-all-icon.png b/documentation/18.11/eiffelstudio/_images/windows-raise-all-icon.png new file mode 100644 index 00000000..5a1c21de Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/windows-raise-all-icon.png differ diff --git a/documentation/18.11/eiffelstudio/_images/windows-raise-all-icon.png.data b/documentation/18.11/eiffelstudio/_images/windows-raise-all-icon.png.data new file mode 100644 index 00000000..70647803 --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/windows-raise-all-icon.png.data @@ -0,0 +1,3 @@ +title=windows-raise-all-icon +author=admin +path=content/windows-raise-all-icon diff --git a/documentation/18.11/eiffelstudio/_images/windows-tool.png b/documentation/18.11/eiffelstudio/_images/windows-tool.png new file mode 100644 index 00000000..fcfc0dbb Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/windows-tool.png differ diff --git a/documentation/18.11/eiffelstudio/_images/windows-tool.png.data b/documentation/18.11/eiffelstudio/_images/windows-tool.png.data new file mode 100644 index 00000000..0636379f --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/windows-tool.png.data @@ -0,0 +1,3 @@ +title=windows-tool +author=admin +path=content/windows-tool diff --git a/documentation/18.11/eiffelstudio/_images/windows-windows-icon.png b/documentation/18.11/eiffelstudio/_images/windows-windows-icon.png new file mode 100644 index 00000000..7c096a06 Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/windows-windows-icon.png differ diff --git a/documentation/18.11/eiffelstudio/_images/windows-windows-icon.png.data b/documentation/18.11/eiffelstudio/_images/windows-windows-icon.png.data new file mode 100644 index 00000000..a3cddf19 --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/windows-windows-icon.png.data @@ -0,0 +1,3 @@ +title=windows-windows-icon +author=admin +path=content/windows-windows-icon diff --git a/documentation/18.11/eiffelstudio/_images/xmi-wizard-cluster-selection.png b/documentation/18.11/eiffelstudio/_images/xmi-wizard-cluster-selection.png new file mode 100644 index 00000000..be7eeeb7 Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/xmi-wizard-cluster-selection.png differ diff --git a/documentation/18.11/eiffelstudio/_images/xmi-wizard-cluster-selection.png.data b/documentation/18.11/eiffelstudio/_images/xmi-wizard-cluster-selection.png.data new file mode 100644 index 00000000..208b08aa --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/xmi-wizard-cluster-selection.png.data @@ -0,0 +1,3 @@ +title=xmi-wizard-cluster-selection +author=halw +path=content/xmi-wizard-cluster-selection diff --git a/documentation/18.11/eiffelstudio/_images/xmi-wizard-path-selection.png b/documentation/18.11/eiffelstudio/_images/xmi-wizard-path-selection.png new file mode 100644 index 00000000..186d0632 Binary files /dev/null and b/documentation/18.11/eiffelstudio/_images/xmi-wizard-path-selection.png differ diff --git a/documentation/18.11/eiffelstudio/_images/xmi-wizard-path-selection.png.data b/documentation/18.11/eiffelstudio/_images/xmi-wizard-path-selection.png.data new file mode 100644 index 00000000..10462190 --- /dev/null +++ b/documentation/18.11/eiffelstudio/_images/xmi-wizard-path-selection.png.data @@ -0,0 +1,3 @@ +title=xmi-wizard-path-selection +author=halw +path=content/xmi-wizard-path-selection diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-how-tos/browsing/index.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-how-tos/browsing/index.wiki new file mode 100644 index 00000000..03712f47 --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-how-tos/browsing/index.wiki @@ -0,0 +1,5 @@ +[[Property:title|Browsing]] +[[Property:weight|1]] +[[Property:uuid|62242eb2-a02d-32f0-e357-6ed0e3966066]] + + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-how-tos/browsing/opening-new-windows.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-how-tos/browsing/opening-new-windows.wiki new file mode 100644 index 00000000..abe1e364 --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-how-tos/browsing/opening-new-windows.wiki @@ -0,0 +1,13 @@ +[[Property:title|Opening new windows]] +[[Property:weight|2]] +[[Property:uuid|1d3066d2-f1ad-9287-ecd2-5341d3c24b61]] +There are several ways to open a new window. First, you can use the pick and drop shortcut. Then, you can use new window menu items and the corresponding icons. There are three such commands: +* Clicking on '''New window''' in the '''File''' menu or on [[Image:new-window-icon]] make an new window appear. In this window, the editor and the context tool will be visible. +* Clicking on '''New editor window''' in the '''File''' menu or on [[Image:new-editor-icon]] does the same as the previous command but the context tool is minimized in the new window. +* Clicking on '''New context window''' in the '''File''' menu make this time a new window with a minimized editor appear. + + +{{note|Icons mentioned above are droppable: instead of simply clicking on them, you can drop a stone on them. The tools in the new window will then be centered on the corresponding component.}} + + + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-how-tos/browsing/searching/index.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-how-tos/browsing/searching/index.wiki new file mode 100644 index 00000000..1b8a45f9 --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-how-tos/browsing/searching/index.wiki @@ -0,0 +1,5 @@ +[[Property:title|Searching]] +[[Property:weight|0]] +[[Property:uuid|655fd717-159f-43f0-00ec-9a804790283f]] + + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-how-tos/browsing/searching/looking-class.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-how-tos/browsing/searching/looking-class.wiki new file mode 100644 index 00000000..3dac47ff --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-how-tos/browsing/searching/looking-class.wiki @@ -0,0 +1,7 @@ +[[Property:title|Looking for a class]] +[[Property:weight|1]] +[[Property:uuid|d3f517bc-46a8-2181-e9fb-ce0430e04261]] +There are two simple ways to find a class if you know its name or a part of it : +* You may use the [[Groups tool|groups tool]] . This tool presents the entire universe of your project. By developing the [[System tree representation|cluster tree]] , you will be able to find what you are looking for. This method is quick if you already have an idea of where the class is in the universe. +* Using [[Address bars|address bars]] will be quicker if you do not have this information or if the size of your project is important. If you type the name of the searched class (you can use wildcards, i.e."*" and "?") in the [[Main address bar|main address bar]] - and then select the right class in the displayed list if there are several possibilities - the editor will be centered on the class you are looking for. The information about the class location will be displayed in the title bar of the window. If you need more complete information about the class location, you can [[Pick-and-drop mechanism|pick]] the name of the class in the editor and drop it on the [[Locate command|view icon ]] [[Image:general-search-icon]] of the [[Groups tool|groups tool]] . This tool will then show where the class is in the universe. + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-how-tos/browsing/searching/looking-cluster.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-how-tos/browsing/searching/looking-cluster.wiki new file mode 100644 index 00000000..4ededde9 --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-how-tos/browsing/searching/looking-cluster.wiki @@ -0,0 +1,7 @@ +[[Property:title|Looking for a cluster]] +[[Property:weight|0]] +[[Property:uuid|95175328-cc1b-0b0f-974d-5be7fde40e92]] +If you know the name of a cluster but not where it is located in the system, there are two ways to find this out: +* You can try to find it in the [[Groups tool|groups tool]] by expanding the cluster tree. +* In a window where the context tool is independent from the editor, you can type the name of the cluster in [[Context tool address bar|context tool address bar]] . You may use wildcards ("*" or "?") if you know only a part of the name. You can then locate the cluster in the system by [[Pick-and-drop mechanism|picking]] the cluster stone in the [[Context tool address bar|address bar]] and dropping it on the [[Locate command|view icon ]] [[Image:general-search-icon]] of the [[Groups tool|groups tool]] . + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-how-tos/browsing/searching/looking-expression-text.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-how-tos/browsing/searching/looking-expression-text.wiki new file mode 100644 index 00000000..bba648c3 --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-how-tos/browsing/searching/looking-expression-text.wiki @@ -0,0 +1,14 @@ +[[Property:title|Looking for an expression in text]] +[[Property:weight|3]] +[[Property:uuid|d71e4302-3f44-5cd8-7a26-365af4a6ecf6]] +To find a word or an expression in a text, you can use the [[Search tool|search tool]] . If it is not displayed, you can make it appear by clicking on its icon [[Image:tool-search-icon]] in the tool bar. This tool will allow you to search a word or a regular expression and to replace it if you want to. It can be case sensitive and look for isolated words. +'''Note''': The [[Search tool|search tool]] will look for the wanted word in the editor or in the context tool, depending on which one has the focus. + + +{{tip|There are several accelerators that will make it even easier to perform a search. They are detailed in the [[Search functionality|editor help]] . }} + + +{{tip|You can use the quicksearch to search in the current text. Press CTRL + F to get the quick search bar. }} + + + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-how-tos/browsing/searching/looking-feature.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-how-tos/browsing/searching/looking-feature.wiki new file mode 100644 index 00000000..1980c5d0 --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-how-tos/browsing/searching/looking-feature.wiki @@ -0,0 +1,8 @@ +[[Property:title|Looking for a feature]] +[[Property:weight|2]] +[[Property:uuid|5ea97cae-9001-7d9d-2dbb-2b632b05fb75]] +There are many ways to find a feature in a class. In particular : +* You can use the [[Features tool|Features tool]] and search the tree by expanding feature clauses. This tool, however, displays only the features that are defined or redefined in the current class text. If you do not know if the feature is inherited or not, you may therefore not find what you are looking for with this method. +* You can also use the [[Viewing Classes|class tab]] in the context tool. It will allow you to see all the [[Attributes| attributes]] or [[Routines|routines]] , or all the [[Exported features|public features]] for instance. If you do not know if the feature you seek is an attributes or a function and if it is public, this may not be the right method either. +* If you know the name or a part of the name of the feature you are looking for, the easier and faster way will probably be to use the [[Main address bar|address bar]] . If you type this name in the feature field of the bar (using "*" and "?" wildcards if you want to), the editor will be centered on the right class if necessary (i.e. if the feature is inherited) and scroll to the position of the text of the feature. + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-how-tos/browsing/viewing-information-about-component/centering-tools-component.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-how-tos/browsing/viewing-information-about-component/centering-tools-component.wiki new file mode 100644 index 00000000..9b646759 --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-how-tos/browsing/viewing-information-about-component/centering-tools-component.wiki @@ -0,0 +1,10 @@ +[[Property:title|Centering tools on a component]] +[[Property:weight|0]] +[[Property:uuid|513b0d4a-78b6-30c3-fdde-b00c3072d8d3]] +There are three kind of tools directly available in a default development tool : [[Browsing tools]] on the right, the [[EiffelStudio Editor]] on the upper left and context tools on the lower left. No browsing tool, except the feature tool, displays information about a particular component. On the contrary, the editor and context tools display information about a given cluster, class or feature : they are centered on this component. There are several ways to center the editor on an element: +* use the [[Main address bar|address bar]] on the top of the editor. It allows you to set which class (and even which feature in the class) you want the editor to display. You may use wildcards ("?" or "*") as you type the names of these components. +* use [[Pick-and-drop mechanism|pick and drop]]. Pick a cluster, class or feature stone anywhere in EiffelStudio and drop it in the editor. It will center it on the component automatically. +* find it in the [[Groups tool|groups]], [[Features tool|features]], or [[Favorites tool|favorites]] tool and click it. +The context tool can be [[Change data share mode|independent]] from the editor. If it is not, both the editor and the context tool will be centered on the same component. If it is, there is a [[Context tool address bar|second address bar]] , in the context tool title bar. You may then center the context tool on a component by using the three methods described for the editor. You can also center the context tool on the same component as the editor ( the context tool remaining independent): Just click [[Image:context-sync-icon]] or select '''Synchronize Context Tool''' tool in the '''View''' menu.
+To make the context tool independent if it is not, click [[Image:context-link-icon]] or select '''Unlink/Link context tool''' in the '''View''' menu. To do the opposite, click the same icon or select '''Merge context tool''' in the '''View''' menu. + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-how-tos/browsing/viewing-information-about-component/index.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-how-tos/browsing/viewing-information-about-component/index.wiki new file mode 100644 index 00000000..d0f21b97 --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-how-tos/browsing/viewing-information-about-component/index.wiki @@ -0,0 +1,5 @@ +[[Property:title|Viewing information about a component]] +[[Property:weight|1]] +[[Property:uuid|58f7ce9a-b5c3-77ab-d7a7-d834bb6d3b58]] + + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-how-tos/browsing/viewing-information-about-component/viewing-information-about-class.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-how-tos/browsing/viewing-information-about-component/viewing-information-about-class.wiki new file mode 100644 index 00000000..ca760873 --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-how-tos/browsing/viewing-information-about-component/viewing-information-about-class.wiki @@ -0,0 +1,12 @@ +[[Property:title|Viewing information about a class]] +[[Property:weight|2]] +[[Property:uuid|6ec8ca83-fbe0-e02c-2570-68b5f3931083]] +Once you [[Centering tools on a component|centered the editor]] on a class, you have access to its [[Class formatters: Basic text view|basic text]]. If the class is compiled, the [[Features tool|features tool]] shows the list of the features that are defined or redefined in this text. You can also view [[Clickable view|clickable]], [[Class formatters: Flat view|flat]], [[Flat Contract view|flat contract]] and [[Contract view|contract]] views of the class in the editor. The class tab in the context tool can display more information. If the [[Centering tools on a component|context tool is independent]], [[Centering tools on a component|center it]] on the wanted class and select this tab. You can then see information about the features ([[Routines|routines]], [[Attributes|attributes]], [[Exported features|exported features,]] [[Class views|etc.]] ..) of the class, its [[Ancestors|ancestors]] and [[Descendants|descendants]] or its [[Clients|clients]] and [[Suppliers|suppliers]] .
+The [[Metrics tool|metric tool]] provides another kind of data. It allows you to compute a complete set of [[How to analyze a project|measures]] on your class. + + +{{seealso|
+[[Looking for a class|Looking for a class]] }} + + + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-how-tos/browsing/viewing-information-about-component/viewing-information-about-cluster.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-how-tos/browsing/viewing-information-about-component/viewing-information-about-cluster.wiki new file mode 100644 index 00000000..063ff695 --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-how-tos/browsing/viewing-information-about-component/viewing-information-about-cluster.wiki @@ -0,0 +1,12 @@ +[[Property:title|Viewing information about a cluster]] +[[Property:weight|1]] +[[Property:uuid|daff6cb5-89bd-4281-4c1e-cf031391a34b]] +To view information about a cluster, you have to center the context tool on this component. Then the [[Metrics tool|metric tool]] will provide a complete set of measures that you will able to compute. + + +{{seealso| '''See Also'''
+[[Looking for a cluster|Looking for a cluster]]
+[[How to analyze a project]] }} + + + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-how-tos/browsing/viewing-information-about-component/viewing-information-about-feature.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-how-tos/browsing/viewing-information-about-component/viewing-information-about-feature.wiki new file mode 100644 index 00000000..800e7273 --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-how-tos/browsing/viewing-information-about-component/viewing-information-about-feature.wiki @@ -0,0 +1,12 @@ +[[Property:title|Viewing information about a feature]] +[[Property:weight|3]] +[[Property:uuid|0151eab9-ee25-210a-bed9-b2709e9fa5f0]] +Once you [[Centering tools on a component|centered the editor]] on a feature, you have access to its text. The feature tab in the context tool can display more information. To have access to it, you have first to center the context tool on the wanted class and select the feature tab. You can then consult the different views of the text of the feature ([[Feature formatters: Basic text view|basic text]] or [[Feature formatters: Flat view|flat]]) and other information such as its [[Feature formatters: Callers|callers]] or its [[Feature formatters: Descendant versions|descendant]] versions.
+The [[Metrics tool|metric tool]] provides another kind of data. It enables you to compute some [[How to analyze a project|measures]] on your feature. + + +{{seealso|
+[[Looking for a feature|Looking for a feature]] }} + + + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-how-tos/compiling/clean-compile.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-how-tos/compiling/clean-compile.wiki new file mode 100644 index 00000000..9cf6a9a4 --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-how-tos/compiling/clean-compile.wiki @@ -0,0 +1,14 @@ +[[Property:title|Clean compile]] +[[Property:weight|8]] +[[Property:uuid|095a89c1-6043-3184-bedc-a42e10ee183d]] +Doing a '''clean compile''', sometimes called a '''compile from scratch''', is occasionally necessary as you develop systems. For example, if you change certain project settings or add, remove, or change a precompiled library, you will have to do a clean compile. + +The process first involves cleaning, that is, removing any of the previously generated intermediate compile information (the EIFGENs folder). Cleaning is followed by a fresh compile which regenerates the EIFGENs anew. + +You can only do a clean compile by closing EiffelStudio on your project, then restarting it and requesting the clean compile when EiffelStudio reopens. + +So, for example, if you need to change precompiled libraries, you would open project settings, remove the old precompiled library, and add the new one. Then you would quit EiffelStudio and restart it. When the EiffelStudio dialog appears, select your project and '''Action: Compile''' and check the '''Clean''' box, as shown in the figure below. When you click '''Open''' EiffelStudio will do a clean compile of your project. + + +[[Image:clean compile dialog]] + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-how-tos/compiling/enabling-profiler.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-how-tos/compiling/enabling-profiler.wiki new file mode 100644 index 00000000..d23eed9c --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-how-tos/compiling/enabling-profiler.wiki @@ -0,0 +1,15 @@ +[[Property:title|Enabling the profiler]] +[[Property:weight|4]] +[[Property:uuid|62732b12-c41f-c87e-f798-8839664dc118]] +To profile an executable, the profiler must first be enabled. To enable the profiler: +* Open the [[General Target Options|Project Settings]] dialog. +* In the '''Target''' section, enable '''Profile'''. +* Click '''OK'''. +* You must [[Generating executables|recompile]] your project for the changes to take effect. + +{{seealso|
+[[Profiler wizard]] }} + + + + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-how-tos/compiling/generating-executables.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-how-tos/compiling/generating-executables.wiki new file mode 100644 index 00000000..6d3b15bf --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-how-tos/compiling/generating-executables.wiki @@ -0,0 +1,27 @@ +[[Property:title|Generating executables]] +[[Property:weight|0]] +[[Property:uuid|d089f44a-9d01-41cf-9ba5-a58570ca5365]] +There are several ways to compile an executable with EiffelStudio. + +The most essential compilation modes are: '''melting''', '''freezing''', and '''finalizing'''. To learn more about the compilation semantics in EiffelStudio, see the documentation of [[Melting Ice Technology|Eiffel's compilation technology]]. + +There is a command for each compilation mode in the '''Project''' menu, under the entries '''Compile''', '''Freeze''' and '''Finalize'''. + +The "drop-down" option of the Compile button ([[Image:compile-button]]) on the '''Project''' toolbar also offers these choices as shown in the image below. + + +[[Image:compile-button-dropdown]] + + +If you need the compilation options even handier than this, you can customize the '''Project''' toolbar by adding icons for each of the options: [[Image:project-melt-icon]] , [[Image:project-freeze-icon]] , [[Image:project-finalize-icon]] . [[Toolbar customization|Here's how]]. Or you can use the keyboard shortcuts that are shown in the Compile button's drop-down menu. + +To help resolve the errors that occur during the Eiffel compilation, use the [[Error wizard|compilation error wizard]]. For errors occurring during the C compilation, check that the installation is not corrupted and refer to your C compiler documentation for more information. + + +{{seealso|
+[[Command line|Command line options]]
+[[Compiler|Compiler]] }} + + + + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-how-tos/compiling/generating-libraries.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-how-tos/compiling/generating-libraries.wiki new file mode 100644 index 00000000..74bdd16a --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-how-tos/compiling/generating-libraries.wiki @@ -0,0 +1,33 @@ +[[Property:title|Generating libraries]] +[[Property:weight|1]] +[[Property:uuid|a2862dd7-1702-50b6-2505-74f9e1ac4b70]] +There are two main types of libraries in Eiffel: precompiled Eiffel libraries and C libraries. Both kinds of libraries can be created via EiffelStudio. The former can only be used in Eiffel projects, C libraries can be used either in Eiffel programs, or in standard C programs. + +To generate an Eiffel precompiled library: +* Select the '''Precompilation Wizard''' in the '''Tools''' menu and follow the instructions, + +or +* Launch a new EiffelStudio session, +* Select your project +* Change the action to '''Precompile''', +* Click '''Open''' + +To generate a dynamically linked C library using Eiffel code: +* Generate a definition file for this library, via the [[Dynamic library builder|Dynamic library Builder]] , +* Open the [[Advanced Options|Project Settings]] dialog, +* In the '''Advanced''' section, set the '''Shared Library Definition''', +* Enter the name of the definition you created in the first step(including the path if necessary), +* Compile the current project. + +The generated C library should be located in the EIFGENs|target_name|W_code directory in the directory of your project. + +To generate a C library from a C compiler, please refer to the documentation of your C compiler. + +{{seealso|
+[[Using libraries|Using libraries]]
+[[CECIL|CECIL library: calling Eiffel routines from C programs]]
+[[Command line|Command line options]] }} + + + + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-how-tos/compiling/index.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-how-tos/compiling/index.wiki new file mode 100644 index 00000000..2a0bfaa2 --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-how-tos/compiling/index.wiki @@ -0,0 +1,5 @@ +[[Property:title|Compiling]] +[[Property:weight|3]] +[[Property:uuid|30b06b72-4988-48a0-2dae-fcf7c2e5c838]] + + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-how-tos/compiling/setting-assertion-level.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-how-tos/compiling/setting-assertion-level.wiki new file mode 100644 index 00000000..0536a74c --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-how-tos/compiling/setting-assertion-level.wiki @@ -0,0 +1,15 @@ +[[Property:title|Setting the assertion level]] +[[Property:weight|2]] +[[Property:uuid|af3a030c-2970-2e07-7bd4-9e9333a8a8c3]] +To modify the assertion level in a generated binary (executable or library), +* Open the [[Assertion Options|Project Settings]] dialog. +* In the '''Target --> Assertions''' section, set a value of "True" for the assertion types you want to have checked at runtime (among require, ensure, check, loop and class invariant). +* Click '''OK'''. +* You must [[Generating executables|recompile]] your project for the changes to take effect. + +{{seealso|
+[[ET: Design by Contract (tm), Assertions and Exceptions|Assertions in Eiffel]] }} + + + + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-how-tos/compiling/setting-syntax-variant.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-how-tos/compiling/setting-syntax-variant.wiki new file mode 100644 index 00000000..21f317b9 --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-how-tos/compiling/setting-syntax-variant.wiki @@ -0,0 +1,37 @@ +[[Property:title|Setting the syntax variant]] +[[Property:weight|3]] +[[Property:uuid|e265de3f-ea49-3062-ff0c-f1c296748d3e]] +The specification of the Eiffel programming language has remained largely static over its life, arguably due to its sound initial design. Still, on occasion there will be significant value in evolving Eiffel and adapting it to new challenges. To accommodate this evolution, the Eiffel Software compiler provides a set of compilation variants which offer a balance of syntax support. This starts with compatibility with previously valid syntax, moves through the latest standard, and forward to language features which are currently supported but not yet etched into the standard. + +EiffelStudio project settings supports four of these syntax compilation variants: + +# '''Obsolete syntax''' +# '''Transitional syntax''' +# '''Standard syntax''' +# '''Provisional syntax''' + + +Because the language, and by necessity the compilation technology too, may at times be a moving target, it is difficult to give precise definitions of what these variants mean at any given time. Today's valid identifier is tomorrow's keyword and vice versa. + + +{{Recommended|It's always a good idea to check the [[EiffelStudio release notes]] and [[Differences between standard ECMA-367 and Eiffel Software implementation]] when you install a new version to see if new language elements are supported or existing ones have been made obsolete.

Additionally, you can see more detail on how these variants effect certain words in a particular version by checking the [[Syntax level variant settings by version|syntax level variant settings by version.]]}} + + +Even so, we can use an example from a particular point in time to show the basic idea. At one time, the word '''indexing''' was a keyword, and the word '''note''' was available for use as a valid identifier. But there came a time that due to a consensus of opinion within the Eiffel standards committee, the role of the keyword indexing was replaced by a new keyword note. This meant two things. First that if you had used the keyword indexing in your classes (and who hadn't?), then at some point you would want to change those occurrences to note. Second, if you had used the word '''note''' as an identifier, then at some point you would have to change your code to use a different identifier it its place. + +The Eiffel compiler is savvy enough in some cases to delay the necessity of these changes by considering code in its current context. For example, if a particular keyword is not appropriate in a certain context, then it is only reasonable that when the word is used in that context, it is used as an identifier. But sometimes ambiguities arise that the compiler cannot resolve by analyzing context. It is in these cases that the syntax variants are useful. + +So, considering the transition from '''indexing''' to '''note''', here are the effects of the first three variants: + +:If '''Obsolete syntax''' is selected, then '''indexing''' is used as a keyword. '''note''' is allowed as an identifier, but with the warning that it will become a keyword in the future. + +:If '''Transitional syntax''' is selected, both '''indexing''' and '''note''' are recognized as keywords, and a warning is issued that '''indexing''' is an obsolete keyword and should be replaced with '''note'''. + +:If '''Standard syntax''' is selected, then '''indexing''' is free to be used as an identifier, and '''note''' is recognized as a keyword. + +When '''Provisional syntax''' is selected, it allows the use of certain language constructs which, although supported by the Eiffel Software compiler, may not yet be stamped into the standard (or at least approved for the standard by a consensus of the standard committee). For example, version 6.6 of EiffelStudio includes support for the [[ET: Instructions#A closer look at the iteration form|iteration form]] of the Eiffel loop construct, which at the time of the release is not yet approved for inclusion in the ISO/ECMA standard ... although it is expected, with reasonable confidence, to become standard in the future. Of course, there is always the risk that, once standardized, the syntax may change some, so selecting '''Provisional syntax''' is an acknowledgment of this risk when non-standard language elements are being used. + +To set the syntax variant, open [[General Target Options|Project Settings]]. Then find the general setting '''Syntax''' for the target or group of interest. The value field for '''Syntax''' will give you a choice of the available variants when clicked. Select the appropriate variant, then, click '''OK'''. + + + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-how-tos/compiling/tuning-program.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-how-tos/compiling/tuning-program.wiki new file mode 100644 index 00000000..1e832260 --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-how-tos/compiling/tuning-program.wiki @@ -0,0 +1,25 @@ +[[Property:title|Tuning a program]] +[[Property:weight|6]] +[[Property:uuid|74d7c168-c9c1-2d43-fb76-4854cf4b69c7]] +The best way to speed up a program is of course to improve the algorithms and data structures you are using. Spotting the functions that slow down the execution and improving can change a lot in a program. [[Profiling|Profiling]] can be used for this. + +Try to keep the number of classes and objects in your system as low as possible to ensure maximum efficiency. This should never hinder the design of the system, though. + +You can also use the functionality provided by the [[ref:libraries/base/reference/memory_chart|MEMORY]] class to tweak the garbage collector behavior according to your needs. However, be careful with this, since providing erroneous parameters might lead to memory leaks, huge memory consumption, or on the contrary a dramatic slow down of the application. If you are not entirely sure what a parameter is for, avoid changing it. The default values should fit for most standard applications. + +On top of that, EiffelStudio provides powerful optimizations, some being done automatically, others being configurable. To obtain a maximum efficiency, it is recommended to [[Generating executables|Finalize]] your program from scratch and without using precompiled libraries. + +In the [[Advanced Options|Project Settings dialog advanced section]] , try experimenting with the '''Inlining''' option, and setting the maximum size of features that should be inlined. Only Eiffel features are inlined by this option, to see how to inline the C functions you may be using in your program, please refer to your C compiler documentation. + +In the [[Advanced Options|Project Settings dialog advanced section]] , enabling the '''Dead code removal''' will help produce smaller executables. + +Removing the '''Execution Trace''' will optimize the executable in size and speed, but in case of crash no information will be available. + +All these options are located in the [[Advanced Options|Project Settings]] dialog, in the '''Advanced''' section. They are only effective during finalizations. + +{{seealso|
+[[Profiler wizard]] }} + + + + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-how-tos/compiling/using-libraries.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-how-tos/compiling/using-libraries.wiki new file mode 100644 index 00000000..27676d61 --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-how-tos/compiling/using-libraries.wiki @@ -0,0 +1,27 @@ +[[Property:title|Using libraries]] +[[Property:weight|5]] +[[Property:uuid|443320fa-8e5c-fd13-ed20-66e49094f3d5]] +There are two kinds of libraries in Eiffel: precompiled Eiffel libraries and C libraries. + +To use an Eiffel precompiled library: +* Open the [[Group Options|Project Settings]] dialog. +* Add a new precompile group to your target. +* You must [[Generating executables|recompile]] your project from scratch for the changes to take effect. + +{{note|You can only use one precompiled library at a time in a project. To use more than one, you should precompile all the libraries you want to use together in a single precompiled library. }} + +To use a C library: +* Open the [[Externals Options|Project Settings]] dialog. +* Add an include external for the directory where the header files needed to use the library are. +* Add an object external for each object file needed to use the library. These files can be either library files (.lib, .a, etc) or object files (.obj, .o, etc) +* Click '''OK'''. +* You must [[Generating executables|recompile]] your project for the changes to take effect. + +{{seealso|
+[[Generating libraries|Creating libraries]]
+[[Adding a cluster|Adding classes and clusters from Eiffel libraries without precompiling the library]]
+[[C externals|Making C calls in Eiffel]] }} + + + + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-how-tos/compiling/using-threads.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-how-tos/compiling/using-threads.wiki new file mode 100644 index 00000000..d1ce56e7 --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-how-tos/compiling/using-threads.wiki @@ -0,0 +1,19 @@ +[[Property:title|Using threads]] +[[Property:weight|7]] +[[Property:uuid|9f53d641-093a-38cb-50bb-568aaadfeb34]] +Eiffel supports multithreaded programs. The [[EiffelThreads|EiffelThread]] Library provides ways to handle threads safely inside an Eiffel program. Make sure you [[Adding a library|add]] it to your project if you want to use threads. + +To create a multithreaded program or library: +* Open the [[Advanced Options|Project Settings]] dialog. +* In the '''Advanced''' section, enable '''Multithreaded''' option. +* Click '''OK'''. +* You must [[Generating executables|recompile]] your project for the changes to take effect. + +{{warning|Make sure the external and precompiled libraries you use have also been compiled with support for threads. }} + +{{seealso|
+[[Generating libraries|Creating libraries]] }} + + + + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-how-tos/customizing-eiffelstudio/changing-default-history-size.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-how-tos/customizing-eiffelstudio/changing-default-history-size.wiki new file mode 100644 index 00000000..6ec9b7d3 --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-how-tos/customizing-eiffelstudio/changing-default-history-size.wiki @@ -0,0 +1,15 @@ +[[Property:title|Changing the default history size]] +[[Property:weight|4]] +[[Property:uuid|d83e13f7-bdc7-a938-e979-da67e0e521d4]] +By default, there may not be more than 10 items in the history of a development window. It means that combo boxes in the [[Main address bar|address bar]] will let you choose between at most 10 possibilities. You can change this number. +To do so, use the [[Preference window overview|preference window]] : select '''Preferences''' in the '''Tools''' menu. Then in the preferences tree, select the "Browsing tools "sub-category in the "Tools" category. On the right part of the window, a list of preferences will appear, including "number of items displayed in the history combo boxes". Click on this item and enter the new value. + +Click on '''save and exit''' to complete the change. + +{{seealso|
+[[Preference window overview|Preference window description]]
+[[EiffelStudio preferences]] }} + + + + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-how-tos/customizing-eiffelstudio/changing-texts-display.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-how-tos/customizing-eiffelstudio/changing-texts-display.wiki new file mode 100644 index 00000000..7bbf03dd --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-how-tos/customizing-eiffelstudio/changing-texts-display.wiki @@ -0,0 +1,9 @@ +[[Property:title|Changing texts display]] +[[Property:weight|1]] +[[Property:uuid|b7c1cbac-975b-c6e6-050b-e48b61732a57]] +By modifying [[EiffelStudio preferences]], you can change the font and the colors used to display texts in the editor. For more information, refer to EiffelStudio [[Interface|graphical preferences reference]] . +{{seealso|
+[[Customizing class text views|Customizing formatted output]] }} + + + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-how-tos/customizing-eiffelstudio/choosing-classes-be-ignored-bon-diagrams.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-how-tos/customizing-eiffelstudio/choosing-classes-be-ignored-bon-diagrams.wiki new file mode 100644 index 00000000..67cfa531 --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-how-tos/customizing-eiffelstudio/choosing-classes-be-ignored-bon-diagrams.wiki @@ -0,0 +1,15 @@ +[[Property:title|Choosing classes to be ignored in BON diagrams]] +[[Property:weight|5]] +[[Property:uuid|18dcc14f-2ad0-3f3b-4b2e-fc9251035b6f]] +Every class in your system inherits from ANY. INTEGER, like other classes that represent basic types, is very often a supplier of the classes the user wrote. It may therefore not be interesting to display classes such as ANY or INTEGER in [[Diagram tool|BON diagrams]]. +EiffelStudio allows you to customize a list of classes that it has to ignore when it creates diagrams. This list is stored in the [[EiffelStudio preferences]] . To modify it, first open the [[Preference window overview|preferences window]] by choosing '''Preferences...''' in the '''Tools''' menu. Select then the "context tool" sub-category of the "Tools" category in the preferences tree. On the right, you will then see a table of preferences, which includes "Show ALL classes in the diagram" and "Names of classes that should not appear in generated diagrams". If "Show ALL classes in the diagram" is not False, click on it and set it to False. Then click on "Names of classes that should not appear in generated diagrams" and edit the list. Class names must be separated by semicolons. + +After modifying the list, click on '''save and exit''' to complete the change. + +{{seealso|
+[[Preference window overview|Preference window description]]
+[[EiffelStudio preferences]] }} + + + + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-how-tos/customizing-eiffelstudio/configuring-external-editor.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-how-tos/customizing-eiffelstudio/configuring-external-editor.wiki new file mode 100644 index 00000000..a80306e3 --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-how-tos/customizing-eiffelstudio/configuring-external-editor.wiki @@ -0,0 +1,15 @@ +[[Property:title|Configuring an external editor]] +[[Property:weight|7]] +[[Property:uuid|15ecd536-139b-e880-d199-9c54aa88c892]] +By clicking on, or by [[Pick-and-drop mechanism|dropping a pebble]] on the external editor toolbar button( [[Image:command-send-to-external-editor-icon]] ), you can launch an external editor. By default, this editor is VI on Unix and Notepad on Windows. You can tell EiffelStudio to launch another editor by editing the preferences. +To do so, first open the [[Preferences Reference|preferences window]] by choosing '''Preferences...''' in the '''Tools''' menu. Select then the "Global preferences" category in the preferences tree. Click on "Command used to launch an external editor" and modify the command line so that it calls your favorite editor. You can use keywords that represent the filename ($target)and the line number ($line) as is explained in the [[Preferences Reference|preferences reference]] . + +After modifying the command line, click on '''save and exit''' to complete the change. + +{{seealso|
+[[Preferences Reference|Preference window description]]
+[[EiffelStudio preferences]] }} + + + + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-how-tos/customizing-eiffelstudio/customizing-class-text-views.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-how-tos/customizing-eiffelstudio/customizing-class-text-views.wiki new file mode 100644 index 00000000..8a772639 --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-how-tos/customizing-eiffelstudio/customizing-class-text-views.wiki @@ -0,0 +1,18 @@ +[[Property:title|Customizing class text views]] +[[Property:weight|6]] +[[Property:uuid|386c40f1-3427-cf1c-1043-46aeac1bc3c5]] +It is possible in EiffelStudio to customize some properties of [[Formatted information about compiled classes and features|class text views]] (other than basic texts) displayed in the editor or class and feature tabs of the context tool. Besides [[Changing texts display|graphical appearance]], you may modify: +* the order of feature clauses. +* the type of callers and suppliers displayed in the corresponding views. +* the views that are selected by default. +* the note clauses that should not be displayed. +These properties are set in the [[EiffelStudio preferences]]. You can modify them in the [[Preference window overview|preferences window]]. To open this window, select '''Preferences...''' in the '''Tool''' menu. Then select the "Context tool" sub-category of the "Tools" category in the preferences tree. Click then on a preference on the right to modify its value. +Click on '''save and exit''' to complete the changes. + +{{seealso|
+[[Preference window overview|Preference window description]]
+[[EiffelStudio preferences]] }} + + + + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-how-tos/customizing-eiffelstudio/customizing-eiffelstudio-subversion-commands.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-how-tos/customizing-eiffelstudio/customizing-eiffelstudio-subversion-commands.wiki new file mode 100644 index 00000000..56997d17 --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-how-tos/customizing-eiffelstudio/customizing-eiffelstudio-subversion-commands.wiki @@ -0,0 +1,103 @@ +[[Property:title|Customizing EiffelStudio for Subversion commands]] +[[Property:weight|8]] +[[Property:uuid|83a8ca76-d714-db60-f697-ae48b161161a]] +==Overview== + +By configuring external commands, you can set up EiffelStudio to execute a few basic commands for Subversion or other source code management (SCM) systems. Source code management systems, sometimes called revision control or version control systems are often used as part of a software configuration management strategy to track and control changes to software and its supporting documents. + + +==Defining external commands== + +You can define external commands by using the [[External commands editor dialog|external commands editor dialog]]. Then you can execute those commands through the '''Tools''' menu or with keyboard shortcuts. + + +===Defining a Subversion command=== + + +{{note|The notation used in the examples on this page will work for Microsoft Windows. Other platforms may require different command formats.}} + + +Suppose that you want to add an external command to EiffelStudio to Subversion's ''update'' command (''update'' brings your working copy up-to-date with the repository). You can define a command with an appropriate name, say ''svn update'', as shown below. + + +[[Image:subversion-update-command-01|define svn update]] + + +The command line: + +svn up $file_name + +invokes Subversion and executes the ''update'' command. The placeholder '''$file_name''' substitutes the name of the file associated with the class currently targeted in the editor pane. So if you were editing class MY_CLASS which exists in file my_class.e, then that file name would be used in the Subversion update command executed. + +Once the command is defined, it will be accessible through EiffelStudio's Tools menu, either by selecting it explicitly or by using its associated keyboard short cut, Alt+0, in the case of this example. + + +[[Image:subversion-update-in-tools-menu|Subversion update command in the tools menu]] + + +===Other Subversion commands=== + +You can use this same technique to add external commands for other Subversion commands that require only a basic form. For example, to create a command that will add the file for the currently edited class to the repository, add a new external command with the command line: + +svn add $file_name + + +or, to revert local changes to the file associated with the class which is currently the target of the editor: + +svn revert $file_name + + +===The option to confirm execution of a command=== + +It's possible that in some cases, for example that of ''svn revert'', you might want to have the command provide you with a chance to back out of the deal before the command actually executes. You can do this by adding a little more to the command line: + + +[[Image:subversion-update-command-02|Confirmable svn update command]] + + +Here the command line: + + +echo Revert changes to $class_name? && pause && svn revert $file_name + + +first asks for confirmation before executing the command. + +When you execute this command you will see the confirmation prompt in EiffelStudio's [[Console tool|Console tool]]: + + +[[Image:subversion-update-console-tool|Subversion update command with confirmation]] + + +If you choose to execute the command, then just press return. If you have second thoughts and want to cancel the command, then do so by clicking the Console tool's stop button ( [[Image:metrics-tool--debug-stop-icon|Stop command]] ). + + +==Defining commands for TortoiseSVN== + +If you are using the TortoiseSVN GUI client for Subversion on Microsoft Windows, you may prefer to have TortoiseSVN execute the Subversion commands for you from EiffelStudio. You can do this by starting '''tortoiseproc.exe''', and providing the specifics for each command as shown in [http://tortoisesvn.net/docs/nightly/TortoiseSVN_en/tsvn-automation.html Appendix D of the TortoiseSVN documentation]. + + +Some common Subversion command invocations are shown with their respective command lines below: + + +{| border="1" +|- +| '''Subversion command''' +| '''Command line''' +|- +| revert +| start tortoiseproc /command:revert /path:"$file_name" /notempfile +|- +| commit +| start tortoiseproc /command:commit /path:"$file_name" /notempfile +|- +| log +| start tortoiseproc /command:log /path:"$file_name" /notempfile +|- +| diff +| start tortoiseproc /command:diff /path:"$file_name" /notempfile +|} + + + + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-how-tos/customizing-eiffelstudio/customizing-toolbars.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-how-tos/customizing-eiffelstudio/customizing-toolbars.wiki new file mode 100644 index 00000000..3a9bc416 --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-how-tos/customizing-eiffelstudio/customizing-toolbars.wiki @@ -0,0 +1,13 @@ +[[Property:title|Customizing toolbars]] +[[Property:weight|2]] +[[Property:uuid|583811a0-abcc-e26f-60e9-0cd6d4f9a8a8]] +There may be up to 26 buttons in the [[Main toolbars|standard toolbar]] and up to 17 in the [[Main toolbars|project toolbar]] . All those buttons are not shown by default though. Only 16 icons are displayed in the default standard toolbar for instance. +It is possible to choose which button are shown and in which order they appear in the toolbars. To do so, use [[Toolbar customization|toolbar customization]] windows. they appear when you choose '''Customize standard toolbar...''' or '''Customize project toolbar...''' in the toolbars sub-menu of the View menu or in the contextual menu of the toolbars (which is displayed when you right-click in the empty space on the right of the toolbars). + +{{seealso|
+[[Main toolbars|The toolbars and their buttons]]
+[[Toolbar customization|Toolbars customization windows]] }} + + + + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-how-tos/customizing-eiffelstudio/index.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-how-tos/customizing-eiffelstudio/index.wiki new file mode 100644 index 00000000..90b9e3a7 --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-how-tos/customizing-eiffelstudio/index.wiki @@ -0,0 +1,5 @@ +[[Property:title|Customizing EiffelStudio]] +[[Property:weight|8]] +[[Property:uuid|6f4b9558-38bc-1350-ce61-5f58d7032646]] + + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-how-tos/customizing-eiffelstudio/making-context-tool-independent-editor.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-how-tos/customizing-eiffelstudio/making-context-tool-independent-editor.wiki new file mode 100644 index 00000000..23b51451 --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-how-tos/customizing-eiffelstudio/making-context-tool-independent-editor.wiki @@ -0,0 +1,19 @@ +[[Property:title|Making the context tool independent from the editor]] +[[Property:weight|3]] +[[Property:uuid|895ca03f-b14c-e0c5-f3e7-6757b47f5bc3]] +{{UpdateNeeded}} + + +By default, the [[EiffelStudio Editor]] and the [[EiffelStudio window overview|context tool]] are [[Centering tools on a component|centered]] on the same cluster, class or feature. It is possible to make the context tool independent from the editor. It has then its own address bar and can display information on a totally different component than the one on which the editor is centered. +To do so, click on or select '''Isolate context tool''' in the '''View''' menu. To go back to the previous configuration, click on the same icon again or select '''Merge context tool''' in the '''View''' menu. + +You can also modify the [[EiffelStudio preferences]] so that next time a window is opened, its context tool will be automatically independent: open the [[Preference window overview|preferences window]] by choosing '''Preferences...''' in the '''Tools''' menu. Select then the "context tool" sub-category in the "Tools" of the preferences tree. Lastly click on "Share addresses between the editor and the context tool" and set it to '''False'''.
+Click on save and exit to complete the change. + +{{seealso|
+[[Preference window overview]]
+[[EiffelStudio preferences]] }} + + + + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-how-tos/customizing-eiffelstudio/setting-editor-behavior.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-how-tos/customizing-eiffelstudio/setting-editor-behavior.wiki new file mode 100644 index 00000000..2d41a775 --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-how-tos/customizing-eiffelstudio/setting-editor-behavior.wiki @@ -0,0 +1,10 @@ +[[Property:title|Setting the editor behavior]] +[[Property:weight|0]] +[[Property:uuid|ff77b886-4a47-2ba4-eac7-ae051934a3f5]] +Some of the [[EiffelStudio Editor]] properties are customizable. [[Automatic completion]], for instance, can be partially or totally disabled, and inserted strings can be defined by the user. Some accelerators are customizable too. For more information, please refer to the [[Editor Preferences|editor preferences reference]] . +{{seealso|
+[[Changing texts display|Text colors and font customization.]] }} + + + + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-how-tos/designing-project/altering-system/creating-new-class.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-how-tos/designing-project/altering-system/creating-new-class.wiki new file mode 100644 index 00000000..8d041f68 --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-how-tos/designing-project/altering-system/creating-new-class.wiki @@ -0,0 +1,11 @@ +[[Property:title|Creating a new class]] +[[Property:weight|0]] +[[Property:uuid|a1d33a03-a691-d7ea-c081-55c2c991e77f]] +* To create a new class pick from the '''Create a new class''' button. [[Image:16x16--new-class-icon]] Then drop on the diagram where you want to place the class bubble. A dialog now appears where you can enter a name and specify the cluster. + +{{seealso|
+[[New class command|Creating a new class using the address bar]] }} + + + + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-how-tos/designing-project/altering-system/creating-new-feature.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-how-tos/designing-project/altering-system/creating-new-feature.wiki new file mode 100644 index 00000000..58849456 --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-how-tos/designing-project/altering-system/creating-new-feature.wiki @@ -0,0 +1,10 @@ +[[Property:title|Creating a new feature]] +[[Property:weight|1]] +[[Property:uuid|f9b79d1c-6ca7-d0a3-1374-e71a8b450644]] +To create a new feature just [[Creating client-supplier links|add a new client link]] in the diagram. +{{seealso| +[[Adding a feature]] }} + + + + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-how-tos/designing-project/altering-system/deleting-items.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-how-tos/designing-project/altering-system/deleting-items.wiki new file mode 100644 index 00000000..0150d38b --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-how-tos/designing-project/altering-system/deleting-items.wiki @@ -0,0 +1,17 @@ +[[Property:title|Deleting items]] +[[Property:weight|6]] +[[Property:uuid|fc702c4e-2e14-7eca-8a61-3acee97f4a26]] +* Pick-and-drop the item you want to remove in the '''Delete''' hole. [[Image:16x16--general-delete-icon]] For links, the associated Eiffel code will be removed from the class text. Clusters and classes will be deleted from disk! + +{{warning|An action that deletes one or more files or directories cannot be undone! }} + + +{{tip|Turn on '''Automatic backups'''. EiffelStudio will make a copy of each class file every time a compilation is done. }} + + +{{seealso|
+[[Removing items from a view|Removing items from the view only]] }} + + + + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-how-tos/designing-project/altering-system/index.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-how-tos/designing-project/altering-system/index.wiki new file mode 100644 index 00000000..fa27a9c4 --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-how-tos/designing-project/altering-system/index.wiki @@ -0,0 +1,5 @@ +[[Property:title|Altering the system]] +[[Property:weight|2]] +[[Property:uuid|89337378-9070-68c5-1e29-e6325c292118]] + + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-how-tos/designing-project/altering-system/refactoring/index.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-how-tos/designing-project/altering-system/refactoring/index.wiki new file mode 100644 index 00000000..5d39275e --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-how-tos/designing-project/altering-system/refactoring/index.wiki @@ -0,0 +1,10 @@ +[[Property:title|Refactoring]] +[[Property:weight|2]] +[[Property:uuid|08099f7b-aaf4-b629-17f6-b637c4efd63a]] +Refactoring actions include renaming classes and features, and relocating features to an ancestor class. Refactoring actions start with a compilation and also end with a compilation. Refactoring has a separate undo functionality which allows you to undo a refactoring action as long as no changes have been made to the classes that have been refactored. + +The [[Main toolbars|Refactoring toolbar]] contains holes for both the '''Rename''' ([[Image:refactor-rename-icon]]) and '''Pull up''' ([[Image:refactor-feature-up-icon]]) refactoring actions. So, if the Refactoring toolbar is visible, you can "pick" a feature, for example, and drop it onto one of the refactoring holes. If the Refactoring toolbar is not visible, you can [[Main toolbars|make it visible]] or you can access refactoring actions through the context menu associated with a class or feature name (right-click to see the context menu, or shift-right-click if you are in "pick-and-drop by default" mode). + + + + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-how-tos/designing-project/altering-system/refactoring/pull-feature.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-how-tos/designing-project/altering-system/refactoring/pull-feature.wiki new file mode 100644 index 00000000..108679e1 --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-how-tos/designing-project/altering-system/refactoring/pull-feature.wiki @@ -0,0 +1,9 @@ +[[Property:title|Pull up Feature]] +[[Property:weight|5]] +[[Property:uuid|445f93dc-b81a-29ea-440b-42e394038c53]] +# Start the '''Pull up feature''' refactoring action by either: +## Selecting '''Refactor->Pull up''' from the context menu associated with the feature you want to relocate. +## Picking the feature and dropping its pebble in the '''Pull up''' hole ([[Image:refactor-feature-up-icon]]) on the [[Main toolbars|refactoring toolbar]]. +# After a compilation the '''Select Class''' dialog appears. You can choose the parent where to pull the feature. +# Click '''OK'''. + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-how-tos/designing-project/altering-system/refactoring/rename-class.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-how-tos/designing-project/altering-system/refactoring/rename-class.wiki new file mode 100644 index 00000000..cb880d95 --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-how-tos/designing-project/altering-system/refactoring/rename-class.wiki @@ -0,0 +1,16 @@ +[[Property:title|Rename Class]] +[[Property:weight|3]] +[[Property:uuid|e70f2760-389a-4c54-ed10-b731dc70e952]] +# Start the '''Rename''' refactoring action by either: +## Selecting '''Refactor->Rename''' from the context menu associated with the class you want to rename. +## Picking the class and dropping its pebble into the '''Rename''' hole ([[Image:refactor-rename-icon]]) on the [[Main toolbars|refactoring toolbar]]. +# After a compilation the '''Refactoring: Class Rename''' dialog appears. You can enter a new name. +# You can choose between these options: +#* '''Compiled Classes''': only to the refactoring in compiled classes. +#* '''All Classes''': do the refactoring in all classes, even in uncompiled classes. +#* '''Rename File''': rename the file of the class to correspond with the class name, if another file with this name already exists the file will not be renamed and a warning will be given. +#* '''Replace Name in Comments''': replace usage of the class name in comments that follow the '''{CLASSNAME}''' syntax. +#* '''Replace Name in Strings''': replace usage of the class name in strings that follow the '''{CLASSNAME}''' syntax. +#* '''Reuse existing name''': allow two or more classes to have the same name during refactoring (note: the compiler will still report an error, if there are two or more classes conflicting with same name, but this option could be use to merge two classes). +# Click '''OK'''. + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-how-tos/designing-project/altering-system/refactoring/rename-feature.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-how-tos/designing-project/altering-system/refactoring/rename-feature.wiki new file mode 100644 index 00000000..12767f94 --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-how-tos/designing-project/altering-system/refactoring/rename-feature.wiki @@ -0,0 +1,13 @@ +[[Property:title|Rename Feature]] +[[Property:weight|4]] +[[Property:uuid|03a8b4de-3c7b-0f9e-ecd2-48ff2035eaf9]] +# Start the '''Rename feature''' refactoring action by either: +## Selecting '''Refactor->Rename''' from the context menu associated with the feature you want to rename. +## Picking the feature and dropping its pebble into the '''Rename''' hole ([[Image:refactor-rename-icon]]) on the [[Main toolbars|refactoring toolbar]]. +# After a compilation the '''Refactoring: Feature Rename''' dialog appears. You can enter a new name. +# You can choose between these options: +#* '''Replace Name in Comments''': replace usage of the feature name in comments that follow the '''`featurename`''' syntax. +#* '''Replace Name in Strings''': replace usage of the feature name in strings that follow the '''`featurename`''' syntax. +#* '''Reuse existing name''': allow two or more features to have the same name during refactoring (note: the compiler will still report an error, if there are two or more features with same name, but this option could be use to merge two features). +# Click '''OK'''. + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-how-tos/designing-project/exporting-diagram-png-image-file.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-how-tos/designing-project/exporting-diagram-png-image-file.wiki new file mode 100644 index 00000000..936abbde --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-how-tos/designing-project/exporting-diagram-png-image-file.wiki @@ -0,0 +1,9 @@ +[[Property:title|Exporting a diagram to PNG image file]] +[[Property:weight|6]] +[[Property:uuid|be2bc19d-29fb-8dda-7b25-b627c5eaff2d]] +* To save the current diagram to an image file, click '''Export diagram to PNG'''. [[Image:diagram-export-to-png-icon]]
+A dialog will pop up where you can specify a location for the generated file. + + + + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-how-tos/designing-project/index.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-how-tos/designing-project/index.wiki new file mode 100644 index 00000000..3b2252db --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-how-tos/designing-project/index.wiki @@ -0,0 +1,5 @@ +[[Property:title|Designing a project]] +[[Property:weight|5]] +[[Property:uuid|e025afd9-0fcf-8300-2ef5-b3711397f773]] + + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-how-tos/designing-project/managing-links/creating-aggregate-clientsupplier-links.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-how-tos/designing-project/managing-links/creating-aggregate-clientsupplier-links.wiki new file mode 100644 index 00000000..2485c4a4 --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-how-tos/designing-project/managing-links/creating-aggregate-clientsupplier-links.wiki @@ -0,0 +1,16 @@ +[[Property:title|Creating aggregate client-supplier links]] +[[Property:weight|2]] +[[Property:uuid|824aa764-3d36-022e-e2c5-8e6c61b0b91d]] +# Select the button '''Create new aggregate client/supplier links'''. [[Image:new-aggregate-supplier-link-icon]] +# Start pick-and-drop on the class where the feature should be added. +# Drop on the desired supplier class. +# The '''Create feature''' dialog appears. See [[Adding an attribute|Creating an attribute]] or [[Adding a function|Creating a function]] using the feature wizard for more information. + +{{seealso|
+[[Creating client-supplier links|Creating client/supplier links]]
+[[Creating inheritance links|Creating Inheritance links]]
+[[New feature dialog]] }} + + + + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-how-tos/designing-project/managing-links/creating-clientsupplier-links.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-how-tos/designing-project/managing-links/creating-clientsupplier-links.wiki new file mode 100644 index 00000000..160e25c8 --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-how-tos/designing-project/managing-links/creating-clientsupplier-links.wiki @@ -0,0 +1,15 @@ +[[Property:title|Creating client-supplier links]] +[[Property:weight|1]] +[[Property:uuid|dea329a5-0b78-8423-a0a0-a8e2516c36e7]] +# Select the button '''Create new client/supplier links'''. [[Image:new-supplier-link-icon]] +# Start pick-and-drop on the class where the feature should be added. +# Drop on the desired supplier class. +# The '''Create feature''' dialog appears. See [[Adding an attribute|Creating an attribute]] or [[Adding a function|Creating a function]] using the feature wizard for more information. + +{{seealso|
+[[Creating aggregate client-supplier links|Creating aggregate client/supplier links]]
+[[Creating inheritance links|Creating Inheritance links]]
+[[New feature dialog]] }} + + + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-how-tos/designing-project/managing-links/creating-handles.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-how-tos/designing-project/managing-links/creating-handles.wiki new file mode 100644 index 00000000..15e3c525 --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-how-tos/designing-project/managing-links/creating-handles.wiki @@ -0,0 +1,5 @@ +[[Property:title|Creating handles]] +[[Property:weight|4]] +[[Property:uuid|0e393d9e-88ec-6855-1f38-9f8fbd57489a]] +Once you have created a link to show the relationship between the classes in your system you may wish to organize them. One technique for doing this easily is to create handles in the links. A handle is simply a point anywhere along the link that causes the link to change direction. To create a handle just click the mouse at the exact point on the link you wish to put the handle and then drag it to where you want the handle to be positioned in the overall diagram. You can create as many handles as you wish and use them to organize you diagram so that it is easier to interpret and so that links do not get too jumbled and become incoherent. + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-how-tos/designing-project/managing-links/creating-inheritance-links.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-how-tos/designing-project/managing-links/creating-inheritance-links.wiki new file mode 100644 index 00000000..153a4db7 --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-how-tos/designing-project/managing-links/creating-inheritance-links.wiki @@ -0,0 +1,16 @@ +[[Property:title|Creating inheritance links]] +[[Property:weight|0]] +[[Property:uuid|eb5649b8-0f9a-2f9f-2785-84c28a2127ca]] +# Select the button '''Create new inheritance links'''. [[Image:new-inheritance-link-icon]] +# Start pick-and-drop on the class where the parent should be added. +# Drop on the desired parent class. + +{{note|This action will also add the parent in the class text. }} + +{{seealso|
+[[Creating client-supplier links|Creating client/supplier links]]
+}} + + + + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-how-tos/designing-project/managing-links/index.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-how-tos/designing-project/managing-links/index.wiki new file mode 100644 index 00000000..7e6541cb --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-how-tos/designing-project/managing-links/index.wiki @@ -0,0 +1,5 @@ +[[Property:title|Managing links]] +[[Property:weight|3]] +[[Property:uuid|dddd0495-e341-c851-c364-e22d6100401b]] + + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-how-tos/designing-project/managing-links/using-link-tool.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-how-tos/designing-project/managing-links/using-link-tool.wiki new file mode 100644 index 00000000..bccb8965 --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-how-tos/designing-project/managing-links/using-link-tool.wiki @@ -0,0 +1,26 @@ +[[Property:title|Using the link tool]] +[[Property:weight|3]] +[[Property:uuid|2ab61f4c-fb5a-901c-f2b3-3ee680f48569]] +If you do not want straight arrows, you can insert handles on them. It is recommended that you use the link tool to do this, because it inserts the handles so that the angles in the line are exactly 90 degrees. +* To apply straight angles to a link, drop it in the '''Put handles on a link''' hole. [[Image:diagram-force-right-angles-icon]] +* The '''Link tool''' appears. Select the type of angle(s) you want for the link. + +[[Image:link-tool]] + +The combinations of handles you can apply to your link are: +* Put handle left
+[[Image:link-tool-left]] +* Put handle right
+[[Image:link-tool-right]] +* Put two handles left
+[[Image:link-tool-two-left]] +* Put two handles right
+[[Image:link-tool-two-right]] +* Remove handles
+[[Image:link-tool-no-handles]] + +* Click '''OK''' when you are satisfied with the result, pressing '''Cancel''' will put the link back the way it was. + + + + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-how-tos/designing-project/managing-views/adding-view.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-how-tos/designing-project/managing-views/adding-view.wiki new file mode 100644 index 00000000..8127228b --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-how-tos/designing-project/managing-views/adding-view.wiki @@ -0,0 +1,9 @@ +[[Property:title|Adding a view]] +[[Property:weight|0]] +[[Property:uuid|28444f17-3f20-72b5-dd5b-d812154a219f]] +* To add a view of the current class or cluster, select the view you want to duplicate to the new one using the '''View''' combo box.
+[[Image:diagram-defaultview]] +* Enter the name of the new view in the '''View''' combo box.
+[[Image:diagram-myview]] +* Press enter. The view is now created. + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-how-tos/designing-project/managing-views/deleting-view.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-how-tos/designing-project/managing-views/deleting-view.wiki new file mode 100644 index 00000000..45865b10 --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-how-tos/designing-project/managing-views/deleting-view.wiki @@ -0,0 +1,15 @@ +[[Property:title|Deleting a view]] +[[Property:weight|1]] +[[Property:uuid|4e53dcce-8b05-823e-6911-ac85b226a511]] + +*To delete a view, select the view you want to remove using the '''View''' combo box.
+[[Image:diagram-defaultview]] +*Click the '''Delete current view''' button. [[Image:16x16--general-delete-icon]]
+ +*If you choose to confirm, the view has been deleted, and the "DEFAULT" view is selected. + + +{{note|You cannot delete the view "DEFAULT". }} + + + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-how-tos/designing-project/managing-views/index.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-how-tos/designing-project/managing-views/index.wiki new file mode 100644 index 00000000..2948fa11 --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-how-tos/designing-project/managing-views/index.wiki @@ -0,0 +1,5 @@ +[[Property:title|Managing views]] +[[Property:weight|5]] +[[Property:uuid|55423866-e62b-ad1f-73ef-1b05fbf3ea3f]] + + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-how-tos/designing-project/modifying-display/adjusting-physics-settings.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-how-tos/designing-project/modifying-display/adjusting-physics-settings.wiki new file mode 100644 index 00000000..9a04dacb --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-how-tos/designing-project/modifying-display/adjusting-physics-settings.wiki @@ -0,0 +1,10 @@ +[[Property:title|Adjusting Physics Settings]] +[[Property:weight|11]] +[[Property:uuid|b46746cc-28e9-0db6-7d26-7aa553605e00]] +* You can adjust the behavour of the physics mode by altering various parameters in the physics settings dialog. To disaply the physics setting dialog press this button [[Image:diagram-physics-settings-icon]] . + +{{tip|To see the effects of each parameter modify it whilst your diagram is in view and you will see the diagram adjust to the new settings dynamically. }} + + + + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-how-tos/designing-project/modifying-display/anchoring.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-how-tos/designing-project/modifying-display/anchoring.wiki new file mode 100644 index 00000000..90bd9095 --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-how-tos/designing-project/modifying-display/anchoring.wiki @@ -0,0 +1,10 @@ +[[Property:title|Anchoring]] +[[Property:weight|10]] +[[Property:uuid|a30d39b6-67a6-6456-f409-e26f5e870629]] +* You may anchor a class to the diagram by right clicking the figure and dropping it onto the anchor button [[Image:diagram-anchor-icon]] . + +{{tip|To see the effects of anchoring [[Turn on Physics Mode|turn on physics mode]] and then anchor a class as described above. Now [[Adjusting Physics Settings|open the physics settings dialog]] and adjust the sliders. In the diagram you will see all anchored classes do not move whilst those surrounding them adjust to the new settings. }} + + + + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-how-tos/designing-project/modifying-display/change-display-quality.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-how-tos/designing-project/modifying-display/change-display-quality.wiki new file mode 100644 index 00000000..7e81f368 --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-how-tos/designing-project/modifying-display/change-display-quality.wiki @@ -0,0 +1,10 @@ +[[Property:title|Change the Display Quality]] +[[Property:weight|7]] +[[Property:uuid|70e4813e-84b5-48e7-dddb-0e7f601125e3]] +* To change the display quality of the diagram press the Toggle Quality button [[Image:diagram-toggle-quality-icon]] . + +{{tip|Lower quality display is faster for drawing so is recommended for very large diagrams. }} + + + + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-how-tos/designing-project/modifying-display/changing-colors-classes.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-how-tos/designing-project/modifying-display/changing-colors-classes.wiki new file mode 100644 index 00000000..39cf91ca --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-how-tos/designing-project/modifying-display/changing-colors-classes.wiki @@ -0,0 +1,8 @@ +[[Property:title|Changing colors of classes]] +[[Property:weight|3]] +[[Property:uuid|0fe16da8-7d57-d32c-291a-4a05ee9a599e]] +# Start pick-and-drop on the class bubble you want to change the color of. +# Drop it in the '''Change color''' hole. [[Image:diagram-choose-color-icon]] +# A color selection dialog appears. Select the color you want and click '''OK'''. +[[Image:color-dialog-windows]] + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-how-tos/designing-project/modifying-display/changing-system-exploration-depth.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-how-tos/designing-project/modifying-display/changing-system-exploration-depth.wiki new file mode 100644 index 00000000..927792ba --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-how-tos/designing-project/modifying-display/changing-system-exploration-depth.wiki @@ -0,0 +1,13 @@ +[[Property:title|Changing system exploration depth]] +[[Property:weight|1]] +[[Property:uuid|edb48c11-23fb-65d2-28c2-75cda5659dd8]] +* If you want to change the context of the current cluster or class in the diagram, click the '''Select depth of relations''' button. [[Image:diagram-depth-of-relations-icon]]
+* The '''Context''' dialog appears. The layout depends on whether the current context is one of a class or cluster. +* Context is a class: + +[[Image:context-dialog-class]] + +* Context is a cluster: + +[[Image:context-dialog-cluster]] + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-how-tos/designing-project/modifying-display/iconifying-and-restoring-cluster.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-how-tos/designing-project/modifying-display/iconifying-and-restoring-cluster.wiki new file mode 100644 index 00000000..be8b422b --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-how-tos/designing-project/modifying-display/iconifying-and-restoring-cluster.wiki @@ -0,0 +1,10 @@ +[[Property:title|Iconifying and restoring a cluster]] +[[Property:weight|6]] +[[Property:uuid|2a40c334-b223-3dbf-8c85-abf19a72213f]] +* If you do not want to hide the cluster, only its contents, iconify it by double clicking on the cluster label. Double clicking it again returns the cluster to its normal state. + +{{tip|If the entire cluster is of no relevance to your diagram, [[Removing items from a view|hide it from the view]] altogether. }} + + + + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-how-tos/designing-project/modifying-display/index.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-how-tos/designing-project/modifying-display/index.wiki new file mode 100644 index 00000000..1ed107f9 --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-how-tos/designing-project/modifying-display/index.wiki @@ -0,0 +1,5 @@ +[[Property:title|Modifying the display]] +[[Property:weight|4]] +[[Property:uuid|a5bcb642-d18e-8d03-da28-6042cffa153a]] + + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-how-tos/designing-project/modifying-display/removing-items-view.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-how-tos/designing-project/modifying-display/removing-items-view.wiki new file mode 100644 index 00000000..49839dcc --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-how-tos/designing-project/modifying-display/removing-items-view.wiki @@ -0,0 +1,9 @@ +[[Property:title|Removing items from a view]] +[[Property:weight|2]] +[[Property:uuid|537ce4ac-5993-4b8f-af4a-55a2c6193da2]] +* To remove an class, cluster, or link from the current view, use pick-and-drop to drop it in the '''Remove figure''' hole. [[Image:general-reset-icon]] . To remove a link handle you can also the same technique + +{{note|If you want to remove the item from the system, use the [[Deleting items|Delete]] hole. }} + + + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-how-tos/designing-project/modifying-display/retrieving-all-classes-cluster.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-how-tos/designing-project/modifying-display/retrieving-all-classes-cluster.wiki new file mode 100644 index 00000000..3a63dfd9 --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-how-tos/designing-project/modifying-display/retrieving-all-classes-cluster.wiki @@ -0,0 +1,5 @@ +[[Property:title|Retrieving all classes into a cluster]] +[[Property:weight|5]] +[[Property:uuid|4f0cffc5-0be9-1dc6-0cd5-25688ad8acef]] +* If you have a cluster in your view that is incomplete and you want to show all classes in it, drop the cluster into the '''Include all classes of cluster''' hole. [[Image:diagram-fill-cluster-icon]] + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-how-tos/designing-project/modifying-display/showing-or-hiding-links-and-labels.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-how-tos/designing-project/modifying-display/showing-or-hiding-links-and-labels.wiki new file mode 100644 index 00000000..dd0ca460 --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-how-tos/designing-project/modifying-display/showing-or-hiding-links-and-labels.wiki @@ -0,0 +1,7 @@ +[[Property:title|Showing or hiding links and labels]] +[[Property:weight|0]] +[[Property:uuid|8a59eb22-a428-0248-65cf-70a3dfda07ff]] +* To toggle visibility of all client links, click '''Show/hide client-supplier links'''. [[Image:diagram-supplier-link-icon]] +* To toggle visibility of all inheritance links, click '''Show/hide inheritance links'''. [[Image:diagram-inheritance-link-icon]] +* To toggle visibility of all client link labels, click '''Show/hide labels'''. [[Image:diagram-show-labels-icon]] + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-how-tos/designing-project/modifying-display/switching-between-bon-and-uml-view.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-how-tos/designing-project/modifying-display/switching-between-bon-and-uml-view.wiki new file mode 100644 index 00000000..51b8c5e3 --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-how-tos/designing-project/modifying-display/switching-between-bon-and-uml-view.wiki @@ -0,0 +1,8 @@ +[[Property:title|Switching between BON and UML View]] +[[Property:weight|9]] +[[Property:uuid|26db4526-db63-7b76-200f-dfac974de8ad]] +* You can switch the diagran between BON and UML views by pressing the BON/UML Toggle Button [[Image:diagram-view-uml-icon]] + + + + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-how-tos/designing-project/modifying-display/turn-physics-mode.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-how-tos/designing-project/modifying-display/turn-physics-mode.wiki new file mode 100644 index 00000000..778bb334 --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-how-tos/designing-project/modifying-display/turn-physics-mode.wiki @@ -0,0 +1,10 @@ +[[Property:title|Turn on Physics Mode]] +[[Property:weight|8]] +[[Property:uuid|03910ac4-6236-0a1d-667e-3a7c25b10c78]] +* You can turn on and off physics to the diagram by pressing the physics mode button [[Image:diagram-toogle-physics-icon]] + +{{tip|The particular configuration of the classes in your system when using the physics mode is determined by the various settings in the [[Adjusting Physics Settings|Physics Setting Dialog]] . }} + + + + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-how-tos/designing-project/modifying-display/using-cluster-legend.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-how-tos/designing-project/modifying-display/using-cluster-legend.wiki new file mode 100644 index 00000000..a500efe7 --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-how-tos/designing-project/modifying-display/using-cluster-legend.wiki @@ -0,0 +1,12 @@ +[[Property:title|Using the Cluster Legend]] +[[Property:weight|12]] +[[Property:uuid|b0d3dc3e-35e7-2668-533e-fefc3acef987]] +* The cluster legend allows you to quickly determine which classes in the view belong to which clusters in the system by changing the colors to match those of cluster assigned ones. Pressing the legend button [[Image:diagram-show-legend-icon]] will display a list of all the clusters in the system for which at least one class is visible in the view. Next to each cluster name is a color, and pressing the top right color square will automatically set a unique color for each cluster and change the classes belonging to that cluster to match. Pressing again the legend button will hide it from view. The image below shows the legend in use and the classes colored. +[[Image:cluster-legend]] + +{{tip|Use the cluster legend also to quickly see sub-cluster organization within your overall cluster design.}} + + + + + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-how-tos/designing-project/modifying-display/zooming-diagram.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-how-tos/designing-project/modifying-display/zooming-diagram.wiki new file mode 100644 index 00000000..9afb9920 --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-how-tos/designing-project/modifying-display/zooming-diagram.wiki @@ -0,0 +1,9 @@ +[[Property:title|Zooming a diagram]] +[[Property:weight|4]] +[[Property:uuid|df6e1cb1-b955-84c1-d0ba-42c720be8cde]] +* To enlarge the diagram, click '''Zoom in'''. [[Image:diagram-zoom-in-icon]]
+ +* To shrink the diagram, click '''Zoom out'''. [[Image:diagram-zoom-out-icon]]
+ +* To enlarge and shrink the diagram to a specific size use the Zoom combo box, enter the percentage size and press the Enter key. + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-how-tos/designing-project/switching-diagram-tool.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-how-tos/designing-project/switching-diagram-tool.wiki new file mode 100644 index 00000000..48b34fc9 --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-how-tos/designing-project/switching-diagram-tool.wiki @@ -0,0 +1,10 @@ +[[Property:title|Switching to the diagram tool]] +[[Property:weight|0]] +[[Property:uuid|87528ee4-72c4-57c3-81f0-8d5bda425276]] +* In order to switch from coding to designing, click the '''Diagram''' tab in the '''Context''' tool. Open the context tool by checking menu item '''View | Explorer Bar |Context'''. + +{{tip|To make sure all your changes are in the diagram, perform a compilation. }} + + + + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-how-tos/designing-project/undoing-and-redoing.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-how-tos/designing-project/undoing-and-redoing.wiki new file mode 100644 index 00000000..5b64aabe --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-how-tos/designing-project/undoing-and-redoing.wiki @@ -0,0 +1,19 @@ +[[Property:title|Undoing and redoing]] +[[Property:weight|1]] +[[Property:uuid|35cb87d8-14c9-f3ce-5275-83c1ec61d746]] +Almost all actions in the diagram tool are undoable. Every action that can be undone, can also be redone. For advanced undoing, open the history tool. + +{{tip|Undo actions cannot be undone. Use redo to undo an undo action. }} +* To undo the last action, click '''Undo last action'''. [[Image:general-undo-icon]] +* To redo the last action, click '''Redo last action'''. [[Image:general-redo-icon]] +* To undo all actions up until a specific action: +*# Click the '''History tool''' button. [[Image:general-undo-history-icon]] +*# The '''History tool''' dialog appears with a list of all undoable actions. By clicking on one of the actions, the diagram returns to the state it was in just after you performed this action. + +[[Image:history-tool|center]] + + +{{note|When an action is performed that cannot be undone, the history tool is emptied. }} + + + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-how-tos/editing-project/adding-class.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-how-tos/editing-project/adding-class.wiki new file mode 100644 index 00000000..7a4924cf --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-how-tos/editing-project/adding-class.wiki @@ -0,0 +1,30 @@ +[[Property:title|Adding a class]] +[[Property:weight|2]] +[[Property:uuid|592f9c3a-4533-d849-a0d7-5c00864e5c26]] +A dialog window is dedicated to the creation of new classes. + + +[[Image:new-class-dialog]] + + +A list of all the clusters of the system lets you to choose in which one the new class will be inserted. The name of the new class and the name of the corresponding file can be set thank to two text fields above the list. It is also possible to define whether the class should be deferred or expanded, what its creation feature is (if any), what its parents are and whether the default feature clauses should be generated. + + +{{tip|You can change the class text that is generated by default by editing the following files:

+$ISE_EIFFEL\studio\help\defaults\$ISE_PLATFORM\full.cls (with default feature clauses) and

+$ISE_EIFFEL\studio\help\defaults\$ISE_PLATFORM\empty.cls (without default feature clauses). }} + + +To make the window appear, you can: +* Click [[Image:16x16--new-class-icon]] in the [[Main toolbars|standard toolbar]] . +* Select '''New class''' in the '''Tools''' menu. +* Type the name of the new class in the class field of the [[Main address bar|main address bar]] or the [[Context tool address bar|context tool address bar]] . The current cluster will then be preselected. +* Use the [[Diagram tool]] : Pick the icon [[Image:16x16--new-class-icon]] and drop it on the diagram in the right cluster. This will make the dialog window appear with the chosen cluster selected. + + +{{seealso|
+[[Removing a class|Removing a class]] }} + + + + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-how-tos/editing-project/adding-cluster.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-how-tos/editing-project/adding-cluster.wiki new file mode 100644 index 00000000..f49a2b59 --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-how-tos/editing-project/adding-cluster.wiki @@ -0,0 +1,27 @@ +[[Property:title|Adding a cluster]] +[[Property:weight|0]] +[[Property:uuid|76a118a9-270e-fbc4-567d-e2ce031585d4]] +It is possible to create new clusters from EiffelStudio. A dialog window has been designed to help you do so. + + +[[Image:new-cluster-dialog]] + + +There are three ways to make this window appear. You can: +* Click [[Image:16x16--new-cluster-icon]] in the [[Main toolbars|standard toolbar]] . +* Click [[Image:new-cluster-icon]] in the [[Groups tool|groups tool]] . +* Select '''New cluster''' in the '''Tools''' menu. +Using this dialog, you can either create a subcluster of an existing cluster or a top-level cluster. +If you decide to create a top-level cluster, you should give it a name and a path (if the selected path does not exist, it will be created). You can also choose if it should be recursive or not.. + +If you want to create a subcluster, give it a name and select its parent in the list of available clusters. Giving it a path is not required. If you do not set a path for a new subcluster, it will be located by default in a subdirectory of its parent cluster, named after the subcluster name. This is the recommended way of creating a subcluster (since its path in the configuration file will be automatically relative to the parent), but it is not compulsory. + +To import an existing cluster, you can also go to the '''Groups''' section in the [[Group Options|Project Settings dialog]] and click '''Add cluster'''. Although this solution may be slightly more tedious, it gives access to more options. + + +{{seealso|
+[[Removing a cluster|Removing a cluster]] }} + + + + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-how-tos/editing-project/adding-feature/adding-attribute.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-how-tos/editing-project/adding-feature/adding-attribute.wiki new file mode 100644 index 00000000..6ca4dbf4 --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-how-tos/editing-project/adding-feature/adding-attribute.wiki @@ -0,0 +1,11 @@ +[[Property:title|Adding an attribute]] +[[Property:weight|4]] +[[Property:uuid|091387a6-2dda-aff4-7741-b44ade4857cb]] +Once [[Opening the new feature dialog|the new feature dialog]] is displayed and '''attribute''' selected in '''feature type''', follow the following steps: +# [[Feature clauses|Choose a feature clause]] +# [[Name field|Type a name]] +# [[Type selection|Select the type]] +# [[Header comment|Type a header comment]] +# [[Invariant field|Select a class invariant]] +# [[Set-procedure|Select to create a set-procedure]] + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-how-tos/editing-project/adding-feature/adding-function.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-how-tos/editing-project/adding-feature/adding-function.wiki new file mode 100644 index 00000000..353b4d66 --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-how-tos/editing-project/adding-feature/adding-function.wiki @@ -0,0 +1,11 @@ +[[Property:title|Adding a function]] +[[Property:weight|3]] +[[Property:uuid|1175bdb8-b8a0-e4c4-c083-3d624ae1e501]] +Once [[Opening the new feature dialog|the new feature dialog]] is displayed and '''function''' selected in '''feature type''', follow the following steps: +# [[Feature clauses|Choose a feature clause]] +# [[Name field|Type a name]] +# [[Argument list|Select formal parameters]] +# [[Type selection|Select the type]] +# [[Header comment|Type a header comment]] +# Enter [[Precondition|precondition]] , [[Local variable|local variable]] , [[Feature body|body]] and [[Postcondition|postcondition]] + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-how-tos/editing-project/adding-feature/adding-procedure.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-how-tos/editing-project/adding-feature/adding-procedure.wiki new file mode 100644 index 00000000..0ed52ccd --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-how-tos/editing-project/adding-feature/adding-procedure.wiki @@ -0,0 +1,10 @@ +[[Property:title|Adding a procedure]] +[[Property:weight|2]] +[[Property:uuid|220515f7-5c16-2648-fcad-74d3fb1583da]] +Once [[Opening the new feature dialog|the new feature dialog]] is displayed and '''procedure''' selected in '''feature type''', follow the following steps: +# [[Feature clauses|Choose a feature clause]] +# [[Name field|Type a name]] +# [[Argument list|Select formal parameters]] +# [[Header comment|Type a header comment]] +# Enter [[Precondition|precondition]] , [[Local variable|local variable]] , [[Feature body|body]] and [[Postcondition|postcondition]] + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-how-tos/editing-project/adding-feature/index.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-how-tos/editing-project/adding-feature/index.wiki new file mode 100644 index 00000000..07fdcaaa --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-how-tos/editing-project/adding-feature/index.wiki @@ -0,0 +1,5 @@ +[[Property:title|Adding a feature]] +[[Property:weight|3]] +[[Property:uuid|c65b3fd0-05fb-9b16-79b9-d4207bf42769]] +To add a feature to a class, you can directly edit its text of course. EiffelStudio offers you other ways to do so. A dialog window has been designed to help you to add features. Once you make it appear, the [[Opening the new feature dialog|new feature dialog]] allows you to choose what kind of feature you want to create and to set most of its characteristics. The process of creating the new feature is different if it is a [[Adding a procedure|procedure]] , a [[Adding a function|function]] or an [[Adding an attribute|attribute]] . + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-how-tos/editing-project/adding-feature/opening-new-feature-dialog.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-how-tos/editing-project/adding-feature/opening-new-feature-dialog.wiki new file mode 100644 index 00000000..acd41a07 --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-how-tos/editing-project/adding-feature/opening-new-feature-dialog.wiki @@ -0,0 +1,10 @@ +[[Property:title|Opening the new feature dialog]] +[[Property:weight|1]] +[[Property:uuid|98d1f7e1-3fca-5884-83fc-f44475a3f364]] +To make the [[New feature dialog overview|new feature window]] appear, you can: +* Click [[Image:16x16--new-feature-icon]] in the [[Main toolbars|standard toolbar]] . +* Select '''New feature''' in the '''Tools''' menu. +* Use the [[Diagram tool]]: First, select '''create new client-supplier links''' by clicking on [[Image:new-supplier-link-icon]] .Then, pick the class to which you want to add the new feature. Lastly, drop the pebble on the class that corresponds to the type returned by the new feature.
+This last method does not allow you to create procedures. +The first thing to do when the dialog is displayed is to choose the kind of feature you want to create. The rest of the process depends on what you selected : [[Adding a procedure|procedure]] , [[Adding a function|function]] or [[Adding an attribute|attribute]] . + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-how-tos/editing-project/adding-library.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-how-tos/editing-project/adding-library.wiki new file mode 100644 index 00000000..88bb1b4a --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-how-tos/editing-project/adding-library.wiki @@ -0,0 +1,21 @@ +[[Property:modification_date|Mon, 09 Jul 2018 15:02:54 GMT]] +[[Property:publication_date|Mon, 09 Jul 2018 14:41:19 GMT]] +[[Property:title|Adding a library]] +[[Property:weight|1]] +[[Property:uuid|6d711ed5-7cd4-481f-1ea3-7bc0eb4e1730]] +A dialog window has been designed to help you to add a library to your project. + + +[[Image:new-library-dialog]] + + +To bring up this dialog: +* go to Project -> Project Settings and either: +** Select the "Add Library" icon [[Image:new-library-icon]] in the top icon bar (or use the keyboard shortcut, normally CTRL-L). +** On a "Target" or "Group" node of the tree, right-click "Libraries" and click "Add Library". +* or also, go to the [[Groups tool|groups tool]] and click on the small toolbar button [[Image:new-library-icon]] . + +Using this dialog, you can either choose a library from a list or select your own library. + + + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-how-tos/editing-project/changing-project-parameters.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-how-tos/editing-project/changing-project-parameters.wiki new file mode 100644 index 00000000..0b2cfdc7 --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-how-tos/editing-project/changing-project-parameters.wiki @@ -0,0 +1,12 @@ +[[Property:title|Changing project parameters]] +[[Property:weight|8]] +[[Property:uuid|54b1b86c-ce04-e634-ca1d-3546e14736f9]] +A tool has been designed to help you to modify the settings of your project. To make the Project configuration tool appear, there are two possibilities: +* Click [[Image:tool-config-icon]] in the [[Main toolbars|standard toolbar]] . +* Select '''Project settings...''' in the '''Project''' menu. +This tool will allow you, for instance, to add or remove clusters, set the assertion level or activate debug clauses. +For more complete information, please refer to the [[EiffelStudio: Project settings window|Project configuration tool help]] . + + + + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-how-tos/editing-project/index.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-how-tos/editing-project/index.wiki new file mode 100644 index 00000000..39889e45 --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-how-tos/editing-project/index.wiki @@ -0,0 +1,5 @@ +[[Property:title|Editing a project]] +[[Property:weight|2]] +[[Property:uuid|d04c152e-1749-9e9f-0503-ec505478471e]] + + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-how-tos/editing-project/moving-class.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-how-tos/editing-project/moving-class.wiki new file mode 100644 index 00000000..ab4ad9d7 --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-how-tos/editing-project/moving-class.wiki @@ -0,0 +1,11 @@ +[[Property:title|Moving a class]] +[[Property:weight|7]] +[[Property:uuid|10947266-61c8-ddd5-445e-9eb0de61cd05]] +To move a class from a cluster to another one, you have to use the [[Diagram tool]]. First, [[Centering tools on a component|center the tool]] on the cluster that contains the class you want to move. Then, if the destination cluster is not shown on the diagram, [[Pick-and-drop mechanism|pick]] it in the [[Groups tool|groups tool]] and drop it in the [[Diagram tool|diagram]]. Once both clusters are displayed, you just have to drag the class to its destination. +{{seealso|
+[[Looking for a class|Find where a class is]]
+[[Looking for a cluster|Find where a cluster is]] }} + + + + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-how-tos/editing-project/removing-class.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-how-tos/editing-project/removing-class.wiki new file mode 100644 index 00000000..f394956a --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-how-tos/editing-project/removing-class.wiki @@ -0,0 +1,17 @@ +[[Property:title|Removing a class]] +[[Property:weight|5]] +[[Property:uuid|f975b6e2-7f81-874b-82f2-e76db588ff5e]] +To remove a class, you can: +* [[Centering tools on a component|Center the editor on the component]], and click [[Image:16x16--general-delete-icon]] in the [[Main toolbars|standard toolbar]] or select '''Remove current item''' in the '''Tools''' menu. +* [[Pick-and-drop mechanism|Drop a pebble]] of this component on [[Image:16x16--general-delete-icon]] in the [[Main toolbars|standard toolbar]] or in the [[Diagram tool]] [[Diagram toolbar|toolbar]]. + +{{warning|Removing a class from the system implies the deletion of the corresponding file on disk. }} + +{{warning|Picking a feature and dropping it on the delete icon, or calling '''Remove current item''' as the editor is centered on a feature, will not remove the feature but the class to which it belongs. }} + +{{seealso|
+[[Adding a class|Adding a class]] }} + + + + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-how-tos/editing-project/removing-cluster.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-how-tos/editing-project/removing-cluster.wiki new file mode 100644 index 00000000..3ab27aae --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-how-tos/editing-project/removing-cluster.wiki @@ -0,0 +1,14 @@ +[[Property:title|Removing a cluster]] +[[Property:weight|4]] +[[Property:uuid|aebcf24c-758b-7c03-4130-533cf34650f5]] +To remove clusters, you can: +* [[Centering tools on a component|Center the editor on the component]], and click [[Image:16x16--general-delete-icon]] in the [[Main toolbars|standard toolbar]] or select '''Remove current item''' in the '''Tools''' menu. +* [[Pick-and-drop mechanism|Drop a pebble]] of this component on [[Image:16x16--general-delete-icon]] in the [[Main toolbars|standard toolbar]] or in the [[Diagram tool]] [[Diagram toolbar|toolbar]]. +* Use the cluster tab in the project configuration window. + +{{seealso|
+[[Adding a cluster|Adding a cluster]] }} + + + + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-how-tos/editing-project/removing-feature.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-how-tos/editing-project/removing-feature.wiki new file mode 100644 index 00000000..af3e821c --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-how-tos/editing-project/removing-feature.wiki @@ -0,0 +1,10 @@ +[[Property:title|Removing a feature]] +[[Property:weight|6]] +[[Property:uuid|8779bb5f-44d4-48fa-7320-d3c02c3dc176]] +To remove a feature, you may of course delete the corresponding lines in the class text. You can also use the Diagram tool if it is an attribute or a function. To do so, make sure that supplier links are shown in the diagram (if [[Image:diagram-supplier-link-icon]] is not pressed, click it). Pick the link that correspond to the feature you want to remove and drop the pebble on [[Image:16x16--general-delete-icon]] . +{{seealso|
+[[Adding a feature]] }} + + + + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-how-tos/eiffelstudio-starting-project/eiffelstudio-creating-new-project.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-how-tos/eiffelstudio-starting-project/eiffelstudio-creating-new-project.wiki new file mode 100644 index 00000000..8cd33be2 --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-how-tos/eiffelstudio-starting-project/eiffelstudio-creating-new-project.wiki @@ -0,0 +1,32 @@ +[[Property:title|EiffelStudio: Creating a new project]] +[[Property:weight|0]] +[[Property:uuid|e73ed6ac-47ba-7e08-a352-0b1cca4ddc62]] +The first thing to do to start Eiffeling is to create a project. Most commands are disabled when no project is created. + +When opening EiffelStudio, by default a dialog is popped up that proposes to create or open a project: + + +[[Image:startup-dialog]] + + +Under '''Create project''', several options are offered, which depend on the platform you are on. +* '''Basic application''' is the most basic new project that can be generated. It only includes the [[EiffelBase|base library]] and by default only creates the frame of the project. This is the ideal choice to start a textual (console) application, or to discover Eiffel. Indeed, the project is very light and includes only things that are essential in any project. It is available on all platforms. +* '''.NET application''' has by default all essential components to start a project targeting the Microsoft .NET platform. Of course, it is only available on Windows, and only if you have chosen to install the .NET support during the installation. +* '''Vision2 application''' creates a new project that includes the [[EiffelVision Introduction|Eiffel Vision2 library]] . This is the perfect choice to start a platform-independent graphic application, or even any graphic application, since EiffelVision2 is easier to use than platform-specific libraries. This option is available on all platforms. +* '''WEL application''' generates a project using the [[WEL|Windows Eiffel Library(WEL)]] . This option is recommended for projects needing advanced Windows features, or Windows applications that are time-critical, since the graphic functionality provided by WEL is more efficient than the one provided by Vision2, which on the other hand provides a platform-independent abstract interface. This wizard is only available on Windows. +* '''EiffelWeb application''' creates a new project based on the EiffelWeb framework (EWF). This is the choice to build a platform-independent web server application on top of various solution (CGI, libFCGI, or standalone EiffelWeb server). This option is available on all platforms. +* This list of wizards is not definitive, and may change in the future, to bring new solutions. + +All those options are also available in the ''' File'''/ '''New project...''' menu. This pops up a dialog with all the options to generate a new project: + +[[Image:create-a-project]] + + +{{tip|If you checked the "Don't show this dialog at startup" checkbox in the start-up dialog but want to get it back, you can use the [[Discardable dialogs|Preferences dialog]] to reset the default value. }} + + +{{seealso| [[Retrieving a project from a configuration file|Retrieving a project from an configuration file]] }} + + + + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-how-tos/eiffelstudio-starting-project/index.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-how-tos/eiffelstudio-starting-project/index.wiki new file mode 100644 index 00000000..fe241451 --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-how-tos/eiffelstudio-starting-project/index.wiki @@ -0,0 +1,5 @@ +[[Property:title|EiffelStudio: Starting a project]] +[[Property:weight|0]] +[[Property:uuid|d3d6bae9-7a93-2c02-1fab-4759341419d6]] + + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-how-tos/eiffelstudio-starting-project/retrieving-project-configuration-file.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-how-tos/eiffelstudio-starting-project/retrieving-project-configuration-file.wiki new file mode 100644 index 00000000..81211b48 --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-how-tos/eiffelstudio-starting-project/retrieving-project-configuration-file.wiki @@ -0,0 +1,16 @@ +[[Property:title|Retrieving a project from a configuration file]] +[[Property:weight|1]] +[[Property:uuid|eef8cf02-0ed0-3e3e-3204-56541df18d37]] +If you have already designed a project and want to retrieve it, or if you want to open a project created by someone else (such as the examples of the libraries which are shipped with EiffelStudio), you can either directly select it from the list of last opened projects or use the '''Add Project''' button to open the configuration file. + +This dialog also allows you to select which target to compile. A target may be selected from the drop down list by clicking the black triangle. You can also specify your own location where the project will be compiled. The '''action''' describes what should be done and the optional '''clean''' removes the compiled files of a previous compilation before doing the action. + +'''Reset user settings''' removes all stored custom information about the project (but not the configuration of the project itself). For example last used target, locations where this project has been compiled, arguments and working directory. + + +{{seealso|
+[[EiffelStudio: Creating a new project|Creating a new project]] }} + + + + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-how-tos/generating-documentation/generating-multi-format-documentation.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-how-tos/generating-documentation/generating-multi-format-documentation.wiki new file mode 100644 index 00000000..e98bc65b --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-how-tos/generating-documentation/generating-multi-format-documentation.wiki @@ -0,0 +1,49 @@ +[[Property:title|Generating multi-format documentation]] +[[Property:weight|0]] +[[Property:uuid|37a81bfb-004f-a1f9-7cc8-140639e96e9f]] +EiffelStudio can generate documentation for a system using many different formats. + +The '''Documentation Wizard''', which helps you to get the documentation you want, is available in the '''Project''' menu, under the entry '''Generate Documentation'''. + +The first page of the Documentation Wizard lets you choose between the available formats for the documentation: + +[[Image:index-37]] + +{{tip|The nicest output is produced by the '''html-stylesheet''' format. }} + + +Now the wizard asks you to select the clusters you want to produce documentation for: + +[[Image:index-38]] + + +In the next page you can specify indexing items on which HTML metatags will be based: + +[[Image:index-39]] + +{{note|This page is only available for HTML documentation. }} + + +You can then pick the formats you need among those available. For example, you might need a file containing the '''Cluster hierarchy''' of your system or, for each class, a file containing the '''Contracts''' of that class. At this point you can also decide to generate BON diagrams for the clusters selected in the previous page. + +[[Image:index-40]] + + +If you have checked '''Cluster diagrams''' in the previous page, you will now be able to choose a view for each diagram that is going to be generated. You have the choice between an automatically arranged view and all of the [[Views|views ]] you may have manually arranged with the [[Diagram tool|Diagram Tool]] . + +[[Image:index-41]] + +{{note|Cluster diagrams are only available for HTML documentation. }} + + +Here comes the last page; you can choose the directory where the documentation is going to be generated: + +[[Image:index-42]] + + +{{seealso|
+[[Generating XMI documentation|Generating XMI documentation]] }} + + + + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-how-tos/generating-documentation/generating-xmi-documentation.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-how-tos/generating-documentation/generating-xmi-documentation.wiki new file mode 100644 index 00000000..d6acbe3d --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-how-tos/generating-documentation/generating-xmi-documentation.wiki @@ -0,0 +1,22 @@ +[[Property:title|Generating XMI documentation]] +[[Property:weight|1]] +[[Property:uuid|a6aa8b26-6ce4-90d5-7204-014c5fee0267]] +EiffelStudio can generate an '''XMI''' description of a system; '''XMI''' (XML Metadata Interchange) format is the new industry standard way to describe and exchange object-oriented systems, further information can be found [http://www.omg.org/technology/xml/ here] . + +The '''XMI Export wizard''' is available in the '''Project''' menu, under the entry '''Export XMI'''. + +The first page of the wizard lets you select the clusters you want to produce documentation for: + +[[Image:xmi-wizard-cluster-selection]] + + +On the second and last page, you can choose the directory where the XML file is going to be generated: + +[[Image:xmi-wizard-path-selection]] + +{{seealso|
+[[Generating multi-format documentation|Generating multi-format documentation]] }} + + + + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-how-tos/generating-documentation/index.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-how-tos/generating-documentation/index.wiki new file mode 100644 index 00000000..2cf2c29d --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-how-tos/generating-documentation/index.wiki @@ -0,0 +1,5 @@ +[[Property:title|Generating documentation]] +[[Property:weight|7]] +[[Property:uuid|18c19156-899a-33fd-92f0-3065267f30f0]] + + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-how-tos/how-analyze-project/computing-measure/evaluating-measure.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-how-tos/how-analyze-project/computing-measure/evaluating-measure.wiki new file mode 100644 index 00000000..993fed00 --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-how-tos/how-analyze-project/computing-measure/evaluating-measure.wiki @@ -0,0 +1,22 @@ +[[Property:title|Evaluating a measure]] +[[Property:weight|1]] +[[Property:uuid|533ec807-ad3d-5338-3955-aa2f8601976e]] +To evaluate a metric over a scope: +# Select the '''Metric Evaluation''' tab from the Metric tool. +# Define the scope by adding either groups, classes or features to the input domain list. +# Select a metric from the list of available metrics. +# Click the '''Run selected metric''' button and the result will appear in the '''Value''' text field. + +You can get more information about the evaluated metric. See [[Viewing measure details|detailing a measure]] . + + + +{{warning|When calculated, a measure is not saved. }} + +{{seealso|
+[[Saving a measure|Saving a measure]]
+[[Viewing measure details|Detailing a measure]]
+}} + + + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-how-tos/how-analyze-project/computing-measure/index.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-how-tos/how-analyze-project/computing-measure/index.wiki new file mode 100644 index 00000000..d15f2034 --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-how-tos/how-analyze-project/computing-measure/index.wiki @@ -0,0 +1,9 @@ +[[Property:title|Computing a measure]] +[[Property:weight|1]] +[[Property:uuid|cff91cf0-1280-f79d-440a-69801b213dac]] +The metric interface allows users to analyze their projects. It provides a set of metrics that could be evaluated over various scopes to obtain quantitative information about systems. + +Thanks to the metric interface, users can evaluate metrics over different scopes, get some detailed information when possible, save the pertinent measures, delete the useless ones, and update the values of previously recorded metrics. + +Below is the list of operations you can perform. + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-how-tos/how-analyze-project/computing-measure/saving-measure.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-how-tos/how-analyze-project/computing-measure/saving-measure.wiki new file mode 100644 index 00000000..ab4c3936 --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-how-tos/how-analyze-project/computing-measure/saving-measure.wiki @@ -0,0 +1,17 @@ +[[Property:title|Saving a measure]] +[[Property:weight|2]] +[[Property:uuid|d967fde4-5dea-a855-50ec-b0d8f1473cf2]] +To save the result of evaluation of a metric: +# Select the '''Metric Archive''' tab of the Metric tool. +# Select the input domain as described in [[Evaluating a measure|Evaluating a measure]] and the metrics you want to compute and save over the selected scope +# Select a file to use to store the results. If you specify a non-existing file, it will be created, if you specify an existing file it will be overriden. The selection of the file can be done by clicking on the button with the three dots in the '''Archive Management''' frame. +# Click the '''Start metric archive evaluation'''. + +{{seealso|
+[[Evaluating a measure|Evaluating a measure]]
+[[Viewing measure details|Detailing measures]]
+}} + + + + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-how-tos/how-analyze-project/computing-measure/viewing-measure-details.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-how-tos/how-analyze-project/computing-measure/viewing-measure-details.wiki new file mode 100644 index 00000000..c7b6e91b --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-how-tos/how-analyze-project/computing-measure/viewing-measure-details.wiki @@ -0,0 +1,17 @@ +[[Property:title|Viewing measure details]] +[[Property:weight|3]] +[[Property:uuid|570feb7a-4650-0a7d-ae45-1336c5429cfb]] +It is possible to have some details when evaluating a metric. +# Select the '''Metric Evaluation''' tab of the metric tool. +# [[Evaluating a measure|Evaluate a metric]] . +# Click the '''Run selected metric and show detailed result''' button and the result will appear in the '''Detailed Result''' tab of the metric tool. +# To come back to the main interface click again on '''Metric Evaluation''' tab of the metric tool. + +{{seealso|
+[[Evaluating a measure|Evaluating a measure]]
+[[Saving a measure|Saving measures]]
+}} + + + + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-how-tos/how-analyze-project/handling-archives/comparing-archive.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-how-tos/how-analyze-project/handling-archives/comparing-archive.wiki new file mode 100644 index 00000000..fc948397 --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-how-tos/how-analyze-project/handling-archives/comparing-archive.wiki @@ -0,0 +1,15 @@ +[[Property:title|Comparing to an archive]] +[[Property:weight|2]] +[[Property:uuid|eb13a2c4-623d-8a35-6175-40a43486beb8]] +The main goal of archives is comparing archives one to another. In order to compare your project to an archived file, you must select the '''Metric archive''' tab of the metric tool. + +The goal is to load the archive of a (preferably different) project, to compare the archived measures to the system's. You can select your current archive or any other archive, against a reference archive file. + +Once the archives are selected, click the '''Compare''' button to start the comparison. It will bring you to the '''Detailed Result''' tab. + +{{seealso|
+[[Creating an archive|Creating an archive]] }} + + + + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-how-tos/how-analyze-project/handling-archives/creating-archive.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-how-tos/how-analyze-project/handling-archives/creating-archive.wiki new file mode 100644 index 00000000..1a53435f --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-how-tos/how-analyze-project/handling-archives/creating-archive.wiki @@ -0,0 +1,11 @@ +[[Property:title|Creating an archive]] +[[Property:weight|1]] +[[Property:uuid|d8bd6d77-a5dc-df38-a796-6fa8a07ddf29]] +Users may want to archive the result of the system they are working on. To create an archive is basically the same as [[Saving a measure|saving a measure]] . + +{{seealso|
+[[Comparing to an archive|Comparing to an archive]] }} + + + + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-how-tos/how-analyze-project/handling-archives/index.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-how-tos/how-analyze-project/handling-archives/index.wiki new file mode 100644 index 00000000..fc844a68 --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-how-tos/how-analyze-project/handling-archives/index.wiki @@ -0,0 +1,7 @@ +[[Property:title|Handling archives]] +[[Property:weight|3]] +[[Property:uuid|1a2bc120-2f9d-0cc3-4883-a98c5999b12d]] +The archive file for a system contains all the values of measures resulting from evaluating selected metrics. It also contains the definitions of non elementary metrics (the one user has [[Defining new metrics|defined]]) in order to be sure of what is being measured. + +The archive files are entitled to achieve comparisons between systems. And then, user can compare systems to evaluate their own projects. + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-how-tos/how-analyze-project/handling-new-metrics/defining-new-metrics/defining-derived-metrics.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-how-tos/how-analyze-project/handling-new-metrics/defining-new-metrics/defining-derived-metrics.wiki new file mode 100644 index 00000000..640bd51e --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-how-tos/how-analyze-project/handling-new-metrics/defining-new-metrics/defining-derived-metrics.wiki @@ -0,0 +1,21 @@ +[[Property:title|Defining derived metrics]] +[[Property:weight|1]] +[[Property:uuid|d9c9037a-7b87-3810-c5c8-d34523cdad7b]] +To define a derived metric, you must select the''' Metric Definition''' tab and click the '''New metric''' button. A menu appears asking you the kind of metric you want to define. Select '''Basic metric''' and then the type of the results you are looking for (i.e. Class, Feature, Line, ...). Once done, you can perform the following steps: +# Enter a name for the metric in the "Name" field. Next to the field you will see the type of metric as well as the unit for this metric. +# Enter a description for the metric. The description is shown as a tooltip when you navigate the list of available metrics. +# Choose your criteria by selecting the item with ... in the '''Criterion definition''' list. Once selected you can press Ctrl+Space to see the list of available criterion. Once the criterion is set, you can add some properties (e.g. a property could be STRING if the criterion you have is to look for descendants of the STRING class). +# Once you have completed the metric definition you need to save your metric by clicking on the Save button. +# If you want to define another derived metric, repeat all the previous steps. + +For more information about criterion, read the [[Criterion References|Managing criterion]] section. + +A summary of the metric you just defined appears in a textual representation in the '''Expression''' text field. + +{{seealso|
+[[Managing new metrics|Managing metrics]]
+[[Criterion References|Managing criterion]] }} + + + + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-how-tos/how-analyze-project/handling-new-metrics/defining-new-metrics/defining-linear-metrics.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-how-tos/how-analyze-project/handling-new-metrics/defining-new-metrics/defining-linear-metrics.wiki new file mode 100644 index 00000000..438709cb --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-how-tos/how-analyze-project/handling-new-metrics/defining-new-metrics/defining-linear-metrics.wiki @@ -0,0 +1,20 @@ +[[Property:title|Defining linear metrics]] +[[Property:weight|2]] +[[Property:uuid|bfcfffff-08ec-8e18-fed4-3f39ac3772da]] +To define a linear metric, you must select the '''Metric Definition''' tab and click the '''New metric''' button. A menu appears asking you the kind of metric you want to define. Select '''Linear metric''' and then the type of the results you are looking for (i.e. Class, Feature, Line, ...). Once done, you can perform the following steps: +# Enter a name for the metric in the "Name" field. Next to the field you will see the type of metric as well as the unit for this metric. +# Enter a description for the metric. The description is shown as a tooltip when you navigate the list of available metrics. +# Define a single term by choosing a metric from the combo box that appears when selecting the '''Metrics''' column, and then choose a coefficent in the '''Coefficient''' column of the metric definition list. +# To add other terms, repeat operation 3 as many times as needs. +# Once you have completed the metric definition you need to save your metric by clicking on the Save button. +# If you want to define another linear metric, repeat all the previous steps. + +A summary of the metric you just defined appears in a textual representation in the '''Expression''' text field. + +{{seealso|
+[[Managing new metrics|Managing metrics]]
+}} + + + + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-how-tos/how-analyze-project/handling-new-metrics/defining-new-metrics/defining-ratio-metrics.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-how-tos/how-analyze-project/handling-new-metrics/defining-new-metrics/defining-ratio-metrics.wiki new file mode 100644 index 00000000..7bf5fa0b --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-how-tos/how-analyze-project/handling-new-metrics/defining-new-metrics/defining-ratio-metrics.wiki @@ -0,0 +1,21 @@ +[[Property:title|Defining ratio metrics]] +[[Property:weight|3]] +[[Property:uuid|40394359-600c-5392-8609-6f994920a3b1]] +To define a ratio metric, you must select the '''Metric Definition''' tab and click the '''New metric''' button. A menu appears asking you the kind of metric you want to define. Select '''Ratio metric'''. Once done, you can perform the following steps: +# Enter a name for the metric in the "Name" field. Next to the field you will see the type of metric as well as the unit for this metric. +# Enter a description for the metric. The description is shown as a tooltip when you navigate the list of available metrics. +# Select a metric for numerator in the "Metric" combo box of the "Numerator" frame to change the numerator in the "Ratio" field. +# Select a metric for denominator in the "Metric" combo box of the "Denominator" frame to change the denominator in the "Ratio" field. +# If you want to change again either numerator or denominator repeat operations 3. or 4. as many times as needed. +# Once you have completed the metric definition you need to save your metric by clicking on the Save button. +# If you want to define another ratio metric, repeat all the previous steps. + +A summary of the metric you just defined appears in a textual representation in the '''Expression''' text field. + +{{seealso|
+[[Managing new metrics|Managing metrics]]
+}} + + + + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-how-tos/how-analyze-project/handling-new-metrics/defining-new-metrics/index.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-how-tos/how-analyze-project/handling-new-metrics/defining-new-metrics/index.wiki new file mode 100644 index 00000000..257c9ae3 --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-how-tos/how-analyze-project/handling-new-metrics/defining-new-metrics/index.wiki @@ -0,0 +1,13 @@ +[[Property:title|Defining new metrics]] +[[Property:weight|1]] +[[Property:uuid|7f36c01c-40f4-be23-dfcd-d92bf2bbd535]] +The metric interface provides by default a set of basic metrics. However, user may want to define other metrics, such as linear sums or different ratios, or combining some criteria... This is possible thanks to the '''Metric Definition''' tab of the metric tool. + +New metrics are increasingly added to the list of metrics which is ordered by unit type, and are available for [[Evaluating a measure|calculation]] . + +{{seealso|
+[[Evaluating a measure|Evaluating a measure]]
+[[Managing new metrics]] }} + + + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-how-tos/how-analyze-project/handling-new-metrics/index.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-how-tos/how-analyze-project/handling-new-metrics/index.wiki new file mode 100644 index 00000000..d1d80084 --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-how-tos/how-analyze-project/handling-new-metrics/index.wiki @@ -0,0 +1,9 @@ +[[Property:title|Handling new metrics]] +[[Property:weight|2]] +[[Property:uuid|1ca7a8cf-f446-6cbc-59e1-0455e633ce44]] +The metric tool ("Metric" tab of the context tool) provides by default a set of metrics that can be used to make some measurements over various scopes in order to evaluate a project. + +This set of metrics is certainly not complete, users may probably want to define other metrics regarding their own needs. And then, since needs are different and in order to avoid an explosion in the number of basic metrics, we agreed on implementing only elementary metrics that could not be evaluated if not implemented in the tool. + +Users can then define their own metrics. The metric tool provides an interface to define new metrics. Click on the '''Metric Definition''' tab in the metric tool to start adding new metrics and modifying existing metrics. + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-how-tos/how-analyze-project/handling-new-metrics/managing-new-metrics.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-how-tos/how-analyze-project/handling-new-metrics/managing-new-metrics.wiki new file mode 100644 index 00000000..f48631dc --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-how-tos/how-analyze-project/handling-new-metrics/managing-new-metrics.wiki @@ -0,0 +1,7 @@ +[[Property:title|Managing new metrics]] +[[Property:weight|2]] +[[Property:uuid|540cbcc4-27cb-7fc4-5c98-0c622bfb0841]] +After having [[Defining new metrics|defined]] some new metrics, it is possible to delete the useless ones, or to edit them: +* Deleting a metric: select the metric you want to delete and click on the '''Remove current selected metric''' button. +* Editing a metric: select the metric you want to edit and start changing its definition by adding or removing criteria (derived), adding or removing terms (linear), changing numerator and denominator (ratio). + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-how-tos/how-analyze-project/index.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-how-tos/how-analyze-project/index.wiki new file mode 100644 index 00000000..46c96728 --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-how-tos/how-analyze-project/index.wiki @@ -0,0 +1,8 @@ +[[Property:title|How to analyze a project]] +[[Property:weight|6]] +[[Property:uuid|85d47406-926e-8754-0c15-a2af5b151658]] +The metric tab in the context tool allows project analyzing. Built on a suitable metric theory, this tool provides a set of elementary metrics that can be evaluated to test projects design and implementation. + +The metric tool provides an interface to evaluate measures, save them or delete some of them when no longer needed. + + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-how-tos/index.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-how-tos/index.wiki new file mode 100644 index 00000000..6dada941 --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-how-tos/index.wiki @@ -0,0 +1,5 @@ +[[Property:title|EiffelStudio How To's]] +[[Property:weight|5]] +[[Property:uuid|10d806ce-5b43-26a5-6f0e-23b3b2faa2ed]] +This chapter contains instructions for accomplishing some of the most commonly required tasks in EiffelStudio. + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-how-tos/running-and-debugging/exploring-application-dynamic-state.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-how-tos/running-and-debugging/exploring-application-dynamic-state.wiki new file mode 100644 index 00000000..449c3061 --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-how-tos/running-and-debugging/exploring-application-dynamic-state.wiki @@ -0,0 +1,20 @@ +[[Property:title|Exploring an application dynamic state]] +[[Property:weight|2]] +[[Property:uuid|0dd359d5-4f84-75c6-1c8c-c4091e916670]] +To view the dynamic state of a debugged application, just stop it at the point where you want to see its context. The debugger tools will automatically be popped up then, yielding the call stack of the application, as well as the state of the objects located in the object tree, which include at least the object corresponding to the level of the call stack where the call stack cursor [[Image:callstack-active-arrow-icon]] is. + +To see at which point the features in the call stack have stopped, just click the feature on which you want this information in the call stack. Doing this will change the cursor position in the call stack and display the flat view of the feature in the context tool. + +To follow an object state between pauses of the application, pick and drop it into the object tree, which will make it stay in it. + +You can also query features dynamically by using the evaluation tool, which can be very useful to have glimpses of the C memory of the system, for instance. + +{{seealso|
+[[Interrupting an application|Pausing an application]]
+[[Call stack tool]]
+[[Object tool]]
+[[Expression evaluation|Evaluation tool]] }} + + + + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-how-tos/running-and-debugging/handling-exceptions.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-how-tos/running-and-debugging/handling-exceptions.wiki new file mode 100644 index 00000000..c41cbc3c --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-how-tos/running-and-debugging/handling-exceptions.wiki @@ -0,0 +1,12 @@ +[[Property:title|Handling exceptions]] +[[Property:weight|4]] +[[Property:uuid|43ce73b9-3ac4-4f71-34a3-f359a66d9082]] +It is possible to raise and catch exceptions in Eiffel. Catching exceptions is done by using the rescue keyword. The [[ref:libraries/base/reference/exceptions_chart|EXCEPTIONS]] class provides helper features to analyze the caught exception and handle it. + +The [[ref:libraries/base/reference/exceptions_chart|EXCEPTIONS]] class also provides ways to raise exception, via its feature [[ref:libraries/base/reference/exceptions_flatshort|raise]] . + +When an exception is raised while the application is being debugged, the application stops immediately and the debugger displays the context in which the exception occurred, whether or not the exception is rescued. + +{{seealso|
+[[ET: Design by Contract (tm), Assertions and Exceptions|Reference of exceptions]] }} + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-how-tos/running-and-debugging/index.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-how-tos/running-and-debugging/index.wiki new file mode 100644 index 00000000..4c08bb34 --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-how-tos/running-and-debugging/index.wiki @@ -0,0 +1,5 @@ +[[Property:title|Running and debugging]] +[[Property:weight|4]] +[[Property:uuid|58896f87-21d7-917d-6d91-661523d8afa9]] + + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-how-tos/running-and-debugging/interrupting-application.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-how-tos/running-and-debugging/interrupting-application.wiki new file mode 100644 index 00000000..f5935e8d --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-how-tos/running-and-debugging/interrupting-application.wiki @@ -0,0 +1,18 @@ +[[Property:title|Interrupting an application]] +[[Property:weight|1]] +[[Property:uuid|89bc6f76-ca23-950f-485a-35973022554b]] +There are two ways a debugged application can be interrupted: its execution can be paused, or it can be killed. + +Two methods can be used to pause a debugged application: +* The [[Pause an application]] , located in both the debug menu and the project toolbar. +* Breakpoints, which make it easy to stop the application at a precise point. + +To kill a debugged application, use the [[Stop a debugged application]] , located in both the debug menu and the project toolbar. + +{{seealso|
+[[Running an application|Running a program]]
+[[Using breakpoints|Using breakpoints]] }} + + + + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-how-tos/running-and-debugging/profiling.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-how-tos/running-and-debugging/profiling.wiki new file mode 100644 index 00000000..cb1c1a4b --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-how-tos/running-and-debugging/profiling.wiki @@ -0,0 +1,72 @@ +[[Property:title|Profiling]] +[[Property:weight|7]] +[[Property:uuid|cd9f3f2d-25bf-4b1a-eaf9-9b9d056228eb]] +The profiler is a tool that gives dynamic execution time information. It is very useful to detect which parts of a program need to be optimized most. + +To use the profiler, the first thing to do is to enable it. + +To enable the profiler: +* Open the [[General Target Options|Project Settings]] dialog. +* In the '''Target''' section, enable '''Profile'''. +* Click '''OK'''. +* You must [[Generating executables|recompile]] your project for the changes to take effect. + +By default the profiler will profile the entire program. However it is possible to enable or disable the profiler on certain clusters only. To do this: +* Open the [[Group Options|Project Settings]] dialog. +* In the '''Clusters''' property, check the '''Profile''' boolean value in the clusters where you want the profiler to be enabled. +* Click '''Apply''' or '''OK'''. +* You must [[Generating executables|recompile]] your project for the changes to take effect. + +It is also possible to dynamically start and stop the profiler in a program. To do this: +* Create an object of type [[ref:libraries/base/reference/profiling_setting_chart|PROFILING_SETTING]] . +* Call [[ref:libraries/base/reference/profiling_setting_flatshort|start_profiling]] on this object to start the profiler. +* Call [[ref:libraries/base/reference/profiling_setting_flatshort|stop_profiling]] on this object to stop the profiler. + +{{tip|To profile only part of a program, turn off the profiler at the very beginning of the program, turn it on just before the part of the code that should be profiled, and turn it back off after this section. Typically, it results in the following code: }} + +In the root feature: + + + local + ps: PROFILING_SETTING + -- Other local variables if necessary. + do + create ps.make + ps.stop_profiling + -- Real program execution. + ps.start_profiling + end + + +And in the feature(s) that needs to be profiled: + + + local + ps: PROFILING_SETTING + -- Other local variables if necessary. + do + create ps.make + ps.start_profiling + -- What needs to be profiled. + ps.stop_profiling + end + + +{{note|Even if the profiler should only work in certain sections of code, the '''Profiling''' check box of the [[General Target Options|Projects Settings]] dialog must be checked or the '''profile''' option must be set on certain clusters. }} + +Once the profiler has been enabled and the program has been recompiled, it is necessary to launch the program. + +{{tip|It is possible to profile debuggable(frozen/melted) executables as well as finalized ones. It is more interesting to profile finalized executables, though, since the execution speed is more representative of what will be obtained by your end users. }} + +When the program exits, a file named 'profinfo' should be generated next to it. + +All that's left to do is launch the [[Profiler wizard]] and follow the instructions. + +{{seealso|
+[[Generating executables|Generating executables]]
+[[Running an application|Running a program]]
+[[Tuning a program|Tuning a program]] }} + + + + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-how-tos/running-and-debugging/running-application.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-how-tos/running-and-debugging/running-application.wiki new file mode 100644 index 00000000..ddbdbde5 --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-how-tos/running-and-debugging/running-application.wiki @@ -0,0 +1,28 @@ +[[Property:title|Running an application]] +[[Property:weight|0]] +[[Property:uuid|61be4ec3-d50c-21b9-0649-fac9cd7796b9]] +There are several ways to launch an application. Not all are available depending on the way you compiled your system. + +Melted and frozen executables can be debugged. Several methods can be used to launch such an executable: +* The default [[Run and stop at breakpoints]] . It launches the executable located in the EIFGENs/target_name/W_code directory under the project directory. The execution stops whenever a breakpoint is encountered. +* The [[Run without breakpoints]] . It has the same behavior except that the execution won't stop when a breakpoint is met. +* The step commands, which execute only a small part of the program at a time: +** The [[Step into a feature]] , which tries to enter the feature that is about to be called. +** The [[Execute one line at a time]] , which executes one execution line. +** The [[Step out of a feature]] , which launches the application and stops it as soon as the application exits the feature it is stopped in. + + +{{tip|All the above commands can be accessed either in the '''Project''' toolbar or in the '''Debug''' menu.
+They can be used either to launch the program or to resume its execution after it has been paused. }} +* It is also possible to select '''Run to breakpoint''' in a [[Breakpoint editing|breakpoint context menu]] to have the application be launched and executed until it reaches the selected execution line. + +Finalized executables can also be run, but they are not debuggable and cannot be interrupted. To run a finalized executable, use the [[Run a finalized executable]] , located in the '''Project''' menu and the '''Project''' toolbar. + +{{seealso|
+[[Generating executables|Compiling an executable]]
+[[Using breakpoints|Using breakpoints]]
+[[Interrupting an application|Interrupting an application]] }} + + + + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-how-tos/running-and-debugging/setting-command-line-arguments.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-how-tos/running-and-debugging/setting-command-line-arguments.wiki new file mode 100644 index 00000000..35aafe09 --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-how-tos/running-and-debugging/setting-command-line-arguments.wiki @@ -0,0 +1,22 @@ +[[Property:title|Setting the command line arguments]] +[[Property:weight|6]] +[[Property:uuid|4aed0363-4aa9-89ce-aaa7-6dce00410afb]] +To debug a program that uses command line parameters, it is possible to have the debugger call the generated program with certain command line arguments automatically. + +To change the command line arguments used when debugging: +* Open the menu entry Execution > Execution Parameters .. +* In this dialog, you can change the current arguments, working directory, and add, change or remove environment variables. +** Use the [Add] button to add a new execution profile. +** Select the '''Arguments''' line, and press '''[Enter]''' to set the arguments value (or double click on the related grid cell). +** Same for Working directory +** To change the environment variable, follow the instructions, i.e double click or press enter to Add a variable, or right click to select from existing variable list. Once the variable line is added, by Right-clicking on the variable line, it is possible to: +*** fill with current variable value (if any), +*** unset it (this way, at execution time, the variable will not be set) +* Click '''[Run]''' to launch the execution in the EiffelStudio debugger. +* It is also possible to launch the execution outside EiffelStudio using the '''[Run Workbench]''' button. + +{{tip|To get the command line arguments in a program, it is possible to either define the root feature as taking an array of [[ref:libraries/base/reference/string_8_chart|STRING_8]] objects, or to use the [[ref:libraries/base/reference/arguments_chart|ARGUMENTS]] class, which provides a lot of functionality linked with command line arguments. }} + + + + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-how-tos/running-and-debugging/tracing.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-how-tos/running-and-debugging/tracing.wiki new file mode 100644 index 00000000..5ffaa81a --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-how-tos/running-and-debugging/tracing.wiki @@ -0,0 +1,220 @@ +[[Property:title|Tracing]] +[[Property:weight|8]] +[[Property:uuid|ecb9dd1e-52a9-25c4-b27b-4b5ec806b115]] +=Introduction= + +The '''tracing facility''' allows you to see a structured log of the flow of control through your system, feature by feature. By default, execution traces are written to standard output. + + +{{note|The tracing facility is not supported on the Microsoft .NET platform.}} + + +=The "Trace" project setting= + +You can make tracing usable for a particular cluster by setting the '''Trace''' setting to '''True''' in your project settings for a particular cluster. + +To do this: +* Open the [[Group Options|Project Settings]] dialog. +* Under '''Clusters''' select the cluster you want to see traced. +* Set the value of '''Trace''' to '''True'''. +* Click '''Apply''' or '''OK'''. +* You must [[Generating executables|recompile]] your project for the changes to take effect. + +This will cause a trace entry to be written to the console for any feature execution on a class in the cluster(s) you selected for tracing. To get a feel for this, look at the following trace outputs, built on the default Eiffel application ("Hello Eiffel World!). + +First, here's what the "Hello Eiffel World!" output looks like without using the tracing facility. + + +[[Image:Tracing 01 off]] + + +Next, here's the output when the '''Trace''' project setting is set to '''True''' on the root cluster. + + +[[Image:Tracing 01 on]] + + +Last, here's the output when '''Trace''' is '''True''' for both the root cluster and EiffelBase. + + +[[Image:Tracing 01 with EiffelBase]] + + +=Dynamic control= + +It is also possible to enable and disable the trace dynamically. To do this: +* Create an object of type [[ref:libraries/base/reference/tracing_setting_chart|TRACING_SETTING]] . +* Call [[ref:libraries/base/reference/tracing_setting_flatshort|enable_tracing]] on this object to start the trace. +* Call [[ref:libraries/base/reference/tracing_setting_flatshort|disable_tracing]] on this object to stop the trace. + +{{tip|To enable tracing on only part of a system, disable tracing at the very beginning of the program, enable it just before the part of the code that should be traced, and then disable it again after this section. The code below illustrates this tip. }} + + +In the root feature: + + + local + ts: TRACING_SETTING + -- Other local variables if necessary. + do + create ts.make + ts.disable_tracing + -- Program execution continues. + ... + + -- Restore tracing before exiting for proper cleanup. + ts.enable_tracing + end + + + +Then, in a feature in which tracing is desired: + + + local + ts: TRACING_SETTING + -- Other local variables if necessary. + do + create ts.make + ts.enable_tracing -- Enable trace + -- Section needing trace. + ... + ts.disable_tracing -- Disable trace + end + + +{{warning| Enabling/disabling tracing as shown above has to be done within the same routine otherwise the computed depth would be inaccurate and this would cause some unpredictable results.}} + +=Using a trace handler= + +You can do more complex tracing tasks by using a trace handler. The deferred class TRACE_HANDLER contains a deferred feature trace which you can effect in a descendant of TRACE_HANDLER. Your effective version of trace will be called whenever a trace event occurs. {TRACE_HANDLER}.trace looks like this: + + + trace (a_type_id: INTEGER; a_c_class_name, a_c_feature_name: POINTER; a_depth: INTEGER; a_is_entering: BOOLEAN) + -- Trigger a trace operation from a feature represented by `a_c_feature_name' defined in + -- class `a_c_class_name' and applied to an object of type `a_type_id' at a call depth `a_depth'. + -- If `a_is_entering' we are entering the routine, otherwise we are exiting it. + require + a_type_id_non_negative: a_type_id >= 0 + a_depth_non_negative: a_depth >= 0 + deferred + end + + +You may notice in the specification for trace above that the arguments representing the class and feature names are of type POINTER (versus some variant of STRING). + +To make this facility more approachable for common tasks, EiffelBase also contains another class, a deferred descendant of TRACING_HANDLER, called STRING_TRACING_HANDLER in which the trace feature's arguments for class and feature names are strings, and the argument for type is an instance of TYPE rather than an integer type id as in TRACING_HANDLER. {STRING_TRACING_HANDLER}.trace looks like this: + + + trace (a_type: TYPE [detachable ANY]; a_class_name, a_feature_name: detachable STRING; a_depth: INTEGER; a_is_entering: BOOLEAN) + -- Trigger a trace operation from a feature represented by `a_feature_name' defined in + -- class `a_class_name' and applied to an object of type `a_type' at a call depth `a_depth'. + -- If `a_is_entering' we are entering the routine, otherwise we are exiting it. + require + a_depth_non_negative: a_depth >= 0 + deferred + end + + +Suppose we wanted to write trace long entries in a private log file for the entry and exit of a number of routines during the run of a simple application. We could create a descendant of STRING_TRACING_HANDLER that looks like this: + + +class + EXAMPLE_HANDLER +inherit + STRING_TRACING_HANDLER + +feature + + trace (a_type: TYPE [ANY]; a_class_name, a_feature_name: STRING_8; a_depth: INTEGER_32; a_is_entering: BOOLEAN) + -- + do + trace_log_file.put_string (create {STRING}.make_filled ('>', a_depth)) + if a_is_entering then + trace_log_file.put_string (" Is entering " + "{" + a_class_name + "}." + a_feature_name + "%N") + else + trace_log_file.put_string (" Is leaving " + "{" + a_class_name + "}." + a_feature_name + "%N") + end + end + + trace_log_file: PLAIN_TEXT_FILE + -- Log file + once + create Result.make_open_write ("my_log_file.txt") + end + + close_log_file + -- Close log file + do + trace_log_file.close + end +end + + +In EXAMPLE_HANDLER the procedure trace is effected to write the desired information to the log_file. + +Then we could use EXAMPLE_HANDLER in a class that might look like this: + + +class + APPLICATION + +create + make + +feature + + make + -- Run application. + local + tracing_setting: TRACING_SETTING + tracing_handler: EXAMPLE_HANDLER + do + create tracing_setting + tracing_setting.enable_tracing + create tracing_handler + tracing_handler.activate + + call_depth_one + + tracing_handler.deactivate + tracing_handler.close_log_file + tracing_setting.disable_tracing + end + + call_depth_one + -- Call depth one routine + do + call_depth_two + end + + call_depth_two + -- Call depth two routine + do + call_depth_three + end + + call_depth_three + -- Call depth three routine + do + + end +end + + +In {APPLICATION}.make, the instances of TRACING_SETTING and EXAMPLE_HANDLER are created. Tracing is enabled and the handler is activated. After the section of interest, the handler is deactivated, the log file closed, and tracing disabled. + +Now consider a system in which {APPLICATION}.make is the root, APPLICATION is the only class in the root cluster, and that the project setting '''Trace''' is true for the root cluster only. After running the system, the content of my_log_file.txt would be: + + +> Is entering {APPLICATION}.call_depth_one +>> Is entering {APPLICATION}.call_depth_two +>>> Is entering {APPLICATION}.call_depth_three +>>> Is leaving {APPLICATION}.call_depth_three +>> Is leaving {APPLICATION}.call_depth_two +> Is leaving {APPLICATION}.call_depth_one + + + + + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-how-tos/running-and-debugging/using-breakpoints.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-how-tos/running-and-debugging/using-breakpoints.wiki new file mode 100644 index 00000000..d27a9d66 --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-how-tos/running-and-debugging/using-breakpoints.wiki @@ -0,0 +1,15 @@ +[[Property:title|Using breakpoints]] +[[Property:weight|3]] +[[Property:uuid|f25c8058-8278-7ee3-79cb-ff97e224e74a]] +To change the status of one breakpoint, it is possible to use the [[Breakpoint editing|breakpoints menu]] , which changes the state of a single breakpoint at a time. + +To change the status of several breakpoints at the same time, the easiest way is to use the [[Breakpoint commands|breakpoints-related commands]] , which have actions at feature-scope, class-scope and system-scope. + +{{seealso|
+[[Running an application|Running an application]]
+[[Interrupting an application|Interrupting an application]]
+[[Breakpoints|Breakpoints reference]] }} + + + + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-how-tos/running-and-debugging/using-debug-clauses.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-how-tos/running-and-debugging/using-debug-clauses.wiki new file mode 100644 index 00000000..f84f5aa5 --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-how-tos/running-and-debugging/using-debug-clauses.wiki @@ -0,0 +1,29 @@ +[[Property:title|Using debug clauses]] +[[Property:weight|5]] +[[Property:uuid|78e0273d-525e-a338-dfe4-d5fc27cd06d3]] +Eiffel provides ways to add debug code to features to help during their debugging. You may think of it as the well-known C construct: + +#ifdef MY_DEBUG_FLAG/* Debug code is here */ #endif + + +The corresponding construct in Eiffel is provided by the debug keyword. It is possible to wrap code inside a debug clause like this: + + + debug("MY_DEBUG_FLAG") + -- Debug code is here. + end + + +It is then possible to enable or disable debug clauses globally. + +To modify the debug clauses status: +* Open the [[Debug Options|Project Settings]] dialog. +* In the '''Debug''' section, you can enable/disable the debug clauses. +* Click '''OK'''. +* You must [[Generating executables|recompile]] your project for the changes to take effect. + +{{tip|Debug clauses make it easy to remove all debug messages when finalizing a system. }} + + + + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-reference/autotest/autotest-interface.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-reference/autotest/autotest-interface.wiki new file mode 100644 index 00000000..1019339c --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-reference/autotest/autotest-interface.wiki @@ -0,0 +1,114 @@ +[[Property:title|The AutoTest Interface]] +[[Property:weight|0]] +[[Property:uuid|6eec11df-9ea0-6834-d41b-a0c23b87c485]] +[[Image:AutoTest interface annotated 01]] + + +The AutoTest interface consists of four primary components: +# The toolbar +# The tests pane +# The test filtering box +# The tabbed creation and results reporting pane + +==Toolbar== + +The toolbar allows you to create new tests using the '''[[#The New Eiffel test wizard|New Eiffel test wizard]]''' and to run existing tests. + +The '''Create new tests''' command ( [[Image:Create new tests]] ) invokes the '''New Eiffel test wizard'''. + +The '''Run filtered tests''' command ( [[Image:debug-run-icon]] ) will, by default, run all tests that are visible in the Tests pane. Whether or not a test is visible depends upon any test [[#Filtering|filtering]] currently in effect. The '''Run filtered tests''' allows other options for running tests through its drop-down icon ( [[Image:toolbar-dropdown-icon]] ). + + +[[Image:AutoTest run all drop down]] + + +The '''Debug filtered tests''' command ( [[Image:AutoTest debug all icon]] ) functions in a similar manner to '''Run filtered tests''' with the exception that each test is paused at its starting point in the EiffelStudio debugger. '''Debug filtered tests''' has a drop-down icon providing the same options as '''Run filtered tests'''. + + +[[Image:AutoTest debug all drop down]] + + +The '''Stop all test related tasks''' command ( [[Image:debug-stop-icon]] ) will halt all tests which were started by the '''Run filtered tests''' or '''Debug filtered tests''' commands. + + +==Tests== + +The Tests pane presents tests in one or more expandable tree views. The structures of the trees depend upon the [[#Filtering|filter]] criteria that you have specified for organizing the view. For example, if you look at tests based on the test classes in which they exist (tag root "''class''"), the structure of the tree view(s) will reflect the clusters in which the test classes exist. + + +[[Image:AutoTest interface test view class]] + + +Likewise, if you look at tests based on their target classes (tag root "''covers''"), the structure of the display will be based on the target classes. + + +[[Image:AutoTest interface test view covers]] + + +Tests and test classes are pickable in the Tests pane. + + +==Filtering== + +The '''Filter''' box allows you to limit which tests are visible in the Tests pane (and, by consequence, the tests run when '''Run filtered tests''' is clicked) by entering filter text in the box and pressing the Enter key. Filter text can be a string of characters that is contained in a test class or test routine name, or it can be a [[Create a manual test#About Tags|tag]] or a portion of a tag hierarchy. + +In fact, filter text fully supports [http://www.regular-expressions.info/ regular expressions], so you can craft more complex and precise filters. (You will notice below when the '''Results''' choice is selected from the Filter box drop-down, that the filter text used is the regular expression "^result".) + +Clicking the '''Clear filter''' icon ( [[Image:general-reset-icon]] ) to the right of the filter box will clear any filter contents and enable the viewing of all tests. The Tests pane is depicted below after clicking the '''Clear filter''' icon and expanding some of the items: + + +[[Image:AutoTest tests pane null filter]] + + +The '''Filter''' box has a drop down icon on its right end. By default this icon provides views of the tests in the Tests pane based on tag criteria. + + +[[Image:AutoTest filter drop down]] + + +The criteria are associated with the roots of their respective tag trees. So for example, if '''Results''' is chosen the Tests pane shows tests grouped by their latest results. + + +[[Image:AutoTest filter result]] + + +{{note|The '''result''' tag hierarchy is, as you may have guessed, virtual and dynamic. A test falling into the '''fail''' subtree may later become part of the '''pass''' subtree without any change to the '''"testing:"''' notes in the test routine code, where tags are established. But for filtering purposes '''result''' tags work like other tags. }} + + +If the '''fail''' subtree name were appended to the '''result''' filter, only the failed tests would be visible in the Tests pane: + + +[[Image:AutoTest filter result fail]] + + +If the filter text is a character string that occurs in a test name, test class name, or a tag path, tests with any match will be visible: + + +[[Image:AutoTest filter withdraw]] + + +==Results== + +This pane supports a tabbed display that provides information about the creation and execution of tests. + +After creation of one or more tests, the creation is logged under the '''Creation''' tab. + +After execution, the tests executed and the status of those tests are shown in the '''Execution''' tab. + + +[[Image:AutoTest interface results execution]] + + +After executing a set of tests, the Testing pane of the Outputs tool shows a chronology of the executions and the results of the tests executed. + + +[[Image:AutoTest testing pane execution results]] + + +You can view more detail about a test's execution by clicking the '''Information''' icon ( [[Image:AutoTest information icon]] ) to the right of the test's entry in '''Results''' when the '''Execution''' tab is selected. + + +[[Image:AutoTest test results details]] + + + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-reference/autotest/eiffel-test-wizard.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-reference/autotest/eiffel-test-wizard.wiki new file mode 100644 index 00000000..8a25599a --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-reference/autotest/eiffel-test-wizard.wiki @@ -0,0 +1,99 @@ +[[Property:title|The Eiffel Test Wizard]] +[[Property:weight|1]] +[[Property:uuid|305a8288-cb6a-df2a-1515-e23138e21566]] +==Introduction== + +The '''New Eiffel test wizard''' creates new tests based on information entered by a developer on a series of wizard panes. Each of the three test types supported by AutoTest requires certain unique information. Therefore, there is a unique sequence of wizard panes corresponding to each test type, but you will notice that some of the same wizard panes are used in more than one sequence. + +The '''New Eiffel test wizard''' is invoked by clicking the '''Create new test''' button ( [[Image:create new tests]] ) on the AutoTest interface toolbar. By default, clicking '''Create new test''' invokes the wizard sequence for a manual test. To choose a different type of test, click the triangle to the right of '''Create new test''' button and use the drop-down menu to select the specific test type you want. + + +[[Image:AutoTest create new test]] + + +Once you begin the process or creation of a new test, you will be shown the sequence of wizard panes. The wizard panes are ordered in such a way that the information most likely to change from the creation of one test to the next appears in the earliest panes. This means that if you need only to change information on the first wizard pane, and the information on later panes can remain as it was when you created a previous test, then you can click the '''Launch''' button directly from the first wizard pane. In this way, you avoid having to re-enter the information on the later panes. + + +==The manual test wizard sequence== + + +Creating manual tests will involve using the following wizard panes. For a guided tour of this process, see [[Create a manual test]]. + + +===The "Manual Test" pane=== + + +In this pane you provide a name for the new test that will be created. This name will be a feature name of the created test class. In this pane you can also indicate that the created class should include redefined versions of features on_prepare (called during preparation for test execution) and/or on_clean (called during clean-up after test execution). + + +[[Image:AutoTest Manual Test pane]] + + +===The "Tags" pane=== + +This pane gives you the ability to associate the new test with certain [[Create a manual test#About Tags|tags]]. + + +[[Image:AutoTest Tags pane]] + + +To add a tag for a covered class and feature, or a predefined tag, such as '''run test serially''' or '''run test in private evaluator''' click on the appropriate link below the text entry boxes. + +There is an entry box with an '''Add''' button to its right. Use it to create entries for a tag system that you have developed. + + +===The "General" pane=== + +Here you provide a name for the class that is your new test set. + + +[[Image:AutoTest General pane]] + + +You can also choose where you would like your test classes to reside. By default, tests will be kept in a folder in your project's EIFGENs folder. This is an easy way to do things, but if you manually delete the EIFGENs folder, you'll delete your tests. In the screenshot above a new cluster called "tests" was created to house the test suite. + + + +==The extracted test wizard sequence== + + +The '''Extract tests from debugger''' choice in the '''Create new test''' drop-down menu is only sensitive if the system is currently running. + +Creating extracted tests will involve using the "Test Extraction", "Tags", and "General" wizard panes. The "Tags" and "General" panes are used as shown above. + + +===The "Test Extraction" pane=== + + +[[Image:AutoTest Test Extraction Pane]] + + +This pane provides a depiction of the current call stack. Choose the routine or routines for which you want extracted tests to be created. + + +==The generated test wizard sequence== + +For generated tests, there are two options on the '''Create new test''' drop-down menu. '''Generate tests for open classes''' and '''Generate tests for custom types'''. The difference is that if you select '''Generate tests for open classes''', AutoTest automatically populates the '''Types to test''' box with the names of any classes that are currently open in the Editor pane. + +Creating generated tests will involve using "Test Generation", "Tags", and "General" panes. The "Tags" and "General" panes are used as shown above. + + +===The "Test Generation" pane=== + + +[[Image:AutoTest Test Generation pane]] + + +On this pane enter the information needed to produce generated tests. Use the '''Class or type name''' entry box, along with the + and - buttons, to declare a list of one or more classes as target classes for generated tests. + +Other information necessary for creating generated tests is: + +*'''Cutoff (minutes)''' -- How long AutoTest will execute random invocations of the routines in the classes to be tested, specified in minutes. +*'''Cutoff (invocations)''' -- How long AutoTest will execute random invocations of the routines in the classes to be tested, specified by invocation count. +*'''Routine timeout (seconds)''' -- How long AutoTest will wait for completion of any invocation. +*'''Random number generation seed''' -- The seed used for random number generator used during the process. A value of zero instructs AutoTest to use a seed derived from the system clock. +*'''Slice minimization''' -- Designate '''slicing''' as the approach for minimizing the size of generated tests. +*'''DDMin for minimization''' -- Designate '''DDMin''' as the approach for minimizing the size of generated tests. +*'''HTML statistics''' -- Output history and statistics from the synthesizing process in html format. + + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-reference/autotest/index.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-reference/autotest/index.wiki new file mode 100644 index 00000000..751550aa --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-reference/autotest/index.wiki @@ -0,0 +1,31 @@ +[[Property:title|AutoTest]] +[[Property:weight|-1]] +[[Property:uuid|1d8cc843-238e-feaa-cfa6-629f080ffba7]] +==Introduction== + +AutoTest is a facility within EiffelStudio that helps developers create, manage, and execute software tests. + +This documentation is intended to describe the AutoTest interface and capabilities. In addition to this material, you will find a tutorial entitled [[Using AutoTest]] in [[Introducing EiffelStudio]]. The tutorial employs a simple example that is used to work step-by-step through AutoTest's different facilities. The tutorial also explains testing basics and recommendations for using AutoTest. Lastly, the tutorial contains definitions for terminology used in both the tutorial and in these reference pages. It is recommended that you become familiar with these definitions, specifically: + +#[[Testing: Background and basics#Test classes and tests|Test classes and tests]] +#[[Testing: Background and basics#Types of tests|The types of test supported by AutoTest]] +#[[Testing: Background and basics#Anatomy of a test|Target classes and target routines]] +#[[Execute tests#About test results|Test results]] + + + +==Components== + +When you use AutoTest, you control things by using two components: '''[[The AutoTest Interface]]''' and '''[[The Eiffel Test Wizard]]'''. The interface is used to access, manage, execute, and monitor tests. The New Eiffel test wizard is used to help you create new tests. + + +{{Caution|At this time, AutoTest will work only for project targets in the classic Eiffel environment. This means that projects targeted to Microsoft .Net will not be able to use AutoTest.}} + + +{{Recommended|During the transition to void-safe Eiffel, projects can be built using '''experimental''' mode. This mode is as stable as '''non-experimental''' mode, but includes some facilities that might break existing code in a few circumstances. However, since version 6.5, EiffelStudio itself is built in experimental mode, so '''we recommend that you use AutoTest only on projects also built using experimental mode'''. Experimental mode can be invoked by using the "-experiment" option from the command line, or on Microsoft Windows by following the '''Start''' menu path to EiffelStudio and selecting experimental mode. }} + + +{{SeeAlso|
[[Using AutoTest]] }} + + + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-reference/browsing-tools/address-bars/change-data-share-mode.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-reference/browsing-tools/address-bars/change-data-share-mode.wiki new file mode 100644 index 00000000..5cfbe498 --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-reference/browsing-tools/address-bars/change-data-share-mode.wiki @@ -0,0 +1,12 @@ +[[Property:title|Change data share mode]] +[[Property:weight|3]] +[[Property:uuid|52206181-e002-0914-d98d-c817d32ec02e]] +Located in the '''View''' menu, named either '''Link context tool''' or '''Unlink context tool''', this command allows you to switch between the two possible [[Address bars|addressing modes]]. Toggling of Linked/Unlinked mode also can be accomplished through a button on the main toolbar ([[Image:context-link-icon]]). By default, this button is not visible, but can be added to the toolbar through [[Toolbar customization|toolbar customization]]. + +{{note|This command only applies to the development window where it is invoked, and this setting is not automatically saved when exiting EiffelStudio. }} + +{{seealso|
+[[Development Window Preferences|Change the default data sharing]]}} + + + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-reference/browsing-tools/address-bars/context-tool-address-bar.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-reference/browsing-tools/address-bars/context-tool-address-bar.wiki new file mode 100644 index 00000000..56b67a24 --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-reference/browsing-tools/address-bars/context-tool-address-bar.wiki @@ -0,0 +1,22 @@ +[[Property:title|Context tool address bar]] +[[Property:weight|2]] +[[Property:uuid|1d68fcd1-8839-0b1e-a546-7ab51b3c0e74]] +The address bar of the context tool has a different look from the [[Main address bar|main address bar]] , but provides the same functionality. + +[[Image:context-address-bar]] + +It also contains history arrows, and by clicking on the cluster, class or feature name, a window is popped up that contains fields similar to the ones of the [[Main address bar|main address bar]] , except that a cluster can also be entered, since the diagram tool and the metrics also work with clusters: + +[[Image:context-address-window]] + +{{tip|Labels in this address bar are pickable, to send the address to other tools easily. }} + + +{{note|The context tool only has an address bar if it is unlinked from the editor. }} + +{{seealso|
+[[Change data share mode|Unlinking the context tool]] }} + + + + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-reference/browsing-tools/address-bars/index.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-reference/browsing-tools/address-bars/index.wiki new file mode 100644 index 00000000..5f7f8ee5 --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-reference/browsing-tools/address-bars/index.wiki @@ -0,0 +1,17 @@ +[[Property:title|Address bars]] +[[Property:weight|1]] +[[Property:uuid|e145c4d3-afd3-653d-cf7c-14fd80f4d566]] +All development windows are composed of two major components, each of which can be centered on a given "address" (either a cluster, a class or a feature). One is the editor, with which go all the peripheral tools (including the [[Groups tool|groups tool]] and the [[Features tool|features tool]] ). The other is the context tool, which contains for example the [[Formatted information about compiled classes and features|class and feature tabs]] , the [[Diagram tool|diagram tool]] and the [[Metrics tool|metric tool]] . + +It is possible to either link both components so that they share the same address (allowing to immediately have extended information on the class that is being edited), or to unlink them (allowing to have extended information on any class while editing a class). + +When both are linked, only the [[Main address bar|main address bar]] appears, whereas when they are unlinked, the [[Context tool address bar|context tool address bar]] is also displayed, since it might point to a different location than the main address bar. + +The [[Change data share mode|toggle data mode command]] allows you to switch between both modes. + +{{seealso|
+[[Development Window Preferences|Change the default data sharing]] }} + + + + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-reference/browsing-tools/address-bars/main-address-bar.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-reference/browsing-tools/address-bars/main-address-bar.wiki new file mode 100644 index 00000000..ed711192 --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-reference/browsing-tools/address-bars/main-address-bar.wiki @@ -0,0 +1,35 @@ +[[Property:title|Main address bar]] +[[Property:weight|1]] +[[Property:uuid|491b7b6d-4d7c-287f-8442-2b35d000a54b]] +The main address bar is located in the top part of windows, between the two [[Main toolbars|main toolbars]] (when they are displayed). + +[[Image:main-address-bar]] + +It has several components: +* '''History back and forth arrows''' [[Image:view-previous-icon]] and [[Image:view-next-icon]] +** These functions are also accessible from the menu path View -> Go to + +* '''Current class and feature name fields''' +** These fields display the names of the class and/or feature currently active in the editor pane. +** It is possible to type a class or feature name to center the editor on it. +** Typing a class name that does not exist in the set of known classes pops up a dialog to create a class of that name. +** The "wildcard" characters '''*''' and '''?''' may be used in these fields. + +* '''View icons''' [[Image:view-editor-icon]] , [[Image:view-clickable-icon]] , [[Image:view-flat-icon]] , [[Image:view-contracts-icon]] and [[Image:view-flat-contracts-icon]] +** Click to change the view currently displayed in the editor. +** Drop a pebble to retarget the editor to a class or feature using the selected view. + +* '''Viewpoints selector''' +** The Viewpoints selector can only be active if you have used [[Group Options#Renaming|renaming and/or prefixing]] in your project settings to specify alternate class names for some classes used by your project. Otherwise it is inactive. In a project with renaming and/or prefixing, the Viewpoints selector becomes active when both of the following are true: +*** The editor window is focused on a class that has been renamed or prefixed in project settings. +*** The class is being viewed in a formatted view, i.e., a view other than the '''Basic text view'''. +** The Viewpoints selector allows you to select how you would like to view renamed or prefixed classes: +*** As they really exist, i.e., as if you are their producer, or +*** Using the alternative names that you have specified in your project settings. + + + + + + + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-reference/browsing-tools/favorites-tool/favorites-menu.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-reference/browsing-tools/favorites-tool/favorites-menu.wiki new file mode 100644 index 00000000..69d962c8 --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-reference/browsing-tools/favorites-tool/favorites-menu.wiki @@ -0,0 +1,15 @@ +[[Property:title|Favorites menu]] +[[Property:weight|2]] +[[Property:uuid|8157cc25-a299-3af6-8218-e5dfd094793d]] +The '''favorites''' menu is composed of two parts. + +First, there are three commands: +* The '''Add to Favorites''' command, that adds the currently edited class to the root of the favorites tree. +* The '''Show/Hide Favorites''' command, that shows or hides the [[Favorites tree|favorites tree]] . +* The '''Organize Favorites''' command, that displays the [[Organize favorites dialog|Organize Favorites dialog]] . + +After the separator, the favorites are displayed in a menu representation. Clicking on any of these menu items will send the selected favorite class to the editor. + + + + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-reference/browsing-tools/favorites-tool/favorites-tree.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-reference/browsing-tools/favorites-tool/favorites-tree.wiki new file mode 100644 index 00000000..a853cf1d --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-reference/browsing-tools/favorites-tool/favorites-tree.wiki @@ -0,0 +1,14 @@ +[[Property:title|Favorites tree]] +[[Property:weight|1]] +[[Property:uuid|642c0a65-971e-b399-3e15-74af6dada046]] +The favorites tree gives a graphical representation of the favorite classes of the system, as opposed to the favorites menu. + +[[Image:favorites-tree]] + +In this tree, the folders are user-definable through the [[Organize favorites dialog|Organize Favorites dialog]] . They have no other goal than ordering the favorites. In particular, they are entirely independent from the clusters of the system. + +Clicking a class in the favorites tree edits it. Keyboard navigation is also available. Favorite classes are [[Pick-and-drop mechanism|pickable]] too, so that it is possible to send them to all interface components that accept classes. + + + + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-reference/browsing-tools/favorites-tool/index.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-reference/browsing-tools/favorites-tool/index.wiki new file mode 100644 index 00000000..2fc3a100 --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-reference/browsing-tools/favorites-tool/index.wiki @@ -0,0 +1,9 @@ +[[Property:title|Favorites tool]] +[[Property:weight|4]] +[[Property:uuid|75cfeda2-3823-ef29-130a-39e686116f40]] +The favorites tool ( [[Image:tool-favorites-icon]] ) gives a quick access to often used classes and features. These may be either classes of a library or classes that are often being modified. They are project-wide, which means they are shared by all development windows working on the same project. + +[[Image:favorites-tool]] + +The favorites tool mainly consists of [[Favorites menu|the favorites menu]] and of the left-panel tool, giving a [[Favorites tree|tree representation]] of the favorite classes. + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-reference/browsing-tools/favorites-tool/organize-favorites-dialog/create-favorite-folder-command.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-reference/browsing-tools/favorites-tool/organize-favorites-dialog/create-favorite-folder-command.wiki new file mode 100644 index 00000000..0949f486 --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-reference/browsing-tools/favorites-tool/organize-favorites-dialog/create-favorite-folder-command.wiki @@ -0,0 +1,12 @@ +[[Property:title|Create favorite folder command]] +[[Property:weight|2]] +[[Property:uuid|a6d2f458-81ad-bc62-6476-2aabb3900a80]] +This command [[Image:favorites-dialog-new-folder]] is accessible in the Organize favorites dialog. When clicked, a dialog is popped up that prompts for a name for the new folder: + +[[Image:favorites-new-folder-dialog]] + +After typing the name of the new folder, pressing '''OK''' adds it to the root of the favorites. + + + + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-reference/browsing-tools/favorites-tool/organize-favorites-dialog/index.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-reference/browsing-tools/favorites-tool/organize-favorites-dialog/index.wiki new file mode 100644 index 00000000..67657924 --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-reference/browsing-tools/favorites-tool/organize-favorites-dialog/index.wiki @@ -0,0 +1,16 @@ +[[Property:title|Organize Favorites dialog]] +[[Property:weight|3]] +[[Property:uuid|3e47cb30-c974-b0f4-1624-4bba035bd906]] +The organize favorites dialog provides a way of sorting the favorites. + + +[[Image:favorites-dialog]] + + +The left part of this dialog is composed of a [[Favorites tree|tree representation]] of the favorites identical to the one in the [[Favorites tool|favorites tool]] . +With it, it is possible to [[New favorite class command|add classes]] and [[Create favorite folder command|folders]] to the favorites or [[Remove favorite command|remove some]] , and also to [[Move to Folder command|spread]] the favorite classes among the favorite folders. + +{{warning|Since the favorites are project-wide, any modifications made in this dialog are reported in all development windows. }} + + + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-reference/browsing-tools/favorites-tool/organize-favorites-dialog/move-folder-command.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-reference/browsing-tools/favorites-tool/organize-favorites-dialog/move-folder-command.wiki new file mode 100644 index 00000000..c75d1025 --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-reference/browsing-tools/favorites-tool/organize-favorites-dialog/move-folder-command.wiki @@ -0,0 +1,23 @@ +[[Property:title|Move to Folder command]] +[[Property:weight|3]] +[[Property:uuid|087439e6-dc0c-d394-b3ed-ffaaf5928b39]] +The Move to Folder command [[Image:favorites-dialog-move-to]] , located in the [[Organize favorites dialog|Organize Favorites dialog]], makes it possible to move favorite items (classes and folders) to specific folders. It is enabled only when an item is selected in the left-hand tree in this dialog. The source is the selected item that could be moved. You can select a different source item by clicking it in the tree, or by using the keyboard. + +When pressed, a dialog is popped up, that prompts for the favorite folder the selected item should be moved to. + +[[Image:favorites-choose-folder-dialog]] + +Select the destination folder by expanding the tree and by clicking it. The top tree item, named Favorites, represents the root of the favorites. + +Pressing '''OK''' moves the source item to the destination folder. Pressing '''Cancel''' discards the dialog box and does not move the source item. + +{{tip|You can also move items around by picking them in the favorites tree and dropping them where you want. }} + + +{{seealso|
+[[Favorites tree|Favorites tree]]
+}} + + + + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-reference/browsing-tools/favorites-tool/organize-favorites-dialog/new-favorite-class-command.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-reference/browsing-tools/favorites-tool/organize-favorites-dialog/new-favorite-class-command.wiki new file mode 100644 index 00000000..c442289f --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-reference/browsing-tools/favorites-tool/organize-favorites-dialog/new-favorite-class-command.wiki @@ -0,0 +1,23 @@ +[[Property:title|New favorite class command]] +[[Property:weight|1]] +[[Property:uuid|18be5a70-d623-a45c-cf3d-45c1dc0a2ec5]] +Located in the [[Organize favorites dialog|Organize Favorites dialog]] , this command: + +[[Image:favorites-dialog-new-class]] + +provides a way of adding a class to the favorites. When clicked, a new dialog is popped up, that allows to select a class among the clusters of the system: + +[[Image:favorites-new-class-dialog]] + +Clicking on a class name sets its name in the top text field, whereas double-clicking it automatically selects it and closes the dialog box. It is also possible to directly type the name of the wanted class in the top text field to select it. + +The selected class goes to the root of the favorite tree. It is then possible to [[Move to Folder command|move]] it to a different favorite folder. + +{{seealso|
+[[Favorites tool|Favorite tool]]
+[[Favorites menu|Favorite menu]]
+}} + + + + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-reference/browsing-tools/favorites-tool/organize-favorites-dialog/remove-favorite-command.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-reference/browsing-tools/favorites-tool/organize-favorites-dialog/remove-favorite-command.wiki new file mode 100644 index 00000000..b95d4ef0 --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-reference/browsing-tools/favorites-tool/organize-favorites-dialog/remove-favorite-command.wiki @@ -0,0 +1,7 @@ +[[Property:title|Remove favorite command]] +[[Property:weight|4]] +[[Property:uuid|c55daacd-a7f8-294b-6b2c-9d503e6a3969]] +The Remove favorite command [[Image:favorites-dialog-remove]] discards a favorite item from the favorites. It is enabled whenever an item is selected in the left-hand tree of the [[Organize favorites dialog|Organize favorites dialog]]. + +Pressing it removes the selected item from the favorites. + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-reference/browsing-tools/features-tool/feature-tree.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-reference/browsing-tools/features-tool/feature-tree.wiki new file mode 100644 index 00000000..0fce1b6f --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-reference/browsing-tools/features-tool/feature-tree.wiki @@ -0,0 +1,25 @@ +[[Property:title|Feature tree]] +[[Property:weight|1]] +[[Property:uuid|6b5e1448-4547-2d4d-ef5d-165d5dbaedc1]] +[[Image:feature-tree]] + +The feature tree gives a summary of all the features of the currently edited class. They are in the same order as they are in the class file, and they are grouped by their feature clause. + +The icon relative to the feature clause indicates the export status of the features inside it: +* [[Image:folder-features-all-icon]] means features are exported to all classes +* [[Image:folder-features-some-icon]] means features are exported to some classes +* [[Image:folder-features-none-icon]] means features are not exported + +The icon on the features indicates the nature of the feature: +* [[Image:feature-attribute-icon]] for attributes +* [[Image:feature-once-icon]] for once and constant features +* [[Image:feature-deferred-icon]] for deferred features +* [[Image:feature-external-icon]] for external features +* [[Image:feature-frozen-routine-icon]] for frozen features +* [[Image:feature-routine-icon]] for normal Eiffel routines + +Clicking a feature or a feature clause in the tree centers the editor on it. Key navigation is also available. All features can be [[Pick-and-drop mechanism|picked]] , to [[Pick-and-drop mechanism|be dropped]] them into any component of the interface that accepts features. + + + + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-reference/browsing-tools/features-tool/index.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-reference/browsing-tools/features-tool/index.wiki new file mode 100644 index 00000000..6e817d07 --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-reference/browsing-tools/features-tool/index.wiki @@ -0,0 +1,15 @@ +[[Property:title|Features tool]] +[[Property:weight|3]] +[[Property:uuid|bc9b2ef1-b4c4-773a-9ba8-97143fb2727a]] +{| border="0" +|- +| [[Image:feature-tool]] +| +And if you click on [[Image:feature-tool-signature-button|[S]]] the signature toggle button.
+You will see the signature for each feature + +| [[Image:feature-tool-signature]] +|} +The Features tool gives a summary of all immediate (written-in) features of the currently edited class. They are listed in a [[Feature tree|tree representation]] , where the nodes are the feature clauses, and the leaves are the features. +In the tool mini-toolbar, a [[New feature command|new feature command]] is available, which adds a new feature in the edited class. + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-reference/browsing-tools/features-tool/new-feature-command.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-reference/browsing-tools/features-tool/new-feature-command.wiki new file mode 100644 index 00000000..de267a66 --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-reference/browsing-tools/features-tool/new-feature-command.wiki @@ -0,0 +1,7 @@ +[[Property:title|New feature command]] +[[Property:weight|2]] +[[Property:uuid|3a670193-29dd-b829-0c90-eec8dd7e74b6]] +The new feature command [[Image:new-feature-icon]] located in the [[Features tool|features tool]] acts like the [[New feature dialog|main new feature command]] . Clicking it pops up the same dialog, making it possible to add a new feature in the currently edited class. + +This command is only available when the class currently in the editor is compiled, can be modified, and has a file on the disk (this may not be the case if the class is precompiled). + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-reference/browsing-tools/groups-tool/index.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-reference/browsing-tools/groups-tool/index.wiki new file mode 100644 index 00000000..b6839338 --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-reference/browsing-tools/groups-tool/index.wiki @@ -0,0 +1,9 @@ +[[Property:title|Groups tool]] +[[Property:weight|2]] +[[Property:uuid|0baebaa5-a9c8-4c7c-6ace-c11d82804906]] +[[Image:tool-clusters-icon]] + +[[Image:groups-tool]] + +The groups tool gives a [[System tree representation|tree representation]] of all clusters, libraries and classes of the project. The toolbar contains a [[New cluster command|new cluster command]] , a [[New class command|new class command]] , and the [[Locate command|locate command]] . + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-reference/browsing-tools/groups-tool/locate-command.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-reference/browsing-tools/groups-tool/locate-command.wiki new file mode 100644 index 00000000..1cfc8d91 --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-reference/browsing-tools/groups-tool/locate-command.wiki @@ -0,0 +1,12 @@ +[[Property:title|Locate command]] +[[Property:weight|4]] +[[Property:uuid|10d2cf53-4e11-d44c-ee05-12fc1c6c354c]] +The locate command ( [[Image:general-search-icon]] ), located in the [[Groups tool|groups tool]], provides an easy way to find a class or a cluster in the [[System tree representation|cluster tree]] . + +Clicking it automatically expands the clusters containing the edited class or cluster and selects it. + +[[Pick-and-drop mechanism|Dropping]] a class or a cluster on it expands the clusters containing the searched item and selects it. + + + + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-reference/browsing-tools/groups-tool/new-class-command.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-reference/browsing-tools/groups-tool/new-class-command.wiki new file mode 100644 index 00000000..ccd9ea2c --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-reference/browsing-tools/groups-tool/new-class-command.wiki @@ -0,0 +1,12 @@ +[[Property:title|New class command]] +[[Property:weight|3]] +[[Property:uuid|ca2a2b34-7bdf-52c7-c300-f780df40bca0]] +The new class command ( [[Image:new-class-icon]] ) located in the groups tool toolbar creates a class in the same fashion as the main new class command. The only difference is that when using the groups tool command, the new class is by default located in the cluster selected in the [[System tree representation|cluster tree]] (or the parent cluster of the selected class, if a class is selected). + +A dialog is then popped up in which it is possible to select the name of the new class, the name of the file it should be created in (by default ".e" is appended to the name of the new class to generate the file name), and the cluster in which the new class should be inserted. Only clusters that are not libraries are displayed in the list, since library clusters cannot be modified. + +[[Image:new-class-dialog]] + + + + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-reference/browsing-tools/groups-tool/new-cluster-command.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-reference/browsing-tools/groups-tool/new-cluster-command.wiki new file mode 100644 index 00000000..9b8eb02d --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-reference/browsing-tools/groups-tool/new-cluster-command.wiki @@ -0,0 +1,17 @@ +[[Property:title|New cluster command]] +[[Property:weight|2]] +[[Property:uuid|8aa7c073-65dd-99d9-edba-73737d90fccf]] +The new cluster command ( [[Image:new-cluster-icon]] ) located in the groups tool toolbar creates a cluster in the same fashion as the main new cluster command. The only difference is that when using the cluster tool command, the new cluster is by default located in the cluster selected in the [[System tree representation|cluster tree]] (or the selected class's parent cluster, if a class is selected). + +A dialog is then popped up in which it is possible to select the name of the new cluster and the cluster in which the new cluster should be inserted. Only clusters that are not libraries are displayed in the list. + +[[Image:new-cluster-dialog]] + +Enabling the '''recursive''' option makes the compiler search not only the cluster directory but also all its sub-directories for classes.
+The '''library''' option optimizes compilations, since the classes inside a library cluster are compiled only once. However, if you modify the classes inside a library cluster, the modifications will not be taken into account in your project. Besides, you cannot add or remove classes in a library cluster, so use this option with care: if you intend to create new classes inside this cluster later in your design, do not select the library option. You should use this option only if the new cluster is given an existing directory, which already contains classes that you will not modify. + +{{tip|You don't have to enter a path for the new cluster if you choose to create a sub-cluster: the new cluster directory will be a sub-directory of the directory of the parent cluster, and its name will be the name of the newly created cluster. }} + + + + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-reference/browsing-tools/groups-tool/system-tree-representation.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-reference/browsing-tools/groups-tool/system-tree-representation.wiki new file mode 100644 index 00000000..b2c2c59d --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-reference/browsing-tools/groups-tool/system-tree-representation.wiki @@ -0,0 +1,21 @@ +[[Property:title|System tree representation]] +[[Property:weight|1]] +[[Property:uuid|fc30ebd1-2a70-08ef-ae54-751ad834b489]] +The groups tool is mainly composed of a tree representation of the system. + +[[Image:cluster-tree]] + +Here is the meaning of the symbols of the cluster tree: +* [[Image:folder-cluster-icon]] , [[Image:folder-cluster-readonly-icon]] , [[Image:folder-blank-icon]] , [[Image:folder-override-cluster-icon]] , [[Image:folder-hidden-cluster-icon]] , are clusters (normal, readonly, subfolder in a recursive cluster, override cluster, hidden/implementation cluster) +* [[Image:folder-library-icon]] are libraries +* [[Image:folder-assembly-icon]] are assemblies +* [[Image:folder-namespace-icon]] are namespaces in assemblies +* [[Image:class-normal-icon]] , [[Image:class-frozen-icon]] , [[Image:expanded-normal-icon]] , [[Image:class-deferred-icon]] , [[Image:class-overriden-normal-icon]] , [[Image:class-override-normal-icon]] are compiled classes (normal, frozen, expanded, deferred, overriden, overriding) +* Greyed out classes are classes outside the system. +* Classes and clusters that are part of a readonly group are shown with a lock (for clusters) or brighter icon than normal (they cannot be modified) +* [[Image:folder-target-icon]] are targets + +Left-clicking on any item will send it to the editor. It is also possible to [[Pick-and-drop mechanism|pick]] items to send them to various components of the development window. + +[[Pick-and-drop mechanism|Dropping]] a class in this tree representation moves it to a different cluster (either the cluster it is dropped on or the cluster containing the class it is dropped on, according to where it is dropped). This is only possible if the dropped class is not in a library cluster, if its source file is readable and writable, and if the destination cluster is not a library or precompiled cluster itself. + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-reference/browsing-tools/index.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-reference/browsing-tools/index.wiki new file mode 100644 index 00000000..2039d620 --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-reference/browsing-tools/index.wiki @@ -0,0 +1,11 @@ +[[Property:title|Browsing tools]] +[[Property:weight|-13]] +[[Property:uuid|b4e840c3-a635-b5dd-fbd2-0db69b3d6ce1]] +The browsing tools are the address bars as well as all the tools that are in the left panel of development windows in normal mode. They help find an item in the system, such as a class, a cluster, a feature, some text, ... They include the [[Address bars|address bars]], the [[Groups tool|groups tool]], the [[Features tool|features tool]], the [[Favorites tool|favorites tool]], the [[Windows tool|windows tool]], and the [[Search tool|search tool]] . + +{{seealso|
+[[EiffelStudio window overview|General window overview]] }} + + + + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-reference/browsing-tools/search-tool.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-reference/browsing-tools/search-tool.wiki new file mode 100644 index 00000000..a8a8cc8c --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-reference/browsing-tools/search-tool.wiki @@ -0,0 +1,99 @@ +[[Property:title|Search tool]] +[[Property:weight|6]] +[[Property:uuid|4d0cc8b3-2ffd-42d4-7855-672fa0c11cf8]] +EiffelStudio includes a '''search tool''' which allows you to look for a word, phrase, string or even a pattern and, if you wish, to replace the matches it finds with some other word, phrase, or string. The search scope of the tool can be confined to the current editor pane, to the whole project, or to a custom domain of your choosing. + +If the search tool is not currently visible, you can make it appear by clicking on the search icon [[Image:tool-search-icon]] or by following either menu path: + + View -> Tools -> Search + +or + + Edit -> Find + + +==The Search panel== + +[[Image:search-tool]] + +Fig. 1: Search panel + +The search panel has two tabs. The '''search tab''' allows you to define how and for what strings and patterns you want to search (or search and replace). The '''scope tab''' allows you to define the limits of your search. + +===The Search tab=== + +On the '''search tab''' of the search panel (shown in Fig. 1), you will find two combo boxes, labeled '''Search for:''' and '''Replace with:'''. These are used to enter the string or pattern for which you want to search and the word or phrase, if any, which you want the editor to use to replace matches resulting from the search. + +Also in the Search tab, there are buttons that control whether you want to '''search''', to '''replace''' the most recently found match, or '''replace all''' matches. + +====Using sub-patterns and back references==== + +If you are searching using '''regular expressions''' (see [[#The options group|The options group]] below), you can use '''sub-patterns''' in your search pattern. This allows you to capture the portion of a "match" that satisfies a sub-pattern the search. Then, in the replacement, you can make a '''back reference''' to that captured part of the match. You can create more than one sub-pattern in any search pattern. + +To create a sub-pattern, in the '''Search for:''' combo box, enclose in parentheses any parts of the search that you want to capture for use in the replacement. Then, in the '''Replace with:''' combo box, you can back reference each capture by its index enclosed in backslashes. The following example should help make this clear. + +Assume that the text you are searching contains the following: + + -- The dog is chasing the cat + +Then, you enter values into the '''Search for:''' and '''Replace with:''' boxes so that it looks like this: + + +[[Image:Search capture boxes]] + +After the replacement, your text will look like this: + + -- The cat is being chased by the dog + + +====The options group==== + +There are four search options, each of them represented by a check box: + +* '''Match case:''' If this option is selected, the search will be case-sensitive, which means that if you search for "example", the tool will highlight "example" but not "EXAMPLE" or "Example", as there are no capital letters in the searched pattern. + +* '''Whole word:''' If this option is selected, the tool will look for isolated words. A word is isolated if it is surrounded by spaces or if it is at the beginning or the end of a line. + +* '''Use regular expressions:''' You can enter a regular expression as a pattern for matching. In Fig. 1, the regular expression in the '''Search for:''' box describes very simple quoted strings. Regular expressions give you the ability to create powerful pattern-oriented searches. If you are not familiar with regular expressions, you might check out the tutorial at [http://www.regular-expressions.info/ www.regular-expressions.info]. + +{{note|It might be good advice to temper your expectations of using regular expressions with these words, [http://www.devtopics.com/101-more-great-computer-quotes/ attributed] to Jamie Zawinski: "Some people, when confronted with a problem, think `I know, I'll use regular expressions.' Now they have two problems."}} + +* '''Search backwards:''' If this option is selected, the tool will highlight the previous occurrence of the searched pattern instead of the next occurrence when you click the '''Search button'''. + +{{note|If the search tool hits one end of the text, it will automatically continue from the other end. }} + +===The Scope tab=== + +[[Image:search-tool-scope-tab]] + +Fig. 2 Scope tab + +In the scope tab, you can choose how wide a search you would like to make. + +* '''Current editor''' Your search will be confined to the class which is the current target of the Editor pane. +* '''Whole project''' The entire project universe will be searched. +* '''Custom''' You are given the opportunity to choose which classes and clusters you would like to be included in the search scope. + +When you make certain choices, one or both of the check boxes become enabled. + +If you choose '''Whole project''', the '''Only compiled classes''' check box becomes enabled. If you check the box, then the search is confined to classes which are actually included in your system (i.e., reachable via relationships from your root class ... the classes shown with blue ovals). If you leave '''Only compiled classes''' unchecked, all classes in your project's universe are included in the search (blue and grey ovals). With '''Whole project''', the '''Recursive''' check box remains disabled. + +If you choose '''Custom''', both the '''Only compiled classes''' check box and the '''Recursive''' check box become enabled. The '''Recursive''' check box allows the search to include recursively subclusters of any cluster included in the search. + +==The Search Report panel== + +[[Image:search-report-01]] + +Fig. 3 Search Report panel + +The search report panel will be visible whenever your search returns matches on multiple classes. The '''collapsed''' view of the search results shows the class name of classes in which matches were found, and the number of matches. When you '''expand''' and entry, you see the line number at which the match occurs, and the exact string that caused the match. If you have used [[#Using sub-patterns and back references|'''sub-patterns''']] in your search, then the captures for each sub-pattern will also be shown in the search report panel when the entries are completely expanded. + +The items in the search report panel can be [[Pick-and-drop mechanism|picked and dropped]] into the editor or other appropriate targets in EiffelStudio. + + + + +{{seealso|The [[Search functionality]] part of the EiffelStudio Editor section to learn keyboard shortcuts and menu entries to launch searches without using the search tool directly. }} + + + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-reference/browsing-tools/windows-tool/index.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-reference/browsing-tools/windows-tool/index.wiki new file mode 100644 index 00000000..9deb10a7 --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-reference/browsing-tools/windows-tool/index.wiki @@ -0,0 +1,16 @@ +[[Property:title|Windows tool]] +[[Property:weight|5]] +[[Property:uuid|57b14a4b-8694-12f6-06c8-24411e331559]] +The windows tool ( [[Image:windows-windows-icon]] ) gives a list of opened development windows. + +[[Image:windows-tool]] + +Its main component is the [[Window list|Window list]] . + +It is also linked to the [[Window menu|Window menu]] menu. + +[[Window related commands|Window related commands]] provide global management of windows. + + + + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-reference/browsing-tools/windows-tool/window-list.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-reference/browsing-tools/windows-tool/window-list.wiki new file mode 100644 index 00000000..66a3a5b3 --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-reference/browsing-tools/windows-tool/window-list.wiki @@ -0,0 +1,14 @@ +[[Property:title|Window list]] +[[Property:weight|1]] +[[Property:uuid|95058f0f-7c1b-841d-03df-dde4494afaf4]] +The window list is the main part of the [[Windows tool|window tool]] . + +[[Image:windows-tool]] + +It displays all opened development windows. Left-clicking a development window in the list raises it so that it becomes the top-level window. Right-clicking one pops up a context menu. + +The four first commands, '''Close''', '''Minimize''', '''Maximize''' and '''Raise''', are relative to the clicked development window. The last command, '''New window''', creates a new development window. + + + + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-reference/browsing-tools/windows-tool/window-menu.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-reference/browsing-tools/windows-tool/window-menu.wiki new file mode 100644 index 00000000..f6035199 --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-reference/browsing-tools/windows-tool/window-menu.wiki @@ -0,0 +1,8 @@ +[[Property:title|Window menu]] +[[Property:weight|2]] +[[Property:uuid|539ef2b0-ed6b-3cfb-5c9f-535fb25a987d]] +The '''window''' menu is divided into two parts. The first one is composed of the [[Window related commands|window-related commands]] . The second one is the list of all opened development windows. Clicking any of these raises the selected development window, so that it becomes the top-level window. + + + + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-reference/browsing-tools/windows-tool/window-related-commands.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-reference/browsing-tools/windows-tool/window-related-commands.wiki new file mode 100644 index 00000000..3cf7b838 --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-reference/browsing-tools/windows-tool/window-related-commands.wiki @@ -0,0 +1,12 @@ +[[Property:title|Window related commands]] +[[Property:weight|3]] +[[Property:uuid|2c8c28d2-7690-dbe2-a264-798d5ad256f7]] +A few commands give the possibility to manage the development windows globally. They are located both in the [[Window menu|Window menu]] and in the main toolbar. +* '''New window''': this command ( [[Image:new-window-icon]] ) creates a new empty development window. Note that it is also possible to [[Pick-and-drop mechanism|drop]] a class or a feature on it to create a development window that is immediately centered on the dropped item. +* '''Minimize all''': this command ( [[Image:windows-minimize-all-icon]] ) iconifies all development windows. +* '''Raise all''': this command ( [[Image:windows-raise-all-icon]] ) raises all minimized development windows. +* '''Raise unsaved windows''': this command raises all the development windows that have not been saved. It may be combined with the '''Minimize all''' command to find easily which development windows need to be saved. + + + + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-reference/compiler/Errors-and-warnings/Legacy-code/VWMA--1-.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-reference/compiler/Errors-and-warnings/Legacy-code/VWMA--1-.wiki new file mode 100644 index 00000000..ac224169 --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-reference/compiler/Errors-and-warnings/Legacy-code/VWMA--1-.wiki @@ -0,0 +1,27 @@ +[[Property:modification_date|Mon, 19 Nov 2018 16:49:36 GMT]] +[[Property:publication_date|Fri, 06 Jul 2018 13:19:54 GMT]] +[[Property:uuid|26E32CD7-7C68-4CDD-A29A-81343EC0DD3B]] +[[Property:weight|0]] +[[Property:title|VWMA(1)]] +[[Property:link_title|VWMA(1)]] +In legacy code, before EiffelStudio [[/doc/uuid/73F20392-AB22-4CD6-BFE5-83296B8BD64B|18.07]], the target of a reattachment could be used to determine the type of a manifest array. For example, with the declaration +```eiffel + x: ARRAY [READABLE_STRING_GENERAL] +``` +the reattachment +```eiffel + x := <<"abc", "def">> +``` +led to creation of an array of type ARRAY [READABLE_STRING_GENERAL] with elements "abc" and "def" of type STRING_8. + +In Eiffel, manifest arrays were the only expressions whose type depended on the type of the target. Starting from EiffelStudio [[/doc/uuid/61F63EE2-58B1-4061-927B-35D4F66EDD9B|18.01]] this is no longer the case, and, by default, the type of a manifest array does not depend on the context where the manifest array is used. + +Taking the rules into account, the type of the manifest array object from the example above is ARRAY [STRING_8]. + +For projects that were developed before EiffelStudio [[/doc/uuid/61F63EE2-58B1-4061-927B-35D4F66EDD9B|18.01]], the compiler checks whether a computed manifest array type is the same as the type of the target of reattachment and reports the warning {{Inline-Warning|VWMA(1)}} to simplify adaptation of legacy code to the new semantics. If the old semantics has to be preserved, an explicit manifest array type has to be used, for example: +```eiffel + x := {ARRAY [READABLE_STRING_GENERAL]} <<"abc", "def">> +``` +The code above would have the behavior identical to the behavior of projects created by the versions before EiffelStudio [[/doc/uuid/61F63EE2-58B1-4061-927B-35D4F66EDD9B|18.01]]. + +After updating all code to follow the standard rules, the project option '''Manifest array type''' can be set to '''standard''' to switch to the standard behavior and to disable comparing types of a manifest array and the target of the attachment. To make sure all occurrences of reattachment of manifest arrays to targets of non-matching types are fixed, the option can also be set to '''mismatch error'''. That would trigger errors instead of warnings for manifest array type mismatches. \ No newline at end of file diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-reference/compiler/Errors-and-warnings/Legacy-code/index.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-reference/compiler/Errors-and-warnings/Legacy-code/index.wiki new file mode 100644 index 00000000..c4c754ec --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-reference/compiler/Errors-and-warnings/Legacy-code/index.wiki @@ -0,0 +1,5 @@ +[[Property:modification_date|Thu, 05 Jul 2018 16:23:57 GMT]] +[[Property:publication_date|Thu, 05 Jul 2018 16:23:57 GMT]] +[[Property:uuid|D7B6372C-C63E-441A-BD5C-4E74387C9561]] +[[Property:weight|0]] +[[Property:title|Legacy code]] diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-reference/compiler/Errors-and-warnings/index.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-reference/compiler/Errors-and-warnings/index.wiki new file mode 100644 index 00000000..914c2171 --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-reference/compiler/Errors-and-warnings/index.wiki @@ -0,0 +1,9 @@ +[[Property:modification_date|Thu, 05 Jul 2018 16:23:17 GMT]] +[[Property:publication_date|Thu, 05 Jul 2018 16:22:54 GMT]] +[[Property:uuid|2C8A219A-D88E-4E7C-8F48-AC3C641C81E7]] +[[Property:weight|50]] +[[Property:title|Errors and warnings]] +[[Property:link_title|Errors, warnings]] +For some error or warning, you will find an English description of the purpose of the error (or warning). + +In addition you may find an example that reproduces the error (or warning) as well as a suggested fix when available. \ No newline at end of file diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-reference/compiler/command-line/Eiffel-compatibility-options.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-reference/compiler/command-line/Eiffel-compatibility-options.wiki new file mode 100644 index 00000000..502c5733 --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-reference/compiler/command-line/Eiffel-compatibility-options.wiki @@ -0,0 +1,168 @@ +[[Property:weight|0]] +[[Property:title|Eiffel compatibility options]] +[[Property:uuid|66673f5d-bc21-563a-b228-e663ea1326f5]] +=Introduction= + +Over the course of several releases, Eiffel Software has introduced a number of options and settings which allow users of EiffelStudio and the Eiffel command line compiler to choose the appropriate level of forward progress and/or backward compatibility for a particular application. + +This is a summary of the motivation behind and the meanings of the various compatibility options. + +=Quick guide to project settings affecting compatibility with older Eiffel code= + +The table below shows project settings that, depending upon their values, can affect the compilation of Eiffel code produced under older standards. That is, certain values for some of these settings may cause older code to fail to compile due to non-compliance. However, other values may allow you to compile non-compliant code during a period in which you convert that code to the current Eiffel implementation. + +{| border="2" style="border-collapse: collapse; border-style: solid;" +|+ +|- +! style="text-align: center; valign: center;" | Setting +! style="text-align: center; valign: center;" | Allowable values +! style="text-align: center; valign: center;" | Meaning +! style="text-align: center; valign: center;" | Default value in version: +|- +| colspan="4" style="background: #E8E8E8" | +|- +| rowspan="5" style="text-align: center" | [[Setting the syntax variant|Syntax]] +|- +| [[Syntax level variant settings by version|Obsolete syntax]] +| Favor obsolete syntax over standard. +| [[Release notes for EiffelStudio 6.3 | 6.3]], [[Release notes for EiffelStudio 6.4 | 6.4]] +|- +| [[Syntax level variant settings by version|Transitional syntax]] +| Favor standard syntax, but allow obsolete syntax when determinable by context. +| [[Release notes for EiffelStudio 6.8 | 6.8]], [[Release notes for EiffelStudio 6.7 | 6.7]], [[Release notes for EiffelStudio 6.6 | 6.6]], [[Release notes for EiffelStudio 6.5 | 6.5]] +|- +| [[Syntax level variant settings by version|Standard syntax]] +| Enforce current standard syntax. +| [[Release notes for EiffelStudio 7.0 | 7.0]] and [[EiffelStudio release notes | more recent]] +|- +| [[Syntax level variant settings by version|Provisional syntax]] +| Like Transitional syntax, but also allow not-yet-approved constructs. +| +|- +| colspan="4" style="background: #E8E8E8" | +|- +| rowspan="3" style="text-align: center" | [[Creating a new void-safe project#Project settings for void-safe projects|Full class checking]] +|- +| True +| Features of parent classes are rechecked for validity in heir classes. +| [[Release notes for EiffelStudio 7.3 | 7.3]] and [[EiffelStudio release notes | more recent]] +|- +| False +| No recheck performed. +| [[Release notes for EiffelStudio 7.2 | 7.2]], [[Release notes for EiffelStudio 7.1 | 7.1]], [[Release notes for EiffelStudio 7.0 | 7.0]], [[Release notes for EiffelStudio 6.8 | 6.8]], [[Release notes for EiffelStudio 6.7 | 6.7]], [[Release notes for EiffelStudio 6.6 | 6.6]], [[Release notes for EiffelStudio 6.5 | 6.5]] +|- +| colspan="4" style="background: #E8E8E8" | +|- +| rowspan="3" style="text-align: center" | [[Creating a new void-safe project#Project settings for void-safe projects|Are types attached by default?]] +|- +| True +| x: T is treated like x: attached T +| [[Release notes for EiffelStudio 7.0 | 7.0]] and [[EiffelStudio release notes | more recent]] +|- +| False +| x: T is treated like x: detachable T +| [[Release notes for EiffelStudio 6.8 | 6.8]], [[Release notes for EiffelStudio 6.7 | 6.7]], [[Release notes for EiffelStudio 6.6 | 6.6]], [[Release notes for EiffelStudio 6.5 | 6.5]] +|- +| colspan="4" style="background: #E8E8E8" | +|- +| rowspan="6" style="text-align: center" | [[Creating a new void-safe project#Project settings for void-safe projects|Void-safety]] +|- +| No +| No checking against any void-safety validity rules. +| [[Release notes for EiffelStudio 7.2 | 7.2]], [[Release notes for EiffelStudio 7.1 | 7.1]], [[Release notes for EiffelStudio 7.0 | 7.0]], [[Release notes for EiffelStudio 6.8 | 6.8]], [[Release notes for EiffelStudio 6.7 | 6.7]], [[Release notes for EiffelStudio 6.6 | 6.6]], [[Release notes for EiffelStudio 6.5 | 6.5]] +|- +| Conformance +| The attachment marks are not ignored for type conformance checks (with respect to VJAR/VBAR and related validity rules). +| +|- +| Initialization +| Validity rules are selectively checked. The initialization rule (VEVI) and the target rule (VUTA) are checked only for attached entities and attached call targets -- i.e., detachable cases are not checked. +| +|- +| Transitional +| Checking against all void-safety validity rules using some potentially unsafe CAPs, assuming that all assertions are satisfied, and ignoring some complex cases like passing incompletely initialized Current from a creation procedure or creating agents when Current is not completely initialized. +| [[Release notes for EiffelStudio 13.11 | 13.11]], [[Release notes for EiffelStudio 7.3 | 7.3]] +|- +| Complete +| Complete checking against all void-safety validity rules ignoring any unsafe CAPs. +| [[Release notes for EiffelStudio 14.05 | 14.05]] and [[EiffelStudio release notes | more recent]] +|} + + +=Discussion of compatibility issues= + +==Eiffel Software and the wheels of progress== + +The Eiffel analysis, design, and programming language has remained relatively static since its original specification in the mid-1980's. However, periodically it has become necessary to make certain changes in order to make certain language improvements and to enable new facilities. It is the policy of Eiffel Software, when such changes are made, to ensure that the changes have minimum impact upon existing software. For some changes, that means no impact at all, but for others it means that the new Eiffel is incompatible with the old Eiffel (the so-called "breaking changes" … those changes that break existing code). And that means that existing software will have to be changed to take advantage of the recent changes to Eiffel. Even so, Eiffel Software has been able to ease the transition from old to new by implementing certain compatibility options which allow existing software still to run as in previous versions during periods of transition. + +==Sources of changes== + +The Eiffel programming language is standardized under the [http://www.iso.org/iso/catalogue_detail.htm?csnumber=42924 ISO] and [http://www.ecma-international.org/publications/standards/Ecma-367.htm ECMA] standardization organizations. So, it is not surprising that many of the changes that are implemented by Eiffel Software are driven by the work of the Eiffel standardization committee. + +Still, the standard itself is a moving target, and there are always differences between what is in the current standard and what has been implemented by Eiffel Software. Also, only immediately after publication of the standard might there be complete agreement between the standard document itself and the perception of Eiffel by the standard committee. That is to say that a new version of the standard may be published once every few years, but the process of moving the language forward continues in the committee in the meantime. + +The diagram below attempts to characterize the relationship among the various factors that define Eiffel. + + +[[Image:Eiffel implementation venn diagram]] + + +It is easy to see the overlapping areas. The centermost represents that part of Eiffel that is at once implemented by Eiffel Software, exists in the current published version of the standard, and is anticipated to remain in the standard for the next version. + +The other areas represent Eiffel features that are supported by only one or a combination of two of these factors. + + +==Types of changes== + +There are many different types of changes that can effect existing code. Here are some examples of these. + +# '''Changes to the Eiffel library classes''' +## Removal or obsoleting of classes or features. Example: {SPECIAL}.make is removed as void-unsafe. +## Changing conformance. Example: ARRAYED_LIST no longer conforms to ARRAY. +## Changing feature types. Example: {ARRAYED_LIST}.count and {ARRAYED_LIST}.area were changed from attributes to functions. +# '''Language keyword changes''' +## A word that was once a keyword is no longer a keyword (potentially allowing the word to be used as an identifier, and affecting software using it as a keyword). Example: indexing is no longer a keyword. +## A word that was not a language keyword in previous versions, becomes one in the current version (potentially breaking any code that used that word as an identifier). Example: attached +## A keyword (or notation) used in a particular context is retired from that context in favor of a more appropriate keyword. (potentially affecting all software using the old keyword in that context). Example: indexing is retired in favor of note. +## The usage of an existing keyword in a new context (usually has no effect on existing software). Example: as used in attached syntax for object test (in addition to its traditional role in the rename part of the inherit clause.) +# '''Language construct changes''' +## Addition of new constructs or extensions to existing constructs. Example: [[ET: Instructions#Loop|iteration form]] of the loop construct. +## Changes to existing constructs. Example: Object test syntax change: attached {T} expr as u versus {u: T} expr +## Removal of obsolete constructs. + +==Types of compatibility options== + +===EiffelStudio and Eiffel compiler options=== + +These "mode" options are selected when EiffelStudio is started up or when the command line Eiffel compiler is invoked. The following two mode options were introduced in version 6.3 on the eve of implementing [[Void-safe programming in Eiffel|void-safety]] as an integral feature of Eiffel. The mode options were intended to help developers deal with the [[Void-safe changes to Eiffel libraries|changes to the Eiffel libraries for void-safety]]. + +* '''-compat''' runs EiffelStudio or the Eiffel compiler in "compatibility mode" so that compilation will use libraries that are compatible with older versions of Eiffel. +* '''-experiment''' runs EiffelStudio or the Eiffel compiler in "experimental mode" so that compilation will use libraries based on an upcoming version of Eiffel. + +Implicit here is that there is also a "default" mode which is invoked when neither of compatibility nor experimental mode is used. Default mode assumes a "current" set of libraries. + +Also, implied by these modes is a progression of their meanings over time. That is, as time passes and language changes are reflected in Eiffel Software's products, the "experimental" mode of today will likely be the "default" mode of tomorrow. And the "default" mode of today may become the "compatible" mode of tomorrow. + +===Project settings=== + +These options are set in the EiffelStudio Project Settings dialog box. + +The most important of these is the '''[[Setting the syntax variant|Syntax]]''' level variant setting. You can choose among a set of syntax level variants that let you control how the compiler views certain language changes. So, for example, if you are compiling classes that contain obsolete keywords, you would set the '''Syntax''' setting to the '''Obsolete syntax''' variant. + +Bear in mind that the detail meanings of the various syntax variants may change from version to version. So, it's a good idea periodically to check the [[Syntax level variant settings by version|syntax level variant settings by version]]. + +==Compatibility tools== + +===The syntax updater=== + +The syntax updater is located in the EiffelStudio "tools" folder. It is a command line utility that will update certain syntax elements from obsolete syntax to current syntax. The syntax updater was introduced with EiffelStudio version 6.4. + +The tool makes the following updates to existing code: +# Replaces obsolete "!!" syntax with create keyword syntax. +# Replaces obsolete keyword creation with create. +# Removes obsolete keyword is after routine signatures. +# Replaces obsolete keyword is in constants with "=" (e. g., "i: INTEGER is 5" becomes i: INTEGER = 5"). +# Replaces obsolete keyword indexing with note. +# Replaces the June 2006 Standard object test syntax (e. g., "{x: T} exp") with the committee-approved provisional standard syntax (e. g., "attached {T} exp as x"). +# Replaces obsolete non-object feature call syntax with current syntax (e. g., "feature {X}.f" becomes "{X}.f"). +# Replaces attached and detachable type markers from June 2006 Standard with committee-approved provisional standard syntax (e. g., "x: !T" becomes "x: attached T" and "x: ?T" becomes "x: detachable T"). diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-reference/compiler/command-line/batch-compilation.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-reference/compiler/command-line/batch-compilation.wiki new file mode 100644 index 00000000..5c335277 --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-reference/compiler/command-line/batch-compilation.wiki @@ -0,0 +1,47 @@ +[[Property:title|Batch compilation]] +[[Property:weight|2]] +[[Property:uuid|18958db6-dafc-57b7-cdef-aca01bc13661]] +In order to launch a compilation without user intervention you need to specify the `-batch` switch in the '''ec''' command line, otherwise the Eiffel compilation will be blocked. We will present below a typical example of batch processing on both Unix and Windows platforms where we want to compile a project in both frozen and finalized mode, then to launch the C compilations. At the same time we want to save the output of '''ec''' and the C compilations. + +===Unix=== +In a file called `launch_ec` you can have the following: + +#!/bin/sh +output_file="/output_path/OUTPUT" + +cd /your_project_path + +#Launch Eiffel compilation +ec -batch -config config.ecf -finalize -c_compile 2> $output_file + +#Since only C compilation for finalized code is done +#Launch C compilation for frozen code + +cd EIFGENs/target_name/W_code +finish_freezing > $output_file + + +It will go the directory where your project is located and compile your Eiffel code using the `config.ecf` file located in your project directory and compile automatically the C code. All outputs will be stored in the file `/output_path/OUTPUT`. + +{{note|All output from '''ec''' are going to the error output, so do not forget to redirect the error output when you want to see the result. }} + +===Windows=== +In a file called `launched_ec.bat` you can have the following: + +rem Launch Eiffel compilation +ec -batch -config config.ecf -finalize -c_compile > c:\output_path\OUTPUT + +rem Since only C compilation for finalized code is done +rem Launch C compilation for frozen code +cd EIFGENs\target_name\W_code +finish_freezing > c:\output_path\OUTPUT + + +It will go the directory where your project is located and compile your Eiffel code using the `config.ecf` file located in your project directory and compile automatically the C code. All outputs will be stored in the file `c:\output_path/OUTPUT`. + +{{seealso|
+[[EiffelStudio: Using command line options|Using command line compiler options]] }} + + + + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-reference/compiler/command-line/command-line-interactive-mode/class-menu.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-reference/compiler/command-line/command-line-interactive-mode/class-menu.wiki new file mode 100644 index 00000000..1d9f1e40 --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-reference/compiler/command-line/command-line-interactive-mode/class-menu.wiki @@ -0,0 +1,72 @@ +[[Property:title|Class menu]] +[[Property:weight|2]] +[[Property:uuid|441d6cbb-2c48-5d44-8cb1-0884ade26b98]] +The Class command (c or C) in the main menu will only work if the system has been successfully compiled, and will give you information based on the result of the last successful compilation. It produces the following menu: + + (A) Ancestors : show the ancestors of a class. + (B) Attributes : show the attributes of a class. + (C) Clients : show the clients of a class. + (E) Deferred : show the deferred features of a class. + (D) Descendants : show the descendants of a class. + (V) Edit : edit the text of a class. + (P) Exported : show the exported features of a class. + (X) Externals : show the external features of a class. + (F) Flat : show the flat form of a class. + (I) Flatshort : show the flat-short form of a class. + (O) Once : show the once & constant features of a class. + (R) Routines : show the routines of a class. + (S) Short : show the short form of a class. + (U) Suppliers : show the suppliers of a class. + (T) Text : show the text of a class. + + (H) Help : show list of commands. + (M) Main : go back to main menu. + (Q) Quit : terminate session. + (Y) Yank : yank (save) output of last command to a file. + + +Each command will prompt you for the name of a class and a filter to use; you can also include the class name and the filter name after the command, separated by a space, as in: + +Command => a linked_list ascii +to obtain the ancestors of the LINKED_LIST class: + + -- Automatic generation produced by ISE Eiffel -- +LINKED_LIST [G] + DYNAMIC_LIST [G] + LIST [G] + CHAIN [G] + CURSOR_STRUCTURE [G] + ACTIVE [G] + BAG [G] + COLLECTION [G] + CONTAINER [G] + ANY + INDEXABLE [G, H -> INTEGER] + TABLE [G, H] + BAG [G]... + SEQUENCE [G] + ACTIVE [G]... + BILINEAR [G] + LINEAR [G] + TRAVERSABLE [G] + CONTAINER [G]... + LINEAR [G]... + FINITE [G] + BOX [G] + CONTAINER [G]... + SEQUENCE [G]... + DYNAMIC_CHAIN [G] + CHAIN [G]... + UNBOUNDED [G] + FINITE [G]... + DYNAMIC_CHAIN [G]... + + -- Generated by ISE Eiffel -- + -- For more details: http://www.eiffel.com -- + +Command => + + + + + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-reference/compiler/command-line/command-line-interactive-mode/compile-and-run-menu.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-reference/compiler/command-line/command-line-interactive-mode/compile-and-run-menu.wiki new file mode 100644 index 00000000..a09dd87e --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-reference/compiler/command-line/command-line-interactive-mode/compile-and-run-menu.wiki @@ -0,0 +1,29 @@ +[[Property:title|Compile (and run) menu]] +[[Property:weight|1]] +[[Property:uuid|58af783e-7fc4-9fa3-2374-4143204948bb]] +The Compile command (i or I) in the main menu yields the following item menu: + + (A) Arguments : set the arguments. + (C) F-compile : (re)compile the C code generated by finalize. + (Z) Finalize : finalize the system (discard assertions by default). + (F) Freeze : freeze the system. + (L) Melt : melt the system. + (K) Quick melt : quick melt the system. + (R) Run : execute the system. + (W) W-compile : (re)compile the C code generated by freeze. + + (H) Help : show list of commands. + (M) Main : go back to main menu. + (Q) Quit : terminate session. + (Y) Yank : yank (save) output of last command to a file. + + +The most common compiling option is L (Melt): recompile the system, melting recent changes. The other compilation possibilities are F (Freeze) and Z (Finalize). After a Freeze you will need to C-compile the result using the W (W-compile) command; similarly, you can C-compile the result of a Finalize using C (F-compile). + +{{caution|You cannot select a different project from within ec loop; also, you cannot select a different configuration file from within the command, although you may of course change the contents of the configuration file (for example by using an editor in an other window). }} + +The R option (Run) runs the application. You will be prompted for the arguments if the application needs any. + + + + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-reference/compiler/command-line/command-line-interactive-mode/documentation-menu.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-reference/compiler/command-line/command-line-interactive-mode/documentation-menu.wiki new file mode 100644 index 00000000..323ac9a7 --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-reference/compiler/command-line/command-line-interactive-mode/documentation-menu.wiki @@ -0,0 +1,21 @@ +[[Property:title|Documentation menu]] +[[Property:weight|7]] +[[Property:uuid|4ed93bc4-07eb-57ed-b339-4890b5f58fcc]] +The Documentation Menu enables you to generate documentation about the classes of your system: + + (I) Documentation (Flat/Short): Generate flat/short form of all classes in system. + (S) Documentation (Short): Generate short form of all classes in system. + (F) Documentation (Flat): Generate flat form of all classes in system. + (T) Documentation (Text): Generate text form of all classes in system. + + (H) Help : show list of commands. + (M) Main : go back to main menu. + (Q) Quit : terminate session. + (Y) Yank : yank (save) output of last command to a file. + + +The four documentation commands will trigger the creation of documentation files corresponding to requested information using the specified filter. These files will then be located in the Documentation subdirectory of your project directory. + + + + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-reference/compiler/command-line/command-line-interactive-mode/feature-menu.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-reference/compiler/command-line/command-line-interactive-mode/feature-menu.wiki new file mode 100644 index 00000000..5d0befda --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-reference/compiler/command-line/command-line-interactive-mode/feature-menu.wiki @@ -0,0 +1,45 @@ +[[Property:title|Feature menu]] +[[Property:weight|3]] +[[Property:uuid|a662251b-777d-5e28-0e52-ba4932195528]] +The Feature Menu enables you to find properties of a feature: + + (A) Ancestors : show the ancestor versions of a feature. + (C) Callers : show the callers of a feature. + (D) Descendants : show the descendant versions of a feature. + (F) Flat : show the flat form of a feature. + (O) Homonyms : shown the homonyms of a feature. + (I) Implementers : show the classes implementing a feature. + (T) Text : show the text of a feature. + + (H) Help : show list of commands. + (M) Main : go back to main menu. + (Q) Quit : terminate session. + (Y) Yank : yank (save) output of last command to a file. + + +Each command will prompt you for the name of a class, the name of a feature in that class and a filter name; you can specify these names (or just the class name) after the command. +{| border="1" +|- +|
'''Command'''
+|
'''Description'''
+|- +| Ancestors +| All the versions of a feature that appeared in ancestors. +|- +| Callers +| The list of classes which contains calls to the feature. Modifiers: +* All senders - include all callers rather than only those in the specified class +* Only assigners - restrict callers to those that use given feature only as a target of an assignment instruction +* Only creators - restrict callers to those that use given feature only as a target of a creation instruction + +|- +| Descendants +| All the versions of a feature that appeared in descendants. +|- +| Implementers +| The list of classes where the feature is redeclared. +|} + + + + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-reference/compiler/command-line/command-line-interactive-mode/index.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-reference/compiler/command-line/command-line-interactive-mode/index.wiki new file mode 100644 index 00000000..a0192afb --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-reference/compiler/command-line/command-line-interactive-mode/index.wiki @@ -0,0 +1,25 @@ +[[Property:title|Command line interactive mode]] +[[Property:weight|3]] +[[Property:uuid|3a0acea6-c6d1-c7b9-c2f9-88021cad26b6]] +If you need to use '''ec''' to execute a number of successive operations on a system, you do not need to restart the command each time; instead you may use the '''-loop''' option, which will interactively prompt you for successive operations. +If you launch '''ec''' with this option, you will get the interactive version's Main Menu: + +==== ISE EiffelStudio - Interactive Batch Version (v5.5.0926 Enterprise Edition) === + (C) Class : class formats and information. + (I) Compile : compile or run the system. + (F) Feature : feature formats and information. + (S) System : Config and cluster details. + (T) Testing : manage and run tests. + (P) Profile : information about a profiled run. + (D) Documentation: create documents from the system. + + (H) Help : show list of commands. + (Q) Quit : terminate session. + (Y) Yank : yank (save) output of last command to a file. +Command => +
+The revision number in the first line may be different in your case to indicate that you have a more recent delivery. In this menu, and in all subsequent ones, the commands appear in two groups. +* commands in the first group are specific to each menu +* commands in the second group H (Help) to repeat the list of choices, Y (Yank) to save the output of the last command to a file that you will be prompted to name, and Q (Quit) to quit appear in all menus, and will be complemented in the Item Menus below by the M (Main) command which returns to the main menu. +By typing one of the letters shown in the Main Menu's first group, you can go to one of the Item Menus: [[Class menu|Class]], [[Compile (and run) menu|Compile]], [[Feature menu|Feature]], [[System menu|System]], [[Profile menu|Profile]], and [[Documentation menu|Documentation]]. [[Compile (and run) menu|Compile]] enables you to compile a system and execute the result; the next three enable you to obtain information about your project. [[Profile menu|Profile]] will enable you to exploit profiling information. Finally, [[Documentation menu|Documentation]] will enable you to generate HTML documentation about your project. + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-reference/compiler/command-line/command-line-interactive-mode/profile-menu.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-reference/compiler/command-line/command-line-interactive-mode/profile-menu.wiki new file mode 100644 index 00000000..eae353ea --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-reference/compiler/command-line/command-line-interactive-mode/profile-menu.wiki @@ -0,0 +1,167 @@ +[[Property:title|Profile menu]] +[[Property:weight|6]] +[[Property:uuid|09c424b0-8ba1-626c-0658-32e5d5e1f81b]] +An execution of an instrumented system will generate a file that contains profiling information. This file (named profinfo) is located in the same directory as your compiled system. You must process it through a profile converter to produce the Execution Profile. +The profile menu will enable you to produce the Execution profile and to extract information from it. + +The menu (obtained by selecting (P) Profile in the main menu) looks like this: + + (S) Switches : show the output switches + #Call-E Name-E Total-D + Self-D Desc-D %Time-D. + (U) Query : manipulate subqueries. + (I) Input : specify input file (filename or last_output) + [*.pfi]. + (L) Language : specify language (eiffel, c, cycles) + [eiffel]. + (R) Run : run the query. + (G) Generate : generate profile information for latest run. + (E) Defaults : reset all values to their defaults. + + (H) Help : show list of commands. + (M) Main : go back to main menu. + (Q) Quit : terminate session. + (Y) Yank : yank (save) output of last command to a file. + +==Switches submenu== +The (S) Switches submenu enables you to set global options. It leads you to the following set of choices: + + (N) Calls : disable output of number of calls to a feature [enabled]. + (F) Feature name : disable output of feature names [enabled]. + (T) Total : enable output of time spent in both the function and its descendants [disabled]. + (S) Self : enable output of time spent in a function itself [disabled]. + (D) Descendants : enable output of time spent in descendants of a function [disabled]. + (P) Percentage : enable output of percentage of time spent in a feature [disabled]. + + (H) Help : show list of commands. + (M) Main : go back to main menu. + (U) Parent menu : go back to parent menu. + (Q) Quit : terminate session. + (Y) Yank : yank (save) output of last command to a file. + +Each one of these commands switches on or off the corresponding column output. The default is set on for the first two, off for the others. To enable or disable a column, type the name with a toggle effect. + +==Query submenu== +The (U) Query submenu enables you to define a set of queries. The result will be a Total Query; by default it is the boolean and all the queries you have entered individually, but you may deactivate some of these and choose other boolean operators. + + (A) Add : add a sub query. + (I) Inactivate : inactivate sub query. + (R) Reactivate : reactivate sub query. + (C) Operator : change the boolean operator. + (S) Show : show the list of queries. + + (H) Help : show list of commands. + (M) Main : go back to main menu. + (U) Parent menu : go back to parent menu. + (Q) Quit : terminate session. + (Y) Yank : yank (save) output of last command to a file. + +To get useful information, you should add the appropriate queries through (A) Add. Each individual query has the following form: ''attribute operator value'', where ''attribute'' is one of: +* feature name +* calls +* total +* self +* descendants +* percentage +''operator'' is one of: +* < +* > +* <= +* >= +* = +* /= +* in
+and ''value'' is one of: +* An integer (for calls) +* A string (for feature name). The string may contain wild card characters: ?, standing for arbitrary characters, and *,standing for arbitrary substrings. +* A real value (for other attributes) +* An interval, of the form a-b for two values a and b. +* max +* min +* avg +The (S) Show command will display the current queries, each with an associated number. The output includes the total query, explained next. +To inactivate a query, use (I) Inactivate. You will be prompted for a query index, which you may retrieve from (S) Show. This is useful if you make a change about a query, or want to set it aside for future use. + +To reactivate a query, use (R) Reactivate. Again you will have to provide a query index. + +The Total Query resulting from a succession of (A) Add commands, possibly with some (I) Inactivate and (R) Reactivate commands, is a boolean query resulting by default from adding all the currently active queries. For example after the following set of commands(note that commands output help lines, which have been skipped here): + +Command => a +--> Subquery: featurename = put* + +Command => a +--> Subquery: calls = 3 + -- Here we change our mind and deactivate the second query + -- to replace it by calls = 3: + +Command => s +[1] featurename = put* is active +[2] calls = 3 is active + +The total active query: +featurename = put* and +calls > + +Command => i +--> Subquery index: 2 + +Command => a +--> Subquery: calls > 5 +
+The (S) Show command will show the following result: + +Command => s +All subqueries: +[1] featurename = put* is active +[2] calls = 3 is inactive +[3] calls > 5 is active + +The total active query: +featurename = put* and +calls > 5 + +To change the boolean operator to 'or' rather than 'and', use the (C) Operator command. It will prompt you for the index of the operator and the new value: + +Command => c +--> Operator index followed by operator ('and' or 'or'): 1 or + +Command => s +All subqueries: +[1] featurename = put* is active +[2] calls = 3 is inactive +[3] calls > 5 is active + +The total active query: +featurename = put* or +calls > 5 + +==Input command== +The (I) Input command serves to load Execution Profiles. It is initially set to *.pfi meaning that it will load all files with extension pfi. By calling the command repeatedly with new arguments, you are able to load more Execution Profiles. If you use the command without any argument, and the set of input files contained just one file, then the queries will use the last generated output. This avoids explicitly loading a file. +==Language command== +The (L) Language command enables you to specify the languages to which profiling should be applied. You can specify Eiffel only, C only, or both. If you specify only one language, the query results will not contain any information about routines written in the other language. +The default is Eiffel only. To switch to both Eiffel and C, use + +Command => L eiffel and c + +To return to just Eiffel, simply type L . + +==Run Command== +To run the current total query, use (R) Run. +==Generate command== +To run the profile converter under the command-line interface, use the (G) Generate command. This will generate an Execution Profile, stored in a file with the extension .pfi. +When running the Generate command with no arguments, you will be prompted for the following information: +* Name of file to be converted (default: profinfo). +* Compilation mode: workbench or finalized (default: workbench). +* Name of profiler tool (default: eiffel). + +You can also type in the arguments directly without waiting to be prompted, as in + +Command => g profinfo finalize eiffel + + +{{seealso|
+[[Profiler Wizard|Profiler wizard]] }} + + + + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-reference/compiler/command-line/command-line-interactive-mode/system-menu.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-reference/compiler/command-line/command-line-interactive-mode/system-menu.wiki new file mode 100644 index 00000000..368e9a60 --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-reference/compiler/command-line/command-line-interactive-mode/system-menu.wiki @@ -0,0 +1,24 @@ +[[Property:title|System menu]] +[[Property:weight|4]] +[[Property:uuid|c1450c9b-a5d3-3709-1176-9c5c49def362]] +The System Menu gives general information about the system: + + (A) Config : show the config file. + (L) Classes : show the classes in alphabetic order. + (S) Cluster hierarchy: display the cluster hierarchy of the system. + (C) Clusters : show the system's classes, cluster by cluster. + (V) Edit : edit the config file. + (I) Indexing : show indexing clauses of classes. + (O) Modifications: show classes modified since last compilation. + (T) Statistics : show system statistics. + + (H) Help : show list of commands. + (M) Main : go back to main menu. + (Q) Quit : terminate session. + (Y) Yank : yank (save) output of last command to a file. + +The A (Config) command shows the configuration file; the E (Edit) command enables you to edit the configuration file; the C (Clusters) command is useful to display the entire list of classes, cluster by cluster. + + + + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-reference/compiler/command-line/command-line-interactive-mode/testing-menu.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-reference/compiler/command-line/command-line-interactive-mode/testing-menu.wiki new file mode 100644 index 00000000..6a27a1a4 --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-reference/compiler/command-line/command-line-interactive-mode/testing-menu.wiki @@ -0,0 +1,21 @@ +[[Property:title|Testing menu]] +[[Property:weight|5]] +[[Property:uuid|a6a0cf9d-ac10-4473-80e1-470acd461610]] +The AutoTest Menu gives information about the autotest entries: + + + (L) List view : Display tests in a list. + (T) Tree view : Display tests in a tree structure. + (E) Execute : run tests. + (A) AutoTest : AutoTest. + + (H) Help : show list of commands. + (M) Main : go back to main menu. + (Q) Quit : terminate session. + (Y) Yank : yank (save) output of last command to a file. + + +The L and T displays the test cases in list or tree. + +The E execute the existing test cases. + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-reference/compiler/command-line/eiffelstudio-using-command-line-options.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-reference/compiler/command-line/eiffelstudio-using-command-line-options.wiki new file mode 100644 index 00000000..6acdc484 --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-reference/compiler/command-line/eiffelstudio-using-command-line-options.wiki @@ -0,0 +1,402 @@ +[[Property:title|EiffelStudio: Using command line options]] +[[Property:link_title|Using command line options]] +[[Property:weight|1]] +[[Property:uuid|a6b6a676-8660-ce2d-6f37-03de7f23a78e]] +==Compiling and viewing== + +The Eiffel Compiler line mode command '''ec''' has many options, as you can see from the tables below. It may be helpful to think of any one '''ec''' command as either a command to compile or a command to view software text. + + +==Getting help== + +You can get details of the usage and options of the '''ec''' command by executing the command with the '''-help''' option. + + + ec -help + + +The usage and options display gives you information about which options are valid in a particular command context. Use this display along with the table below to choose the options that meet your needs. + +Usage and options of the command line compiler vary from version to version in order to accommodate new and changed features. Here is an example of the command line help from the latest version of EiffelStudio: + + +ISE EiffelStudio version 14.05.9.5158 GPL Edition - win64 + +Usage: + ec [-help | [-compat | -experiment] | -version | -full + -batch | -clean | -verbose | -use_settings | + -freeze | -finalize [-keep] | -precompile [-finalize [-keep]] | -c_compile | + -loop | -debug | -quick_melt | -melt | -clients [-filter filtername] class | + -suppliers [-filter filtername] class | + -flatshort [-filter filtername] [-all | -all_and_parents | class] | + -flat [-filter filtername] [-all | -all_and_parents | class] | + -short [-filter filtername] [-all | -all_and_parents | class] | + -pretty input_filename [output_filename] | + -filter filtername [-all | class] | + -descendants [-filter filtername] class | + -ancestors [-filter filtername] class | + -aversions [-filter filtername] class feature | + -dversions [-filter filtername] class feature | + -implementers [-filter filtername] class feature | + -callers [-filter filtername] [-show_all] [-assigners | -creators] class feature | + -callees [-filter filtername] [-show_all] [-assignees | -creators] class feature | + [[-config config.ecf] [-target target] | + -ace Ace (obsolete) | -project Project_file_name (obsolete)] | + [class_file.e [-library library_name]] | + -stop | -no_library | + -project_path Project_directory_path | -file File | + -code-analysis [-cadefaults | -caloadprefs pref_file | -caclasses class ...] | + -gc_stats] + +Options: + default (no option): quick melt the system. + + -ace: specify the Ace file (obsolete). + -ancestors: show the ancestors of a class. + -aversions: show the ancestor versions of a feature. + -batch: launch the compilation without user request. + -c_compile: launch C compilation if needed. + -callees: show the callees of a feature. + -callers: show the callers of a feature. + -class_file.e: specify a class file for single file compilation. + -clean: delete existing project if any and perform a fresh compilation. + -clients: show the clients of a class. + -compat: enable pre-attached type compatibility. + -config: specify the configuration (ECF) file. + -debug: debug the system as a command loop. + -descendants: show the descendants of a class. + -dversions: show the descendant versions of a feature. + -experiment: enable experimental functionalities. + -file: save the output to a file. + -filter: show a filtered form (troff, ...) of the class text. + -finalize: finalize the system (discard assertions by default). + -flat: show the flat form of a class. + -flatshort: show the flat-short form of a class. + -freeze: freeze the system. + -full: with full class checking regardless of ECF settings. + -gc_stats: Show GC statistics. + -gui: start the graphical environment. + -help: show this help message. + -implementers: show the classes implementing a feature. + -library: specify a library for single file compilation. + -loop: run ec as a command loop. + -melt: melt the system. + -no_library: do not convert clusters into libraries. + -overwrite_old_project: overwrite any existing old project. + -precompile: precompile the system. + -pretty: show the pretty form of a class. + -project: specify the project file to load (obsolete). + -project_path: specify the compilation directory. + -quick_melt: quick melt the system. + -short: show the short form of a class. + -stop: stop on error. + -suppliers: show the suppliers of a class. + -target: specify the target. + -use_settings: use settings for project location. + -version: show compiler version number. + + + +==Commands for compiling== + +The simplest compiling command you can enter is: + + + ec + + +The command does not include any of the ''Compiling options'' shown below, so the default option "-melt" is used. The "-config" is omitted, so '''ec''' will try to find a configuration file named Ace.ecf in the current directory. + +The command: + + + ec -config my_config_file.ecf + + +melts the system having the configuration file in the current directory my_config_file.ecf . + +To freeze or finalize that system, you would just include the appropriate ''Compiling option'': + + + ec -freeze -config my_config_file.ecf + + +You can specify the name of a file which contains the root class of a system in the current directory: + + + ec application.e + + +This command will compile a system with the class in application.e as its root. If there is no configuration file named application.ecf in the current directory, then '''ec''' will create one. It will also use any classes in the current working directory and by default the library EiffelBase. + + +{{tip|This "configuration-less" form of compilation is convenient to use for a quick compile. But you should understand that because it does create a configuration file with default names for the configuration file itself, the project, and the root cluster, using it against a root class file in a folder in which a configuration file with another name already exists could lead to confusion. }} + + +You can add additional libraries to the configuration by using the "-library" option and specifying either the short name of one of the EiffelStudio libraries or a path to a library configuration file. To include EiffelTime in the compilation of application.e, you could use this command: + + + ec application.e -library time + + +This immediately adds the EiffelTime library to the configuration file application.ecf, so if you compile again, it is not necessary to respecify the library. + + +==Commands for viewing== + +By selecting certain options on the '''ec''' command, you can generate advanced views of your software much like those provided by EiffelStudio. In the table below you will see the set of ''Viewing options''. These options take arguments that are either a class name or a class name and feature name. The following examples will give you an idea of how to use the ''Viewing options''. + +To see the "flat" form of class APPLICATION in the example used above: + + + ec -flat application -config application.ecf + + +To save the output, add the "-file" option with a file name: + + + ec -flat application -config application.ecf -file application_flat_form.txt + + +Feature-oriented options, like "-implementers", take a class name and feature name: + + + ec -implementers application some_feature -config application.ecf + + + +===Commands for generating documentation=== + +You can use variations of the viewing commands to generate documentation for your Eiffel system much like [[Producing and Exporting Documentation|you can from EiffelStudio]]. + +The following command will produce the ''Chart'', ''Relations'', and ''Text'' documentation for the "application" system in html-stylesheet format in the "Documentation" subfolder of the project folder. + + + ec -filter html-stylesheet -all -config application.ecf + + +To produce documentation for a view other than ''Text'', use its option in the command. The following generates ''Chart'', ''Relations'', and ''Flat Short'' documentation: + + + ec -flatshort -filter html-stylesheet -all -config application.ecf + + +==Commands for Eiffel Inspector== +To start the Eiffel Inspector you need to pass the '''-code-analysis''' command line options. If no other options are given, it will analyze the whole system. To specify some preferences, enable specific rules or analyze part of a system, you will need to provide some more options described below: + + + ec -config project.ecf -code-analysis [-cadefaults | -caloadprefs pref_file | -caclasses "CLASS1 CLASS2" | + -caforcerules "RULE1 (First preference=1, Second preference=2) RULE2"] + + +; -cadefaults : If provided, all preferences regarding the analysis will be reset to their default values (before the analysis is run). For example this leads to enabling all rules that are enabled by default, no matter whether they have been disabled before. + +; -caloadprefs : Use preferences from ''pref_file'', an XML file containing the code analysis preferences. ''pref_file'' can be generated by exporting the current preferences in the GUI. + +; -caclass : Followed by a list of class names (without file extension ''.e'') of the classes that shall be analyzed. If omitted then the whole system will be analyzed. If more than one class is to be specified, the list must be wrapped in double quotes. The class names can optionally be separated by semicolons ("CLASS1; CLASS2"). + +; -caforcerules: Followed by a list of rules, enables those rules for the analysis and disables all the others, overriding the current preferences. Specific rule preferences can also be provided in parentheses. Preferences must be separated by commas. The class names can optionally be separated by semicolons. The following example summarizes the syntax of this option: + + + -caforcerules "RULE1; RULE2 (Maximum length threshold=20, Enable something=False); RULE3" + + +==Command options== + +The table below lists the available ''options'', the arguments they require, and their effect: + + +{| border="1" +|- +| width="175pt" | '''OPTION''' +| '''ARGUMENTS''' +| '''EFFECT''' +|- +| ''Compiling options'' +|- +| -melt +| +| [[Melting Ice Technology#Melting|Melt]] compilation. This is the default option, if no other compiling or viewing option is specified. +|- +| -freeze +| +| [[Melting Ice Technology#Freezing|Freeze]] system. +|- +| -finalize +| +| [[Melting Ice Technology#Finalizing|Finalize]] system. See note below. +|- +| -precompile +| +| [[Melting Ice Technology#Precompiling|Precompile]] system, treating it as a library. +|- +| -full +| +| Full class checking. Rechecks features of the parent classes for validity in heirs. See example in [[Converting existing software to void-safety#Enable full class checking|Converting existing software to void-safety]]. NOTE: Full class checking increases compile times, which may be noticeable in large systems. +|- +| -compat +| +| Compile using facilities that are [[Eiffel compatibility options#EiffelStudio and Eiffel compiler options|compatible with older versions]] of Eiffel. +|- +| -experiment +| +| Compile using facilities that are [[Eiffel compatibility options#EiffelStudio and Eiffel compiler options|compatible with an upcoming version]] of Eiffel. +|- +| ''Viewing options'' +|- +| -ancestors +| class_name +| Print the ancestors of the class. +|- +| -aversions +| class_name, feature_name +| Print the ancestor versions of the feature. +|- +| -callers +| class_name, feature_name +| Print all the routines that call the feature. +|- +| -clients +| class_name +| Print the clients of the class +|- +| -descendants +| class_name +| Print the descendants of the class. +|- +| -dversions +| class_name, feature_name +| Print all the versions of the feature in the descendant versions of the class. +|- +| -flat +| class_name +| Print the flat view of the class. +|- +| -flatshort +| class_name +| Print the Flat Contract view (previously called flat-short form) of the class. +|- +| -implementers +| class_name, feature_name +| Print all the classes that declare or redeclare the feature. +|- +| -short +| class_name +| Print the Contract view (previously called short form) of the class. +|- +| -suppliers +| class_name +| Print all the suppliers of the class. +|- +| ''Other options'' +|- +| -batch +| +| Launch the compilation without user request. +|- +| -clean +| +| Delete project if already compiled and compile project as if it was the first time. +|- +| -config +| file_name +| Use the file as configuration. +|- +| -c_compile +| +| Launch C compilation, if needed, after Eiffel compilation. +|- +| -file +| file_name +| Save the output to the file. +|- +| -filter +| filter_file_name +| Print text as processed by the [[Appendix: Writing Documentation Filters with EFF, the Eiffel Filter Format|filter]] defined in the file named "''filter_file_name''.fil" +|- +| -help +| +| Print the help. +|- +| -keep +| +| Keep assertions in final mode. Useful with -finalize only. +|- +| -library +| library_name +| Library is included in the configuration when a file name for the root class is given. +|- +| -loop +| +| Enter interactive mode. See: [[Command line interactive mode]]. +|- +| -metadata_cache_path +| directory_name +| Specify location of Metadata Cache used for .NET compilation. This overrides any settings from your configuration file. +|- +| -no_library +| +| When converting an old configuration file format, do not convert clusters into libraries. +|- +| -project_path +| directory_name +| Use this directory as compilation directory. (Default: current directory.) +|- +| -stop +| +| Stop on errors. (Default: no.) +|- +| -target +| target_name +| Act on the system target named ''target_name''. +|- +| -use_settings +| +| Use the project global settings to retrieve the project location for the last compilation of this project. +|- +| -verbose +| +| Display detail progress report during compile. +|- +| -version +| +| Print compiler version number. +|} + + +{{note|In the third column, to '''print''' means to produce the requested information on the default output of the '''ec''' command.}} + + +{{note|When using '''-finalize''', assertions will be discarded (unlike in EiffelStudio which asks first). The assertion disposition specified in the project configuration file can be retained in finalization by combining the '''-keep''' option with '''-finalize'''.}} + + +Some options can have modifiers that can affect their results. The modifiers are listed in the table below: +{| border="1" +|- +|
'''Option'''
+|
'''Modifier'''
+|
'''Effect'''
+|- +| -callers +! colspan="2" | +|- +| +| -show_all +| Include all callers rather than only those in the specified class. +|- +| +| -assigners +| Restrict callers to those that use given feature only as a target of an assignment instruction. +|- +| +| -creators +| Restrict callers to those that use given feature only as a target of a creation instruction. +|} + + +{{seealso|
+[[Batch compilation|Batch compilation]] }} + + + + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-reference/compiler/command-line/finish-freezing-utility.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-reference/compiler/command-line/finish-freezing-utility.wiki new file mode 100644 index 00000000..444b5200 --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-reference/compiler/command-line/finish-freezing-utility.wiki @@ -0,0 +1,64 @@ +[[Property:title|finish_freezing utility]] +[[Property:weight|4]] +[[Property:uuid|bfc362f4-9187-ea47-baf6-46880ed43fdd]] +=Introduction= + +The command line utility finish_freezing is used to compile external code generated by the Eiffel compiler. Most of the time finish_freezing gets executed behind the scenes as you freeze and finalize Eiffel systems, so you don't really need to be aware of it. However, finish_freezing can be run standalone, and is useful, for example, when [[Porting an Eiffel application from UNIX to Windows or vice-versa|porting systems to other platforms]]. + +=Usage of finish_freezing= + + +finish_freezing [-location ] [-generate_only] [-nproc ] [-low] +[-x86] [-library] [-version] [-nologo] + + +Options: +:Options should be prefixed with: '-' or '/' + +{| border="1" +|- +! style="text-align: center" | Option +! style="text-align: center" | Arguments +! style="text-align: center" | Effect +|- +|- +| -location +| ''directory'' +| Alternative location to compile C code in. +|- +| -generate_only +| +| Informs tool to generate only a Makefile. +|- +| -nproc +| ''n'' +| Maximum number of processors to use. +|- +| -low +| +| Executes finish freezing in low-execution priority mode. +|- +| -x86 +| +| Generate 32bit lib DLLs for .NET projects. +|- +| -library +| +| Compiles the C code of an Eiffel library. +|- +| -? +| +| Display usage information. +|- +| -version +| +| Displays version information. +|- +| -nologo +| +| Supresses copyright information. +|} + + + + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-reference/compiler/command-line/index.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-reference/compiler/command-line/index.wiki new file mode 100644 index 00000000..7c800c69 --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-reference/compiler/command-line/index.wiki @@ -0,0 +1,11 @@ +[[Property:title|Command line]] +[[Property:weight|-13]] +[[Property:uuid|e1a93995-38bf-14fa-421e-e6fe1f07b9f6]] +==Using the command line compiler== + +It is possible to compile from outside of the graphical environment, by using the command '''ec'''. The form of compilation's results are the same in both cases. You may therefore alternate between the two techniques. '''ec''' will enable you to [[EiffelStudio: Using command line options|melt or freeze]] a project and therefore to use [[Batch compilation|batch compilation]] . It will also enable you to produce [[EiffelStudio: Using command line options|information about a class]] such as its Flat and Flat Contract views. + +The [[EiffelStudio: Using command line options|-loop option]] makes it possible to start '''ec''' just once and then repeatedly request any of the available operations. + + + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-reference/compiler/compiler-history/Major-changes-between-ISE-Eiffel-15.01-and-ISE-Eiffel-15.08.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-reference/compiler/compiler-history/Major-changes-between-ISE-Eiffel-15.01-and-ISE-Eiffel-15.08.wiki new file mode 100644 index 00000000..a44f23f3 --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-reference/compiler/compiler-history/Major-changes-between-ISE-Eiffel-15.01-and-ISE-Eiffel-15.08.wiki @@ -0,0 +1,40 @@ +[[Property:uuid|C86C3894-2FBC-443E-8E19-FD4A442642CA]] +[[Property:weight|6]] +[[Property:title|Major changes between ISE Eiffel 15.01 and ISE Eiffel 15.08]] +[[Property:link_title|15.08]] +==What's new== +* Supported a new inline separate instruction that allows making feature calls on uncontrolled separate targets inline rather than calling dedicated routines: + + separate + some_expression_of_separate_type as x, + other_expression_of_separate_type as y + do + x.foo + y.bar + end + +* Supported creation of passive regions in SCOOP that execute all logged calls on caller's processors: + + create foo.make -- Creation instruction. + bar := create {separate BAZ}.make -- Creation expression. + +A side effect is that all calls on passive regions are synchronous. + +==Improvements== +* runtime: Improved memory management by performing O(log N) lookups when looking for a large block of memory instead of O(N). This would occur after allocating many large objects whose size is greater than 512 bytes (on 32-bit platform) and 1024 bytes on 64-bit platform and then freeing all those objects. Next time you look for a large object it might have to go through all those large objects without finding one that is large enough. +* code generation: Made code slightly more compact (2 to 6% size reduction on some platform). +* Optimized `expr and False` and `expr and then False` to just False if `expr` is a local, a argument, Result, Current, an attribute access or if it is the `and` boolean op. + +==Changes== + +==Bug fixes== + +===Compiler issues=== +* Fixed eweasel test#final122 and bug#19028 where we would incorrectly optimize `expr and False` or `expr and then False` into just `expr` which is wrong if `expr` is True (as the whole expression would be True and not False). + +===SCOOP issues=== +* The SCOOP runtime is now fully written in C to avoid portability issues. +* Corrected access to tuple fields in SCOOP mode that now follow the validity rules and the semantics of ordinary attributes of a class. +* test#scoop034 - Fixed a code generation bug in finalized mode for a generic derivation with an actual generic of a basic type. +* test#term216 - Fixed a crash when processing conversion queries defined as constant attributes. +* Changed agent creation rules for separate targets. This change makes it possible to introduce library features that help users to avoid writing small little wrapper features in SCOOP to control an object. It is now possible to create agents on separate, uncontrolled target. The newly created agent object is placed on the same processor as the target, and it inherits the 'is_controlled' status. diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-reference/compiler/compiler-history/Major-changes-between-ISE-Eiffel-15.08-and-ISE-Eiffel-15.12.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-reference/compiler/compiler-history/Major-changes-between-ISE-Eiffel-15.08-and-ISE-Eiffel-15.12.wiki new file mode 100644 index 00000000..021e315d --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-reference/compiler/compiler-history/Major-changes-between-ISE-Eiffel-15.08-and-ISE-Eiffel-15.12.wiki @@ -0,0 +1,27 @@ +[[Property:uuid|A4F3EBA0-0E2B-4CF4-86A9-4757F7401A63]] +[[Property:weight|5]] +[[Property:title|Major changes between ISE Eiffel 15.08 and ISE Eiffel 15.12]] +[[Property:link_title|15.12]] +==What's new== +* Agents have a new type declaration. Instead of PROCEDURE [X, TUPLE [Y]], one can now write PROCEDURE [Y] where the first generic actual parameter is not considered anymore and the TUPLE declaration omitted. The compiler accepts both syntaxes but only one at a time based on the project's ECF (in other words, you cannot mix both syntaxes within the same project). Meaning that an Eiffel project can use libraries with mismatched syntaxes. The choice of the accepted syntax is based on the version associated to the project's ECF. The new version generated by EiffelStudio will use the new syntax, while existing ECFs will use the old syntax. To upgrade your projects to use the new syntax, use the '''syntax_updater''' tool and using the '''-a''' argument. + +==Improvements== +* Introduced options to select the number of types being generated in each C directory via the general.cfg located in $ISE_EIFFEL/studio/eifinit. The first option is workbench_c_basket_limit for workbench code (defaulting at 33) and the other is finalized_c_basket_limit (defaulting at 50). +* Fixed incrementality performance issues on large system. Instead of taking a few minutes at the end of degree 3 before jumping to degree 2, it will now take about 10 to 15 seconds. + +==Changes== + +==Bug fixes== + +===Compiler issues=== +* Fixed bug#19120 (test#tuple019) by reporting the tuple field name that violated VUAR(2) for the corresponding assigner command. +* Fixed test#attach049 by checking target type of boolean operators when computing scopes of variables. +* Fixed test#attach114 by checking that parenthesis may be used as parenthesis alias calls. +* Fixed test#anchor012. +* Fixed bug#17907 (test#incr417), bug#17913 (test#incr418), (in assertion-enabled mode) bug#17942 (test#incr419), test#incr432 by making sure any changes after an error fix are taken into account. +* Fixed test#attach115 by recording a qualified call as soon as there is an iteration form of a loop. +* Fixed improper type of like argument in generics (test#exec364). + +===SCOOP issues=== +* Fixed test#scoop074 by propagating the controlled status of an object test expression to an object test local to avoid unnecessary wrapping for this local. +* Fixed test#scoop075 by allocating a separate call data structure register before message processing and by freeing it at the end of a call so that the register does not get incorrectly reused. \ No newline at end of file diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-reference/compiler/compiler-history/Major-changes-between-ISE-Eiffel-15.12-and-ISE-Eiffel-16.05.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-reference/compiler/compiler-history/Major-changes-between-ISE-Eiffel-15.12-and-ISE-Eiffel-16.05.wiki new file mode 100644 index 00000000..cf8afa01 --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-reference/compiler/compiler-history/Major-changes-between-ISE-Eiffel-15.12-and-ISE-Eiffel-16.05.wiki @@ -0,0 +1,116 @@ +[[Property:uuid|54814BE5-3591-46C0-B883-42F1FC265873]] +[[Property:weight|0]] +[[Property:title|Major changes between ISE Eiffel 15.12 and ISE Eiffel 16.05]] +[[Property:link_title|16.05]] +==What's new== +* Change the default behavior of attachment of local entities and Result. They are treated as if they were detachable. We instead apply the rules of void-safety to check that all usages are properly typed. In the case of Result, it has to be attached at the end of the routine. + +This is achieved as follows: +# If a local (or Result) is a target of an assignment, it's type is considered detachable. +# If a local (or Result) of a type that required initialization (this includes attached and formal generic types, possibly through anchors) is not set, it's value is considered detachable. +# If a local (or Result) is considered attached due to an assignment or a CAP, it is also considered set (even though it might have never been assigned). +# If a local (or Result) is assigned a value that requires initialization (i.e. of an attached or formal generic type), it is considered set, but may be detachable. +# If a local (or Result) is assigned a value of a detachable type that does not require initialization, it is considered unset and detachable. +# A target of an assignment attempt may not be of an attached type or a type that requires initialization. +# At routine end Result is required to be set if it is of a type that requires initialization. + +The change allows dropping explicit detachable marks in local declarations and simplifying the code that uses Result, e.g. + + foo: X + local + r: detachable X + do + r := something + if not attached r then + r := something_else_attached + end + Result := r + end + + foo: X + do + if attached something as r then + Result := r + else + Result := something_else_attached + end + end + + +into + + foo: X + do + Result := something + if not attached Result then + Result := something_else_attached + end + end + + +The change does not allow previously void-unsafe code to be treated as void-safe, but may affect errors reported by the compiler, in particular: +# VEVI errors may be now reported as VUTA(2) when a local of an attached type is used as a target of call before it is attached. +# VEVI errors may be now reported as VJAR (or the counterpart for argument passing) when a local of an attached type is used as a source expression before it is attached. + + +==Improvements== +* Improve reporting for errors in regular expressions used in include and exclude file rules in ECF by adding position information and providing error description all the time. + +* Improve performance of code using across iterator. {{Inline-Warning|Breaking change:}} custom descendants of READABLE_INDEXABLE may need to be updated in one of the following ways: +*# By removing index_set, if no backward compatibility with earlier versions of EiffelStudio is required +*# By adding an explicit redeclaration clause for index_set, if backward compatibility with [[Release notes for EiffelStudio 15.12|EiffelStudio 15.12]] is required: + + inherit + READABLE_INDEXABLE + redefine + index_set + end + +*:The specific changes in the compiler and cursor classes include: +** Optimized code generation for iteration instruction calls to after and forth by rechecking the code with the actual type of a cursor variable. +** Added lower and upper to READABLE_INDEXABLE to be used instead of index_set by iteration cursor. +** Marked {READABLE_INDEXABLE}.index_set as obsolete in favor of lower and upper to avoid object creation, especially when implementing external cursors for iterative forms of a loop. +** Provided implementation of index_set in READABLE_INDEXABLE so that it can be removed in descendants. +** Made lower_defined and upper_defined in INTEGER_INTERVAL always True because this was the case for all created objects and clients almost never checked if boundaries were defined. +** Provided specialized versions of iteration cursors for SPECIAL, ARRAY, ARRAYED_LIST, READABLE_STRING_8, READABLE_STRING_32 to improve performance of across loops for these containers. + + +==Changes== +* Change code analysis command-line arguments to report errors immediately instead of trying to run code analysis and improve error reporting by providing more details (such as option name, rule name, kind of syntax error). +* Add support of position-independent code analysis options (still retaining old code analysis options) that act like regular EiffelStudio command-line options: +** -ca_default +** -ca_setting ''preference_file_name'' +** -ca_class ( -all | ''class_name'' ) +** -ca_rule ''rule_name_with_optional_setting'' + +* Add a more efficient way to perform access on void target in non-void-safe mode by making the check only once for side-effect free entities. +* Avoid checks for voidness for object test locals because they are always attached. + +==Bug fixes== +* Fix crash during documentation generation via the Generate documentation dialog when the project contains library that are not actually part of the system because they are conditionnaly included (see bug#19173) +* Fix code analysis issue by resetting the internal data between checks (see eweasel test#codeanalysis019) +* Fix .NET code generation failure causing a stack overflow. +* Fix spurious compilation error when involving conversions between attached and detachable types. +* Fix invalid type checking error when using a manifest array in an across loop when some special crafted code appears before (see eweasel test#valid288) as in: + + + failure + local + i: INTEGER + do + -- Comment out next line to fix the bug. + bar (Void).make_from_array (Void) + across + <<1, 2, 3>> as c_i + loop + i := c_i.item -- Error here. + end + end + + +* Fix .NET code generation to generate verifiable code when converting a manifest integer constant compatible with a NATURAL_64 (see eweasel test#dotnet118) +* Fix invalid .NET code generation when you inherit from a .NET class where one of the following routines is frozen: Equals, Finalize, ToString and/or GetHashCode (see eweasel test#dotnet119) +* Fix invalid inlining of routine involving an object test local, an iteration cursor or a separate instruction local (see bug#18028, test#final114, test#final123, test#bench019). +* Fix test#scoop077 by applying SCOOP semantics rules and checking SCOOP validity rules for iteration cursors. +* Fix an issue when extracting a type ID from a string involving the separate keyword. + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-reference/compiler/compiler-history/Major-changes-with-ISE-Eiffel-18.07.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-reference/compiler/compiler-history/Major-changes-with-ISE-Eiffel-18.07.wiki new file mode 100644 index 00000000..818479ae --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-reference/compiler/compiler-history/Major-changes-with-ISE-Eiffel-18.07.wiki @@ -0,0 +1,6 @@ +[[Property:modification_date|Wed, 04 Jul 2018 09:15:02 GMT]] +[[Property:publication_date|Wed, 04 Jul 2018 09:13:19 GMT]] +[[Property:uuid|C7E5CC3E-D942-4970-A6C3-CCF560F84E1F]] +[[Property:weight|-1]] +[[Property:title|Major changes with ISE Eiffel 18.01 and 18.07]] +[[Property:link_title|18.07]] diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-reference/compiler/compiler-history/eiffelstudio-5-compiler-history/index.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-reference/compiler/compiler-history/eiffelstudio-5-compiler-history/index.wiki new file mode 100644 index 00000000..a6402f47 --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-reference/compiler/compiler-history/eiffelstudio-5-compiler-history/index.wiki @@ -0,0 +1,6 @@ +[[Property:title|EiffelStudio 5 compiler history]] +[[Property:link_title|5.x]] +[[Property:weight|15]] +[[Property:uuid|6fc4449c-889f-521d-4f80-69245fbd5f54]] + + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-reference/compiler/compiler-history/eiffelstudio-5-compiler-history/major-changes-between-ise-eiffel-45-and-ise-eiffel-50/assertions-checking-configuration-changes.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-reference/compiler/compiler-history/eiffelstudio-5-compiler-history/major-changes-between-ise-eiffel-45-and-ise-eiffel-50/assertions-checking-configuration-changes.wiki new file mode 100644 index 00000000..f017905f --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-reference/compiler/compiler-history/eiffelstudio-5-compiler-history/major-changes-between-ise-eiffel-45-and-ise-eiffel-50/assertions-checking-configuration-changes.wiki @@ -0,0 +1,24 @@ +[[Property:title|Assertions checking configuration changes]] +[[Property:weight|0]] +[[Property:uuid|45e5cc54-cc3d-9f21-b73f-462430ae845e]] +One of the major differences between 4.5 and 5.0 is how to specify the assertion checking in the ace file or in the project settings window. In 4.5, assertions of a certain type where checked if their level was below the requested level. Here is what the level hierarchy looked like: +# require +# ensure +# loop +# check +# invariant +# all + +Meaning that you could not just check one type of assertions. With 5.0 this is now possible and we changed the presentation to follow the cost to evaluate a given type of assertions, the first one being the less expensive: +# check +# require +# ensure +# loop +# invariant +# all + +The default assertion level has changed too. Not specifying any assertion level used to be equivalent to selecting the 'require' level. This is not the case any more in 5.0 it will be not checking assertions. + + + + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-reference/compiler/compiler-history/eiffelstudio-5-compiler-history/major-changes-between-ise-eiffel-45-and-ise-eiffel-50/compiler-differences-45-50.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-reference/compiler/compiler-history/eiffelstudio-5-compiler-history/major-changes-between-ise-eiffel-45-and-ise-eiffel-50/compiler-differences-45-50.wiki new file mode 100644 index 00000000..69313839 --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-reference/compiler/compiler-history/eiffelstudio-5-compiler-history/major-changes-between-ise-eiffel-45-and-ise-eiffel-50/compiler-differences-45-50.wiki @@ -0,0 +1,32 @@ +[[Property:title|Compiler differences from 4.5 to 5.0]] +[[Property:weight|1]] +[[Property:uuid|0937ae2f-0959-ca89-e851-2c8ccbf4f3aa]] +==What's new== +* Implementation of new external syntax. +* Implementation of verbatim strings. +* Implementation of agents. +* Implementation of agent creations on `Result` and `Current` object. +* Improved incrementality of the C compilation: fewer directories will have their C files changed after a freeze. +* New MSIL generation. +* Introduction of 4 new basic classes: INTEGER_8, INTEGER_16, INTEGER_64, WIDE_CHARACTER. +* Changed the storable mechanism so that we do not store POINTER objects with their value, instead we store a NULL value. As a consequence it is safe to store on disk objects that have references to C objects. Upon retrieval those references will be equal to `default_pointer`. This is now the default behavior, if someone wants to have the previous behavior, simply call `set_keep_pointer_value` from STORABLE. + +==Improvements== +* New run-time speed improvement (between 30 to 100% faster than the 4.5 release). +* Compiler that is much faster (between 200 and 300% faster than 4.5). +* Compiler now detects unused local variables (at freeze/finalize time only) + +==Bug fixes== +* Compiler now fixes incrementality issues with frozen/melted code. +* Degree 4/Degree 3 crash on *_SERVER when doing an incremental recompilation has been fixed. +* Fixed crash when using creation expression that includes a feature call. +* Fixed creation of an ARRAY of BIT type. +* CHARACTER has been extended to support the extended ASCII which means that the following expressions are now True instead of being False as it was in our previous version: +** '%/127/' < '%/128/' +** '%/127/' < '%/128/' +** When using `independent_store`, in case of retrieval error due to a name change in one of the class attributes we will display the original attribute name that was used to make the storable file. This will help when managing many storable files. + + + + + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-reference/compiler/compiler-history/eiffelstudio-5-compiler-history/major-changes-between-ise-eiffel-45-and-ise-eiffel-50/eiffelthread-differences-45-50.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-reference/compiler/compiler-history/eiffelstudio-5-compiler-history/major-changes-between-ise-eiffel-45-and-ise-eiffel-50/eiffelthread-differences-45-50.wiki new file mode 100644 index 00000000..3eb8ac5e --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-reference/compiler/compiler-history/eiffelstudio-5-compiler-history/major-changes-between-ise-eiffel-45-and-ise-eiffel-50/eiffelthread-differences-45-50.wiki @@ -0,0 +1,17 @@ +[[Property:title|EiffelThread differences from 4.5 to 5.0]] +[[Property:weight|0]] +[[Property:uuid|f95360f9-3b02-5f1b-9667-68846d0e0a7d]] +Users of EiffelThread in 4.5 will notice a few changes that we made to make their life easier. + +==Object sharing== + +Indeed one aspect of EiffelThread in 4.5 that was not easy to implement was object sharing between threads. Most of the difficulty came from our special implementation of the Eiffel Software GC (Garbage Collector) where each thread had its own GC. +A consequence was that an object in thread A referencing an object in thread B needed to let the GC of B that it had a reference to an object that belongs to him. This was done by using the PROXY class and instead of referencing the object directly you were referencing the PROXY object. Another limitation of this approach was that the referred object could not hold reference to other objects, it could only hold values of basic expanded types (also previously called flat objects) +Now, there is a global GC and therefore you do not need to use the PROXY class anymore and you can reference any kind of objects. The PROXY class is still available for backward compatibility, but it is now obsolete and its implementation has been reduced to a bare minimum. +The class OBJECT_CONTROL has been removed altogether and the class OBJECT_OWNER is now obsolete as well. + +==Global onces== + +In 4.5, you would have to use a special tricky way to create once per process feature by using an existing once per thread feature and an external C feature that we were providing to achieve a once per process behavior. +In 5.0, this has been simplified and you can now specify at the level of the source code if it will be a once per process or once per thread. Click [[Once features in multithreaded mode|here]] for more details on how this is done. + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-reference/compiler/compiler-history/eiffelstudio-5-compiler-history/major-changes-between-ise-eiffel-45-and-ise-eiffel-50/index.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-reference/compiler/compiler-history/eiffelstudio-5-compiler-history/major-changes-between-ise-eiffel-45-and-ise-eiffel-50/index.wiki new file mode 100644 index 00000000..5a03291e --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-reference/compiler/compiler-history/eiffelstudio-5-compiler-history/major-changes-between-ise-eiffel-45-and-ise-eiffel-50/index.wiki @@ -0,0 +1,11 @@ +[[Property:title|Major changes between ISE Eiffel 4.5 and ISE Eiffel 5.0]] +[[Property:link_title|5.0]] +[[Property:weight|-7]] +[[Property:uuid|82179716-24e3-0aa1-7562-bf0a87c05749]] +* [[Assertions checking configuration changes|Assertions checking]] +* [[EiffelThread differences from 4.5 to 5.0|EiffelThread]] +* [[Compiler differences from 4.5 to 5.0|Miscellaneous]] + + + + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-reference/compiler/compiler-history/eiffelstudio-5-compiler-history/major-changes-between-ise-eiffel-50-and-ise-eiffel-51.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-reference/compiler/compiler-history/eiffelstudio-5-compiler-history/major-changes-between-ise-eiffel-50-and-ise-eiffel-51.wiki new file mode 100644 index 00000000..75797435 --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-reference/compiler/compiler-history/eiffelstudio-5-compiler-history/major-changes-between-ise-eiffel-50-and-ise-eiffel-51.wiki @@ -0,0 +1,62 @@ +[[Property:title|Major changes between ISE Eiffel 5.0 and ISE Eiffel 5.1]] +[[Property:link_title|5.1]] +[[Property:weight|-8]] +[[Property:uuid|bdb0c46b-2774-f348-f8e8-9932cda47722]] +==What's new== + + +* .NET generation now includes: +** Support for multiple inheritance. +** Support for generics. +** Partial implementation of generic conformance (same as what was supported up to and including ISE Eiffel 4.2). +** Support for tuples and agents. +** Support for any existing Eiffel code that does not use C externals. +** Partial support for compiling Eiffel libraries using C externals (e.g. WEL) + +And the following limitations: +** Eiffel classes cannot inherit from non-Eiffel .NET classes (but they can be clients). +** The compiler performances are rather poor now (both in terms of memory usage and speed) + +Those limitations should disappear with 5.2 which will be the official release that fully supports .NET +** Support for INTEGER_64 constants. Now a manifest integer value that is written in decimal or hexadecimal format that can't fit into an INTEGER_32 will be automatically promoted to an INTEGER_64 constant value. +** New feature access syntax for accessing constants, C/C++ externals and IL static externals. [[Differences between ETL 2nd printing and Eiffel Software implementation|Check out more here]] . + + +==Improvements== +* Compiler that is about 20% faster than 5.0. + +==Bug fixes== +* Fixed VAPE errors that were not previously reported. Now VAPE errors are checked against arguments of a feature used in a precondition and are also checked for a qualified call. +* Fixed a conformance bug that made a manifest array not conform to ANY. +* Fixed a generic conformance bug where an assignment attempt would change the behavior of the execution. +* Fixed a wrongly reported error by the compiler in the following case: +In a system that has a generic class CLIENT with constraint `G -> SUPPLIER create make end', where the creation procedure of SUPPLIER is exported to {CLIENT}. If another class has an attribute `x: CLIENT [SUPPLIER]' the compiler reports a VTCG error, though it should accept the classes. + +* Fixed a crash when one of the following command lines was used in a directory with no existing project that contains no default configuration file: +ec -flat -all +ec -short -all +ec -flatshort -all +ec -flat -all_and_parents +ec -short -all_and_parents +ec -flatshort -all_and_parents + +* Fixed a bug in output display between standard output and error output. Doing the following: +io.put_string ("foo%N") +io.error.put_string ("bar%N") + +you get the following output when simply launched from the command line: +foo +bar + +however if you do: +my_program >& RESULT + +to redirect both standard and error outputs to RESULT you get in the RESULT file this incorrect content: +bar +foo + +* Fixed a non reported VTEC or VTCG error when an invalid type used as actual generic parameters in an explicit type in a creation instruction. + + + + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-reference/compiler/compiler-history/eiffelstudio-5-compiler-history/major-changes-between-ise-eiffel-51-and-ise-eiffel-52.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-reference/compiler/compiler-history/eiffelstudio-5-compiler-history/major-changes-between-ise-eiffel-51-and-ise-eiffel-52.wiki new file mode 100644 index 00000000..bf2fda3a --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-reference/compiler/compiler-history/eiffelstudio-5-compiler-history/major-changes-between-ise-eiffel-51-and-ise-eiffel-52.wiki @@ -0,0 +1,37 @@ +[[Property:title|Major changes between ISE Eiffel 5.1 and ISE Eiffel 5.2]] +[[Property:link_title|5.2]] +[[Property:weight|-9]] +[[Property:uuid|f08242d4-d472-142c-7f92-f2c043bc5fa6]] +==What's new== +* .NET generation now includes support for the following language features: +** Support for multiple inheritance. +** Support for generics. +** Partial implementation of generic conformance +** Support for tuples and agents. +** Support for any existing Eiffel code that does not use C externals. +** Support for compiling Eiffel libraries using C externals that are not related to the Eiffel Software C runtime. + +And the following limitations: +** Eiffel classes cannot inherit from non-Eiffel .NET classes (but they can be clients). +** No support for `expanded` keyword. + + +* .NET generation now supports assembly signing in enterprise edition. +* .NET generation now supports precompiled libraries. +* Supports for manifest integer constants of different sizes, i.e. you can now assign for example the value `8` to a location of type INTEGER_8, INTEGER_16, INTEGER or INTEGER_64, however you can only assign the value `254` to a location of type INTEGER_16, INTEGER or INTEGER_64. + +==Improvements== +* Compiler that is about 20% faster than 5.1. +* Runtime is about 10-20% faster than 5.1 + +==Changes== +* One cannot create an instance of a basic expanded class ( BOOLEAN, CHARACTER, INTEGER_8, INTEGER_16, INTEGER, INTEGER_64, POINTER, REAL, DOUBLE), you will now get a VGCC(6) error. Instead directly assign to it, or create an instance of its corresponding _REF class. + +==Bug fixes== +* Fixed memory corruption issue when trying to access an INTEGER_64 value. +* Fixed a problem with manifest INTEGER_64 constants whose values were incorrectly interpreted. +* Fixed VAPE errors that were not previously reported in 5.1. Now VAPE errors are checked against call to infix and prefix features. + + + + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-reference/compiler/compiler-history/eiffelstudio-5-compiler-history/major-changes-between-ise-eiffel-52-and-ise-eiffel-53.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-reference/compiler/compiler-history/eiffelstudio-5-compiler-history/major-changes-between-ise-eiffel-52-and-ise-eiffel-53.wiki new file mode 100644 index 00000000..af821fa7 --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-reference/compiler/compiler-history/eiffelstudio-5-compiler-history/major-changes-between-ise-eiffel-52-and-ise-eiffel-53.wiki @@ -0,0 +1,165 @@ +[[Property:title|Major changes between ISE Eiffel 5.2 and ISE Eiffel 5.3]] +[[Property:link_title|5.3]] +[[Property:weight|-10]] +[[Property:uuid|c4a7cbf4-da42-791d-cc80-862692233ed9]] +==What's new== +* Finalized executable with option `exception trace' enabled will now display the instruction number (usually equivalent to the line number in the routine) being executed when a failure occurred. It was already displaying this information in workbench/melted mode, we have just extended this feature to finalize mode. +* Incremental compilation is now available for .NET code generation. Meaning that if you modify one class, only this class is being recompiled. It dramatically improves development time when targeting .NET. +* In .NET code generation, assertions can be turned on or off on a class per class basis without having to recompile those classes. +* Implemented [[EiffelBase, The Kernel|recoverable storable]] to enable the retrieval of slightly different version of an object. It only applies for classic Eiffel. + +==Improvements== +* Enabled support for Borland C compiler in .NET. +* Removed too many warnings during C compilation on Tru64. +* Improved formatting of exception traces so that class names, feature names, exception tags are not truncated. Display limit has been pushed at about 256 characters. + +==Changes== +* Made `\\' follow the balancing rules for various integer types. +* Precompiled libraries now precompiles all classes reachable from clusters defined in project settings only if root class is ANY, otherwise it will only precompile classes reachable from the root class. In 5.1 and prior version it was precompiling all classes reachable from clusters. + +==Bug fixes== + +===Language issues=== +* Fixed semantic of object creations to strictly follow definition given in "Eiffel: The Language". Namely, if you have x of type X: +create x.make is equivalent to x := create {X}.make +It implies some bug fixes which might break existing code. For example: + +x: X is + once + -- If make calls back to x then it used to return + -- a non-Void value for x, where it should have been Void. + create Result.make + end + +x: X + + -- If make accesses back the x attribute then it used to return + -- new value of x rather than the old value. +create x.make +Or in melted code only the following code now works properly, i.e. make gets the old value of x, not the new one
+create x.make (x) + +* Fixed undetected VDRD(3) errors: compiler was not strict enough and accepted ensure where only ensure then was valid. + +===Store/Retrieve issues=== +* Fixed issue in storable mechanism when retrieving expanded objects. +* Fixed issue with independent_store where storing arrays of objects whose count was greater than 65536 will cause a memory corruption. +* Added correct_mismatch on HASH_TABLE to enable retrieval of the 5.1 and older version of HASH_TABLE. + +===Runtime/code generation issues=== +* Fixed incorrect C code generation in final mode when creating an ARRAY of expanded type. +* Fixed incorrect C code generation in final mode when creating a complex object which contains expanded objects that have expanded objects. +* Fixed random crash issue in finalized applications due to incorrect memory management when you have code similar to: + f (g: STRING): ANY is + do + Result := create {STRING}.make_from_string (g) + end + +* Fixed issue with deep_equal on ARRAY of expanded types which was returning False where it should have returned True . +* Fixed code generation issue with double constants where code below was not producing the expected result of 1e+030: + value: DOUBLE is 1.0e15 + print (value * value) + +* Fixed issue in melted code where computation such as INTEGER_X // INTEGER_Y will either crash or give an incorrect computation where X and Y represents integers that are either 8, 16, 32 or 64 bits long and X < Y. +* Fixed incorrect C code generation of finalized code when your project configuration includes a precompiled library and that you cancel finalization process at degree -2, and then restart a finalization. +* Fixed issue with incorrect C code generation of inspect instruction based on character values above 128. +* Fixed compilation crash at degree 3 with following code: + local + i: INTEGER + do + i := << 1 >> @ 2 + end + +* Fixed a crash in finalized mode with invariant checking enabled with following code and when checking the invariant triggers a garbage collection cycle:
+ value: INTEGER + is_value_required: BOOLEAN is + do + Result := value = 1 + end + + +* Fixed crash of compiler at degree 4 while trying to compile this incorrect class: +class CRASH + +inherit + CHAIN -- Missing generic parameter + +create + make + +feature -- Initialization + + make is + do + end + + index: INTEGER is + do + end + + duplicate (n: INTEGER): like Current is + do + end + +end + +* Fixed issue with pathological memory allocation scheme that could trigger an `out of memory' exception where enough memory is still available. +* Fixed incorrect allocation of expanded arrays where creation routine of expanded class was not called on all items of the newly created array. +* Fixed incorrect creation type of attribute where attribute's type has some generic parameter. In some cases, instead of creating an ARRAY [B2 [C]] it would create an ARRAY [B2 [STRING]]. + +===.NET issues=== +* Fixed issue in IL code generation where having a class that inherits from a non-Eiffel .NET class. And the class has the following features: + a: ARRAY [like f] + f: STRING is + do + end +Then you could neither load nor execute the generated code. +* Fixed incorrect C file naming when generating a .NET system that uses a C++ external (it should be .cpp, not just .c). +* Fixed incorrect .NET code generation with following assignment attempts whose source is expanded: + local + a: ANY + o: SYSTEM_OBJECT + do + a ?= 12 + o ?= 12 + end + +* Fixed incorrect code generation in .NET for assertions checking with following code where precondition of test will not be checked although it should: + make is + do + test_which_fail_and_rescued + test + end + + test is + require + should_be_checked: False + do + end + + test_which_fail_and_rescued is + local + retried: BOOLEAN + do + if not retried then + failure + end + rescue + retried := true; + retry + end + + failure is + require + should_be_checked: False + do + end + +* Fixed .NET verification issue where sometimes you could get the following message when checking an Eiffel assembly against peverify: [IL]: Error: Unverifiable PE Header/native stub. +* Fixed incorrect code generation when creating and accessing a NATIVE_ARRAY of expanded type. +* Fixed incorrect metadata heap generation to use standard CLI tables. +* Fixed bug where content of NATIVE_ARRAY could not be looked up in .NET debuggers (cordbg, DbgClr or Visual Studio) + + + + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-reference/compiler/compiler-history/eiffelstudio-5-compiler-history/major-changes-between-ise-eiffel-53-and-ise-eiffel-54.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-reference/compiler/compiler-history/eiffelstudio-5-compiler-history/major-changes-between-ise-eiffel-53-and-ise-eiffel-54.wiki new file mode 100644 index 00000000..5ad09450 --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-reference/compiler/compiler-history/eiffelstudio-5-compiler-history/major-changes-between-ise-eiffel-53-and-ise-eiffel-54.wiki @@ -0,0 +1,80 @@ +[[Property:title|Major changes between ISE Eiffel 5.3 and ISE Eiffel 5.4]] +[[Property:link_title|5..4]] +[[Property:weight|-11]] +[[Property:uuid|2fa36c0f-5b6a-f3f8-67a6-6bd73f63732d]] +==What's new== +* Support for assertion checking on external routines. +* Removed limitation about implementing or redefining a non-external routine by an external one and vice versa. +* Support for new C/C++ inline specification. +* For .NET, allow calling of overloaded features for a .NET classes to be called without using disambiguated names. Disambiguated names are still needed when redefining inherited features from .NET classes. +* Support for inclusion of .NET resources within Eiffel assemblies. +* Launch C compilation when needed if "-c_compile" option is specified on the "ec" command line. +* Added ability to define custom attributes on assembly. One as to define custom attributes under the new `assembly_metadata` index clause of the root class. +* Limited support for new convert keyword (only on argument passing and assignments. Not supported when used with infix routines). + +==Improvements== +* Improved speed of compilation by about 20-30% +* Improved run-time memory allocation speed and footprint so that it has a 15%-20% faster allocation scheme and takes less memory than before. +* Reduced waiting time at the end of the degree 6 when performing a compilation from scratch (reduced to about 50% or more of the time it used to take) +* Improved speed of TUPLE creation and TUPLE access which generates more compact C code. +* Improved speed of agent calls by a factor of 2 to 3. +* Improved speed of Eiffel calls from C (CECIL and use of $ operator on routines). It also makes generated executables smaller (about 1-5% smaller depending on number of routines used in this context) + +==Changes== +* Changed the way we generate calls to C/C++ external routines. It is possible that because of this change, code that used to C compile, will not compile anymore. This happens mostly when mixing C and C++ code and the C call being made is incorrect but was not previously checked against the C header files if provided. +* In multithreaded mode, all C externals that could potentially block the execution of the system should be marked `blocking` as in:
+ sleep (m: INTEGER) is + external + "C blocking" + end +Not doing it could generate dead-lock during the execution of a multithreaded system. +* Static access on externals is now only authorized when external is a frozen external without assertions. +* Compiler will now report a warning for assignments like those:
+td: TUPLE [DOUBLE] +ti: TUPLE [INTEGER] + +td := ti +The warning will help you correct code using this pattern, because in the next release this will be rejected in order to conform to the Eiffel programming language specification. +* Now we do not generate by default the .NET attribute ComVisibleAttribute with a False value. If needed it has to be done through the new compiler functionality to add custom attributes on assembly. +* Changed indexing clause tag for specifying custom attributes for .NET systems. Now `attribute` is replaced by `metadata`. Now you can have: +** metadata: generated for both interface and implementation classes +** assembly_metadata: generated for assembly only when specified in root class of system +** class_metadata: generated only for implementation class +** interface_metadata: generated only for interface class + + +==Bug fixes== + +===Language issues=== +* Now checks for valid export status in agent creation. Meaning that in class MY_CLASS, the following agent creation agent target. call is valid if and only if call is exported to MY_CLASS. +* Allowed type specification for open operands in agent creation, i.e. one can now write: agent f ({ A}). +* Fixed bug which allowed compiler to accept the following incorrect code: char: CHARACTER is "rdsf" +* Fixed bug in error reporting for incompatible BIT types involving bit manifest constants. It would always report BIT 0, instead of the actual number of bits in the bit manifest constant. + +===Compiler issues=== +* Fixed non-detection of changes when changing code from agent call to agent Current . call. Which should check for the validity of export of call to current class. +* Fixed creation and assignment attempts on generic types that have anchored types in their generic parameter, and the anchor is itself generic. + +===Runtime/code generation issues=== +* Fixed issue when shared library definition file did not exist or was invalid. Now it will not produce any C compilation errors. +* Fixed bug in recoverable storable when there is a mismatch. The first assignment attempt in internal_correct_mismatch from ANY would crash. +* Fixed issue when retrieving storable files that contain TUPLE instances. +* Fixed issues when using agents in a multithreaded application, they will sometimes disable the garbage collector and the application might quickly run out of memory. +* Fixed random crashes when EIF_MEMORY_CHUNK, EIF_MEMORY_SCAVENGE and EIF_STACK_CHUNK environment variables had an incorrect value. Instead the runtime will now fix the value to an appropriate one. + +===.NET issues=== +* Fixed bug in code generation with following statement:
+l_time: TIME_SPAN +print (l_time.total_milliseconds.out) + +* Fixed incorrect code generation with code accessing attributes of .NET expanded types. +* Fixed incorrect computation of equal when used with basic types, e.g. equal (1, 1) would return False instead of True. + +===Store/Retrieve issues=== +* Fixed memory corruption bug with recoverable storable when a mismatch was detected +* Fixed issue where mismatch was not detected if attributes were dropped +* Fixed issue with independent store when storing TUPLE objects where it would crash if storable did not include a reference to ANY. + + + + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-reference/compiler/compiler-history/eiffelstudio-5-compiler-history/major-changes-between-ise-eiffel-54-and-ise-eiffel-55.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-reference/compiler/compiler-history/eiffelstudio-5-compiler-history/major-changes-between-ise-eiffel-54-and-ise-eiffel-55.wiki new file mode 100644 index 00000000..97781d27 --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-reference/compiler/compiler-history/eiffelstudio-5-compiler-history/major-changes-between-ise-eiffel-54-and-ise-eiffel-55.wiki @@ -0,0 +1,149 @@ +[[Property:title|Major changes between ISE Eiffel 5.4 and ISE Eiffel 5.5]] +[[Property:link_title|5.5]] +[[Property:weight|-12]] +[[Property:uuid|1d8b9ba7-0609-b664-a4cf-16be1132b071]] +==What's new== +* Full support for new convert keyword. +* Made Void, previously a feature of ANY, a keyword. This prevents the renaming of Void into not_void previously possible when it was a routine of ANY. +* Addition of the reference keyword used in generic constraints (See next point). +* Added support for reference and expanded constraints on a formal generic parameter. In other word, one can now write: +class A [reference G] ... end +class B [expanded G] ... end +to say that the valid actual generic parameters for A are always reference types, and for B are always expanded types. +* Added support for Microsoft .NET 2.0 runtime. +* Allowed agent creation on infix or prefix routines. + +==Improvements== +* Reduced, in classic mode, size of finalized executables by 10 to 50%. +* Improved speed of evaluation of global onces, in a multithreaded system, by having a lock-free mechanism after a once has been evaluated. +* Reduced memory usage of special of expanded which do not have any reference attributes. Before there was a 8 bytes (or 16 bytes depending on the platform) overhead per item in the special. + +==Changes== +* Compiler is now checking that you cannot redeclare a formal generic parameter into a reference type unless the formal generic parameter is being constraint to be always a reference type (See the '''What's new''' section above). +* Removed obsolete eifcid, eif_expand and eifexpfrom the CECIL interface, one has to use eif_type_idinstead. +* In .NET, changed the naming conventions of resources included in an assembly. The extension `.resources` is appended for resources that are originally provided as `.resx` or `.txt` files. Other files are embedded as is in the assembly and the name of the resource is the name of the file. +* In .NET, now all classes inherit from ANY. Before all classes inherited from SYSTEM_OBJECT. The consequences are: +** You can write an Eiffel generic classes where the actual generic parameter is a .NET class. +** If you used to inherit from .NET classes and Eiffel classes you can replace the inheritance clause below: +class A +inherit + APPLICATION_EXCEPTION + undefine + finalize, + equals, + to_string, + get_hash_code + end + + ANY +by the much simpler inheritance clause: +class A +inherit + APPLICATION_EXCEPTION + + +** If you were using a feature of SYSTEM_OBJECT directly on Eiffel classes, now you need to assign the value to a variable entity of type SYSTEM_OBJECT. In other word: +e: EIFFEL_CLASS +o: SYSTEM_OBJECT +... +o := e +o.feature_of_system_object + +** The following assignment attempt will succeed whereas it failed before because SYSTEM_OBJECT did not inherit from ANY: +a: ANY +o: SYSTEM_OBJECT +... +check o /= Void and a = Void end +a ?= o +check o /= Void and a /= Void end + + +* New format of the independent storable files which takes into account internal changes made for a better generic conformance in classic mode. +* New validity rule for expanded types: It is valid to use an expanded type of base class C in the text of a class B if and only if it satisfies the following conditions: +** C is not a deferred class +** C's version of the procedure default_create (inherited from ANY) is one of the creation procedures of C available to B for creation. + +* New validity rule for expanded class: An expanded class C needs to have the version of the procedure default_create (inherited from ANY) as one of its creation procedure. + +==Bug fixes== + +===Language issues=== +* Fixed issue about conformance checking of type containing a formal generic parameter. We would always evaluate the formal to its constraint, thus allowing the code below to be accepted where it should not have been: + +class A [G] +feature + bug is + local + l_any: LIST [ANY] + l_g: LIST [G] + do + l_any := l_g + l_g := l_any + end + +The workaround is to use the reference keyword to guarantee that the formal generic parameter will always be instantiated with a reference type. For example the code below is correct: + +class A [reference G] +feature + bug is + local + l_any: LIST [ANY] + l_g: LIST [G] + do + l_any := l_g + l_g ?= l_any + end + + + +===Compiler issues=== +* Enabled creation of SPECIAL instances, no need to create an instance of TO_SPECIALor ARRAY to get a SPECIALinstance. Now you can simply do: +my_special: SPECIAL [INTEGER] +create my_special.make (10) + +* Fixed incrementality issues with strip and static calls on external routines which could fail after a class has been added to or removed from the system. + +===Runtime/code generation issues=== +* Fixed incorrect code generation which would result in a C compiler error in classic mode when assigning a Void entity to a formal generic parameter that will be instantiated as a basic type. +* In multithreaded mode, fixed dead lock on Unix platforms when evaluating global onces. +* In multithreaded mode, prevented dead lock when a thread is exiting. +* In multithreaded mode, prevented memory corruption which could occur if the first thing that a thread performs when launched is to trigger a GC collection. +* Fixed incorrect generic conformance data when manipulating expanded generic types. For example, the following code: +class A [G, H] +feature + item: H +end + +class C [G] +end + +class ROOT_CLASS +create + make +feature + make is + local + l_a: A [STRING, expanded C [ANY]] + do + create l_a + io.put_string (l_a.item.generating_type) + end +end + +would print +expanded C [STRING] +instead of +expanded C [ANY] + +* Fixed issue where you could get a bogus reference when trying to get a reference to the object associated to an ID (obtained through the IDENTIFIED class). + +===.NET issues=== +* Fixed incorrect code generation of native arrays which would cause the code to be rejected in newer version of the .NET Framework. +* Fixed incorrect computation of `max_stack` for a routine body which could make the generated code not verifiable. + +===Store/Retrieve issues=== +* Fix some issues related to the use of recoverable storable when manipulating generic types. + + + + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-reference/compiler/compiler-history/eiffelstudio-5-compiler-history/major-changes-between-ise-eiffel-55-and-ise-eiffel-56.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-reference/compiler/compiler-history/eiffelstudio-5-compiler-history/major-changes-between-ise-eiffel-55-and-ise-eiffel-56.wiki new file mode 100644 index 00000000..27fcfc3c --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-reference/compiler/compiler-history/eiffelstudio-5-compiler-history/major-changes-between-ise-eiffel-55-and-ise-eiffel-56.wiki @@ -0,0 +1,161 @@ +[[Property:title|Major changes between ISE Eiffel 5.5 and ISE Eiffel 5.6]] +[[Property:link_title|5.6]] +[[Property:weight|-13]] +[[Property:uuid|c22fad22-3dce-cf2c-1d24-4e70fc29f3f3]] +==What's new== + +{{seealso|See also: [[Differences between standard ECMA-367 and Eiffel Software implementation|Differences between standard ECMA-367 and Eiffel Software implementation]] }} +* Implemented once manifest strings. They can be used at the same places where normal manifest strings can be used, e.g.: +s := once "abc" +io.put_string (once "Hello World!") +Once manifest strings are not created every time they are accessed. Instead one instance is created at the first access and then it is reused for subsequent accesses. + +==What's new== + +{{seealso|[[Differences between standard ECMA-367 and Eiffel Software implementation|Differences between standard ECMA-367 and Eiffel Software implementation]] }} +* Implemented once manifest strings. They can be used at the same places where normal manifest strings can be used, e.g.: +s := once "abc" +io.put_string (once "Hello World!") +Once manifest strings are not created every time they are accessed. Instead one instance is created at the first access and then it is reused for subsequent accesses. In multithreaded application one instance is created for one thread. +* Supported aligned and non-aligned verbatim strings. Aligned verbatim strings use characters [ and ] in opening and closing sequence respectively, non-aligned verbatim strings use { and }. +* Added support for manifest type expression "{MY_TYPE}" which gives an instance of TYPE [MY_TYPE]. +* New syntax for manifest constants. Now they can be preceeded by a manifest type expression. For example 1 is of type INTEGER, whereas {INTEGER_8} 1 is of type INTEGER_8. +* Support for NATURAL_XX types which are unsigned integers. +* Supported new feature alias syntax to specify operator and bracket names: +negate alias "-": like Current ... +multiply alias "*" (other: like Current): like Current ... +item alias "[]" (index: INTEGER): G ... +The first two declarations can be used similar to features prefix "-" and infix "*". The last one can be used to make feature calls with bracket expressions like +letter := letters [i] +Operator and bracket aliases can also be used in rename subclause to change an alias name associated with a feature. +* Supported new feature assigner syntax to associate feature with an assigner command: +item alias "[]" (index: INTEGER): G assign put ... +put (value: G; index: INTEGER) ... +Given the declaration above the following instructions become equivalent: +x.put (x.item (i + 1), i) +x.item (i) := x.item (i + 1) +x [i] := x [i + 1] + + +==Improvements== +* Optimized .NET code generated for inspect instruction. +* Optimized access to process-relative once routines to avoid heavy-weight synchronization primitives when possible. +* Speed-up access to once routines in finalized multi-threaded applications. +* Improved some error messages to be more precise. +* Removed the requirement to freeze code that declares process-relative once routine. +* Improved multi-threaded application performance in classic mode by using built-in support for thread-local storage provided by some ''C'' compilers. +* Allowed underscores in hexadecimal literals. +* Provided syntax highlighting for hexadecimal literals in editor. +* Slightly improved reporting of syntax errors. +* Made keyword operator names clickable in flat view. + +==Changes== +* Void does not conform to expanded types. As a consequence, assignments of Void to expanded entities will be rejected rather than throwing an exception at run-time. And comparison of expanded entities to Void will cause a VWEQ validity error. +* Changed default behavior of once routines in .NET mode from once-per-process to once-per-thread to match behavior in classic mode. +* Provided project options (old_verbatim_strings and old_verbatim_strings_warning) to support semantics of verbatim strings as in previous versions when they were not left-aligned. +* Changed processing of hexadecimal integer literals to be consistent for different integer types. For example, 0xFF gives 255 when assigned to a variable of type INTEGER rather than -1 as before. +* Due to the new {} syntax, a few older syntax constructs have been removed: +** "{X} Precursor (..)" is rejected and should be replaced by "Precursor {X} (...)". +** "agent f (?, {A})" is now rejected, as it would conflict with a manifest type expression, instead you should write "agent f (?, {A} ?)". + +* In .NET, all usage of INTEGER_8 from .NET libraries have been changed to NATURAL_8. +* In .NET, renamed TYPE, ATTRIBUTE_ and VOID_ from the mscorlib assembly into SYSTEM_TYPE, SYSTEM_ATTRIBUTE and SYSTEM_VOID. +* Changed exception handling for once routines so that exception raised during the first call is raised during any subsequent call to this routine. +* Introduced upper limit for value of integer constant used in BIT type declaration and extended VTBT rule to cover this change. +* To evaluate the type of a manifest array we now use the first item of the manifest array instead of the last one as a first guessed type. +* Allowed for integer literals with intermediate underscores at arbitrary positions. +* To ensure same behavior on various platforms, the standard output is now unbuffered (it previously was unbuffered on Windows and line buffered on Unix platforms). + +==Bug fixes== + +===Language issues=== +* Used '%N' as an end of line in verbatim strings regardless of the end of line sequence in source code. +* Fixed incorrect handling of negative hexadecimal integer literals when sign before the literal was not taken into account. For example, -0x1 could be interpreted as 1. +* Implemented checks for input ranges of integer constants and fixed issue with inability to assign minimum integer values to variables of the corresponding integer types. +{| +|+ Allowed integer values +|- +| Type +| Integer interval +| Unsigned hexadecimal representation +|- +| INTEGER_8 +| -128 .. 127 +| 0x0 .. 0xFF +|- +| INTEGER_16 +| -32768 .. 32767 +| 0x0 .. 0xFFFF +|- +| INTEGER_32 +| -2147483648 .. 2147483647 +| 0x0 .. 0xFFFFFFFF +|- +| INTEGER_64 +| -9223372036854775808 .. 9223372036854775807 +| 0x0 .. 0xFFFFFFFFFFFFFFFF +|} + +* Excluded nonsignificant leading zeroes from determination of allowed integer constant type, so that 00000000000000123 is now a valid INTEGER_8 value. +* Shared the same data accross once routines and string constant attributes from different generic derivations of the same class. Added a warning for once routines that appear in a generic class to notify about this change in semantics. +* Correctly supported replication of once features when compiling for .NET. +* Changed order of evaluation of once routines to check precondition with class invariant even when once routine has already been called. +* Added a check that length of identifier, manifest string and free operator does not exceed a maximum value of 32767 bytes. + +===Compiler issues=== +* Fixed crash of the compiler at the very end of a finalization of a system which has an assignment of a manifest type into a variable of type ARRAY [like anchor] where anchor is a feature being redefined with a different type in a descendant class. +* Fixed an issue where compiler would report more than once the same error in an incremental recompilation. +* Fixed issue where changing a normal routine to an external and having a compile error, and then reverting back to a normal routine while fixing the error would cause the compiler to crash. +* Fixed some cases where project could be corrupted after a recompilation. +* Now compiler reports VTCT errors at the end of degree 5, rather than during degree 5, so that you can collect all the VTCT errors at once. +* Thanks to the improvement in VTCT errors reporting, now compiler will not generate an incorrect VTCT errors during an incremental recompilation for a class which has actually been removed from the system. +* Supported recompilation of once routines when their status is changed from "process-relative" to "thread-relative" or back. +* Supported output of multi-line obsolete messages. +* Fixed a recompilation bug that resulted in incorrect (or even, in case of .NET, in invalid) generated code when incrementally finalizing a system without explicitly specified root creation procedure. +* Fixed a bug with resolving some generic-like types (i.e., types that are processed in a special way: tuple, native array, typed pointer) that depend on anchored types: before they were converted to "normal" generic types thus loosing their special properties. +* Fixed a bug that caused compiler to crash when finalizing a code that looks like +if true then [else(if) ...] end +i.e. has empty compound for a primary condition which is a constant true. +* Fixed a bug in processing configuration option precompiled that caused a compiler to crash when no option value was provided. +* Fixed a bug in incremental recompilation when multi-branch validity rules are violated in one class because constant attribute used in the multi-branch instruction is changed in another class, that declares them, into a non-constant feature. +* Fixed multiple bugs in feature basic text view that caused truncated or extraneous output. +* Fixed bug where if an actual generic parameter was an anchor, then if the type containing this actual was used for assignment attempt or for creation we would use an incorrect type for the actual generic. We were using the type of the anchor in the class were the code was written, instead of actually re-evaluating the type of the anchor for each descendant class. + +===Runtime/code generation issues=== +* Fixed bug in deep_twin from ANY in .NET which would cause a call on Void target when applied on object of type STRING and possibly other types. +* Corrected C code on Windows for constants of type INTEGER_64. Before constants of this type between -2147483648 and -1 could be processed as positive 64-bit values. +* Fixed incorrect C and IL code generation for INTEGER_8 and INTEGER_16 arithmetic and shift operations that might produce incorrect result when combined in two or more operations in a row. For example, +i := (i + i) |>> 1 +assigned -128 to i of type INTEGER_8 if the initial value of i was -128. Now this instruction assigns 0. +* Synchronized access to data of process-relative once routines to avoid race conditions when two or more threads simultaneously access the same once routine. +* Avoided permanent blocking of a thread accessing process-relative once routine when this routine is concurrently evaluated in some other thread and raises an exception. +* Fixed bugs in memory allocation in C code for result of a once function that returns basic type: +** it might cause memory corruption when memory size required to store the result is greater than size of a pointer; +** there was a memory leak. + +* Fixed a bug in classic mode that caused last exception to be cleared after returning from a routine that has a rescue clause but returns normally. +* Fixed several bugs related to handling of nested exceptions in classic mode. +* Changed a limit of maximum class name length in melted byte code from 256 bytes to 32767 bytes. +* Changed C code generation for long strings (that result from long manifest strings, identifiers, etc.) to avoid restrictions imposed by some C compilers on long string literals (in particular, by the Microsoft C compiler cl that issued error C2026). +* Fixed a bug in finalized C code generation when calling Precursor in a routine which is recursively calling itself before the call to Precursor. Instead of generating the call to Precursor we would generate a recursive call to the routine. +* Fixed a bug where calls to standard_is_equal from ANY on objects whose type is generic would yield False where it should have been True. + +===.NET issues=== +* Corrected processing of literal floating point fields from external assemblies (such as System.Math.PI) to obtain proper values. +* Fixed a bug where the value -1 was actually 255 on .NET. +* Fixed issue where declaring a NATIVE_ARRAY of a .NET expanded type would be rejected by the compiler. +* Fixed issue where assigning a .NET expanded type to an entity of type ANY would be rejected by the compiler. +* Fixed a crash in the compiler when generating the code for a class which inherits from a .NET class and from an Eiffel class which has some anchored types. +* Fixed a bug in assertion monitoring that could lead to wrong monitoring of assertions that are evaluated concurrently in different threads. +* Fixed a bug in code generation for entry point of executable when root procedure is a redeclaration of a deferred feature that caused an exception MissingMethodException to be raised on startup of such an application. +* Fixed a bug in code generation when solely inheriting from a .NET interface. +* Fixed a bug in code generation when inheriting from a .NET class which has a routine whose name is identical to one of the routine of ANY. +* Fixed a bug in code generation of custom attributes encoding in the case of a named argument whose base type is a .NET enum type. +* Improved conforms_to from ANY so that even though full generic conformance is still not yet supported, it checks it properly when the base class are the same. + +===Store/Retrieve issues=== +* Fixed an issue where the GC would be disabled after a failure in a retrieval operation. + + + + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-reference/compiler/compiler-history/eiffelstudio-5-compiler-history/major-changes-between-ise-eiffel-56-and-ise-eiffel-57.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-reference/compiler/compiler-history/eiffelstudio-5-compiler-history/major-changes-between-ise-eiffel-56-and-ise-eiffel-57.wiki new file mode 100644 index 00000000..0f903586 --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-reference/compiler/compiler-history/eiffelstudio-5-compiler-history/major-changes-between-ise-eiffel-56-and-ise-eiffel-57.wiki @@ -0,0 +1,68 @@ +[[Property:title|Major changes between ISE Eiffel 5.6 and ISE Eiffel 5.7]] +[[Property:link_title|5.7]] +[[Property:weight|-14]] +[[Property:uuid|fc50f98f-4dfd-0173-23d4-9db219dde0cf]] +==What's new== + +{{seealso|See also: [[Differences between standard ECMA-367 and Eiffel Software implementation|Differences between standard ECMA-367 and Eiffel Software implementation]] }} +* Support for new expanded semantics defined in ECMA-367. The current limitations are: no copy semantics in the .NET code generation, and still no generic conformance. +* Inline agents as defined in ECMA-367 with the limitation to only accept the do form. +* Added possibility to define agents on attributes or externals. +* Named tuples as defined in ECMA-367. +* Added PREDICATE class for agent based on boolean queries. +* Added CHARACTER_32 for Unicode support. + +==Improvements== +* Improved memory management: +** Ensure that if a block of allocated memory is not used it will eventually be freed. Before it will only be freed if it was the last allocated block. +** Compaction is actually working. Before it was working if you had a lot of dead objects, now it will compact even if all you have is alive objects and that the memory is fragmented. +** For large memory heap (i.e. larger than 1GB) improved speed of collections where there is a lot of dead objects. + +* Changed the way we search melted file, it is done in the following order: +** Directory specified by environment parameter MELT_PATH +** Current working directory +** Directory where application is launched +** Original directory where .melted file was generated the first time. + +* Improved speed of initial compilation of .NET projects as well as the speed for incremental compilation at degree 6 which went from a few seconds to no time if no new assemblies have been added to the system. +* No freeze is required when adding an agent, saving you time since C compilation can be long for very large project. +* Reduced the required disk space for a workbench compilation in classic mode (went from 1.8 GB to 1GB for a very large project). +* Improved speed of agent calls in classic mode. +* Support use of IL enumerations with underlying integer types different from System.Int32. In particular, the built-in features `to_integer` and `from_integer` now use the underlying type rather than System.Int32. +* Support generation of IL properties as well as custom attributes for them. +* Support the new syntax without the is keyword in the feature declaration. +* Allowed bracket expressions to be used as a target of a qualified feature call (this is an extension to ECMA standard that does not permit this syntax at the moment). +* Added checks for VYCP(2,3) and VYCQ(2,3) (validity rules for conversion features to prohibit conversion to conforming types). + +==Changes== +* VWEQ is not an error, but a warning that can be triggered or not depending on your configuration. +* Inherited assertions are rechecked each time that a feature is redefined, meaning that some errors that were not previously detected by the compiler can now be found. + +==Bug fixes== +* Fixed an issue with x2c if you had inlined C code which contains comments with single or double quote. Then it will not properly convert .x into .c file. +* Fixed bugs in code generation for once manifest strings that caused "index out of bounds" exception, void results. +* Fixed a bug in processing synonyms of a routine with an indexing clause that might cause a compiler crash, in particular this could happen for synonyms of a global once routine. +* Fixed a bug in recompilation of a once routine that changes its process-relative status into thread-relative one or back in multithreaded finalized mode that can cause C compilation to fail due to unresolved externals. +* Corrected inlining of routines redeclared into attributes or into routines with a different internal/external status. +* Fixed a bug in incremental recompilation of queries with assigner commands. +* Added detection of a VUEX error for static feature calls used in intervals of a multibranch instruction. + +===Compiler issues=== +* Added a new validity error VTEC(3) to report unsupported inheritance hierarchy under .NET when an expanded type is based on a class with an external ancestor. +* Not supported reverse attachment of boxed built-in .NET value types to Eiffel reference types such as NUMERIC, HASHABLE, etc. + +===Runtime/code generation issues=== +* Ensured that our runtime is async-safe for signals for all the runtime routines using some locking mechanisms. +* Fixed a memory corruption issue in arycpy if a GC cycle was triggered as part of the processus of reallocating the SPECIAL object. +* Fixed a bug with allocating memory for once routines that caused "no memory" exception at program startup when Borland run-time is used. + +===.NET issues=== +* Removed limitation to inherit an Eiffel class which inherited from a .NET class. + +===Store/Retrieve issues=== +* Fixed a memory leak in the recoverable retrieval when an exception is raised from a correct_mismatch routine call. +* Fixed test#store008 regarding a crash when retrieving a type that does not exist in retrieved system. + + + + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-reference/compiler/compiler-history/eiffelstudio-6-compiler-history/index.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-reference/compiler/compiler-history/eiffelstudio-6-compiler-history/index.wiki new file mode 100644 index 00000000..5c25de80 --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-reference/compiler/compiler-history/eiffelstudio-6-compiler-history/index.wiki @@ -0,0 +1,6 @@ +[[Property:title|EiffelStudio 6 compiler history]] +[[Property:link_title|6.x]] +[[Property:weight|14]] +[[Property:uuid|62e7ba4a-0db5-1e46-0097-73313657a7ca]] + + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-reference/compiler/compiler-history/eiffelstudio-6-compiler-history/major-changes-between-ise-eiffel-57-and-ise-eiffel-60.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-reference/compiler/compiler-history/eiffelstudio-6-compiler-history/major-changes-between-ise-eiffel-57-and-ise-eiffel-60.wiki new file mode 100644 index 00000000..bdf95c7f --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-reference/compiler/compiler-history/eiffelstudio-6-compiler-history/major-changes-between-ise-eiffel-57-and-ise-eiffel-60.wiki @@ -0,0 +1,72 @@ +[[Property:title|Major changes between ISE Eiffel 5.7 and ISE Eiffel 6.0]] +[[Property:link_title|6.0]] +[[Property:weight|-7]] +[[Property:uuid|83f6c19c-b0da-6acb-0333-a92d445cfe56]] +==What's new== + +{{seealso|See also: [[Differences between standard ECMA-367 and Eiffel Software implementation|Differences between standard ECMA-367 and Eiffel Software implementation]] }} +* Added support for multiple constraints in formal generic parameters. +* The root class can now be a generic class, and thus one can now specify a root type. +* The notion of creation readiness according to ECMA Eiffel standard (2nd edition, chapter 8.12.12) is implemented. +* Added experimental option for full class checking. It can be enabled at the system, cluster or class level. However not all our code has been compiled with this option so don't be surprised if you get errors in our libraries. The next release should fix all the remaining issues. +* Integers can now also be specified with binary and octal representation. +* Manifest characters can now also be specified with binary, octal and hexadecimal representation. Manifest characters can be specified up to 32 Bit. +* Supported reattachment of generic derivations with expanded parameters to generic derivations with reference parameters. + +==Improvements== +* The command line compiler doesn't need a configuration file to compile a system, one can simply provide a root class and the compiler will automatically use the current directory and EiffelBase. You can also add more libraries if needed. +* Improved backup mechanism so that overridden classes are copied in the library where they are defined (they were previously copied in the library where the override cluster was defined). +* Possibility for hidden/implementation clusters in libraries, i.e. clusters that are not accessible if the library is used (like libraries in libraries are not accessible). +* Class names which don't match the source filename emit a warning. +* The unique keyword will yield a syntax warning if enabled. +* Static access on external routines is allowed even if not marked frozen (this simply applies a relaxed rule that was adopted by ECMA). +* When an environment variable is being used to compile a system and if this environment variable value changes next time you use a project, you will get a prompt asking whether or not you want to update the value or keep the initial one. +* Externals (includes, objects, resources, ...) can now be relative to the ecf file by using the new replacement $ECF_CONFIG_PATH. +* UUID is not needed for non library systems. If no UUID is specified a random one will be generated. + +==Changes== +* Added supplier_precondition assertion level that enables to only check preconditions of trusted libraries. By default when importing an old project they are not enabled, thus assertions on the library you are using are most likely going to be disabled. +* Added the platform value as part of the version info of the compiler. This will prevent trying to load a project compiled for a different platform instead of failing with a retrieval error. +* The compiler can be compiled against the original EiffelBase version or with the FreeELKS version which is now the default one for EiffelBase. + +==Bug fixes== +* Fixed eweasel test#tuple006 showing a failure when calling deep_copy on a TUPLE instance. +* Fixed bug#12782 where compiler would crash at degree 1 when removing a formal generic parameter of class (eweasel test#incr249 and test#incr284). +* Fixed bug#12823 where specifying in the command line a target in a different case than the lower case version of the actual target name would fail to find the target in your configuration file. +* Fixed bug#12698 where compiler was not processing the target extension properly if not specified in lower case. +* Fixed bug#12591: compiler would not find classes from library referenced deeply using relative path. This also removes the extra `.` or `..` in the displayed path for a class. +* Fixed issue with incorrect labeled tuples which were not detected in signature of features (see eweasel test#tuple008). +* Fixed crash when checking an incorrect labeled tuple (e.g. TUPLE [a, a: INTEGER]) (see eweasel test#tuple009). +* Fixed issue with inline agents where if you have one and during a compilation from scratch you have a compiler error, then fixing this error and recompiling, it would crash when melting or freezing (test#incr277). +* Fixed issue with C compilation linking error when a generic class which have an invariant clause has its formal generics changed (test#incr278). +* Fixed C compilation error on Windows for trying to compile empties Cxxx directories (test#ccomp061). +* Fixed incorrect code generation of agents on attribute when target is open (test#exec264). +* Fixed incremental bug when an agent creation based on a feature whose signature changes for less arguments (test#incr276). +* Fixed a backup creation bug when two classes from the same cluster/library have the same original file name, the backup would only contain one or the other because we use the original file name. Now we use the original class name. +* Fixed various issues with the processing of the Eiffel Configuration File. + +===Compiler issues=== +* Adapted the compiler so that ISE_EIFFEL does not need to be defined with a short path name on Windows, since some file systems can disable support for short path. +* Fixed incrementality bug with agents where finalizing and then freezing would cause some unresolved externals. + +===Runtime/code generation issues=== +* Fixed a memory corruption which would occur once an invariant has been violated. +* Fixed a memory corruption which could occur when performing a deep_twin on an object whose graph contains a TUPLE object. See test#tuple006. + +===.NET issues=== +* Speed up consumer cache synchronization so working with large .NET caches or large assembly sets is much faster. +* Fixed bug#12565 where a wrong EIFFEL_NAME_ATTRIBUTE custom attribute would be generated on .NET for Eiffel generic class where the actual generic parameter is a .NET value type.. +* Fixed bug in .NET resx to resource generation when using resx files with relative paths. +* .NET Enums can be automatically converted to INTEGERs. +* Indexing tags ''interface_metadata'' and ''class_metadata'' are supported on feature level like this is done on class level and allow to specify custom attributes for associated methods only in interface type or only in implementation type. +* All versioned COM import interfaces now have versioned interface member names based on the trailing version number of the interface name, as this meta information is not available in any other way. This greatly improves the versioned names and makes implementing interfaces much easier. +* Fixed various issues in the .NET consumer that would prevent the usage of certain .NET assemblies. +* Added configurable (project to class-level) optimization for .NET project that will mark all classes frozen if they are not descended by another. + +===Store/Retrieve issues=== +* Now the retrieval of objects is done with the GC (garbage collector) disabled. +* Fixed issue when retrieving 64-bit storables on 32-bit machines. It requires a regeneration of the 64-bit storables if one wants to retrieve them on 32-bit machines. Fixed bug#11744. + + + + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-reference/compiler/compiler-history/eiffelstudio-6-compiler-history/major-changes-between-ise-eiffel-60-and-ise-eiffel-61.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-reference/compiler/compiler-history/eiffelstudio-6-compiler-history/major-changes-between-ise-eiffel-60-and-ise-eiffel-61.wiki new file mode 100644 index 00000000..71a16f66 --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-reference/compiler/compiler-history/eiffelstudio-6-compiler-history/major-changes-between-ise-eiffel-60-and-ise-eiffel-61.wiki @@ -0,0 +1,51 @@ +[[Property:title|Major changes between ISE Eiffel 6.0 and ISE Eiffel 6.1]] +[[Property:link_title|6.1]] +[[Property:weight|-8]] +[[Property:uuid|32beeca8-08df-4918-b231-8a14114fdd62]] +==What's new== + +{{seealso|See also: [[Differences between standard ECMA-367 and Eiffel Software implementation|Differences between standard ECMA-367 and Eiffel Software implementation]] }} +* Multiple errors are reported for each compilation degree. +* Experimental support for Non-conforming Inheritance has been added (Classic only). Classes may now be inherited (using inherit {NONE} but no conformance of that class is implied. +* Attachment marks are supported. Now it's possible to specify whether an entity is attached or detachable: +a: !A -- a cannot be used before it is attached +b: ?A -- b can be used before it is attached +Default attachment status (for types without an attachment mark) is controlled by the option ''is_attached_by_default''. +* Object test expression is a replacement for the reverse assignment construct with a new notion of scope: +if {o: !A} e then do_something_with (o) end + +* Attached variables are subject to the new check that they are properly set before use, in particular, attached attributes must be set by a creation procedure and all attached local variables must be set before they are used. The checks are performed when the option ''is_void_safe'' is turned on. +* A feature call can be performed only on an attached target if the option ''is_void_safe'' is turned on. +* Certified attachment patterns (CAP) are used to identify additional cases when an entity is attached (controlled by the option ''is_void_safe''). In particular, the following code is considered void-safe: +f (a: ?ANY) + do + if a /= void then + x := a.out + end + end + + +==Improvements== +* Improved speed of degree 3. Improvements are even more visible when the checking of inherited features in their descendants is enabled. + +==Changes== +* No major known changes. + +==Bug fixes== +* Fixed an issue where the version of default_create from ANY would not yield a dynamic binding if statically it had an empty body (See test#exec280). + +===Compiler issues=== +* The options ''is_void_safe'' and ''is_attached_by_default'' are not tracked during recompilation, so in order to take any changes in their settings, the project has to be recompiled from scratch. +* Object test is not permitted inside a precondition or a check instruction. +* Object tests inside a feature should use different names for the corresponding locals. + +===Runtime/code generation issues=== +* Non-conforming inheritance dynamic conformance only works with Classic compilations, for .Net non-conforming inheritance has no effect on code generation +* Implemented time accounting on Windows. + +===Store/Retrieve issues=== +* Fixed a potential dead lock when an exception occurs while retrieving an object in a multithreaded environment (See test#store012). + + + + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-reference/compiler/compiler-history/eiffelstudio-6-compiler-history/major-changes-between-ise-eiffel-61-and-ise-eiffel-62.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-reference/compiler/compiler-history/eiffelstudio-6-compiler-history/major-changes-between-ise-eiffel-61-and-ise-eiffel-62.wiki new file mode 100644 index 00000000..083c40be --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-reference/compiler/compiler-history/eiffelstudio-6-compiler-history/major-changes-between-ise-eiffel-61-and-ise-eiffel-62.wiki @@ -0,0 +1,53 @@ +[[Property:title|Major changes between ISE Eiffel 6.1 and ISE Eiffel 6.2]] +[[Property:link_title|6.2]] +[[Property:weight|-9]] +[[Property:uuid|20122f4c-22c6-d0ee-c38b-36908ca86ad2]] +==What's new== + +{{seealso|See also: [[Differences between standard ECMA-367 and Eiffel Software implementation|Differences between standard ECMA-367 and Eiffel Software implementation]] }} +* Exceptions as objects are now implemented. +* Added support for new ~ operator which can compare 2 objects safely regardless of their type. +* Added detection of harmful catcall at runtime (harmless ones are currently ignored). +* Added support for `note` keyword with a migration path in case `note` is being used as an identifier in your code. +* Added `-gc_stats` option to get some information on how much CPU time is spent in GC during an Eiffel compilation. +* Introduced several new much more powerful CAPs that now can be applied not only to read-only entities, but also to local variables (including Result), and can take into account execution paths as well as some obvious void-safe patterns. + +==Improvements== +* Improved speed of compiler by a significant factor for large system. +* Generated code is about 3-4% faster with a size reduction of about 2-3%. +* Improved number of dynamic to static bindings in finalized code. Improved quality of inlined code for reducing even more of the dynamic calls. +* Reduced the size of the AST stored in memory during a compilation by 20/25% which results in a memory usage reduction for EiffelStudio of about 15%. For example when compiling EiffelStudio on Windows 64-bit, it was taking 920MB with the previous version, and now it would be 800MB. +* Fixed performance issue with {SPECIAL}.clear_all when handling a special of reference. +* Removed VUOT(2) that required that the type of an object test local is attached. + +==Changes== +* Protected several calls to `eif_wean` on the same EIF_OBJECT. This will prevent a memory corruption for people using it incorrectly with a minor slow down since in a typical application there should not be too many protected objects. +* Removed VFAV(4) validity error that is no longer specified in the standard. +* Due to new meaning of ~, the old syntax for agents is not being supported anymore. If you still have some code using the old agent syntax, compile it with 6.1 with syntax warning enabled to fix your code before upgrading to 6.2. + +==Bug fixes== + +===Language issues=== +* Fixed various limitations with support of attached types in 6.1, including support for +** attachment marks for tuple types and formal generics +** object tests in class invariants + + +===Compiler issues=== +* Fixed eweasel test#final046 by avoiding useless creation of temporary objects during dynamic dispatch. It can also dramatically speed up certain kinds of code; on the compiler itself, the speed up is about 8-10%. In the worst case scenario it is 400% or more. Note this bug was introduced in version 6.0. Compared to 5.7, in 6.2 the worst case scenario is still about 10% slower. +* Fixed an incorrect code generation for `is_equal` in ANY when exception trace is off which could cause a memory corruption. +* Fixed various issues with compiler when inlining is enabled. +* Fixed compiler crash when compiling a class where a type used in a signature of a feature has the wrong number of generic parameters. Fixed eweasel test#incr285. +* Fixed an incorrect code generation for the dynamic binding of routines defined in generic classes and attribute access in general. Fixed eweasel test#exec272 and test#final039. +* Fixed eweasel test#melt081 where having a redefined routine involving an anchor to a non-existing feature would crash the compiler instead of reporting a VEEN error. +* Various bug fixes with respect of handling of expanded generic classes used in generic classes. + +===Runtime/code generation issues=== +* Changed the usage of `eif_adopt`, `eif_protect`, `eif_wean`, `eif_freeze` and `eif_unfreeze` so that they can be used in concurrent thread, meaning that it is safe to use them as long as the argument is different in various threads. + +===Store/Retrieve issues=== +* Fixed some issues with the storing or retrieving of generic expanded types. + + + + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-reference/compiler/compiler-history/eiffelstudio-6-compiler-history/major-changes-between-ise-eiffel-62-and-ise-eiffel-63.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-reference/compiler/compiler-history/eiffelstudio-6-compiler-history/major-changes-between-ise-eiffel-62-and-ise-eiffel-63.wiki new file mode 100644 index 00000000..9f87d26d --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-reference/compiler/compiler-history/eiffelstudio-6-compiler-history/major-changes-between-ise-eiffel-62-and-ise-eiffel-63.wiki @@ -0,0 +1,62 @@ +[[Property:title|Major changes between ISE Eiffel 6.2 and ISE Eiffel 6.3]] +[[Property:link_title|6.3]] +[[Property:weight|-10]] +[[Property:uuid|55a1c34d-5313-1bcc-924e-3a3a68905665]] +==What's new== + +{{seealso|[[Differences between standard ECMA-367 and Eiffel Software implementation|Differences between standard ECMA-367 and Eiffel Software implementation]] }} + +* Implemented proper runtime conformance for attached types, that is to say A [!ANY] will conform to A [!ANY] or A [?ANY], but A [?ANY] will only conform to A [?ANY]. +* Added support for the new attribute keyword (support is enabled when using the standard syntax option, i.e. the same option that allows you to use the note keyword. + +==Improvements== +* Improved speed of compiler by about 10% overall. +* Reduced memory usage at runtime of Eiffel applications (on EiffelStudio itself it is about 30MB over 100MB). + +==Changes== +* Changed the way files are opened on Windows by ensuring that they cannot be inherited by child processes. This was necessary since one would need to wait for the child process to exit to remove files owned by the parent process. +* Compiler now accepts the new syntax for variant in a loop (i.e. before the end keyword). +* Fixed missing detection of VREG and VRFT errors for labels of a named tuples which is used as an actual generic parameter of a type (fixes eweasel test#tuple012 and test#tuple013), thus some of your code might be broken since the compiler failed to check this before. +* Fixed eweasel test#valid222 where compiler properly detects VDRS-4 errors when you redefine a repeatedly inherited routine in at least one but not all branches, but fail to provide a local definition. +* Now a formal generic parameter only conforms to a formal generic parameter, that is to say assignment to a formal generic parameter where the source is of type NONE (i.e Void) will now be rejected by the compiler. +* Dropped support for older Microsoft C/C++ compilers on Windows platforms. We only support VS 2005 or greater. + +==Bug fixes== + +===Language issues=== +* Fixed compiler issues with handling of attached types. + +===Compiler issues=== +* Renamed `eif_com.h` from the compiler delivery into `eif_com_exception.h` as it conflicts with `eif_com.h` from the EiffelCOM library. +* Fixed eweasel test#final061 and test#final063 where some kind of code could cause a crash of the compiler during degree -3 with inlining enabled. +* Fixed eweasel test#final063 which caused a C compiler error when your code uses an inline agent in an assertion and the routine in which it is defined is deferred. +* Fixed Makefile code generation issue on machine with many cores which could cause a C compilation error because some dependencies are missing in the Makefile targets. +* Fixed bug#13881 where if you have a VKCN error when using a routine whose return type is a like argument then it would crash instead of reporting the VKCN error. Improved VKCN error reporting by providing the instruction or expression which causes the problem. +* Fixed eweasel test#rdtp001 and test#term158 where if TUPLE is not written using upper case characters, then the compiler will crash when trying to analyze the type. +* Fixed the issue found with GCC 4.x series where an assignment of the form *(a + x) = f() would first evaluate (a+x) and then `f` which could cause a memory corruption if `f` triggers a GC cycle. As far as we could tell, this kind of code generation was only done when `f` would return a basic type. See eweasel test#runtime007. +* Fixed eweasel test#ccomp076 where C/C++ inlines did not get the protected object if any, but only the unprotected one which could cause some issue if the C/C++ inline code uses `eif_access` or `eif_adopt`. +* Fixed various issues with the `full class checking` option that would not work for inherited code involving conversion or labeled tuples (see eweasel test#svalid001, test#svalid007, test#svalid009 and test#svalid010). +* Fixed bug#14856 and test#final064 where if before generating the agent call/item routine we generated a call to a deferred routine without implementation we would not generate the arguments of the agent causing a C compilation error in finalized mode. +* Fixed improper runtime semantics for creation of manifest tuples, arrays and agents (see eweasel test#tuple011, test#tuple014 and test#agent006) +* Fixed eweasel test#term159 where the compiler would crash if there is a conversion for one of the closed argument of an agent creation. +* Fixed some inlining problem of routines that may return an expanded type (fixes eweasel test#final065 and test#exec147). +* Fixed C compilation error when using CECIL on system using gcc 3.4 or greater as the later generated an abort sequence rather than calling a feature. Partially improves eweasel test#ccomp063 behavior. +* Fixed eweasel test#agent005 where some large agent signature would cause a crash in the compiler. +* Fixed eweasel test#syntax050 where the compiler incorrectly valid code using an assigner where the target is a parenthesized expression (e.g. (create {A}).item := b). +* Fixed an issue with the DLL specification which would not allow hyphen in the name of a DLL. +* Fixed eweasel test#exec287 where if you assigned a basic type (INTEGER, CHARACTER, ...) to a TUPLE entry expecting a reference type and that you were assigning it via its assigner (t.field := value) then it would generate incorrect code causing a crash at runtime. + +===Runtime/code generation issues=== +* When registering externally created threads, make sure that the runtime does not exit them when no more Eiffel code needs to be run as it must be done by the code that created it. Also made sure that the runtime per thread data are reset to 0 to ensure that we can register/unregister the external thread as many times as needed. +* Fixed a buffer overflow that would occur on some Unix platforms when a signal was received by the application. +* Fixed eweasel test#thread006 where if many threads allocate small objects which are quickly dying then we could break the runtime synchronization and cause a crash. +* Added a cast to ensure that `eif_globals` can compile properly in C++ mode. +* Fixed eweasel test#runtime008 where we have a leak on each created thread if invariants are monitored. +* Fixed eweasel test#runtime009 where a reallocation of a SPECIAL object could cause a memory corruption. +* Fixed various issues with exceptions (performance, failure when reporting invariant, added I/O reason to exception object, extended stack traces up to the root class, rather than stopping at the first rescue clause). + +===Store/Retrieve issues=== +* Fixed a dead lock in a multithreaded application when a store operation fails to store data to a stream. +* Changed the independent store version number due to the usage of ! and ? in Eiffel code. Meaning that storables created by 6.3 cannot be read by older versions of EiffelStudio. + + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-reference/compiler/compiler-history/eiffelstudio-6-compiler-history/major-changes-between-ise-eiffel-63-and-ise-eiffel-64.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-reference/compiler/compiler-history/eiffelstudio-6-compiler-history/major-changes-between-ise-eiffel-63-and-ise-eiffel-64.wiki new file mode 100644 index 00000000..a739a54a --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-reference/compiler/compiler-history/eiffelstudio-6-compiler-history/major-changes-between-ise-eiffel-63-and-ise-eiffel-64.wiki @@ -0,0 +1,78 @@ +[[Property:title|Major changes between ISE Eiffel 6.3 and ISE Eiffel 6.4]] +[[Property:link_title|6.4]] +[[Property:weight|-11]] +[[Property:uuid|08206c9f-42fc-d007-ca09-4cf6a42207c2]] +==What's new== +{{seealso|[[Differences between standard ECMA-367 and Eiffel Software implementation|Differences between standard ECMA-367 and Eiffel Software implementation]] }} +* Added new compiler command line options: '''-experiment''' and '''-compat'''. The '''-compat''' option has no effect in 6.4. The '''-experiment''' option changes the internal value of $ISE_LIBRARY to look for libraries under $ISE_EIFFEL/experimental/library. Those libraries are truly void-safe with respect to ARRAY/SPECIAL and because of that change, might break your existing code. In 6.5, the experimental libraries will become the default libraries. So, you are encouraged to take steps to ensure that your code will compile with the experimental libraries. We have made it possible to compile the same code under both sets of libraries. This should facilitate testing. +* Added support for iPhone platform. +* Added support for the new syntax for object test, i.e. "attached {T} expr as u" instead of "{u: T} expr". +* Added free syntax for '''stable''' attributes; the final syntax is being discussed by the ECMA committee. Stable attribute is an attribute of a detachable type that is never assigned void. This property makes it possible to apply to it most of the CAP rules suitable for read-only entities. The stable attributes can be declared using value '''stable''' of the note tag option, for example: +a: detachable MY_TYPE note option: stable attribute end + + + +==Improvements== +* Added support for multiple object tests using the same object test local name in a single feature, provided that their scopes do not intersect. +* Made precompilations work on Mac OS X. +* Improved inlining of deferred routines implemented as attributes or constants in INLINER by allowing their inlining. +* Added support for detecting Mac OS X and VxWorks target compilation. +* Improved C compilation speed of E1/eskelet.c in workbench mode when using VS 2005 C++ for 64-bit. We went from a benchmark of 3 minutes down to 1 minute. This is definitely caused by a bug in VS, because the 32-bit version compiles the same code in just a matter of a few seconds. Microsoft reports having a fix for this in VS 2010. +* Fixed bug#15343 where backups were very large if you referenced many .NET assemblies even when not compiling for .NET. +* Attached attribute initialization in creation procedures is now detected not only by inspecting the top-level instructions, but also the nested complex instructions with several possible execution paths, like conditional instruction, multi-branch, etc. +* Improved degree 6 performance by not examining the content of all .e files to determine the associated class name. We now assume on the first pass that the file name is the class name. On EiffelStudio, if none of the files were buffered, we went from about 1 minute spent to just less than 3 seconds. The improvement should be even more visible when classes are on a remote drive. +* Fixed eweasel test#runtime010 where certain allocation patterns could cause a major slow down during a garbage collection cycle. + +==Changes== +* Ensured that particular options specified in a library cannot be overridden in a project, because they apply to the source code (e.g., specify a variant of a syntax) rather than to the code generation (e.g., specify which assertions have to be monitored). +* Removed usage of infix/prefix in most of the libraries. To ease transition, added a compatibility option that allows existing code using the infix/prefix notation to continue to compile. +* Attachment status of formal generic constraints are now taken into account when checking conformance and detecting VUTA errors when target type is a formal generic. '''Important''': default attachment status of the constraints follows the "attached-by-default" setting, so the code might need to be updated by adding a detachable mark in front of the formal generic constraints if the actual generic parameters can be detachable types. +* The compiler does not produce the class progress output in batch mode. The old behavior is available by using the '''-verbose''' option. +* Fixed incorrect display of NATURAL_32 attributes when calling `out` (fixes eweasel test#exec298 and bug#13862.) + +==Bug fixes== + +===Language issues=== +* Renamed VUPR errors to their ECMA name VDPR. +* Better explanation for VDPR(3) errors when two or more precursors are available, by listing all the precursors. +* Non-void arguments are now detected not only when they are specified in the voidness tests in immediate preconditions, but also in inherited ones. +* Fixed missing detection of VRFT errors in cases like "a: TUPLE [a: TUPLE [out: INTEGER]]". + +===Compiler issues=== +* Incremented ECF XML schema version to reflect the recent changes. +* Replaced ECF schema attribute syntax_level of an integer type with syntax of a string type that contains one of the three possible values. +* Replaced ECF schema attribute is_void_safe of a boolean type with void_safety of a string type that contains one of the three possible values ('''none''': no void-safety checks; '''all''':all void-safety checks; '''initialization''': on-demand void-safety checks, i.e. only for entities that are attached). +* Fixed eweasel test#syntax042 and test#syntax047 as well as bug#15514 that allowed invalid characters in new C external specification. Removed generation of error when trying the old syntax, the syntax error will be based in the new syntax now. +* Fixed eweasel test#agent004 and test#agent010 by ensuring the result type of the agent is properly instantiated in the agent target type context. +* Fixed missing reporting of VEVI error for attributes initialized from a creation procedure by calling a once routine because the latter is not guaranteed to be executed on subsequent calls. +* Fixed eweasel test#incr322 and test#final079 where compiler would crash when a routine was implemented as an attribute that can be access statically in final mode. +* Fixed eweasel test#incr322 and test#final079 which caused a crash during finalization of a call to a deferred routine implemented as an attribute with a body or some assertions. +* Fixed eweasel test#melt085 and test#melt086 where using Precursor in a manifest array, manifest tuple or expression of an object test would cause a crash at runtime. +* Fixed multiple issues with validity checks involving multi-constraint formal generics and "like Current" types. +* Fixed system validity errors which were not previously detected or on the other hand rejected when it was correct. Fixes eweasel tests test#svalid019, test#svalid020 and test#multicon051. +* Fixed eweasel test#exec310 and bug#14477 where if you have a class name that is longer than 512 bytes or an attribute name longer than 512 bytes and you call `out` it would cause a buffer overflow. + +===Runtime/code generation issues=== +* Fixed broken generation of single threaded DLL. +* Fixed a bug on Windows where including some Eiffel multithreaded code in a DLL would cause a crash. This was due to the way we compiled our Thread Local Storage using a Microsoft optimization that only works for normal binaries, not DLLs. +* Fixed some interpreter crashes when handling manifest strings or agent expressions. +* Fixed eweasel test#final077 where the arguments passed to a creation expression where not properly processed when analyzing expressions. This caused the following instruction: "l_x := x.y.z (create .make (l_x))" to override the value of `l_x` with the value of `x.y` which is wrong. +* Fixed eweasel test#incr321 when if you finalize after removing a class from the system, then execution of workbench code fails. +* Fixed eweasel test#attach047 where type of array of string passed as argument to the creation procedure of the root class should have an attached actual argument type. +* Fixed eweasel test#expanded008 and bug#15693 where if you had an expanded with references attributes then the garbage collector would not update the internal references of the expanded and cause some memory corruption. +* Fixed a non-detection of stack overflow in a multithreaded application on Linux. +* Fixed test#thread002 where early termination of parent threads could corrupt memory if children thread are still alive. +* Fixed eweasel test#thread003 and test#thread007 where you could have a memory corruption at runtime when calling {THREAD}.join and no children threads have been launched yet. +* Fixed test#thread008 where you could have a memory corruption at runtime when calling {MEMORY}.find_referers. +* Fixed eweasel test#thread010 where a child thread would crash if its parent has already terminated and that child thread never started a thread. +* Improved signal handling to use more recent APIs when available. It especially fixes issue on Solaris where a signal handler was not reinstated after a SIGSEGV signal. It fixes eweasel test#except029. +* Fixed a bug with exception generated during the evaluation of a once in melted mode. This fixes eweasel test#except014 and test#except030. +* Worked around a bug in the Sun C compiler which caused the creation of SPECIAL in melted code to always fail when runtime is compiled with optimizations. It fixes eweasel test#melt070, test#melt081, test#term139, test#store014 and test#tuple006. +* Fixed a potential infinite loop when exiting a crash application when while quitting a signal is received which cause our last print statement to also fail (case of SIGPIPE), then it will infinitely repeat that sequence. This fixes the issue where eweasel test#vsrp208, although it was passing, ec was still using 100% CPU. + +===Store/Retrieve issues=== +* When handling a mismatch instead of generating the _REF classes for basic types, we generate directly an instance of the basic type so that one can do an object test on the basic type directly. +* Improved compatibility of storables between void-safe and non-void-safe systems so that a non-void-safe system can retrieve a storable created by a void-safe system by ignoring all the attachment marks. +* Fixed an unnoticeable performance issue with the C storable/retrieval mechanism (bug#14495). + + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-reference/compiler/compiler-history/eiffelstudio-6-compiler-history/major-changes-between-ise-eiffel-64-and-ise-eiffel-65.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-reference/compiler/compiler-history/eiffelstudio-6-compiler-history/major-changes-between-ise-eiffel-64-and-ise-eiffel-65.wiki new file mode 100644 index 00000000..7a4f4199 --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-reference/compiler/compiler-history/eiffelstudio-6-compiler-history/major-changes-between-ise-eiffel-64-and-ise-eiffel-65.wiki @@ -0,0 +1,49 @@ +[[Property:title|Major changes between ISE Eiffel 6.4 and ISE Eiffel 6.5]] +[[Property:link_title|6.5]] +[[Property:weight|-12]] +[[Property:uuid|c4cf1874-cb2b-1034-704b-a537c1d5cd68]] +==What's new== +{{seealso|[[Differences between standard ECMA-367 and Eiffel Software implementation|Differences between standard ECMA-367 and Eiffel Software implementation]] }} +*Added support for transient attribute. A transient attribute is an attribute which is not stored at runtime and for which its absence in the retrieval system has no effect. Only implemented for C based storable. +* New loop constructs implementation per a draft specification of the next ECMA standard. Although the compiler supports the new construct, the library counterpart was not included in this release. It will be available as a separate download a few weeks after the 6.5 release. + +==Improvements== +No major improvements in 6.5 as this release was mostly focused on quality improvements. + +==Changes== +* All the void-safe project configuration files have been removed from the non-experimental version. The rationale is that the usage of ARRAY and SPECIAL would not be void-safe and you need to switch to the experimental version to ensure complete void-safety. +* The command line compilation has been fixed to use the current working directory unless -project_path is specified (restoring pre-ecf behavior) +* When an ecf file has been specified with -config, the previously compiled target is chosen as the first option in the compilable target list. + +==Bug fixes== + +===Language issues=== +* Ensured that code generation in .NET mode with experimental compiler worked properly. The current limitation is that manifest type instances are not unique unlike their classic counterpart and that {ANY}.generating_type cannot be applied on .NET types. + +===Compiler issues=== +* Fixed eweasel test#incr313, test#incr317 and test#incr318 where removal of a convert clause was not taken into account by the compiler. +* Fixed eweasel test#svalid022 where conversion to a target of a detachable type was not accepted, and also now the compiler will verify that the source of the conversion is always attached. Ensured that the source or the target type mentioned in a convert clause is attached. +* Fixed eweasel test#svalid024 where using an inspect clause with static constant access would failed to compile in a descendant class when `full class checking` is enabled. +* Fixed eweasel test#term156 and test#svalid025 where compiler would crash while compiling code that needs to be regenerated in descendant classes (e.g. code from precondition) involving anchors or formal generic parameters. +* Supported tracking changes made to a shared library definition file to trigger freeze automatically when there are any modifications to this file. +* Fixed bug on Unix platforms where spaces in project/installation paths failed to create the necessary symbolic links, when using precompiles. +* Fixed eweasel test#final083 where compiler would crash when inlining certain type of code involving generic classes. + + +===Runtime/code generation issues=== +* Fixed eweasel test#final086 where an object test could evaluate the expression more than once. +* Fixed bug#13969 where an Eiffel generated DLL trying to print something to the console would cause a crash. +* Fixed bug#15553 where querying {FILE}.is_socket and some other file properties would not work properly on some Unix platforms (Solaris in particular). +* Fixed bug#13852 and bug#13816 where allocating large arrays would cause a memory corruption. +* Improved runtime protection of certain routines if a signal is delivered to avoid either corruption or memory leak (Fixes bug#13851, bug#13842, bug#13849, bug#13850 and bug#13840). +* Fixed bug#15241 where finalizing with assertions enabled would cause a C compilation error when freezing later in the same EiffelStudio session. +* Fixed a bug in CECIL macros which would cause a segmentation violation on some platforms at the first GC cycle. +* Fixed creation of manifest array with an attached actual generic parameter to not throw a precondition violation in void-safe mode. +* Fixed eweasel test#array006 where creating a manifest array would trigger an unjustified invariant violation. +* Fixed eweasel test#final084 where compiler would generate incorrect type at run-time causing some memory corruption or a general failure. + + +===Store/Retrieve issues=== +* Fixed bug#16395 and eweasel test#store026 to avoid mismatch if the metadata stored in `eskelet` is simplified or not (i.e. for class A[G] feature g: B[G], and then having A [INTEGER] could either describe `g` as either `B[G]` or `B[INTEGER]`, even though different they are the same type and should not yield a mismatch). +* Fixed eweasel test#store028 where retrieving an object whose type involves a TUPLE type without a TUPLE instance could corrupt the retrieval system. + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-reference/compiler/compiler-history/eiffelstudio-6-compiler-history/major-changes-between-ise-eiffel-65-and-ise-eiffel-66.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-reference/compiler/compiler-history/eiffelstudio-6-compiler-history/major-changes-between-ise-eiffel-65-and-ise-eiffel-66.wiki new file mode 100644 index 00000000..d90db604 --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-reference/compiler/compiler-history/eiffelstudio-6-compiler-history/major-changes-between-ise-eiffel-65-and-ise-eiffel-66.wiki @@ -0,0 +1,52 @@ +[[Property:title|Major changes between ISE Eiffel 6.5 and ISE Eiffel 6.6]] +[[Property:link_title|6.6]] +[[Property:weight|-13]] +[[Property:uuid|4ff759ff-c389-f765-0252-2d844b69fa54]] +==What's new== +{{seealso|[[Differences between standard ECMA-367 and Eiffel Software implementation|Differences between standard ECMA-367 and Eiffel Software implementation]] }} +* Added support for [[ET: Other Mechanisms#Adjusting once semantics with "once keys"|new once syntax and once per object]]. However support for once object is still experimental in this release. +* Added support for [[ET: Inheritance#Qualified Anchored Declarations|RAT/QAT]], with the following limitations: +** Qualified anchored types that involve formal generics with multiple constraints are not supported. +** When an attribute of type `like a.b.c' yields a formal generic parameter in the chain, then the creation of such attributes would not yield the proper type. +** Creation and object tests with the type depending on qualified anchored types that involve deferred intermediate types are not supported on .NET. +* Added a new option Total Order on REALs which let you have NaN equal to NaN and NaN being the smallest number of all. This option is disabled by default as it could break existing code. The rationale for this option is to have contracts work properly when manipulating the NaN value and not getting spurious contract violation. +* Added the ability to version a class for storable. It is done via the note clause of a class, i.e. note storable_version: tag. When the storing and retrieving system have a different version a mismatch is triggered even if they look to have the same content. +* Supported new variant of a check instruction that is not subject for assertion monitoring settings (in other words the check cannot be turned off) and can be used to introduce a new void safe scope of a read-only or object test local: +check Assertion then + Compound +end + +* Now the compiler will report usage of is keyword as obsolete in transitional mode and will reject it in standard mode. + +==Improvements== +* Added support of [[ET: The Dynamic Structure: Execution Model#Transient attributes|transient attributes]] for .NET. Added queries in INTERNAL to find out the transient attributes. Extended the Eiffel serialization SED to support them. +* Redone some of the multithreading internals of the Eiffel runtime to make it easier to add platforms and to ensure the same behavior on various platforms, namely that mutex should be recursive. +* On Windows, the MUTEX class is now internally using a CRITICAL_SECTION object which is much more efficient especially on multiprocessors. + +==Changes== +* The experimental mode available in 6.5 and earlier version has become the default mode. To have access to the default mode of 6.5, one has to use the compatible version. It can be accessed on Windows via the Start menu shortcut or by using "-compat" on the command line. +* Allowed manifest real constants to be assigned to REAL_32 entities without having the need to type the constant, that is to say `r_32 := 4.5' will now be accepted whereas before one had to do `r_32 := {REAL_32} 4.5'. This is to simplify migration from code that compiled fine under 6.5 and would not under 6.6 due to the removal of the conversion routine from REAL_64 to REAL_32. +* When twinning a SPECIAL instance where capacity is much higher than its count the new copy will have its capacity set to count. +* The storable format has changed to support versioning. This new format is only available in the default mode. When using the compatible mode it will store using the old format and no version information will be stored. + +==Bug fixes== + +===Language issues=== +* Fixed in void-safe mode conformance of detachable COMPARABLE to attached ANY. Fixes updated eweasel test#conform001. + +===Compiler issues=== +* Fixed test#incr168 when recompilation did not regenerate the code in some complex cases when features are modified deep in inheritance tree. It also fixes eweasel test#exec283 and addresses a consistency issue with the order of merging inherited assertion clause that would not trigger the same output if recompiled from scratch after some incrementality changes (see eweasel test#incr124). +* Fixed bug#16545 when compiler did not detect that a new file does not contain an expected class after referencing it in a system (see test#incr340). +* Fixed several recompilation bugs (bug#16546, bug#16547, bug#16553) for cases when a feature with assertions is removed from a parent class while a child class remains unchanged (see test#incr341, test#incr342, test#incr343). +* Fixed recompilation bugs (bug#14525, bug#16052) that caused compiler crash or incorrect error message when checking inherited code of a client that refers to a feature that is (re)moved (see test#incr293, test#incr338). +* Fixed bug#16593 where finalizing twice in the same sessions with many changes in the system could cause the compiler to crash during degree -3. + +===Runtime/code generation issues=== +* Fixed test#runtime016 due to an improper optimization of the call {SPECIAL}.copy_data when inlining is enabled. It could cause a memory corruption. +* Fixed bug#16626 bug that occurred when melted code called frozen code that called a melted agent triggering exception (see test#incr348). +* Fixed eweasel test#agent001 and test#agent013 by preventing wrong optimization when call to `{ROUTINE}.call' or `{FUNCTION}.item' are subject to dynamic binding. +* Fixed eweasel test#exec323 where comparison using <= or >= in melted mode which involved NaN was not yielding the same result as in workbench mode. + +===Store/Retrieve issues=== +* Fixed eweasel test#store029 where retrieving a storable made by 6.3 or older could fail with a mismatch error when there is actually no mismatch. + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-reference/compiler/compiler-history/eiffelstudio-6-compiler-history/major-changes-between-ise-eiffel-66-and-ise-eiffel-67.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-reference/compiler/compiler-history/eiffelstudio-6-compiler-history/major-changes-between-ise-eiffel-66-and-ise-eiffel-67.wiki new file mode 100644 index 00000000..dadc2794 --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-reference/compiler/compiler-history/eiffelstudio-6-compiler-history/major-changes-between-ise-eiffel-66-and-ise-eiffel-67.wiki @@ -0,0 +1,39 @@ +[[Property:title|Major changes between ISE Eiffel 6.6 and ISE Eiffel 6.7]] +[[Property:link_title|6.7]] +[[Property:weight|-14]] +[[Property:uuid|56177121-d509-3dd3-bb11-5f70d69a74f7]] +==What's new== +{{seealso|[[Differences between standard ECMA-367 and Eiffel Software implementation|Differences between standard ECMA-367 and Eiffel Software implementation]] }} +* EiffelStudio can use GCC on Windows for both 32-bit and 64-bit edition. We are using version 4.4.5 of gcc. +* EiffelStudio can now parse UTF-8 source code. Unicode characters can be used in strings, comments and operators. +* New tracing facility for Eiffel code. Until now tracing was done at the runtime level by writing to the standard output. The new tracing facility lets you execute some user defined Eiffel code at entry and exit of all routine calls. It can be used for logging purposes, or for test coverage. + +==Improvements== +* Allowed for a qualified anchored type that has a standalone type qualifier to be used as a type of a once function *bug#16947, test#anchor050). + +==Changes== + +==Bug fixes== + +===Language issues=== + +===Compiler issues=== +* Fixed various issues related to qualified anchored types: bug#16791 (test#anchor011), bug#16792 (test#incr352), bug#16793 (test#incr353), bug#16797 (test#anchor012), bug#16798 (test#anchor013), bug#16799 (test#anchor014), bug#16800 (test#anchor015), bug#16803 (test#anchor016), bug#16804 (test#anchor017), test#anchor018, bug#16819 (test#anchor019), bug#16821 (test#incr354), test#anchor020, test#anchor021, bug#16824 (test#anchor022), test#anchor023, bug#16839 (test#anchor024), test#anchor026, bug#16848 (test#anchor027), bug#16849, bug#16850 (test#attach030), bug#16855 (test#final089), bug#16849, bug#16867 (test#anchor028), bug#16868 (test#anchor029), bug#16876 (test#anchor031), bug#16878 (test#incr356), bug#16879 (test#anchor033), bug#16883 (test#anchor034), bug#16884 (test#anchor035), bug#16885 (test#anchor036), bug#16886 (test#anchor037), bug#16887 (test#anchor038), bug#16889 (test#incr358), bug#16890 (test#anchor040), bug#16893 (test#incr359), bug#16897 (test#anchor041), bug#16899 (test#incr362), bug#16900 (test#incr363), bug#16901 (test#incr364), bug#16902 (test#anchor043), bug#16943 (test#anchor047), bug#16944 (test#anchor048), bug#16945 (test#anchor049), bug#16959 (test#anchor052). +* Fixed various issues related to once per object: test#once001, test#once002, test#once003, test#once004, test#once005, test#once006, test#once007, test#once008, test#once009, test#once010, test#once011, test#incr366, test#incr376, test#incr384. +* Fixed various incrementality bugs: test#incr295 test#incr302 test#incr307 test#incr309 test#incr324 test#incr331 test#incr332 test#incr346 test#incr372 test#incr373 test#incr374. +* Fixed eweasel test#exec327 where evaluation an assertion the code being executed encounter the new check ... then ... end instruction it would reset some internal flags causing assertion within assertions to be checked when they should not. +* Fixed eweasel test#valid243, test#svalid028, test#svalid029, test#tuple004, test#freez032 and test#multicon058. The issue was that when we performed the type checking of inherited routines using prefix/infix we were not using the new name of the prefix/infix operator but still the old one. Thus if it was renamed it would cause a spurious compilation error instead of accepting the code. + +===Runtime/code generation issues=== +* When running an Eiffel system on Windows without assertion monitoring and you try to write a file that is not yet open, it will trigger an exception instead of silently exiting. +* Fixed eweasel test#thread016 where we forget to protect arguments used for catcall checking. +* Fixed building of shared libraries of CECIL system which failed on Windows. +* Fixed eweasel test#ccomp085 where compiler ensures that the order of includes of an Eiffel external is respected at compile time. +* Fixed eweasel test#exec326 by properly generating the REAL_32 values for {REAL_32}.min_value and {REAL_32}.max_value. + +===Store/Retrieve issues=== +* Prevented the C storable from blocking all threads while waiting from data to be read in retrieved. Now control waits for the storable type first before blocking all the other runtime threads. This fixes bug#16859. +* Fixed bug#16946 and eweasel test#store032 where corruption could occur if an object is stored in a different thread than the main thread. + + + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-reference/compiler/compiler-history/eiffelstudio-6-compiler-history/major-changes-between-ise-eiffel-67-and-ise-eiffel-68.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-reference/compiler/compiler-history/eiffelstudio-6-compiler-history/major-changes-between-ise-eiffel-67-and-ise-eiffel-68.wiki new file mode 100644 index 00000000..bd90e23b --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-reference/compiler/compiler-history/eiffelstudio-6-compiler-history/major-changes-between-ise-eiffel-67-and-ise-eiffel-68.wiki @@ -0,0 +1,29 @@ +[[Property:title|Major changes between ISE Eiffel 6.7 and ISE Eiffel 6.8]] +[[Property:link_title|6.8]] +[[Property:weight|-15]] +[[Property:uuid|4ae502ce-5832-c323-4c3a-d1b0d1243735]] +==What's new== +* Support for [[Concurrent programming with SCOOP|SCOOP concurrency model]]. +{{seealso|
1) SCOOP implementation [[SCOOP implementation#Known limitations|limitations]].
2) [[Differences between standard ECMA-367 and Eiffel Software implementation|Differences between standard ECMA-367 and Eiffel Software implementation]]. }} + +==Improvements== +* Made ECF parser more tolerant by converting errors into warnings when the current namespace is unknown. +* Improved error reporting by including attachment status indicator in type information so that one can easily see the difference between attached and detachable types when they come from the classes with different default attachment settings. + +==Changes== +* Made feature {ITERATION_CURSOR}.start optional when processing an iteration form of a loop. + +==Bug fixes== +* Fixed bug#17374: Feature call on void target in {EB_CLASS_INFO_ANALYZER}.stone_in_click_ast in EiffelStudio. +* Fixed bug#17299: Locale preference lost the second time opening EiffelStudio. +* Fixed a crash that occurs when there is an error inside a check instruction. + +===Language issues=== + +===Compiler issues=== + +===Runtime/code generation issues=== + +===Store/Retrieve issues=== + + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-reference/compiler/compiler-history/index.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-reference/compiler/compiler-history/index.wiki new file mode 100644 index 00000000..c4b84ff1 --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-reference/compiler/compiler-history/index.wiki @@ -0,0 +1,7 @@ +[[Property:title|Compiler History]] +[[Property:weight|-8]] +[[Property:uuid|359395e7-4933-bb74-4397-353c8b6955cd]] +==Compiler version history== + + + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-reference/compiler/compiler-history/major-changes-between-ise-eiffel-1311-and-ise-eiffel-1405.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-reference/compiler/compiler-history/major-changes-between-ise-eiffel-1311-and-ise-eiffel-1405.wiki new file mode 100644 index 00000000..3f8efc8e --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-reference/compiler/compiler-history/major-changes-between-ise-eiffel-1311-and-ise-eiffel-1405.wiki @@ -0,0 +1,63 @@ +[[Property:title|Major changes between ISE Eiffel 13.11 and ISE Eiffel 14.05]] +[[Property:link_title|14.05]] +[[Property:weight|8]] +[[Property:uuid|a901f880-4f88-f889-4880-d3687b6939b1]] +==What's new== +* Syntax warnings are now reported for unsupported empty lists such as (), or [], or {}, as well as an empty export clause `export {NONE} end'. +* Added ability to extract the file location of a class in interactive mode. + +==Improvements== +* Made workbench code more compact and faster by about 5 to 9% on average. +* Improved memory tool to list all fields of an object. +* Better command line usage that will report why the command line is incorrect instead of displaying the whole help. +* Compiler is now more robust if some required routines/classes are not found as expected by the compiler. It will now report a Library_error error instead of failing. +* Now the compiler reports all VWEQ warnings as before it was only doing it if you were comparing an expanded with a reference. + +==Changes== +* In circa 2000, we allowed $x and $(expr) as expression instead of just argument passing. But while this was good for just $x, $(expr) is actually not supported properly in the code generation. In 14.05, we have disallowed $(expr) outside argument passing. +* In workbench mode, if the melted file cannot be found, instead of exiting the application, the application will run as if it had never been melted and will instead print a warning in the console. + +==Bug fixes== + +===Language issues=== + +===Compiler issues=== +* test#anchor071 - Fixed computation of a qualified anchored type that involves a formal generic parameter and feature redeclaration in a descendant of the formal generic constraint. +* test#anchor077 - Fixed a compiler crash when analyzing the following qualified anchored type '''like x.f''' where f is defined as '''f: like y.z.w'''. + +* bug#16991 (test#anchor056) - Fixed a bug that might cause the compiler to report an unknown feature in a qualified anchored type with a formal generic qualifier constrained only by formal generic types. +* test#anchor070 - Fixed a bug that might cause a compiler crash when nested qualified anchored types with a longer feature chain were involved in qualifiers of other qualified anchored types. +* bug#16983 (test#anchor055), bug#17034 (test#anchor057) - Fixed a bug that caused a crash when compiling code with a creation of an object of a qualified anchored type with a formal generic. +* bug#17239 (test#term198) - Fixed a bug that caused a crash when compiling the code that used an inline agent as an iteration expression. +* bug#17233 (test#term196) - Supported iteration on an expression of a formal generic type. +* bug#18759 (test#iteration004) - Changed processing of {ITERABLE}.new_cursor to use a renamed version of the feature in a descendant class rather than the feature having this name. +* test#config028, test#config029 and test#config038 - Fixed a crash when using a cluster/library with an invalid path. +* Fixed a long standing bug where descriptions in external nodes were lost. +* Fixed an issue with interactive mode where displaying all classes was actually not display classes which are part of a recursive cluster. +* bug#18758 (test#anchor073, test#anchor074, and test#anchor059) - Fixed some improper handling of qualified anchors. +* test#anchor050 - Fixed an issue on .NET where the compiler would not properly handle '''like {X}.f'''. +* test#anchor065 - Fixed a compiler crash when processing '''like {G}.value'''. +* Fixed a bug in the interactive mode of the compiler that was preventing the display of classes that belong to a folder of a cluster. +* test#valid265 - Fixed a bogus compilation error when the type of a variant expression is of an anchored type when it should have accepted it. +* bug#18824 (test#anchor075) - Fixed a compiler crash in .NET code generation where '''like {X}.dotnet_query''' would crash the compiler at degree 3. +* text#catcall013 - Fixed an issue with catcall checking which would crash the compiler in the specific case where a type used as argument has some conversion routines. +* Fixed bug#18855 where we used the wrong constant to display the command switch for the `-debug' option. + +===SCOOP issues=== + +===Runtime/code generation issues=== +* test#exec341 - Fixed a crash at runtime when performing an assignment using an object-less call, e.g. '''{EXT}.fea := bar'''. +* Fixed a regression that caused a C compilation error after removing a type from the system. +* bug#18758 (test#anchor072) - Fixed crash which only affected .NET code generation of qualified anchor types. +* test#anchor018, test#anchor050, test#anchor054, test#anchor056, test#anchor059, test#anchor063 and other tests - Fixed a code generation issue on .NET where some incorrect casts where generated causing an exception at runtime when the code is actually ok. +* test#freez022 - Fixed a missing conversion at runtime when formal argument type is an anchor. +* Fixed CECIL library creation to take into account the new memory_analyzer.o and offset.o modules of the runtime. +* bug#18785 (test#ccomp089) - Fixed a code generation issue for Linux 32-bit for the generation of the value of NaN, +Infinity and -Infinity for floating numbers. + +===Store/Retrieve issues=== +* Fixed an issue where retrieving a large amount of objects on a x86 platform, we would crash where restoring one of the store/retrieve stack using ''epop''. +* bug#18835 - Fixed a potential overflow issue with store/retrieve when you have more than 2^31 objects. + + + + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-reference/compiler/compiler-history/major-changes-between-ise-eiffel-68-and-ise-eiffel-70.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-reference/compiler/compiler-history/major-changes-between-ise-eiffel-68-and-ise-eiffel-70.wiki new file mode 100644 index 00000000..248736f8 --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-reference/compiler/compiler-history/major-changes-between-ise-eiffel-68-and-ise-eiffel-70.wiki @@ -0,0 +1,60 @@ +[[Property:title|Major changes between ISE Eiffel 6.8 and ISE Eiffel 7.0]] +[[Property:link_title|7.0]] +[[Property:weight|13]] +[[Property:uuid|0211321e-969d-04a4-66ee-2a6069836845]] +==What's new== +* Supported development of incomplete void-safe classes (so called "design mode") by avoiding reporting void-safety errors for unreachable code, e.g. for the code after a call to a feature that never returns normally, say, to {EXCEPTIONS}.die. As a result it became possible to declare a creation procedure that does not initialize attached attributes properly (because the corresponding effective classes are not available yet), for example: + +make (...) + do + ... -- Some attributes are not initialized. + die (1) -- Compiler does not report VEVI errors. + end + +:or + +make (...) + do + ... -- Some attributes are not initialized. + check implemented: False then end -- Compiler does not report VEVI errors. + end + + +==Improvements== +* Enforced full class checking for void-safe classes. +* Disallowed void-safety mismatch when a descendant or a client have stricter void-safety setting than the corresponding ancestor or supplier. +* Taken into account changes of class options when performing recompilation. +* Changed processing of "stable" features to follow the recent modifications to the standard. +* Avoided reporting errors related to variable initialization when the right-hand part of assignment to this variable causes an error. +* Promoted keywords across and some from the '''provisional''' [[Setting the syntax variant|syntax variant]] to the '''standard''' one. +* Made class BIT_REF optional as soon as a BIT type is not used in a system (to be ready to drop support for BIT types in the next releases). +* Replaced keyword completion for indexing with keyword completion for note. + +==Changes== +* Changed default options: default [[Setting the syntax variant|syntax variant]] is set to [[Syntax level variant settings by version|standard]], [[Creating a new void-safe project#The "Are types attached by default?" setting|attached-by-default]] is set to '''true''' unless specified otherwise. +* Moved [[Creating a new void-safe project#The "Are types attached by default?" setting|attached-by-default]] option to [[Advanced Options|Advanced]] section. + +==Bug fixes== + +===Language issues=== +* Considered like Current as attached regardless of [[Creating a new void-safe project#The "Are types attached by default?" setting|attached-by-default]] option. +* Prohibited assignment of Void to a variable of a reference formal generic type that has no detachable mark. +* Supported attachment marks on the type NONE, including implicit setting via [[Creating a new void-safe project#The "Are types attached by default?" setting|attached-by-default]] option. +* Corrected processing of self-initializing attributes to follow the standard rules. + +===Compiler issues=== +* Included location information in VTCT error and VTCM warning reports. +* Fixed several recompilation issues. +* Fixed several cases that could lead to a compiler crash. +* Corrected checks for attachment status of variables to include not only a body of a loop, but also its invariant, variant and exit condition when a variable may be detached in the loop body. +* Taken into account attachment status of like Current when checking for conformance. +* Taken separateness status into account when checking for formal generic type equality and conformance as well as when substituting actual generics. +* Made custom conditions in ECF case-insensitive to be in line with the processing of custom variables. +* Changed context of inherited assertion evaluation to use the one of the inherited assertion so that the types are evaluated correctly (this in particular affects qualified anchored types that involve formal generics that are no longer present in a descendant class). + +===Runtime/code generation issues=== +* Fixed several issues with separate feature calls. + +===Store/Retrieve issues=== +* Fixed an issue when there are too many mismatches in a storable, the retrieval would fail with an invalid object being retrieved. + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-reference/compiler/compiler-history/major-changes-between-ise-eiffel-70-and-ise-eiffel-71.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-reference/compiler/compiler-history/major-changes-between-ise-eiffel-70-and-ise-eiffel-71.wiki new file mode 100644 index 00000000..64133660 --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-reference/compiler/compiler-history/major-changes-between-ise-eiffel-70-and-ise-eiffel-71.wiki @@ -0,0 +1,63 @@ +[[Property:title|Major changes between ISE Eiffel 7.0 and ISE Eiffel 7.1]] +[[Property:link_title|7.1]] +[[Property:weight|12]] +[[Property:uuid|4b7325ad-4c9c-d6f8-3a25-7d2a4d709fcb]] +==What's new== +* New SCOOP processor GC which lets you create as many processors as you want as long as they are no more than 1500 concurrent processors (or less depending on your available memory). +* Supported the EIFFEL_LIBRARY environment variables to locate libraries. + +==Improvements== +* The Eiffel Configuration Files accept C compiler and linker flags. Former ECFs using a workaround to specify those flags as part of the external includes or external objects sections are automatically updated to the new specification. +* Report invalid Unicode code point for STRING_8 manifest. +* Ensured you can switch C compilers after compiling with one on Windows. +* Speed up C compilation with Visual Studio by using `#pragma once` on our header files (bug#17092). +* Speed up execution of expanded comparison using ~ when types are known to be different at compile time. +* Optimized code generation of {CHARACTER_32}.is_character_8. +* Optimized code generation of boolean expressions that are known to be False or True at compile time in both workbench and finalized mode. + +==Changes== +* Breaking change of generating Unicode code point for STRING_8 manifest written in UTF-8 source code. (Written UTF-8 bytes was generated). Unlike previous versions, what you see will be what you get at runtime, i.e. the character codes are the same. +* In the `on-demand` void-safety mode, the compiler will not report a VD88 error when you are using a non-void safe library. This should help migrating existing code to full void-safety. +* Removed support for type qualifier for strings used in obsolete messages. +* Removed type qualifiers from manifest constants to follow the changes in the language rules that now prevent from using them in constant attribute declarations. +* VWEQ warnings will only be triggered for immediate code, not inherited code. +* The assignment attempt operator ?= is now triggering an obsolete syntax warning. +* Changed expected content of verbatim strings to take into account that empty lines and empty lines with blanks are considered as different (test#syntax045). +* Default projects are now console applications by default. + +==Bug fixes== + +===Language issues=== +* Fixed bug that the compiler accepted invalid typed character. i.e. {BOOLEAN} 'c'. +* Made sure that typed manifest strings are using a proper string type, not just any type (bug#18045). +* Ensured all attributes are set when an unqualified agent is created (bug#18067). +* Triggered a warning when a non-empty body of an attribute which has a self-initializing type as the body is guaranteed to be never executed (bug#15145, test#exec296). +* Added detection of inline agents on attributes to report a NOT_SUPPORTED error (bug#15147, test#term168). + +===Compiler issues=== +* Fixed various issues where compiler did not properly report errors for mal-formed Eiffel Configuration Files. +* Fixed formatting of VFAV(2) error reporting (bug#18050). +* Fixed duplicated report of VFAC(1) error (bug#18047). +* Made sure one can perform the C compilation using the 32-bit version of the compiler on a 64-bit machine. +* Fixed compilation of EiffelBase using the new replication mode (test#replication008 and test#replication009). +* Improved VTAT error description (bug#16875). +* Fixed a compiler failure when the F_code or W_code sub-directories are deleted after an initial compilation. + +===SCOOP issues=== +* Fixed a memory corruption when a query on a separate target would not properly register the results to the garbage collector, making the results potentially unusable. + +===Runtime/code generation issues=== +* Fixed code generation in melted mode when you declare a CHARACTER_32 constant feature such as x: CHARACTER_32 = '%/027/'. +* Prevented a deadlock situation after a fork is performed on Unix platforms when using the `eif_thread_fork` (bug#18094). +* Fixed a traitor situation where a multi-dot chain involving a separate target are treated as separate calls rather than normal calls (test#scoop024). +* Fixed code generation of object test on basic types that was failing on .NET (test#dotnet113). +* Fixed some definitions conflicts with `complex.h` which occurs on some platforms. +* Ensured that on Windows using any Microsoft C++ compiler only 2 digits are displayed for exponents that can be represented on 2 digits and three otherwise. +* Fixed a potential memory leak of thread context when a parent and a child are exiting at about the same time. +* Fixed an incorrect handling of detachable NONE at runtime (test#melt088, test#valid154). +* Fixed a performance issue when a thread exits which would slow downs all threads until the next garbage collector cycle. +* Redesigned termination of a multithreaded program to avoid some deadlock and/or race conditions that could occur on a heavily loaded system (test#thread020, test#thread021 and test#thread023) + +===Store/Retrieve issues=== +N/A + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-reference/compiler/compiler-history/major-changes-between-ise-eiffel-71-and-ise-eiffel-72.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-reference/compiler/compiler-history/major-changes-between-ise-eiffel-71-and-ise-eiffel-72.wiki new file mode 100644 index 00000000..814e203a --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-reference/compiler/compiler-history/major-changes-between-ise-eiffel-71-and-ise-eiffel-72.wiki @@ -0,0 +1,36 @@ +[[Property:title|Major changes between ISE Eiffel 7.1 and ISE Eiffel 7.2]] +[[Property:link_title|7.2]] +[[Property:weight|11]] +[[Property:uuid|a063cc22-7638-e0cf-7d92-93aca615a283]] +==What's new== +* Added support for parsing Eiffel classes located in Unicode path. + +==Improvements== +* Better error messages for VBAC(3), VBAR(2), VUTA(2) and VD80. +* Fixed latency issues regarding SCOOP client and supplier processor. + +==Changes== +N/A + +==Bug fixes== + +===Language issues=== +N/A + +===Compiler issues=== +* Fixed bug#18309: Refreezing system with no changes causes all C compilations to be redone. +* Fixed eweasel test#valid278 and test#term188 (bug#18281 and bug#1984) by ensuring that the type used in the objectless call is full valid. + +===SCOOP issues=== +* Fixed eweasel test#scoop027 to ensure lock passing detection when logging on a chain creator during creation of a new processor. + +===Runtime/code generation issues=== +* Fixed bug#18299 and eweasel test#exec351 where copying nested expanded would cause a memory corruption. +* Fixed eweasel test#thread024 where mutltithreaded projects could crash during a GC cycle. +* Fixed an issue with EIF_INITIALIZE_AUX_THREAD that would not work properly in workbench mode because it forgot to initialize the interpreter side by calling `xinitint'. +* Fixed a bug during debugging that causes a GC corruption due to the insertion of expanded objects located on the stack in the hector stack which is not allowed. + + +===Store/Retrieve issues=== +N/A + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-reference/compiler/compiler-history/major-changes-between-ise-eiffel-72-and-ise-eiffel-73.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-reference/compiler/compiler-history/major-changes-between-ise-eiffel-72-and-ise-eiffel-73.wiki new file mode 100644 index 00000000..5c289caf --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-reference/compiler/compiler-history/major-changes-between-ise-eiffel-72-and-ise-eiffel-73.wiki @@ -0,0 +1,36 @@ +[[Property:title|Major changes between ISE Eiffel 7.2 and ISE Eiffel 7.3]] +[[Property:link_title|7.3]] +[[Property:weight|10]] +[[Property:uuid|84a0a02d-b9cc-9897-c1d9-41dfc27c294a]] +==What's new== +* Added support for agents with targets of separate types. +* Added new levels of void-safety: "conformance" that enables taking attachment marks into account when checking for conformance; "transitional" (previously "all") that checks almost all void-safety rules except those for unqualified agents and allows CAPs for preconditions and check instructions; "all" that checks all void-safety rules. + +==Improvements== +* Fixed issue that causes many classes to be recompiled when not needed. +* Relaxed rules for using Current and unqualified agents when not all attributes are set to report VEVI errors only when qualified calls are involved in a sequence of unqualified calls and creation procedure calls ("targeted rules"). + +==Changes== +* The BIT type has been completely removed from libraries and runtime. + +==Bug fixes== + +===Language issues=== +N/A + +===Compiler issues=== +* Fixed error in processing replicated and selected attributes with self-initializing attribute bodies that could lead to reporting these attributes as uninitialized. +* Fixed a bug that might result in a missing VEVI error for Result in a self-initializing attribute body. + +===SCOOP issues=== +* Fixed a bug that caused incorrect conformance checks for formal generics of different separate status. +* Fixed a bug that might cause incorrect conformance checks for attachment and separateness status of a constrained formal generic parameter against a class type. +* Fixed a C code generation bug that might cause an access on an invalid address during object test evaluation with an expression of a separate type. + +===Runtime/code generation issues=== +* Fixed a bug where the TYPE instance of a new generic derivation in the running system would be corrupted. + +===Store/Retrieve issues=== +* Fixed a bug in .NET where using the Eiffel serialization or marking objects would trigger computation of `hash_code` on Eiffel objects and thus changing their state. + + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-reference/compiler/compiler-history/major-changes-between-ise-eiffel-73-and-ise-eiffel-1311.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-reference/compiler/compiler-history/major-changes-between-ise-eiffel-73-and-ise-eiffel-1311.wiki new file mode 100644 index 00000000..581555d7 --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-reference/compiler/compiler-history/major-changes-between-ise-eiffel-73-and-ise-eiffel-1311.wiki @@ -0,0 +1,43 @@ +[[Property:title|Major changes between ISE Eiffel 7.3 and ISE Eiffel 13.11]] +[[Property:link_title|13.11]] +[[Property:weight|9]] +[[Property:uuid|e32947f4-928c-816e-1dbd-4aa53030e8c7]] +==What's new== +* Supported parenthesis aliases that allow treating feature calls with arguments on entities that take no arguments to look like regular feature calls. This is mostly useful to make calls on agent objects, e.g. instead of my_agent.call (x) it may be possible to use my_agent (x). Unlike bracket alias, parenthesis alias can be used with both queries and commands, but as with bracket alias, the corresponding feature should have at least one argument. +* Supported new rules to handle actual arguments in a feature call that wrap last arguments into a tuple when: +** the number of actual arguments exceeds the number of formal arguments +** the number of actual arguments is equal to the number of formal arguments, but the last actual argument is not type-compatible with the last formal argument unless wrapped in a tuple. +:: This is mostly useful to make calls on agent objects avoiding explicit manifest tuple notation. For example, my_agent.call ([123, "abc", value]) can be written as my_agent.call (123, "abc", value), or, when combined with parenthesis alias, as my_agent (123, "abc", value). +* Supported conditional expressions that allow using different expressions to compute a value depending on some condition: if x < y and x < z then x elseif y < z then y else z end. +* ECF redirection support to provide a way to create redirection from a .ECF to another. +* Added VD89 warnings to highlight library dependency cycles. + +==Improvements== +* Added support for Sun C compiler on Linux for RHEL, OL and Ubuntu 8.04. Other Linux distributions are not supported. +* Speed up SCOOP by an average of 35% up to 500% on some benchmarks: +** Added various optimizations to reduce massive latency over call logging and waiting due to overhead from operating system synchronization primitives and scoop call cleanup. Improved lock passing client supplier synchronization speed by a factor of 60 due to removing latency from condition variable use. + +==Changes== + +==Bug fixes== + +===Language issues=== +* Fixed bug#18643 (test#attach107, test#attach102) - Fixed a bug that may lead to unreported VEVI errors for attributes not properly set by a creation procedure when compiled in complete void-safety mode (rev#92835). +* Fixed bug#18266 (test#svalid031) - Fixed a bug that caused reporting a non-existent error for a renamed feature with a bracket alias. +* Fixed bug#18282 (test#multicon062) - Fixed a bug that caused incorrect error report for features with a bracket alias specified in multiple formal generic constraints. + +===Compiler issues=== +* Fixed a crash when converting old Ace files to new ECF format. (bug#18642 and bug#18628, rev#92820) +* Fixed bug#15591 (test#attach106), bug#17302 (test#valid270) - Fixed an erroneous reporting of VUOT for object test locals when right-hand side of a binary expression using these locals has a validity error (rev#92769). +* Fixed test#attach108 - Corrected computation of scopes of read-only variables used in implicative expressions with conjuctions. + +===SCOOP issues=== +* Fixed a crash when a separate detachable argument is Void (test#scoop035). +* Fixed lock passing creation of separate processor from non root processors. +* Fixed uncontrolled detection to iterate parent request chains. Prior to this a new chain would be created even though the processor was controlled in a parent routine, leading to inevitable deadlock. + +===Runtime/code generation issues=== + +===Store/Retrieve issues=== + + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-reference/compiler/differences-between-etl-2nd-printing-and-eiffel-software-implementation.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-reference/compiler/differences-between-etl-2nd-printing-and-eiffel-software-implementation.wiki new file mode 100644 index 00000000..244c600e --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-reference/compiler/differences-between-etl-2nd-printing-and-eiffel-software-implementation.wiki @@ -0,0 +1,95 @@ +[[Property:title|Differences between ETL 2nd printing and Eiffel Software implementation]] +[[Property:link_title|ETL 2nd printing vs implementation]] +[[Property:weight|-9]] +[[Property:uuid|fc1e73f4-5646-aa41-e7fe-97dc6f3ceb04]] +{{seealso|See also: [[Differences between standard ECMA-367 and Eiffel Software implementation|Differences between standard ECMA-367 and Eiffel Software implementation]] }} + +"ETL 2nd printing" refers to the book "Eiffel: The Language" (2nd printing), published by Prentice Hall. + +==Added classes== +* New basic classes have been added: INTEGER_8, INTEGER_16, INTEGER_64 and WIDE_CHARACTER.{{seealso|[[Differences between standard ECMA-367 and Eiffel Software implementation|Differences between standard ECMA-367 and Eiffel Software implementation]] }} + +==Added classes== +* New basic classes have been added: INTEGER_8, INTEGER_16, INTEGER_64 and WIDE_CHARACTER. INTEGER is now specified as having a 32 bits representation +* New TUPLE, ROUTINE, PROCEDURE and FUNCTION classes required by the agent mechanism. + +==Added keywords== +* Precursor +* reference: new keyword to specify that a type is used as a reference type. +* agent: new keyword used by the agent mechanism. +* create: Instead of using the famous exclamation mark to create an instance of a class, you can use the keyword create. Below you will find a correspondence table between the old and the new syntaxes. The old syntax is still valid, but at some points Eiffel Software will remove it from its implementation: +{| +|- +| Old syntax +| New syntax +|- +| !! a +| create a +|- +| !! a.make +| create a.make +|- +| !B! a +| create {B} a +|- +| !B! a.make +| create {B} a.make +|} +* note: replacement for the keyword indexing. +* attribute: new keyword to declare attribute body. +* attached: new keyword to specify attached types and object tests. +* detachable: new keyword to specify detachable types. + + +==Added semantics== +* [[ET: Genericity and Arrays|Generic creation]] +* Expression creation: you can now create an object within an expression. For example, you want to create an object and pass it as an argument to a function. Whereas you had to create a local variable, create the object and pass it to the function, you now simply need to pass to the function the creation expression. Here is a small example: +{| +|- +| Old method +| New method +|- +| + +local + a: STRING +do + !! a.make (10) + f (a) +end + + +| + +do + f (create {STRING}.make (10)) +end + + +|} +This is also very useful since it can improve the power of assertions. +* Mutually recursive constraints: one can now write class A [H, G->H] or class B [H -> C, G -> ARRAY [H]]. As a result, the declaration A [D, E] is valid only if E is a descendant of D. Similarly, the declaration B [E, ARRAY [D]] is not valid, if E is a descendant of D. +* [[ET: Other Mechanisms|Tuples]] +* [[ET: Agents|Agents]] +* Feature access:
+ +local + value: INTEGER +do + value := {MY_CLASS}.value +end + +
+The previous call is valid, if and only if: +** value is a feature representing a constant of a basic type (INTEGER, DOUBLE or CHARACTER) +** value is a C/C++/DLL external feature +** value is an IL static external feature + + +==Added external support== + +Look at the page for [[C externals|C]] and [[C++ Externals|C++]] with the introduction of `struct` and C++ external features encapsulation. + + + + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-reference/compiler/differences-between-standard-ecma-367-and-eiffel-software-implementation.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-reference/compiler/differences-between-standard-ecma-367-and-eiffel-software-implementation.wiki new file mode 100644 index 00000000..5928c143 --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-reference/compiler/differences-between-standard-ecma-367-and-eiffel-software-implementation.wiki @@ -0,0 +1,381 @@ +[[Property:title|Differences between standard ECMA-367 and Eiffel Software implementation]] +[[Property:link_title|ECMA-367 vs implementation]] +[[Property:weight|-10]] +[[Property:uuid|0eb58761-5b06-585f-ea92-cab2b8cd74b2]] +"ETL 2" refers to the book "Eiffel: The Language" (2nd printing), published by Prentice Hall. + +==Kernel classes== +{| class="doctable" +|- +!
'''Feature'''
+!
'''Example'''
+!
'''ETL2'''
+!
'''ECMA-367'''
+!
'''EiffelStudio'''
+|- +| Fictitious class for tuples +| TUPLE +| No +| Yes +| Yes +|} + +==Features== +{| class="doctable" +|- +!
'''Feature'''
+!
'''Example'''
+!
'''ETL2'''
+!
'''ECMA-367'''
+!
'''EiffelStudio'''
+|- +| Prefix and infix feature names +| infix "+" +| Yes +| No +| Yes, marked as obsolete +|- +| Operator and bracket aliases +| add alias "+" +| No +| Yes +| Yes, except for new rules +for free operator names +|- +| Assigner command +| item alias "[]" (index: INTEGER): G assign put +| No +| Yes +| Yes +|} + +==Design by Contract== +{| class="doctable" +|- +!
'''Feature'''
+!
'''Example'''
+!
'''ETL2'''
+!
'''ECMA-367'''
+!
'''EiffelStudio'''
+|- +| Only postcondition clauses +| ensure only a, b +| No +| Yes +| No +|} + +==Genericity== +{| class="doctable" +|- +!
'''Feature'''
+!
'''Example'''
+!
'''ETL2'''
+!
'''ECMA-367'''
+!
'''EiffelStudio'''
+|- +| Mutually recursive constraints +| A [H, G -> H]
+B [H -> C, G -> ARRAY [H]] +| No +| Yes +| Yes +|- +| Full mutually recursive constraints +| A [H -> G, G -> H]
+ +| No +| Yes +| Yes +|- +| Expandedness restriction on formal generic +| A [reference G]
+B [expanded H] +| No +| No +| Yes +|} + +==Creating objects== +{| class="doctable" +|- +!
'''Feature'''
+!
'''Example'''
+!
'''ETL2'''
+!
'''ECMA-367'''
+!
'''EiffelStudio'''
+|- +| Implicit creation procedure (version of +ANY.default_create) +| class A feature ... end
+-- The following instructions are equivalent:
+create {A} a
+create {A} a.default_create +| No +| Yes +| Yes +|- +| Bang-bang syntax +| !! a
+!! a.make
+!B! a
+!B! a.make +| Yes +| No +| Yes, marked as obsolete +|- +| Keyword syntax +| create a
+create a.make
+create {B} a
+create {B} a.make +| No +| Yes +| Yes +|- +| Creation expression +| print (create {TIME}.make_now) +| No +| Yes +| Yes +|- +| [[ET: Genericity and Arrays|Generic creation]] +| create {G} x.make +| No +| Yes +| Yes +|} + +==Attachment== +{| class="doctable" +|- +!
'''Feature'''
+!
'''Example'''
+!
'''ETL2'''
+!
'''ECMA-367'''
+!
'''EiffelStudio'''
+|- +| Preserving expandedness status +when attaching expanded object +to reference entity +| x := y +| No, object is copied to new +object of the corresponding +reference type +| Yes +| Yes, except for TYPED_POINTER +that is converted to POINTER before +reattachment +|- +| Reverse assignment (assignment attempt) +| x ?= y +| Yes +| No +| Yes. Marked as obsolete (V7.1). +|} + +==Feature calls== +{| class="doctable" +|- +!
'''Feature'''
+!
'''Example'''
+!
'''ETL2'''
+!
'''ECMA-367'''
+!
'''EiffelStudio'''
+|- +| Precursor call +| Precursor +| No +| Yes +| Yes +|- +| Non-object call +| c := {COLOR}.green +| No +| Yes +| Yes +|- +| Assigner call +| x [i] := x [i] + 1 +| No +| Yes +| Yes +|- +| Bracket expression as call target +| x [i].update +| No +| No +| Yes +|} + +==Void-safety== +{| class="doctable" +|- +!
'''Feature'''
+!
'''Example'''
+!
'''ETL2'''
+!
'''ECMA-367'''
+!
'''EiffelStudio'''
+|- +| Attachment marks +| a: attached ANY
+b: detachable ANY +| No +| Yes, attached by default +| Yes, attached by default +|- +| Object test +| attached {STRING} e as o +| No +| Yes +| Yes +|- +| Attached target of a call +| x.f +| No +| Yes +| Yes, by option ''void_safety'' +|- +| Properly set variable +| x := value
+use (x) +| No +| Yes +| Yes, by option ''void_safety'' +|} + +==[[Concurrent programming with SCOOP|SCOOP]]== +{| class="doctable" +|- +!
'''Feature'''
+! width="160pt"|
'''Example'''
+!
'''ETL2'''
+!
'''ECMA-367'''
+!
'''EiffelStudio'''
+|- +| Separate declaration +| a: separate ANY +| No +| No. separate reserved but not used +| Yes. Object attached to a may be handled by different SCOOP processor. +|} + +==Expressions== +{| class="doctable" +|- +!
'''Feature'''
+!
'''Example'''
+!
'''ETL2'''
+!
'''ECMA-367'''
+!
'''EiffelStudio'''
+|- +| Bracket expression +| y := x [i] +| No +| Yes +| Yes +|- +| Creation expression +| set_buffer (create {STRING}.make (100)) +| No +| Yes +| Yes +|- +| Manifest type +| {MY_TYPE} +| No +| Yes +| Yes +|- +| Manifest [[ET: Other Mechanisms|tuple]] +| [a, b, c] +| No +| Yes +| Yes +|- +| [[ET: Agents|Agent]] +| list.do_all (agent print (?)) +| No +| Yes +| Yes +|- +| Once manifest string +| once "abc" +| No +| Yes +| Yes +|} + +==Constants== +{| class="doctable" +|- +!
'''Feature'''
+!
'''Example'''
+!
'''ETL2'''
+!
'''ECMA-367'''
+!
'''EiffelStudio'''
+|- +| Verbatim string +| +x := "[ + This string is left-adjusted. +]" +y := "{ + This string is used "as is". +}" + +| No +| Yes +| Yes +|- +| Manifest type qualifier +| {INTEGER_8} 123 +| No +| Yes +| Yes +|- +| Non-decimal integer +| 0xFF +| No +| Yes +| Yes +|- +| Integer with intermediate underscores +| 1_000 0xFFFF_0000 +| In groups by 3 digits +| Yes +| Yes +|} + +==Interfacing with external software== +{| class="doctable" +|- +!
'''Feature'''
+!
'''ETL2'''
+!
'''ECMA-367'''
+!
'''EiffelStudio'''
+|- +| Access to software written in C +| Basic syntax for any external software +| Registered sub-language +| See details for [[C externals|C externals]]. +|- +| Access to software written in C++ +| Basic syntax for any external software +| Registered sub-language +| See details for [[C++ Externals|C++ externals]]. +|- +| Access to dynamically loaded libraries (DLLs) +| Basic syntax for any external software +| Registered sub-language +| See details for [[uuid:4ad177dd-13ec-c237-99b3-efc9851995a5|Interfacing with DLLs]]. +|- +| Other external software +| Basic syntax for any external software +| Unregistered sub-language +| No +|} + + + + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-reference/compiler/dynamic-library-generation/definition-file.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-reference/compiler/dynamic-library-generation/definition-file.wiki new file mode 100644 index 00000000..295c37b2 --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-reference/compiler/dynamic-library-generation/definition-file.wiki @@ -0,0 +1,64 @@ +[[Property:title|Definition file]] +[[Property:weight|2]] +[[Property:uuid|3a4b017c-ede1-7af1-2934-c7a28b303764]] +The syntax is pretty simple when you understand what you need to export a feature: you need the name of the '''feature''', the name of the concerned '''class''', and the name of a '''creation procedure'''. What is optional is to specify an '''alias''', an '''index''' and a '''calling convention'''. The index and calling convention are mainly used to create a DLL for windows, and the alias to export the feature under a different name. + +===Syntax=== + +{| border="1" +|- +| '''Export_feature''' +| Class_name [Creation_part] ":" Feature [Optional_part] +|- +| '''Creation_part''' +| "(" feature_name ")" +|- +| '''Optional_part''' +| [Index_part] [Alias_part] +|- +| '''Index_part''' +| "@" integer +|- +| '''Alias_part''' +| "Alias" alias_name +|- +| '''Call_type_part''' +| "call_type" call_type_name +|} + + +===Example=== + + +ROOT_CLASS (make): foo @ 4 Alias my_foo call_type __stdcall + +===Constraints=== +; on the class: The class cannot be deferred or generic. +; on the feature: It could be any feature except an attribute, an external feature or a deferred feature. +; on the creation procedure: It must have zero argument, and no return type. +; on the alias name: It must be a valid name for a C function. +; on the index: It must be strictly positive. +; on the call type: It must be a valid call type for the targeted platform (useful for Windows only). For Visual C++, the valid calling conventions are __stdcall, __cdecl and __fastcall. + +For each feature the required fields are the '''class''', the '''creation procedure''', and of course the '''feature''' itself. +* If the feature is a creation procedure then do not specify any creation, it will use the feature as creation. For example '''ROOT_CLASS: make'''. +* If the class has no creation procedure, do not specify any creation. default_create will be automatically used. + +===A definition file=== + + +-- EXPORTED FEATURE(s) OF THE SHARED LIBRARY +-- SYSTEM : demo + +-- CLASS [BAR] +-- Here get_string uses make_b as creation +BAR (make_b) : get_string +-- Here print_bar uses make_a as creation +BAR (make_a) : print_bar + +-- CLASS [ROOT_CLASS] +-- Here the feature is also a creation +ROOT_CLASS : make +ROOT_CLASS (make) : foo +ROOT_CLASS (make) : test_bar + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-reference/compiler/dynamic-library-generation/dynamic-library-builder.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-reference/compiler/dynamic-library-generation/dynamic-library-builder.wiki new file mode 100644 index 00000000..806039ac --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-reference/compiler/dynamic-library-generation/dynamic-library-builder.wiki @@ -0,0 +1,30 @@ +[[Property:title|Dynamic library builder]] +[[Property:weight|1]] +[[Property:uuid|e64cdcf2-6da1-98d5-8356-28b50d01374b]] +In order to facilitate the creation of C dynamic libraries using EiffelStudio, a wizard helps generate the definition files used to define the contents of the shared library. If for some reason you need to override the wizard, the [[Definition file|syntactic rules]] of the definition files are available, but their knowledge is not necessary to use the generation of dynamic libraries in EiffelStudio. + +The wizard is accessible in the '''Tools'''/ '''Dynamic library builder''' menu. + +The dynamic library window that appears when selecting this menu is mainly composed of a list which contains all features that should be exported. This list is course empty at first. + +[[Image:shared-library-window]] + +{{note|The layout of this wizard is slightly different on Windows and on Unix systems, because the index and calling convention fields never appear on Unix systems. }} + +To add a new feature to the definition file, you can either: +* Pick the feature from any place in EiffelStudio and drop it into the list. If several creation procedures exists in the container class, a dialog is popped up to give the choice between all possible creation procedures. +* Or, use the Add command [[Image:16x16--general-add-icon]] in the '''Edit'''/ '''Add''' menu. This pops up a dialog where it is possible to enter manually all parameters for the exported feature. + +[[Image:new-exported-feature]] + +Other commands of the '''Edit''' menu allow you to remove [[Image:16x16--general-delete-icon]] exported features or to modify their export parameters [[Image:16x16--general-edit-icon]] . + +It is also possible to check the validity of the definition file. This command [[Image:view-unmodified-icon]] performs both a global check, to ensure that for example two features do not have the same name or same index in the library, and also local checks, that check for each feature that the parameters are valid. + +Other commands, located in the '''File''' menu, give standard file operations, such as opening [[Image:general-open-icon]] a definition file, creating a new definition file [[Image:new-document-icon]] ,or saving the current definition file [[Image:16x16--general-save-icon]] . + +{{tip|Although the wizard can handle several files during the same EiffelStudio session, remember that only one file can be used in the project settings to effectively generate a shared library. }} + + + + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-reference/compiler/dynamic-library-generation/dynamic-library-generated-files.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-reference/compiler/dynamic-library-generation/dynamic-library-generated-files.wiki new file mode 100644 index 00000000..cfa8f7c1 --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-reference/compiler/dynamic-library-generation/dynamic-library-generated-files.wiki @@ -0,0 +1,47 @@ +[[Property:title|Dynamic library: Generated files]] +[[Property:weight|3]] +[[Property:uuid|f3926dd7-eb68-7a82-39f0-b4f5ea891436]] +Once the Eiffel definition file is created, the compiler will generate a set of files and will compile them to generate the Dynamic library into the EIFGENs/target_name/W_code or EIFGENs/target_name/F_code directory. + +{{note|To generate and compile these files, you have to indicate the definition file that should be used in the [[Advanced Options|advanced node of the project settings]] of your system. This way EiffelStudio will know which one to use. If you do not specify any definition file, nothing will be generated. }} + +The set of files is composed of: +* EIFGENs/target_name/W_code/'''system.def''' (or F_code) +* EIFGENs/target_name/W_code/'''edynlib.c''' (or F_code) +* $(ISE_EIFFEL)/studio/config/$(ISE_PLATFORM)/templates/'''egc_dynlib.template'''
+this file will be copied during the compilation into the EIFGENs/target_name/W_code/E1 directory as '''egc_dynlib.c''' +* $(ISE_EIFFEL)/studio/spec/$(ISE_PLATFORM)/include/'''egc_dynlib.h''' +* and the Makefile + +The ''system.def'' is only used on windows, it is the definition file used to generate a DLL when linking.
+Information about the DLL +LIBRARY demo.dll +DESCRIPTION DEMO.DLL +The following are EXPORTed functions. + +EXPORTS +This part concerns the run-time. It initializes the run-time and reclaim Eiffel objects. + +;System + init_rt + reclaim_rt + +The exported for the BAR class: +; CLASS [BAR] + get_string + print_bar + +The exported for the ROOT_CLASS class: +; CLASS [ROOT_CLASS] + make + foo + test_bar + + +The ''edynlib.c'' file is the interface between the Eiffel system and the C code. It contains the declaration and the implementation of the function used to directly call the eiffel feature with its real name. + +The ''egc_dynlib.c'' and ''egc_dynlib.h'' files are used for operations performed by the run-time. + + + + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-reference/compiler/dynamic-library-generation/index.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-reference/compiler/dynamic-library-generation/index.wiki new file mode 100644 index 00000000..9956da8d --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-reference/compiler/dynamic-library-generation/index.wiki @@ -0,0 +1,13 @@ +[[Property:title|Dynamic library generation]] +[[Property:weight|-12]] +[[Property:uuid|201551d5-84af-f1ee-deed-b599d4f6e64a]] +The Eiffel compiler offers the possibility to generate a '''dynamic shared library''' based on the system. + +Thanks to this dynamic library, it is possible to call Eiffel features from a C program, by using the real names of the features. + +In other words, the user can generate a DLL ''(*.dll)'' using features of the system on windows, and/or a shared library ''(*.so)'' on Unix. + +For that, the user has first to describe what he wants to export in his dynamic library. This is done via a definition file ''(*.def)'', which specifies what features should be exported. A [[Dynamic library builder|wizard]] helps build the definition file, which makes this step very intuitive. The second step is to select the definition file in the [[Advanced Options|project settings]] to take this definition file into account. This done, the next compilation of the system will yield [[Dynamic library: Generated files|C files]] that can be used to create the shared library. + + + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-reference/compiler/index.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-reference/compiler/index.wiki new file mode 100644 index 00000000..ee33493e --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-reference/compiler/index.wiki @@ -0,0 +1,10 @@ +[[Property:title|Compiler]] +[[Property:weight|-9]] +[[Property:uuid|6ce8a6e1-5f44-8c47-fcf0-549d1ea0ffaf]] +EiffelStudio naturally includes a powerful Eiffel compiler, which is at the core of the IDE. It supports the entire Eiffel programming language as defined in the third edition of ''Eiffel: The Language''. + +This compiler uses Eiffel's Melting Ice Technology (TM), which accounts for lightning-fast incremental recompilations, ideal during the development cycle. It also provides finalization, which yields a high level of optimization that should be used for released programs. + + + + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-reference/compiler/melting-ice-technology.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-reference/compiler/melting-ice-technology.wiki new file mode 100644 index 00000000..5d7ac5d9 --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-reference/compiler/melting-ice-technology.wiki @@ -0,0 +1,34 @@ +[[Property:title|Melting Ice Technology]] +[[Property:weight|-15]] +[[Property:uuid|17c5cf39-2bb3-67e4-11e3-2b6d021e5df1]] +=Types of compilation provided by Melting Ice= + +EiffelStudio relies on Melting Ice Technology, the proprietary compilation mechanism of Eiffel Software, which offers three forms of compilation: '''melting''', '''freezing''', and '''finalizing'''. + +==Melting== + +Melting is used for making a few changes during typical development activity. The fastest of the mechanisms, typically taking a few seconds after small changes. Melting time is proportional to the size of the changed parts and affected classes, while the time needed to freeze or finalize is partly proportional to the size of the whole system. As long as you do not include new external C/C++ code, a C/C++ compiler is not required. However, execution speed is not optimal. The generated executable is debuggable. + +==Freezing== + +Freezing generates C code from the active system, and then compiles it into machine code; you must have a C/C++ compiler installed. You need to use this option if you add new agents or external C/C++ calls. Unless you add external code, you can re-freeze every couple of days. The rest of the time, you can melt your software to receive immediate feedback. The speed is still slower than when finalizing, but the generated executable is still debuggable. + +==Finalizing== + +Finalizing delivers a production version (intermediate or final) of your software. It can be used to measure its performance in operational conditions. Finalization performs extensive time and space optimizations that enable Eiffel to match the efficiency of C/C++; it also creates a stand-alone C package that you can use for cross-platform development. Because of all the optimizations involved, finalizing takes the most time, and the generated executable is not debuggable. + +==Precompiling== + +Precompilation allows you to create a library in which the classes are already compiled, so when it is used, compile times are decreased. EiffelStudio comes with optional precompiled forms of commonly used libraries. For example, in the Microsoft Windows distribution you can opt for precompiled EiffelBase, or WEL + EiffelBase, or EiffelVision 2 + WEL + EiffelBase. As indicated by these options, the precompilation of a library must also include any other library upon which the target library depends. In other words, it would not be possible to precompile EiffelVision 2 without also including WEL and EiffelBase, too. + +=Additional detail= + +Melting and freezing generate an executable in the EIFGENs|target_name|W_code subdirectory of the project directory. The executable is composed of a standard executable file named after the system, and of a < ''system name''>.melted file, which is called the Eiffel update file. Although it is recommended to finalize the system when running it from outside EiffelStudio (since the performance is better), it is possible to launch a melted/frozen executable. However, the Eiffel update file is necessary, the executable alone will not run. + +Basically, the Eiffel update file incorporates the changes that have been made to the system since it was last frozen. Therefore, it is very small when the system has just been frozen, and progressively becomes bigger each time the system is melted. On the contrary, the executable is only modified when the system is frozen, never when it is melted. + +The contents of the Eiffel update file are in a byte code representation which is dynamically interpreted at run-time. + + + + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-reference/compiler/supported-c-compilers.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-reference/compiler/supported-c-compilers.wiki new file mode 100644 index 00000000..43552ada --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-reference/compiler/supported-c-compilers.wiki @@ -0,0 +1,58 @@ +[[Property:title|Supported C compilers]] +[[Property:weight|-14]] +[[Property:uuid|4d4a70fa-b6da-cecb-83e0-dcc18d6ed54a]] +==Unix/Linux Users:== + +EiffelStudio supports `gcc` on most platforms and the native `cc` compiler if it is an ANSI C compiler. + + +==Microsoft Windows Users== + +EiffelStudio supports Microsoft and MinGW compilers on Microsoft Windows. + +===Microsoft Visual C++ Users=== + +EiffelStudio supports versions 10.0 and higher of the Microsoft Visual Studio C++ environment. This is available in Visual Studio 2010 or higher revision, or in version of the Windows SDK 7.1 or higher. + +EiffelStudio will automatically detect the location of the C compiler. + +By default the installation program will set in the registry keys the ISE_C_COMPILER key to `msc` (for versions 12.0 and below) or `msc_vc140` (for Visual Studio C++ 2015 and later.) + +===MinGW Users=== + +By default the installation program will set in the registry keys the ISE_C_COMPILER key to `mingw`. + +In versions as late as 6.6, there is a [[EiffelCOM Wizard Guided Tour|restriction]] that prevents the use of EiffelCOM with the MinGW compiler. + +===Changing your C compiler on Windows=== + +You can do it in either of two different ways. + +You can manually edit the registry key HKLM\Software\ISE\EiffelNN and change the value of the ISE_C_COMPILER string key to either `msc` (`msc_vc140`) or `mingw` depending upon the effect you desire. + +Alternatively, you can set the environment variable ISE_C_COMPILER to either `msc` (`msc_vc140`) or `mingw`. + +{| style="width: auto; margin: 0 auto;" +|+ Reference information about supported C compilers on Windows +! Compiler +! Value of ISE_C_COMPILER +|- +| MinGW +| `mingw` +|- +| Microsoft Visual Studio C++ 2010 (v10.0) +| `msc` +|- +| Microsoft Visual Studio C++ 2012 (v11.0) +| `msc` +|- +| Microsoft Visual Studio C++ 2013 (v12.0) +| `msc` +|- +| Microsoft Visual Studio C++ 2015 (v14.0) +| `msc_vc140` +|- +| Microsoft Visual Studio C++ 2017 (v15.0) +| `msc_vc140` +|- +|} diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-reference/compiler/syntax-level-variant-settings-version.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-reference/compiler/syntax-level-variant-settings-version.wiki new file mode 100644 index 00000000..e454db3f --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-reference/compiler/syntax-level-variant-settings-version.wiki @@ -0,0 +1,140 @@ +[[Property:title|Syntax level variant settings by version]] +[[Property:weight|-11]] +[[Property:uuid|aa52a183-c616-4590-5e7e-f9b9e2a71f14]] +The Eiffel Software compiler provides a set of options, available in [[General Target Options|Project Settings]], which allows users to [[Setting the syntax variant|select a variant of the Eiffel programming language syntax]] that best suits their needs. The meanings of these options, and in fact the options themselves, are subject to change from one version to the next. Below you will find a table that defines the meaning of the syntax level variants for each version. + +The options are distinguished by how the compiler handles the processing of certain words found in Eiffel text which may be: +# Associated with language constructs, or +# Allowed as identifiers, or +# In the case of some options as either keywords or identifiers depending upon the context in which the words are found. + + +{| border="1" style="border-collapse: collapse; border-style: solid;" +|+ '''Legend''' +| style="color: navy;" | '''keyword''' +| Accepted as a keyword +|- +| style="color: blue;" | '''keyword''' +| Accepted as a keyword with a warning +|- +| style="color: maroon;" | '''keyword''' +| Accepted as a keyword or if grammar permits as an identifier with a warning +|- +| style="color: gray;" | name +| Accepted as an identifier with a warning +|- +| style="color: black;" | name +| Accepted as an identifier +|} + + + +{| border="1" style="width: 100%; border-collapse: collapse; border-style: solid;" +|+ '''Constructs affected by the ''syntax'' project setting''' +|- +! rowspan="2" style="text-align: center; valign: center;" | Release +! colspan="4" style="text-align: center;" | Setting value* +|- +! Obsolete +! Transitional +! Standard +! Provisional +|- +! rowspan="9" style="valign: center; text-align: center;" | [[Release notes for EiffelStudio 7.0 | 7.0]] and [[EiffelStudio release notes | more recent]] + +| style="color: gray;" | across +| style="color: maroon;" | '''across''' +| style="color: navy;" | '''across''' +| style="color: navy;" | '''across''' +|- +| style="color: maroon;" | '''assign''' +| style="color: maroon;" | '''assign''' +| style="color: navy;" | '''assign''' +| style="color: navy;" | '''assign''' +|- +| style="color: gray;" | attached +| style="color: maroon;" | '''attached''' +| style="color: navy;" | '''attached''' +| style="color: navy;" | '''attached''' +|- +| style="color: gray;" | attribute +| style="color: maroon;" | '''attribute''' +| style="color: navy;" | '''attribute''' +| style="color: navy;" | '''attribute''' +|- +| style="color: gray;" | detachable +| style="color: maroon;" | '''detachable''' +| style="color: navy;" | '''detachable''' +| style="color: navy;" | '''detachable''' +|- +| style="color: navy;" | '''indexing''' +| style="color: blue;" | '''indexing''' +| style="color: black;" | indexing +| style="color: black;" | indexing +|- +| style="color: navy;" | '''is''' +| style="color: blue;" | '''is''' +| style="color: black;" | is +| style="color: black;" | is +|- +| style="color: gray;" | note +| style="color: navy;" | '''note''' +| style="color: navy;" | '''note''' +| style="color: navy;" | '''note''' +|- +| style="color: gray;" | some +| style="color: maroon;" | '''some''' +| style="color: navy;" | '''some''' +| style="color: navy;" | '''some''' +|- style="border-top: 4px solid gray;" +! rowspan="9" style="valign: center; text-align: center;" | [[Release notes for EiffelStudio 6.8 | 6.8]], [[Release notes for EiffelStudio 6.7 | 6.7]], [[Release notes for EiffelStudio 6.6 | 6.6]] +| style="color: gray;" | across +| style="color: gray;" | across +| style="color: gray;" | across +| style="color: maroon;" | '''across''' +|- +| style="color: maroon;" | '''assign''' +| style="color: maroon;" | '''assign''' +| style="color: navy;" | '''assign''' +| style="color: maroon;" | '''assign''' +|- +| style="color: gray;" | attached +| style="color: maroon;" | '''attached''' +| style="color: navy;" | '''attached''' +| style="color: maroon;" | '''attached''' +|- +| style="color: gray;" | attribute +| style="color: maroon;" | '''attribute''' +| style="color: navy;" | '''attribute''' +| style="color: maroon;" | '''attribute''' +|- +| style="color: gray;" | detachable +| style="color: maroon;" | '''detachable''' +| style="color: navy;" | '''detachable''' +| style="color: maroon;" | '''detachable''' +|- +| style="color: navy;" | '''indexing''' +| style="color: blue;" | '''indexing''' +| style="color: black;" | indexing +| style="color: black;" | indexing +|- +| style="color: navy;" | '''is''' +| style="color: blue;" | '''is''' +| style="color: black;" | is +| style="color: black;" | is +|- +| style="color: gray;" | note +| style="color: navy;" | '''note''' +| style="color: navy;" | '''note''' +| style="color: navy;" | '''note''' +|- +| style="color: gray;" | some +| style="color: gray;" | some +| style="color: gray;" | some +| style="color: maroon;" | '''some''' +|} + + +* A general explanation of what each variant setting means can be found in the section on [[Setting the syntax variant|setting the syntax variant.]] + + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-reference/console-tool.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-reference/console-tool.wiki new file mode 100644 index 00000000..72a085b7 --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-reference/console-tool.wiki @@ -0,0 +1,92 @@ +[[Property:title|Console tool]] +[[Property:weight|-4]] +[[Property:uuid|bbc24d41-ce47-662a-16c3-4426b4c6e884]] +The Console tool lets you run external commands from within EiffelStudio. The Console tool is shown in the following figure: +[[Image:console1|Defining an input domain]] + +You can type your command in the "Command" region and then press the [[Image:metrics-tool--debug-run-icon|Launch Command]] Run button to launch that command. When a command is running, you can type input data to that command in the "Input" region if necessary. And you can press the [[Image:metrics-tool--debug-stop-icon|Stop Command]] Stop button to terminate a running command. If the command uses a different locale from your default locale, you can specify the desired locale in the "Locale" region where all supported locales are listed. The selected locale will be used for both the input and output of the command. After the command has exited, its return value will be displayed at the bottom line. + +==Placeholders== + +In the "Command" region, the following placeholders can be used: +* $class_name: this will be replaced by the name in lower case of the targeted class in editor +* $directory_name: this will be replaced by the directory location of the targeted class in editor +* $file: this will be replaced by file name part, i.e., without heading directory path ($directory_name) of the targeted class in editor +* $file_name: this will be replaced by the fully specified file name ($directory_name + $file) to the targeted class in editor +* $f_code: this will be replaced by the F_code directory of current target, if defined +* $group_directory: this will be replaced by the directory of the group where targeted class in editor locates +* $group_name: this will be replaced by the group name of the targeted class in editor +* $line: this will be replaced by the line number of the cursor of the targeted class in editor +* $path: same as $file_name +* $project_directory: this will be replaced by the directory of current project, if defined +* $target_directory: this will be replaced by the directory of current target, if defined +* $target_name: this will be replaced by current target name +* $w_code: this will be replaced by the W_code directory of current target, if defined + +==Buffer support== + +Buffer is a way to refer to text of a class, a feature or text/selected text in an editor tab in external command. Three kinds of buffers are supported: +* {SOME_CLASS} represents text of SOME_CLASS +* @{SOME_CLASS} represents selected text in the opened editor tab for class SOME_CLASS +* {SOME_CLASS}.some_feature represents text of some_feature from SOME_CLASS + +For example, if you run the command: + +gvim {ANY} +then the text of class ANY will be displayed in a gvim window. + + +If you run the command: + +gvim @{ANY} +and if class ANY is opened in an editor tab and some text is selected there, the selected text will be displayed in a gvim window. + + +If you run the command: + +gvim @{ANY}.is_equal +then the text of feature is_equal from class ANY will be displayed in a gvim window. + + +If you run the command: + +gvim -d {ANY}.is_equal {APPLICATION}.is_equal +then a gvim window in diff mode will be opened showing the difference between ANY.is_equal and APPLICATION.is_equal. + + +The text used in buffer is stored in a temporary file so whatever change done to that text won't affect the text used in EiffelStudio. + + +==Auto-completion== + +The command area supports auto-completion. You can auto-complete placeholder, class name and feature name, shown in the following pictures: + +Auto-complete placeholder: + + +[[Image:console-auto1|Auto-complete placeholder]] + + +Auto-complete class name: + + +[[Image:console-auto2|Auto-complete class name]] + + +Auto-complete feature name: + + +[[Image:console-auto3|Auto-complete feature name]] + + + +==Pick and drop== + +You can also pick and drop a group/class/feature into the command area to have related name/path inserted. + +{{seealso|
+[[External commands editor dialog|External commands Editor dialog]] }} + + + + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-reference/contract-editor-tool.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-reference/contract-editor-tool.wiki new file mode 100644 index 00000000..a1538859 --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-reference/contract-editor-tool.wiki @@ -0,0 +1,137 @@ +[[Property:title|Contract Editor tool]] +[[Property:weight|-11]] +[[Property:uuid|867bcb6b-1052-b28f-bd18-243532816dfd]] + +[[Image:es ref contract editor 01|center]] + + +=Overview= + +As a rule, in EiffelStudio, class text can only be edited in the Editing tool, and then only when the Basic Text view is selected. The Contract Editing tool is an exception to this. + +The Contract Editor tool gives you the ability to examine and edit class contracts in a context that is isolated from the full class text. In other words, when you use the Contract Editor tool, you see and edit the contracts without having to work around other elements of the software text such as implementation. For routines, you can edit pre- and postconditions, and for classes, you can edit class invariants. The tool provides views of inherited contracts as well as immediate ones. + +Also included is a set of templates for creating common assertion patterns. By using these templates whenever possible, you add consistency to your class text. + +You can target the Contract Editor tool by picking a routine name or class name and dropping it into the tool. Within the Contract Editor tool window, a single contract element is shown. A contract element here means either a precondition or a postcondition for a routine, or a class invariant for a class. Each assertion clause for a particular contract element is editable individually. + +The Contract Editor tool can be helpful during analysis and design phases of development, when class specification is a primary concern. + + +=Invoking the Contract Editor tool= + +If the Contract Editor tool is not currently visible, it can be made visible by following the menu path: + + +View --> Tools --> Contract Editor + + +Once visible, the tool can be [[Customizing the tools layout and toolbars#Docking|docked]] to an appropriate location, if desired. + + +=Toolbar= + +The Contract Editor toolbar contains the following items: + +: [[Image:16x16--general-save-icon]] ''Save modifications to the associated class.'' Becomes enabled when changes have been made to a contract. Clicking will cause changes to be saved. + +: [[Image:16x16--general-add-icon]] ''Add a new contract.'' Allows you to add a new contract assertion clause to the currently selected contract element (precondition, postcondition, or invariant). Clicking will provide a choice of creating from a template or creating a custom assertion clause. + +: [[Image:metrics-tool--general-remove-icon]] ''Remove selected contract.'' Will delete the currently selected assertion clause from the contract element being edited. + +: [[Image:contract-editor-edit-icon]] ''Edit selected contract.'' Will place the currently selected assertion clause in edit mode. Clauses can also be edited by double-clicking the clause itself, or right-clicking on a selected clause and choosing "Edit". + +: [[Image:move-up-icon]] and [[Image:move-down-icon]] ''Move selected contract up (or down).'' Use to move the selected assertion clause up or down in relation to the other clauses for this contract element. + +: [[Image:refresh-icon]] ''Refresh the current contracts to include any unsaved, undetected editor changes.'' EiffelStudio updates the Contract Editor tool display whenever class text is saved. However, if you edit a class in the Editing tool and have not saved it, there will be a difference between the Editing tool's display and the Contract Editor tool's display for the edited code. Clicking this icon will update the Contract Editor tool to include unsaved changes from the Editing tool. + +: [[Image:contract-icon]] ''Select the type of contracts to edit.'' Use to select the contract element to edit. The name of the element (precondition, postcondition, or invariant) is listed to the right of the icon. If the Contract Editor tool is targeted to a routine, you can choose between Precondition and Postcondition by clicking this icon. If the tool is targeted to a class, then Invariant is selected and this icon is disabled in the toolbar. + +: [[Image:show-hide-contract-placeholders-icon]] ''Show/hide the hidden contract place holders for inherited contracts.'' In addition to the assertion clauses that are coded immediately on the target routine or class, the Contract Editor tool also shows any assertion clauses inherited from a class's proper ancestor classes. These clauses are labeled with the name of the class from which they are inherited. By default, any classes in the inheritance graph which do not contribute clauses to a contract element are not shown. Toggling this icon down will show placeholders for these classes that are in the graph but do not contribute assertion clauses. Toggling the icon up will re-hide the placeholders. + +: [[Image:feature-callers-icon]] or [[Image:class-descendents-icon]] ''Show the callers of the currently edited feature.'' The icon shown here is dependent upon whether the tool is targeted to a routine or class. If the tool is targeted to a routine, then the icon shown will be the feature callers icon ([[Image:feature-callers-icon]]). If the tool is targeted to a class, then the icon shown will be the class descendants icon ([[Image:class-descendents-icon]]). In either case, clicking the icon does not effect the display in the Contract Editor tool. Rather, the action is shown in either the Feature tool (in the case of routines) or the Class tool (in the case of classes). + + +=Editing contracts= + +You edit contracts one assertion clause at a time. When you make a selection in the Contracts column of the Contract Editor tool, an entire assertion clause will be selected. In the depiction below, the clause minute_valid is selected from the class invariant of class TIME_OF_DAY. + + +[[Image:es ref contract editor 02]] + + +This applies to multi-line assertion clauses, too, as shown below. + + +[[Image:es ref contract editor 03]] + + +The selected clause can be moved up or down relative to the other clauses by using the up and down arrows in the toolbar. + +To make changes to the text of the currently selected assertion clause, click the Edit button ([[Image:contract-editor-edit-icon]]) on the toolbar, or just double-click the selected clause. The clause appears in the Edit Contract dialog box. + + +[[Image:es ref edit contract dialog 01]] + + +You can edit the tag for your assertion clause and the assertion itself. + +Assertion clause tags must be valid identifiers. The Contract Editor tool will check your input as you type and alert you if entered a character string that would not be a valid identifier. The tag is optional, so you can leave it empty if you wish. + +After editing the assertion clause itself, you can click OK. At this point the Contract Editor tool will perform a syntactical analysis on your assertion clause in order to help you avoid some types of errors. If your assertion clause appears syntactically sound, the Edit Contract dialog box will be dismissed and your changes will be visible in the Contract Editor tool display. + +At this point, the changes have not been saved to the class text. To save the changes click the Save icon ([[Image:16x16--general-save-icon]]) in the toolbar. + + +=Adding assertion clauses= + +You can add a new clause to any contract assertion by clicking the "Add" button ([[Image:16x16--general-add-icon]]) on the toolbar. The button provides two methods of creation "Custom" and "From Template". + + +[[Image:es ref contract editor add 01|Add Custom or Add from Template]] + + +Choosing "Add Custom..." produces a freeform dialog, much like the editing dialog show earlier in which you can edit an assertion clause from scratch: + + +[[Image:es ref contract editor add 02|Add a custom assertion clause]] + + +"Add from Template" provides a list of code templates for commonly used assertion types. Adding assertion clauses from templates when possible speeds up class specification and helps to avoid errors. Consider a newly coded routine: + + + my_routine (a_string: STRING) + -- Do something with `a_string`. + do + + end + + +Part of the specification of this routine might be a precondition that states that the argument must be attached (i.e., not Void), and not the empty string. This precondition can be added to the feature by adding two assertion clauses from templates. To specify that a_string must be attached, you would first choose the template "Attached Contract" which provides this dialog: + + +[[Image:es ref add attached contract template 01|Attached contract]] + + +This template focuses on the fact that some entity (expressed as var in the template) must be the object of an assertion clause that guarantees that the entity is attached. To have the template create such a clause for the argument a_string shown in the routine above, just replace var with a_string in the top text box of the dialog. The resulting code is updated automatically: + + +[[Image:es ref add attached contract template 02|Attached contract]] + + +Adding a clause to specify that a_string must not be empty is done similarly, by selecting the "Not is empty" template. After adding these two precondition clauses, the routine now looks like this: + + + my_routine (a_string: STRING) + -- My routine + require + a_string_attached: a_string /= Void + not_a_string_is_empty: not a_string.is_empty + do + + end + + + + + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-reference/debugger/breakpoints/breakpoint-commands.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-reference/debugger/breakpoints/breakpoint-commands.wiki new file mode 100644 index 00000000..6f79f396 --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-reference/debugger/breakpoints/breakpoint-commands.wiki @@ -0,0 +1,12 @@ +[[Property:title|Breakpoint commands]] +[[Property:weight|2]] +[[Property:uuid|3631e866-0acd-005d-b1f5-f43377b6e27f]] +Located in the '''debug''' menu and the '''project''' toolbar, three commands allow you to change the state of set [[Breakpoints|breakpoints]] in the system. + +Enable breakpoints ( [[Image:16x16--breakpoints-enable-icon]] ), disable breakpoints ( [[Image:16x16--breakpoints-disable-icon]] ) and remove breakpoints ( [[Image:breakpoints-delete-icon]] ) all have global and local actions. Left-clicking on them has a global action: all breakpoints currently set in the system will be respectively enabled, disabled, or discarded. However, it is also possible to [[Pick-and-drop mechanism|drop]] a feature or a class onto them, in which case only set breakpoints of the feature/class will be affected. + +Note that these commands work only on set breakpoints (that is, enabled or disabled breakpoints). Therefore, discarded breakpoints cannot be set again with these commands. + + + + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-reference/debugger/breakpoints/breakpoint-editing.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-reference/debugger/breakpoints/breakpoint-editing.wiki new file mode 100644 index 00000000..7417c321 --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-reference/debugger/breakpoints/breakpoint-editing.wiki @@ -0,0 +1,60 @@ +[[Property:title|Breakpoint editing]] +[[Property:weight|1]] +[[Property:uuid|1ac830ab-7600-8e52-2351-c515bcc31d41]] +In all flat views ( [[Feature formatters: Flat view|feature flat view]] and [[Class formatters: Flat view|class flat view]] ), a margin is displayed on the left of the editor. [[Breakpoints|Breakpoints]] are symbolized there as circles, with different looks depending on their state: enabled ( [[Image:bp-enabled-icon]] ), disabled ( [[Image:bp-disabled-icon]] ) or not set ( [[Image:bp-slot-icon]] ). A small question mark in the circle ( [[Image:bp-enabled-conditional-icon]] , [[Image:bp-disabled-conditional-icon]] ) indicates [[Breakpoint menu|conditional breakpoints]] . + +Right-clicking on any breakpoint pops up a context menu: + +[[Image:breakpoint-context-menu]] + +The first line provides the breakpoint slot index of the selected breakpoint (i.e: the one used in call stack or exception trace output).
+Clicking one of the three first entries of the context menu changes the state of the breakpoint that was right-clicked. The last entry ('''Run to This Point''') launches the debugged application so that it will stop as soon as the selected breakpoint is encountered, as if the breakpoint had been enabled.
+ + +"Edit This Breakpoint" allows you to edit the parameters of the breakpoint (condition, hit count, when hits actions...) through the breakpoint dialog. On the first tab, '''Context''', the breakpoint dialog provides access to the associated tags, condition, and hit count control. And on the second tab, it allows you to associate '''When hits...''' action(s) with the breakpoint. + +{| +|- +| +'''Context''' tab + [[Image:breakpoint-dialog-context|Context tab]] +| +'''When hits ...''' action tab + [[Image:breakpoint-dialog-when-hits-action|When hits... tab]] +|} + + +Tags allow you to identify a collection of breakpoints, either from the [[Breakpoint information command|breakpoints tool]] , or in the parameters of "When hits .." actions.
+Any existing breakpoint can be referenced by an implicit tag with the form: ''"'''bp:'''cluster.{CLASS}.feature@index"'' (cluster is not mandatory).
+ +{{sample|A sample breakpoint tag: "'''bp:'''elks.{LINKED_LIST}.extend@2"}} + +* the "Condition" allows you to set a condition for stopping. +* the "Hit count" allows you to set a condition on hitcount for stopping. +* And the "When Hits..." allows you to associate specific actions with the breakpoint: +** Print message: display the expanded message to the output (there are predefined variables, and you can also evaluate expressions). +** Disable/Restore Assertion Checking: this might be useful to deactivate assertion checking on a specific part of the execution. +** Record Execution: start or stop the execution recording (cf: [[Execution record and replay|Execution recording and replay]] ) +** Enable/Disable Breakpoints: either use tags or implicit tags (ex: ''"bp:elks.{LINKED_LIST}.extend@2"''), to reference a set of existing breakpoints. This can be pretty useful to enable a breakpoint only if the execution takes a specific execution path. +** Reset Hits count + + + + +"Edit Condition" allows you to set a condition for stopping, it opens the same dialog as "Edit This Breakpoint", but focus on the "condition" field. + +[[Image:breakpoint-dialog-condition]] + +"Hit count" allows you to set a condition on hitcount for stopping + +[[Image:breakpoint-dialog-hit-count]] + +"When hits ..." allows you to perform an action, print a message for example, when execution stops on this breakpoint. + +[[Image:breakpoint-dialog-when-hits]] + +{{seealso| [[Breakpoint commands|Breakpoint commands]], [[Breakpoint information command|Breakpoint information command]] }} + + + + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-reference/debugger/breakpoints/breakpoint-information-command.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-reference/debugger/breakpoints/breakpoint-information-command.wiki new file mode 100644 index 00000000..32c8fbe3 --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-reference/debugger/breakpoints/breakpoint-information-command.wiki @@ -0,0 +1,31 @@ +[[Property:title|Breakpoint information command]] +[[Property:weight|3]] +[[Property:uuid|9fa30dd2-231f-c1f2-4139-f8e90df0e77f]] +The breakpoint information command, located in the '''debug''' menu and in the '''project''' toolbar ( [[Image:tool-breakpoints-icon]] ), displays the list of all set breakpoints in the system (enabled or disabled). + +Display all breakpoints in a grid:
+ +[[Image:breakpoints-list]] + +{{note|
+The * shows that the breakpoint has a [[Breakpoint menu|condition]] .
+You can edit the selected breakpoint by double clicking on it, or pressing [enter] which show the menu.
+You can disable/enable the selected breakpoint(s) by pressing [space].
+You can sort by clicking the column, especially the first column which provide tree, flat or sorted view. }} + +Display all breakpoints in a list:
+ +[[Image:breakpoints-list-flat]] + +Display all breakpoints in a list filtered by a tag using button [[Image:breakpoints-list-filter-button]] :
+ +[[Image:breakpoints-list-filter]] + +{{seealso|
+[[Breakpoint commands|Breakpoints commands]]
+[[Breakpoint information command|Breakpoint information command]]
+}} + + + + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-reference/debugger/breakpoints/breakpoint-menu.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-reference/debugger/breakpoints/breakpoint-menu.wiki new file mode 100644 index 00000000..2728dd5f --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-reference/debugger/breakpoints/breakpoint-menu.wiki @@ -0,0 +1,26 @@ +[[Property:title|Breakpoint menu]] +[[Property:weight|4]] +[[Property:uuid|dd68a84b-9bb7-98d5-8aa3-7e16969086f1]] +A condition breakpoint is a breakpoint in which debugger will stop if a certain condition is met. To set a conditional breakpoint use the [[Breakpoint editing|breakpoint menu]] and choose `Set conditional breakpoint': + +[[Image:breakpoint-context-menu]] + +Once done a dialog pops up where you can enter a condition: + +[[Image:breakpoint-dialog-condition]] + +The condition is a Boolean expression that follows the same rule as the expression you can enter in the [[Expression evaluation|expression evaluation tool]] .
+ + +{{caution|If you enter an expression that is not supported or which raises an error during evaluation, by default the condition is considered as True (then the debugger will stop) }} + +{{seealso|
+[[Breakpoint editing|Breakpoint menu]]
+[[Breakpoint commands|Breakpoints commands]]
+[[Breakpoint information command|Breakpoint information command]]
+[[Expression evaluation|Expression evaluation tool]]
+}} + + + + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-reference/debugger/breakpoints/index.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-reference/debugger/breakpoints/index.wiki new file mode 100644 index 00000000..b17f9317 --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-reference/debugger/breakpoints/index.wiki @@ -0,0 +1,32 @@ +[[Property:title|Breakpoints]] +[[Property:weight|-14]] +[[Property:uuid|6ed5890a-9b23-210a-5640-cee348d6e27e]] +Breakpoints are entities that stop a debugged application. Breakpoints can be put at the beginning of each execution line, so that it is possible to see the context in which the line is executed before executing it. + +In EiffelStudio, breakpoints are represented as circles in the left margin of flat views (both [[Feature formatters: Flat view|feature flat view]] and [[Class formatters: Flat view|class flat view]] ). +Breakpoints can be in three different states: '''enabled''' ( [[Image:bp-enabled-icon]] ), '''disabled''' ( [[Image:bp-disabled-icon]] ), or '''not set''' ( [[Image:bp-slot-icon]] ). + +Only enabled breakpoints will stop the application when they are encountered. By default, breakpoints are not set. +Disabled breakpoints are useful to temporarily discard a breakpoint, while keeping the possibility to put it back quickly. + +Enabled and disabled breakpoints can have an associated '''[[Breakpoint menu|condition]]''' . They are then shown as [[Image:bp-enabled-conditional-icon]] and [[Image:bp-disabled-conditional-icon]] . + +Left-clicking on a breakpoint in a flat view changes the state of the breakpoint: it switches from not set to enabled, from enabled to not set, and from disabled to enabled. Removing a conditional breakpoint discards its condition. + +The [[Breakpoint editing|breakpoint menu]] lets you change the state of one breakpoint, whereas the [[Breakpoint commands|breakpoint commands]] let you change the state of several breakpoints at a time. The [[Breakpoint information command|breakpoint information command]] shows the state of all set breakpoints. + +{{note|You can toggle the status of a breakpoint easily using shortcuts
- '''F9''': toggle between enabled/not-set.
- '''Shift+F9''': toggle between enabled/disabled.
- '''Ctrl+F9''': open the breakpoint dialog for [[Breakpoint editing|editing]]. }} + +{{note|Breakpoints cannot be set in all features. In particular, breakpoints cannot be set in external features or attributes.
+However, breakpoints can be set in assertions (require and ensure). }} + +{{tip|Breakpoints can be set on-the-fly while the application is running. }} + + +{{tip|You can relocate a breakpoint by '''Ctrl+RightClick''' on a breakpoint [[Image:bp-enabled-conditional-icon]] and '''Ctrl+RightClick''' on an empty breakpoint location [[Image:bp-slot-icon]] }} + + +{{tip|to go to the line corresponding to a specific breakpoint index, just use Ctrl+G, enter the index, and the corresponding line should appear selected}} + + + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-reference/debugger/call-stack-tool/call-stack-tool-interface.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-reference/debugger/call-stack-tool/call-stack-tool-interface.wiki new file mode 100644 index 00000000..2a4f02e6 --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-reference/debugger/call-stack-tool/call-stack-tool-interface.wiki @@ -0,0 +1,34 @@ +[[Property:title|Call stack tool: Interface]] +[[Property:weight|1]] +[[Property:uuid|ff70f68f-31db-c5d1-4d68-7b0fc70b1dd7]] +[[Image:call-stack-tool]] + + +The call stack tool provides information, at a particular point during system execution, about the call stack of a system being executed under control of the debugger. + +The call stack is composed of a list representing the call stack elements, in which the root procedure of the system is at the bottom of the list and the currently executing routine is at the top.
+* The currently selected call stack element, to which the [[Information relative to a stack element|other debugger tools]] refer, is indicated by a green arrow [[Image:callstack-active-arrow-icon]] .
+* Clicking on a call stack element represented by an empty arrow [[Image:callstack-empty-arrow-icon]] , or picking the element and dropping it onto either the call stack list or the locals view defines it as being the currently selected call stack element.
+* The call stack elements with no icon are called external call stack elements, they represent a call stack out of Eiffel, for example, a true .NET call stack.
+* For each feature in the call stack, the name, dynamic class, and static class are displayed. The dynamic class is the type of the object upon which the feature is called, whereas the static class is the class in which the feature was written. +* An asterisk next to the name of a feature means the feature is melted, as opposed to frozen. + +At the top of the list, one line of text gives the state of the debugged application, in this case "Status = Breakpoint reached". A second line describes the exception that caused the application to stop, if any. In the case shown above, execution stopped at a breakpoint, so no exception is shown on the second line. For more information concerning exceptions, see the [[Supported exceptions|supported exceptions]]. +The button [[Image:debug-exception-dialog-icon]] is used to open the Exception dialog which show the exception details. For instance a call on Void target in a .NET system would popup : + + +[[Image:exception-dialog]] + + +When more than one thread is available to the debugger, you can switch from one thread to another. To do that, click on the thread's id "0x000..." and select from the pop-up list of available threads. Or (recommended) you can use the [[Threads tool|threads tool]] (clicking on '''Show threads panel''' will show the threads tool). + + +[[Image:call-stack-tool-with-threads]] + + +In the toolbar, the button [[Image:general-save-icon]] gives you the capability to [[Save call stack|save the call stack]] to a text file. The button [[Image:general-copy-icon]] can be used to copy the call stack to the clipboard. The [[Image:debugger-callstack-depth-icon]] button makes it possible to choose a desired depth for the call stack in the list (the default is to display the 100 top stack elements). + + + + + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-reference/debugger/call-stack-tool/index.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-reference/debugger/call-stack-tool/index.wiki new file mode 100644 index 00000000..f779f9df --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-reference/debugger/call-stack-tool/index.wiki @@ -0,0 +1,14 @@ +[[Property:title|Call stack tool]] +[[Property:weight|-13]] +[[Property:uuid|8c3cd0fe-78aa-7ec6-f36a-2233a4e26755]] +The call stack is the list of routines that have been entered during execution, but not yet exited since execution started. The list can be considered a '''stack''' structure, because before any routine, say my_routine, can exit, any routine that my_routine may have called must have exited first. Therefore the last entered feature is listed at the top of the stack and the program root feature is its bottom. + +There is one level in the call stack, the currently selected element, that has a special status. It is the level to which all debugging tools refer. The currently selected element is, as you might guess, user-selectable. So it is possible to move along the call stack, changing the currently selected element, and view information in the debugging tools about any level.. + +To keep a record of a call stack (for example in order to indicate to other people where a problem occurred), you can [[Save call stack|save the call stack]] to a text file. + +Information concerning the call stack is spread over several graphical components: +* The entire call stack, depicted as a list of elements, is displayed in the [[Call stack tool: Interface|call stack tool]] . +* [[Information relative to a stack element|Information concerning the current call stack element]] is displayed in the feature tab, the locals view, and is used to provide the expressions evaluations contained in the [[Evaluation tool or Watch tool|Expression evaluator tool]] . + + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-reference/debugger/call-stack-tool/information-relative-stack-element.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-reference/debugger/call-stack-tool/information-relative-stack-element.wiki new file mode 100644 index 00000000..3432a806 --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-reference/debugger/call-stack-tool/information-relative-stack-element.wiki @@ -0,0 +1,12 @@ +[[Property:title|Information relative to a stack element]] +[[Property:weight|2]] +[[Property:uuid|f78fca33-2e19-1021-70f4-fd262991da7a]] +In addition to the [[Call stack tool: Interface|call stack tool]] that provides global information concerning the call stack, some other debug tools give more detailed information concerning the [[Call stack tool: Interface|currently selected call stack element]] . + +In debug mode, the context tool is automatically switched to the feature tab in flat view, and displays the feature which corresponds to the current call stack element. In the left margin, a yellow arrow ( [[Image:bp-current-line-icon]] ) marks the execution line where the program is currently stopped, whereas a green arrow ( [[Image:bp-slot-other-frame-icon]] ) indicates the execution line that was attained in the feature in the current call stack element. Therefore, if a feature is recursive, and appears several times in the call stack, changing the current call stack element may cause green arrows to be displayed at different places in the same feature (if the different calls did not reach the same execution point). On the other hand, the yellow arrow can only appear at one place as long as the application is not started again. + +The left part of the [[Object tool|object tool]] gives valuable information concerning parameters that were passed to the feature corresponding to the current call stack, the current value of the local variables, and, if the feature is a function, the current value of its result. + + + + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-reference/debugger/call-stack-tool/save-call-stack.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-reference/debugger/call-stack-tool/save-call-stack.wiki new file mode 100644 index 00000000..be39318c --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-reference/debugger/call-stack-tool/save-call-stack.wiki @@ -0,0 +1,8 @@ +[[Property:title|Save call stack]] +[[Property:weight|4]] +[[Property:uuid|495a2601-8e25-0b48-f86a-6cccf7099c1e]] +It is possible to copy the current call stack to the clipboard ( [[Image:general-copy-icon]] ) or to a text file ( [[Image:general-save-icon]] ). This may be useful to indicate to other members of a team where an error has occurred. After the button is clicked, a dialog is popped up that prompts for a place in which to save the [[Call stack tool: Interface|call stack]] file (if the selected file already exists, it is overwritten). + + + + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-reference/debugger/call-stack-tool/supported-exceptions.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-reference/debugger/call-stack-tool/supported-exceptions.wiki new file mode 100644 index 00000000..4271ae3d --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-reference/debugger/call-stack-tool/supported-exceptions.wiki @@ -0,0 +1,48 @@ +[[Property:title|Supported exceptions]] +[[Property:weight|3]] +[[Property:uuid|f3b4498a-0772-32fb-041d-13428e258f52]] +Here is a list of exceptions that may appear in the [[Call stack tool: Interface|call stack tool]] . When they are raised, a tag may be there to give more information, if necessary. All these exceptions are declared in EXCEPT_CONST. + +'''Feature call on Void target''': An attempt was made to call a feature on an object that is Void. The tag indicates the name of the feature of the feature that could not be called. For instance if the code line is a.b.c and the tag is "c" then a.b was Void. + +'''No more memory''': A memory allocation failed. + +'''Precondition violated''': One of the conditions necessary prior to entering a feature is not verified. This may indicate either that the precondition is too strong, or that the call is invalid. The tag should give the name of the violated precondition, if any. + +'''Postcondition violated''': One of the conditions checked when a feature exits is not verified. This may indicate either that the postcondition is too strong, or that the feature did not behave correctly. The tag should give the name of the violated postcondition, if any. + +'''Class invariant violated''': One of the conditions that checks the validity of objects is not verified. This may indicate that an object was left in an invalid state after a method call. The tag should give the name of the violated invariant, if any. + +'''Assertion violated''': An assertion was not verified. The tag should give the name of the violated assertion, if any. + +'''Non-decreasing loop variant''': A loop variant does not vary. This may lead to stack overflows or erroneous results. + +'''Loop invariant violated''': A condition that should be checked when executing a loop is not verified. The tag should give the name of the violated invariant. + +'''Floating point exception''' (signal SIGFPE): An error occurred while processing floating point numbers. This may be for example a FPU overflow, a division by zero, or an invalid operation. + +'''Unmatched inspect value''': An inspect clause couldn't find the value it was passed among the `when` clauses. If any value maybe passed to the `when` clause, adding an `else` clause will solve this problem. + +'''I/O error''': An error occurred while accessing a stream. Examples of this are a missing file, or insufficient rights. + +'''Retrieval error''': A file could not be retrieved. This maybe caused by an invalid header, or more generally by a corrupted data file. + +'''Developer exception''': Developer exceptions can be raised by calling {EXCEPTIONS}.raise. They can indicate any kind of internal error. + +'''Operating system signal''': The program received a signal from the operating system. + +'''Exception in rescue clause''': An exception occurred within a rescue clause. + +'''Void assigned to expanded''': An attempt was made to assign a Void value to an expanded object. + +'''Run-time I/O error''': Exception raised by the run-time when encountering a I/O error internally. + +'''External event''': On Unix, this happens when an operating system error occurs and does not set the `errno` variable. + +'''Operating system error''': On Unix, this happens when an operating system error occurs and sets the `errno` variable. + +'''COM error''': Raised when EiffelCOM encounters an error. + + + + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-reference/debugger/command-line-debugger.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-reference/debugger/command-line-debugger.wiki new file mode 100644 index 00000000..6f668a2c --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-reference/debugger/command-line-debugger.wiki @@ -0,0 +1,63 @@ +[[Property:title|Command line debugger]] +[[Property:weight|-3]] +[[Property:uuid|ad1ef861-8307-a56c-5f94-f236c520da55]] +The command line debugger is not as rich as the EiffelStudio debugger, however it provides simple debugging functionalities without any graphical user interface. + += How to enter the command line interface ? = +* ec -config your_system.ecf -debug +* Then you get the debug menu + --< Debugger main menu >-- + (A) Set arguments + (E) Set environment + (D) Set working directory + (I) Display parameters + --- + (R) Start and stop at breakpoints + (L) Start without stopping at breakpoints + (S) Step into + --- + (H) Help + (Q) Quit + -> + +* Enter your choice using the letter inside parentheses +** (A) to set the arguments for the execution +** (E) to set the environment variables +** (D) for the working directory +** (R), (L) or (S) to start the execution +** When the execution is paused, you can display the menu by pressing ENTER + += To set breakpoints = +If you want to set breakpoints, you first need to step into (S) to start execution +** The execution starts, then pauses at the entry of the system +** Press ENTER to get the new "Debugger execution menu" + --< Debugger execution menu >-- + (N) Step next + (I) Step into + (O) Step out + (C) Run to next stop point + (G) Run without stop point + (T) Toggle 'Ignore stop point' + (K) Kill application + (P) Pause application + --- + (B) Breakpoints control + (D) Display information + (H) Help + -> + +** Then you choose "(B) Breakpoints control" to add, modify or list breakpoints. + --< Debugger menu :: Breakpoints >-- + (A) Add breakpoint + (M) Modify existing breakpoint + (L) List breakpoints + (H) Help + (..) Back to parent menu + -> + += Limitations = +* It is not possible to interrupt the execution. +* The command line debugger is not as rich as the EiffelStudio graphical debugger. As a result you may miss specific functionalities (such as conditional breakpoints, ...) available in the EiffelStudio debugger. +* The command line debugger is experimental. It would need more enhancement to satisfy advanced debugging needs, however it provides simple (and limited) debugging facilities directly from the command line. + + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-reference/debugger/debuggees-object-storage.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-reference/debugger/debuggees-object-storage.wiki new file mode 100644 index 00000000..955a5489 --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-reference/debugger/debuggees-object-storage.wiki @@ -0,0 +1,25 @@ +[[Property:title|Debuggee's Object Storage]] +[[Property:weight|-9]] +[[Property:uuid|b26fb1b0-85ef-26b5-9b9d-6e3b8ad977c2]] +This command can be accessed through the context menu, and from the objects tool, and watches tools thanks to the tool bar's button [ [[Image:execution-object-storage-icon]] ]. + +By Pick-and-Dropping a debuggee object onto the button [ [[Image:execution-object-storage-icon]] ], you raise the "save" dialog. Then you need to choose the name for the file into which EiffelStudio will store the debuggee object. + + +[[Image:debuggee-object-storage-save]] + + +By clicking on Evaluation tool's button [ [[Image:execution-object-storage-icon]] ], you raise the "load" dialog. Then you need to select the name of the file which contains the debuggee object's storage. If the loading is successful, the retrieved object will be added in the related Evaluation tool.
+ + +[[Image:debuggee-object-storage-load]] + + +{{tip|By Pick-and-Dropping an object onto the button, you can load the retrieved values into the dropped object (provided that both have the same type).}} + + +{{caution|For now this command implements only basic functionality, and is provided as-is. The underlying implementation uses {FILE}.independent_store and {FILE}.retrieved for save and load operations. To load the value into an existing object, it uses {ANY}.standard_copy (..). For details, you can have a look at the code in class RT_EXTENSION_GENERAL. }} + + + + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-reference/debugger/debugging-limitations.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-reference/debugger/debugging-limitations.wiki new file mode 100644 index 00000000..4679ca00 --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-reference/debugger/debugging-limitations.wiki @@ -0,0 +1,22 @@ +[[Property:title|Debugging limitations]] +[[Property:weight|-2]] +[[Property:uuid|4377d765-8664-ee0c-5d5b-e42fd7d172c3]] +==General limitations== +* Watch expression: Agents are not supported (for instance "agent my_function" is not supported"). +* You cannot yet create an instance of SPECIAL. +* The debugger is not very helpful when the execution is stopped inside an invariant. +* Wrong assertion tag shown in debugger for precondition violation if violated during an exception rescue, indeed the tag remains the one from the exception +* If you use the "Disable Assertion Handling" functionality when the execution is stopped in a rescue, the effect might be cancelled as soon as the execution exits the rescue's associated feature. +* Evaluating an expression with a catcall might crash the debugger + +==Limitations or known bugs for the Classic debugger== +* Evaluating Precursor will produce the current feature's Result (not the precursor) +* If you use any of the previous non supported expressions in a breakpoint condition, since the evaluation is failing the condition will always return True. In such case the debugger will stop. + +==Limitations or known bugs for the .Net debugger== +* When stepping through disabled assertions or disabled debug clauses, the debugger may show incorrect current line. +* When stepping through an inspect code, the debugger may show incorrect current line (especially if the inspect is not ordered) +* Under dotnet v2.0, the debugger may have difficulties to fetch the stack values, especially during first chance exception events + + + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-reference/debugger/debugging-preferences.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-reference/debugger/debugging-preferences.wiki new file mode 100644 index 00000000..c8a57145 --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-reference/debugger/debugging-preferences.wiki @@ -0,0 +1,19 @@ +[[Property:title|Debugging preferences]] +[[Property:weight|-4]] +[[Property:uuid|05e820ff-917f-e41f-d921-990283ac886f]] +Debugger preferences are available as part of the [[EiffelStudio Preferences]]. + +The debugger section of the EiffelStudio preferences looks like this: + + +[[Image:debugging-tools-preferences]] + + +The EiffelStudio preference documentation contains a guide to the [[Debugger Preferences]]. + +Some preferences have an effect upon the speed at which the debugger can display objects: +* Enable/disable the debug_output display (see [[Debug output|debug output]]) +* Enable/disable the full generic type display (for example, ARRAY [INTEGER] is displayed, instead of only ARRAY) +* To avoid infinite evaluation processing, the debugger aborts evaluation after "max evaluation duration" timeout. + + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-reference/debugger/debugging-tips-objects-grid-view.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-reference/debugger/debugging-tips-objects-grid-view.wiki new file mode 100644 index 00000000..a5538f3e --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-reference/debugger/debugging-tips-objects-grid-view.wiki @@ -0,0 +1,15 @@ +[[Property:title|Debugging tips with the objects grid view]] +[[Property:weight|-5]] +[[Property:uuid|56b3c189-8fda-d78e-7e7c-c4cf4f786ff6]] +General behavior +* Double clicking on the grid's header separator will resize the corresponding column. If you hold the SHIFT key at the same time, it will resize according to the displayed cells. +* Right clicking on the header's cell will popup a menu that enable or disable the auto resizing on the selected column. This can be useful to resize automatically the "name" column when inspecting an object value. +* Pressing CTRL+E when the selected line represents a value with potential text representation (STRING, DEBUG_OUPUT ...) will open the [[Object Viewer (also known as Expanded display)|expanded view dialog]]. + +Evaluation tool (also known as Watch tool) +* Dropping an object value on a [[Evaluation tool or Watch tool|Evaluation tool ]] will open the [[New expression dialog|expression definition dialog]] with the object's address filled. This way you can evaluate expression directly on this object. If you hold the CTRL key while dropping, the dropped object will be added as expression in the Evaluation tool as itself. +* You can also drop the object on the notebook tab of the desired Evaluation tool. + + + + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-reference/debugger/exceptions-handling-tool.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-reference/debugger/exceptions-handling-tool.wiki new file mode 100644 index 00000000..f7f0278a --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-reference/debugger/exceptions-handling-tool.wiki @@ -0,0 +1,44 @@ +[[Property:title|Exceptions handling tool]] +[[Property:weight|-7]] +[[Property:uuid|9a62611f-46ba-7d74-ba1c-989f6709074b]] +This Exceptions handling tool is used to specify whether the debugger stops or continues on specific exceptions. + +To access this tool, follow the menu path: + + + +Execution --> Exception handling + + +{{note|Now that exceptions are objects in Eiffel, the mechanism is unified for classic and .NET systems, using the Eiffel exception class names. }} + + +==Tailoring exception handling behavior== + +The image below shows the Exceptions handling tool. + + +[[Image:exceptions-handling-tool|Exception handling tool]] + + +In the top two checkboxes, the tool provides a way to enable and disable "Catcall" warnings on the console or in the debugger. + +If the "filter exceptions" checkbox is enabled, for each exception you can specify the exception action as one of: +* '''Disabled''' means that filtering for this exception is not enabled. Therefore, the default behavior of '''Catch''' applies. +* '''Catch''' means stop on such an exception. +* '''Ignore''' means do not stop on such an exception. +You can double clicking an exception name to toggle its status between '''Ignore''' and '''Catch'''. + +Clicking the button labeled ''Ignore External Exception?'' will set the status of a set of external exceptions to '''Ignore'''. + +Click the button labeled ''Apply'' to apply your selections, or ''Reset'' to reset the tool to its default values. + + +{{tip|Using the "Pattern" field, you can add your own filters using regular expression.}} + + + + + + + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-reference/debugger/execution-commands/attach-application.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-reference/debugger/execution-commands/attach-application.wiki new file mode 100644 index 00000000..0c4ca417 --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-reference/debugger/execution-commands/attach-application.wiki @@ -0,0 +1,32 @@ +[[Property:title|Attach application]] +[[Property:link_title|]] +[[Property:weight|0]] +[[Property:uuid|e369df0f-2e1f-5730-ae67-cd7b60b55c5f]] +Usually when you want to debug an application, you launch it from EiffelStudio and the debugger is automatically attached to the execution of the application. +However for specific needs (such as server development), you might want to start the execution outside EiffelStudio, and then attach EiffelStudio's debugger to it. + += Requirements: = +* The application should be compiled in workbench mode. +* EiffelStudio should be opened on the project used to compile the application. + += How to make it work? = +* The application execution will wait for the debugger to connect on a specific port number (given by the user). + +== Execution == +There are 2 ways to provide this port number: +* Setting the ISE_DBG_PORTNUM environment variable to a specific port number will make the execution to wait right away for EiffelStudio to attach the process. +* calling {RT_DEBUGGER}.wait_for_debugger (a_port_number: INTEGER) from the application code will wait for EiffelStudio to attach the process. +In both case, if it is unable to open the port, the execution continues, otherwise it waits until EiffelStudio get connected (i.e attach the execution). +It is possible to use any available port number, for that make sure your machine does not already use the port number you choose, and that the application is authorized to open that port (for instance try with port 50505). + +Note that the port number should be greater than 1023 and available (i.e not opened by other application). +The range 49152-65535 can be used for such custom or temporary purposes, and is more likely to have available port. + +== EiffelStudio == +To attach the process from EiffelStudio, follow the menu path Execution->Attach Debuggee and provide the same port number as specified above. +(Note that you can add the associated command to the execution tool bar.) +If EiffelStudio is unable to "attach" the debuggee, it will timeout and report the error (this could happen if the debuggee does not open the specific port). + +Once attached the execution, EiffelStudio is able to debug the application just as if the application was launched from EiffelStudio. + + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-reference/debugger/execution-commands/detach-application.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-reference/debugger/execution-commands/detach-application.wiki new file mode 100644 index 00000000..9bce9ed6 --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-reference/debugger/execution-commands/detach-application.wiki @@ -0,0 +1,11 @@ +[[Property:title|Detach application]] +[[Property:weight|0]] +[[Property:uuid|5da63d87-107d-338e-de64-1a52912fd00c]] +When you are executing an Eiffel application within EiffelStudio (i.e you are debugging it), you may want to detach the debugger from this application without killing the application. The "Detach Execution" command will address this need. + + +You can find it under menu Execution->Detach Execution, and you can also add it to the execution tool bar items. + + + + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-reference/debugger/execution-commands/execute-one-line-time.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-reference/debugger/execution-commands/execute-one-line-time.wiki new file mode 100644 index 00000000..102a4c73 --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-reference/debugger/execution-commands/execute-one-line-time.wiki @@ -0,0 +1,14 @@ +[[Property:title|Execute one line at a time]] +[[Property:weight|-9]] +[[Property:uuid|7d4489b4-5f29-2b1c-af83-afc2b25c8f85]] +If no application was already running, this command launches an application compiled in Work Bench mode and stops at its first line. + +If an application was stopped, it attempts to execute the instruction located on the execution line where the application is stopped. If this execution line does not contain an instruction, the execution stops at the next execution line. + +It is accessible through the '''project''' toolbar ( [[Image:debug-step-over-icon]] ) or through the '''debug''' menu. + +{{seealso| [[Execution commands]], [[Generating executables|Compiling in Workbench mode]] }} + + + + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-reference/debugger/execution-commands/execution-profiles.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-reference/debugger/execution-commands/execution-profiles.wiki new file mode 100644 index 00000000..8a9f2d2d --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-reference/debugger/execution-commands/execution-profiles.wiki @@ -0,0 +1,33 @@ +[[Property:title|Execution profiles]] +[[Property:weight|-13]] +[[Property:uuid|90e64e1c-b5fc-e150-9901-50daffaac893]] +While working on a project, you may want to launch your system with values for one or more arguments, specify a working directory, and/or change certain environment variables. + +Those parameters are done by changing the execution profiles. For that you need to use the '''Execution parameters''' dialog. + +* You can open this dialog in either of two ways: +** Follow the EiffelStudio menu path: Execution -> Execution parameters . +** Right-click any of the buttons on the debugging/execution toolbar. + +==Using the "Execution parameters" dialog== + +[[Image:argument-dialog]] + + +The dialog allows you to manage different execution profiles to specify parameters to be passed to the system at execution time. + +Each profile lets you set a title, the '''arguments''', the '''working directory''', as well as your own '''environment variables'''. + +To use a profile, just select it by clicking the corresponding line in the grid. + +Once the appropriate execution profile is selected then the system can be run with those parameters using the Run button (If "Keep Dialog Open" is selected the dialog remains opened).
+To run without any particular parameters, select the '''default''' profile. + +If you click on "Run Workbench" or "Run Finalized", the system will be executed outside EiffelStudio (thus debugging is unavailable). + + +{{tip|From version 6.5, you can unset an environment variable FOO by adding the "&-FOO" to the environment variables. By prefixing with "&-", you mark the variable "FOO" to be removed. If you use "&-*", all variables will be removed (except for any that you add to the list after the "&-*" entry). }} + + + + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-reference/debugger/execution-commands/index.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-reference/debugger/execution-commands/index.wiki new file mode 100644 index 00000000..70b44d3b --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-reference/debugger/execution-commands/index.wiki @@ -0,0 +1,28 @@ +[[Property:title|Execution commands]] +[[Property:weight|-15]] +[[Property:uuid|098e4d2b-18c5-6933-fe42-2d55e427f5fa]] +While working on a project, you may want to launch it to see if it behaves as expected, and if not to find out where the problem is located. + +There are several ways to launch the application you are working on from EiffelStudio: +* [[Run a finalized executable|Run a finalized executable]] [[Image:debug-run-finalized-icon]], where no debug is possible. +* Launch an application and enable its debugging +** [[Run and stop at breakpoints|Launch and stop]] [[Image:debug-run-icon]] as soon as the application encounters a [[Breakpoints|breakpoint]] +** [[Run without breakpoints|Launch and do not stop]] [[Image:debug-run-without-breakpoint-icon]] when encountering breakpoints + +* Execute one step in the application +** [[Step into a feature|Step into a feature]] [[Image:debug-step-into-icon]] +** [[Execute one line at a time|Execute one line]] [[Image:debug-step-over-icon]] +** [[Step out of a feature|Exit a feature]] [[Image:debug-step-out-icon]] + + +Once the application is launched in debug mode, you can [[Pause an application|pause]] [[Image:debug-pause-icon]] it at any time to see its current state or you can [[Stop a debugged application|stop its execution]] [[Image:debug-stop-icon]] completely. + +* In addition, you can also [[detach application|detach an application]] being debugged, and there is an experimental solution to [[attach application|attach]] the debugger to the Eiffel application launched outside EiffelStudio. + +All these commands are accessible either through the '''Execution''' menu, or through the '''project''' toolbar. + +{{seealso| The Eiffel [[Compiler|Compiler]] }} + + + + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-reference/debugger/execution-commands/pause-application.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-reference/debugger/execution-commands/pause-application.wiki new file mode 100644 index 00000000..50146825 --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-reference/debugger/execution-commands/pause-application.wiki @@ -0,0 +1,12 @@ +[[Property:title|Pause an application]] +[[Property:weight|-7]] +[[Property:uuid|846b52cb-6654-23be-3576-cc175a6fbf04]] +This command stops the execution of a running debugged application. + +This gives access to dynamic information concerning the application, such as the current [[Call stack tool|call stack]] and the [[Object tool|state of objects]] in the system. + +It is accessible through the '''project''' toolbar ( [[Image:debug-pause-icon]] ) or through the '''debug''' menu. + +{{seealso| [[Execution commands]] }} + + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-reference/debugger/execution-commands/run-and-stop-breakpoints.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-reference/debugger/execution-commands/run-and-stop-breakpoints.wiki new file mode 100644 index 00000000..64af16be --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-reference/debugger/execution-commands/run-and-stop-breakpoints.wiki @@ -0,0 +1,11 @@ +[[Property:title|Run and stop at breakpoints]] +[[Property:weight|-15]] +[[Property:uuid|16310d6f-9ab8-e27c-5802-059d8fc80914]] +This command launches an application compiled in Work Bench mode. The application will stop as soon as a [[Breakpoints|breakpoint]] is encountered, or when an exception occurs. + +It is accessible through the '''project''' toolbar ( [[Image:debug-run-icon]] ) or through the '''debug''' menu. + +{{seealso| [[Execution commands]], [[Generating executables|Compiling in Workbench mode]] }} + + + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-reference/debugger/execution-commands/run-arguments.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-reference/debugger/execution-commands/run-arguments.wiki new file mode 100644 index 00000000..f3781ee6 --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-reference/debugger/execution-commands/run-arguments.wiki @@ -0,0 +1,12 @@ +[[Property:title|Run with arguments]] +[[Property:weight|-14]] +[[Property:uuid|0c8c089c-f953-3337-87dc-09a0c8150c21]] +While working on a project, you may want to launch your system with one or more arguments. + +There are two ways to access the '''Execution Parameters''' dialog which lets you specify arguments to be used by your system when launched from EiffelStudio: +* By following the EiffelStudio menu path: Execution -> Execution parameters . +* By right-clicking any of the buttons on the debugging toolbar. + +See the [[Execution profiles|Execution parameters dialog]] for more details. + + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-reference/debugger/execution-commands/run-finalized-executable.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-reference/debugger/execution-commands/run-finalized-executable.wiki new file mode 100644 index 00000000..c7c6ef5b --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-reference/debugger/execution-commands/run-finalized-executable.wiki @@ -0,0 +1,14 @@ +[[Property:title|Run a finalized executable]] +[[Property:weight|-11]] +[[Property:uuid|a69ab49a-2bd1-a405-837c-b3e629fa5394]] +As opposed to other execution commands, this command launches an application compiled in finalized mode. This has the same effect as running the application in the EIFGENs/target_name/F_code directory from a console prompt. + +No debugging is possible with this command, but it lets you test the real speed of your program without any overhead. + +It is accessible through the '''project''' toolbar ( [[Image:debug-run-finalized-icon]] ) or through the '''project''' menu. + +{{seealso| [[Execution commands]], [[Generating executables|Compiling in finalized mode]] }} + + + + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-reference/debugger/execution-commands/run-without-breakpoints.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-reference/debugger/execution-commands/run-without-breakpoints.wiki new file mode 100644 index 00000000..e07c3c59 --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-reference/debugger/execution-commands/run-without-breakpoints.wiki @@ -0,0 +1,13 @@ +[[Property:title|Run without breakpoints]] +[[Property:weight|-12]] +[[Property:uuid|1f619bce-a3c7-5984-d3e6-4c5dceabf53d]] +This command launches an application compiled in Workbench mode. The application will not stop when a [[Breakpoints|breakpoint]] is encountered. However, it stops when an exception occurs. + +It is accessible through the '''project''' toolbar ( [[Image:debug-run-without-breakpoint-icon]] ) or through the '''debug''' menu. + +{{seealso| [[Execution commands]], [[Generating executables|Compiling in Workbench mode]] }} + + + + + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-reference/debugger/execution-commands/step-feature.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-reference/debugger/execution-commands/step-feature.wiki new file mode 100644 index 00000000..7f07b991 --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-reference/debugger/execution-commands/step-feature.wiki @@ -0,0 +1,14 @@ +[[Property:title|Step into a feature]] +[[Property:weight|-10]] +[[Property:uuid|a141505a-cc5a-afe1-6f8c-8e216bd7a232]] +If no application was already running, this command launches an application compiled in Work Bench mode and stops at its first line. + +If an application was stopped, it attempts to enter the feature located on the execution line where the application is stopped. If this feature is an attribute, or another non debuggable feature, it simply executes the current execution line and stops at the next one. + +It is accessible through the '''project''' toolbar ( [[Image:debug-step-into-icon]] ) or through the '''debug''' menu. + +{{seealso| [[Execution commands]], [[Generating executables|Compiling in Workbench mode]] }} + + + + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-reference/debugger/execution-commands/step-out-feature.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-reference/debugger/execution-commands/step-out-feature.wiki new file mode 100644 index 00000000..9e9ce964 --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-reference/debugger/execution-commands/step-out-feature.wiki @@ -0,0 +1,13 @@ +[[Property:title|Step out of a feature]] +[[Property:weight|-8]] +[[Property:uuid|4d3b068d-cbeb-be94-94c9-f73eb12b6c0e]] +If no application was already running, this command launches an application compiled in Work Bench mode and stops at its first line. + +If an application was stopped, it attempts to exit the feature where the application is stopped. + +It is accessible through the '''project''' toolbar ( [[Image:debug-step-out-icon]] ) or through the '''debug''' menu. + +{{seealso| [[Execution commands]], [[Generating executables|Compiling in Workbench mode]] }} + + + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-reference/debugger/execution-commands/stop-debugged-application.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-reference/debugger/execution-commands/stop-debugged-application.wiki new file mode 100644 index 00000000..2ccb4dc3 --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-reference/debugger/execution-commands/stop-debugged-application.wiki @@ -0,0 +1,13 @@ +[[Property:title|Stop a debugged application]] +[[Property:weight|-6]] +[[Property:uuid|648fdd76-c393-982d-5367-1e9b02669248]] +This command kills the debugged application, if any. This stops the debugging session. + +It is accessible through the '''project''' toolbar ( [[Image:debug-stop-icon]] ) or through the '''debug''' menu. + +{{seealso| [[Execution commands]] }} + + + + + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-reference/debugger/execution-record-and-replay/index.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-reference/debugger/execution-record-and-replay/index.wiki new file mode 100644 index 00000000..c51220ce --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-reference/debugger/execution-record-and-replay/index.wiki @@ -0,0 +1,26 @@ +[[Property:title|Execution record and replay]] +[[Property:weight|-12]] +[[Property:uuid|5184f354-f954-49e2-d38f-15214dcd3d6b]] +This feature allows you to record the debugger controlled execution of your system, and then replay this recording when the debugger is stopped. One could regard this feature as a rewind/forward, or undo/redo of the execution calls.
+In practice, +* the debugger is [[Record execution|recording]] the effective routine calls, and the attribute assignments, as well as the local variable assignments. +* when the execution is stopped, you can [[Replay (recorded) execution|replay]] the previous execution from its recording. +* when [[Replay (recorded) execution|replaying]] a recorded execution, the debugger restores the recorded values, and changes the execution cursor to show the recorded context (values, calls) in the debugging tool. +* This way you can use the standard debugging tools to view, inspect the values, browse the calls, and even evaluate expressions on objects ( but, be careful, if you evaluate expressions to avoid side effects). + + +The execution record and replay functionalities are graphically available on the Call stack tool, or though the "Execution" menu (formerly the "Debug" menu). + +How to use it +* Execute while [[Record execution|recording]] +* [[Replay (recorded) execution|Replay]] and use the debugging tools to browse, inspect, evaluate, ... + +{{caution|There is a '''specific limitation''' that '''once''' routine's information (not yet called ...) are not recorded and thus not restored as one might expect (for instance, the debugger does not reset a once during replay). This may be changed in a later release.}} + +{{caution|Be aware that there is a logical '''limitation''' concerning the world external to EiffelStudio. That is, it is not possible for EiffelStudio to record and replay external changes such as file or database modifications.
+Likewise if, during an external routine call, some Eiffel values are changed, those are not recorded (and thus not replayed).}} + +{{note|EiffelStudio provides record and replay '''only in classic mode'''. So the facility is not yet supported for .NET systems.}} + + + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-reference/debugger/execution-record-and-replay/record-execution.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-reference/debugger/execution-record-and-replay/record-execution.wiki new file mode 100644 index 00000000..58c101ac --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-reference/debugger/execution-record-and-replay/record-execution.wiki @@ -0,0 +1,54 @@ +[[Property:title|Record execution]] +[[Property:weight|1]] +[[Property:uuid|1255beef-e115-b8ae-87f6-08e267fe3d8f]] +For performance reason, the recording mechanism has a few parameters. For now there is no way to change them easily with the graphical debugger, however you can change those parameters by editing (and recompiling) {RT_DBG_EXECUTION_PARAMETERS}.make. +* {RT_DBG_EXECUTION_PARAMETERS}.maximum_record_count +** Type: INTEGER +** Default value: 1_000_000 +** Effect: The recording keeps only the last maximum_record_count object's records. +* {RT_DBG_EXECUTION_PARAMETERS}.flatten_when_closing +** Type: BOOLEAN +** Default value: True +** Effect: When leaving a feature, the recorder flattens the associated record. This saves memory space, and optimizes the underlying mechanism. The default value of True is recommended. +* {RT_DBG_EXECUTION_PARAMETERS}.keep_calls_records +** Type: BOOLEAN +** Default value: True +** Effect: When flattening call records' values, keep the sub-call records (i.e: the execution calls history) +* {RT_DBG_EXECUTION_PARAMETERS}.recording_values +** Type: BOOLEAN +** Default value: True +** Effect: During execution, record attribute and locals assignment. Set to False if you just want to review the calls history. Values will not be recorded, but recording will be faster. + + +{{warning|Since there is no way to restore local values when the execution left the related call stack frame, the recording discards the recorded local values.}} + + +The recording functionality is graphically available on the Call stack tool, or though the "Execution" menu (formerly the "Debug" menu). + +After you start debugging, if at some point you decide to start recording, click on the "record" button in the Call stack tool: + + +[[Image:exec-replay-00]] + + +or follow the menu path: + +Execution --> Activate Execution Recording + + +{{note|If you want to record from the beginning, just enable the recording before starting the debug session (the recording button is a toggle button)}} + + +{{tip|You can also use the "When hits.." actions of [[Breakpoint editing|breakpoints]] to start and stop the execution recording. This can be useful to record only the part of an execution that you are interested in.}} + + +[[Image:exec-replay-00-1]] + + +The execution is now recorded. Whenever the application is stopped, you can decide to [[Replay (recorded) execution|replay]] the previously recorded execution. See: [[Replay (recorded) execution]] to learn how to replay an execution. + + +{{note|EiffelStudio provides record and replay only in classic mode. So, it is not yet supported for .NET systems.}} + + + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-reference/debugger/execution-record-and-replay/replay-recorded-execution.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-reference/debugger/execution-record-and-replay/replay-recorded-execution.wiki new file mode 100644 index 00000000..a369f4fa --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-reference/debugger/execution-record-and-replay/replay-recorded-execution.wiki @@ -0,0 +1,61 @@ +[[Property:title|Replay (recorded) execution]] +[[Property:weight|2]] +[[Property:uuid|13932252-4eca-7c71-d047-b0b011e50d60]] +The replay functionality is available from a button on the Call stack tool, or though EiffelStudio's "Execution" menu. + + +{{note|First, you must be sure execution recording is activated ([[Record execution|read how to record execution]]).}} + + +Now, whenever the application is stopped in the debugger, you can replay the recorded execution by clicking on the "Replay" button: + + +[[Image:exec-replay-01]] + + +After clicking the "Replay" button, the Call stack tool enters "execution replay" mode, as shown below: + + +[[Image:exec-replay-02]] + + +In "execution replay" mode, the "Replay" button is enabled, and an additional command bar becomes visible with replay control buttons "Back", "Forth", "Previous", "Next", and "Go to". The numbers on the right end of this command bar indicate the call stack depth, the breakable index, and the nested breakable index. The buttons have following meanings: + +* '''Back''': means replay back to caller, i.e., down in the call stack. +* '''Forth''': means replay to callee, i.e., up in the call stack. +* '''Previous''': means replay to previous instruction (previous call in the same stack; i.e., similar to step previous) if possible. +* '''Previous''': means replay to next instruction (next call in the same stack; i.e., similar to step next) if possible. +* '''Go to''': replay to the selected call when possible. + +Below the command bar, in the first column, you will find a tree structure, which shows, on the root level, the effective call stacks, and for each root node, you can inspect the sub element to browse the call history.
+The '''bold entries''' show the active call stacks (i,e., the current call stack when the debugger was stopped).
+The '''red arrow''' shows the replayed call stack level, and the call stack levels which can be replayed have a light blue background.
+ + +If you expand a node, you will be able to browse the whole recorded execution history from this stack, as shown below (if you expand the bottom node, the whole recorded execution history will be available). + +You can still select other call stack levels as you do in normal debugging mode to inspect them. When you do, the red arrow stick to the replayed call, and the green arrow indicates the call stack level you selected. + + +[[Image:exec-replay-02-1]] + + +In the image below, we have clicked on "Back" 3 times. You can now also replay "Forth" 3 times. When you execute a "Replay" operation, the debugger restores the related recorded values, and the various debugger tools are updated with tools values (including the watch tools) + + +[[Image:exec-replay-03]] + + +And then if you replay "previous" twice, you rewind the execution in the same call stack frame. Notice the "blue" dot that shows the replayed execution cursor. + + +[[Image:exec-replay-04]] + + +{{note|When replaying, you will notice the debugging tools are synchronized and refresh.
+This means the objects tool, the watch tools, and the feature tool will display the replayed context (values, and replayed execution cursor).
+If you evaluate an expression in a watch tool, it will use the recorded values. So, be careful about side effects, because you can modify those values... }} + + + + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-reference/debugger/expression-evaluation/evaluation-tool-or-watch-tool.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-reference/debugger/expression-evaluation/evaluation-tool-or-watch-tool.wiki new file mode 100644 index 00000000..99345c8c --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-reference/debugger/expression-evaluation/evaluation-tool-or-watch-tool.wiki @@ -0,0 +1,44 @@ +[[Property:title|Evaluation tool or Watch tool]] +[[Property:weight|1]] +[[Property:uuid|e70d5827-a00d-47ee-9e7a-b7b4bfb34ccf]] +The Evaluation (or Watch) tool displays a list of expressions and their values (provided that those values can be obtained). + +[[Image:expression-evaluation-tool]] + +In the display, the ''Expression'' column gives the expression's text. The ''Context'' column gives the context in which the [[New expression dialog|expression]] is evaluated. The ''Value'' column gives the result of the expression, and the ''Type'' column the type of the expression's value. + +In the image above, you can see various expressions. Look at the one on the fourth line. This is an object that has been dropped on to the Evaluation tool, and the tool displayed it as itself, as shown by "As object" in the ''Context'' column, and by the italic style. The user can name the dropped object by editing the value in the ''Expression'' column for the expression. This can be useful to help you remember the origin of the value. + +The expression in the fifth row has an error, the icon is different, and the ''Value'' shows there is an error, double click on it for more details. + + +{{tip|If the expression returns a non-Void (and non-basic type) object, then the corresponding row in the list is pickable. The object can be dropped, for example, on the Evaluation tool to inspect it or to keep the object visible while stepping through system execution. }} + + +{{tip|holding the mouse pointer over the expression's cell will pop up a tooltip with details on the pointed expression }} + + +On top of the list, four buttons can be found. +* the button [[Image:toolbar-dropdown-icon]] is used to create/close watch tools via a menu popup +* [[Image:debugger-auto-values]] Enable or disable auto expressions. +* [[Image:new-expression-icon]] pops up the [[New expression dialog|expression definition dialog]], and can be used to define new expressions. If you have selected text in the editor, this text will be used to create the expression. +* [[Image:general-edit-icon]] edits a currently selected expression (it is not possible to change the context of an expression, only the expression itself). The associated key shortcut is F2. +* [[Image:general-toogle-icon]] disable/enable the evaluation of the selected expressions from the list.
+ +* [[Image:debugger-set-sizes-icon]] set the slice limits of dropped SPECIAL or NATIVE_ARRAY objects.
+ +* [[Image:debugger-show-hex-value-icon]] Toggle format display of numeric between decimal and hexadecimal format.
+ +* [[Image:debugger-expand-info-icon]] This command can give an [[Object Viewer (also known as Expanded display)|expanded display]] of the string relative to an object, by dropping the object onto the button (or pressing CTRL+E on the selected value). Use it if an object has a very long string representation or a string representation that contains carriage returns, for example.
+ +* [[Image:execution-object-storage-icon]] This button is used to remotely store or load a "stored" object (check [[Debuggee's Object Storage|remote object storage]]).
+ +* [[Image:general-delete-icon]] removes the selected expressions from the list. The associated key shortcut is Del. +* And the last two buttons are used to move up and down the expressions. You can also move the expressions up and down using CTRL+- or CTRL++ respectively (that is, the Control key with the ''minus'' key or the Control key with the ''plus'' key). + +{{tip|Dropping an object onto this list lets you define quickly an expression whose context is the dropped object. This avoids having to type object addresses manually.
+If you hold the CTRL key while dropping, you will add the dropped object as itself. }} + + + + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-reference/debugger/expression-evaluation/index.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-reference/debugger/expression-evaluation/index.wiki new file mode 100644 index 00000000..1b13daca --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-reference/debugger/expression-evaluation/index.wiki @@ -0,0 +1,27 @@ +[[Property:title|Expression evaluation]] +[[Property:weight|-10]] +[[Property:uuid|e55442ac-7861-1995-d315-baeed6c49223]] +[[Image:expression-evaluation-tool]] + +The Expression evaluation tool (sometimes called the Watch tool) makes it possible to evaluate expressions while the application is stopped in the debugger. A typical use for it is the case in which you would like to know the result that an external feature would return. Since you do not have access to the C memory of the application, doing this would be impossible without the Expression evaluation tool. You might also want to know the result of an Eiffel feature whose body is too complex for you to evaluate. + +In these cases (and any other that suits you), you should use the dynamic expression evaluation. Simply [[New expression dialog|define the expression]] and its result will be immediately available in the [[Evaluation tool or Watch tool|list of expressions]] . + +If you keep the mouse cursor over the expression cell of line, you get a tooltip describing the expression result. + +You can disable the evaluation of the selected expression by clicking on [[Image:general-toogle-icon]] . After you do, the context value will display 'disabled'. + +If the expression has an error, or if the evaluation raised an exception, you can obtain a more detailed description by double-clicking on the expression row. + + +{{caution|During the evaluation of an expression, all features that are necessary to obtain the result are called. Therefore, you should avoid calling queries that have side-effects, since doing so may alter the program execution. The Eiffel methodology recommends against creating queries with side-effects for other important reasons, as well. }} + +{{caution|Eiffel ''agents'' (for example: agent my_function) are not supported is not supported. }} + +{{caution|The evaluation ignores void-safety checking, a side effect is that expression {FOO} is interpreted as {detachable FOO} even if your application is void-safe. Thus keep this in mind when your expression implies TYPE objects. }} + + +{{caution|Currently, for classic Eiffel systems, evaluating Precursor will result the current feature's result (not the precursor). }} + + + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-reference/debugger/expression-evaluation/new-expression-dialog.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-reference/debugger/expression-evaluation/new-expression-dialog.wiki new file mode 100644 index 00000000..97758794 --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-reference/debugger/expression-evaluation/new-expression-dialog.wiki @@ -0,0 +1,28 @@ +[[Property:title|New expression dialog]] +[[Property:weight|2]] +[[Property:uuid|95a78497-434d-759f-fdce-f9025c891495]] +Adding new expressions to the [[Evaluation tool or Watch tool|list of expressions]] that should be dynamically evaluated is performed via a dialog. + + +{| +|- +| [[Image:new-expression-definition-dlg]]
+context: Current feature +| [[Image:new-expression-as-object-definition-dlg]]
+context: As object +|} + + +The first part in the dialog makes it possible to select the context of the expression. +* The default context is the context of the [[Information relative to a stack element|currently selected call stack element]], as shown in the left image above. This context gives access to the locals, the arguments, the result and the enclosing object features. +* The object context, that requires a valid object address, gives access to the features of the selected object. If you select "As object", the result of the expression is the referenced object itself; and you can supply a name for the object, as depicted in the right image above. +* The last context, the class-related context, gives access to the once and constant features of that class. It requires a valid class name. + + +The second part prompts for the expression itself. This field supports arguments, dot calls and operators (to a certain extent), but does not support creation expressions, agents or non-object calls. Genericity is partially supported. + +The "Keep Assertion Checking" checkbox is used to enable assertion checking during expression evaluation if desired (by default assertions won't be checked). + + + + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-reference/debugger/index.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-reference/debugger/index.wiki new file mode 100644 index 00000000..7adf9a6d --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-reference/debugger/index.wiki @@ -0,0 +1,18 @@ +[[Property:title|Debugger]] +[[Property:weight|-8]] +[[Property:uuid|31c4857e-f19e-e9e3-b7db-d6c30515277f]] +A debugger is a tool that allows you to [[Execution commands|run]] an application and view its state at any moment. This includes having information concerning the current [[Call stack tool|call stack]] and the [[Object tool|state of objects]] of the system, i.e. the values of their attributes. This kind of information can be used to spot objects that have invalid states, to see the consequences of the execution of a feature over an object state, and so on. + +The features of the EiffelStudio debugger include: +* Stopping the application in frozen features as well as in melted features +* [[Step into a feature|Stepping into]] features, [[Execute one line at a time|executing them one line at a time]] , or [[Step out of a feature|stepping out]] of them +* Setting [[Breakpoints|breakpoints]] on-the-fly, while the execution is running +* [[Expression evaluation|Dynamic evaluation of expressions]] +* [[Breakpoints|Conditional breakpoints]] +* [[Stack overflow prevention|Stack overflow prevention]] +* Classes can implement the [[Debug output|debug_output interface]] and have their objects display a string in the debugger +* Execution can be recorded to be replayed when execution is paused, use the [[Execution record and replay|execution replay mechanism]] from the call stack tool interface, and have the debugging tools updated. +* Debuggee objects can be stored/retrieved from the debugger, check the [[Debuggee's Object Storage|debuggee object storage mechanism]] available from the objects tool, and watch tools' toolbar. + + + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-reference/debugger/object-tool/attribute-symbols.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-reference/debugger/object-tool/attribute-symbols.wiki new file mode 100644 index 00000000..5a3beba0 --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-reference/debugger/object-tool/attribute-symbols.wiki @@ -0,0 +1,19 @@ +[[Property:title|Attribute symbols]] +[[Property:weight|1]] +[[Property:uuid|6dfbde5d-3423-4f10-6569-30af2ba00dd1]] +In both trees of the [[Object tool|object tool]], objects are displayed. The values displayed for each object fall into two categories: the object's attributes (grouped under the '''attributes''' folder [[Image:feature-attribute-icon]] ) and its once routines (grouped under the '''once routines''' folder [[Image:feature-once-icon]] ). + +The following symbol scheme is used to categorize each item: +* [[Image:debugger-object-immediate-icon]] An attribute of a basic Eiffel type, such as [[ref:libraries/base/reference/kernel/integer_chart.xml|INTEGER]] or [[ref:libraries/base/reference/kernel/classic/double_chart.xml|DOUBLE]] +* [[Image:debugger-object-eiffel-icon]] An attribute that is a reference to an object +* [[Image:debugger-object-void-icon]] A Void reference +* [[Image:debugger-object-expanded-icon]] An object that is expanded + +For .NET system, special symbols are used to describe : +* [[Image:debugger-object-dotnet-icon]] An object that is external (i.e., not known as an Eiffel type) +* [[Image:debugger-object-dotnet-static-icon]] A static value object that is external (i.e., not known as an Eiffel type) +* [[Image:debugger-object-static-icon]] A static value object that is known as an Eiffel type + + + + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-reference/debugger/object-tool/debug-output.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-reference/debugger/object-tool/debug-output.wiki new file mode 100644 index 00000000..25bcc2b0 --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-reference/debugger/object-tool/debug-output.wiki @@ -0,0 +1,16 @@ +[[Property:title|Debug output]] +[[Property:weight|2]] +[[Property:uuid|41544c3b-e1f1-53a5-ff63-e63224c32fa3]] +For virtually any object displayed in the Object tool, it is possible for the developer to cause the Object tool to display a user-definable string value next to the object address. + +In order to have the instances of a class display such a string in the object tool, make the class an heir to class DEBUG_OUTPUT. Then implement the feature debug_output to return the string to be displayed. At run-time, the debugger will automatically query this feature on all objects that define it, and then will display the results in the object tool and the [[Expression evaluation|evaluation tool]]. + + +{{sample|The numeric *_REF classes inherit (through class NUMERIC) from the class DEBUG_OUTPUT so that it is possible to see immediately the value of *_REF objects in the Object tool. The *_REF classes are reference versions of the basic Eiffel classes such as [[ref:libraries/base/reference/kernel/integer_chart.xml|INTEGER]] and [[ref:libraries/base/reference/kernel/classic/double_chart.xml|DOUBLE]]. So, without DEBUG_OUTPUT, if you wanted to see, for example, the value of the [[ref:libraries/base/reference/kernel/integer_chart.xml|INTEGER]] associated with an instance of [[ref:libraries/base/reference/kernel/integer_ref_chart.xml|INTEGER_REF]] displayed in the Object tool, you would have expand the reference first.}} + + +{{tip|If an object has a long string output or an output with carriage returns, for instance, pick-and-drop it to the expanded display command [[Image:debugger-expand-info-icon]] in the object tool. }} + + + + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-reference/debugger/object-tool/index.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-reference/debugger/object-tool/index.wiki new file mode 100644 index 00000000..3963a1c8 --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-reference/debugger/object-tool/index.wiki @@ -0,0 +1,47 @@ +[[Property:title|Object tool]] +[[Property:weight|-11]] +[[Property:uuid|6b736424-1729-0b6f-6ddd-8240f9f8ffd6]] +[[Image:object-tool]] + +The object tool is a debugging tool that displays extended dynamic information about runtime objects while debugging an application. This information includes the values of attributes, as well as the values of once functions that have already been called. + +By default the Object tool display is composed of one grid, which gives information about the [[Call stack tool|current stack element]]. Specifically, it provides the Current object value, the arguments' values of the current stack element's feature call, the values of the local variables, as well as the value of the Result (if this feature is a function). + +When an exception occurs (for instance, an assertion violation), the object tool will also display the exception information: + + +[[Image:objects-tool-exception]] + + +{{note|A specific case for .NET systems: When the system is stopped, the first item of the local view displays the module name for the feature at which execution stopped. }} + +All objects can be expanded to see the values of their attributes. They are also pickable, so that it is possible to drop them onto the Object tool, an [[Expression evaluation|expression evaluator tool]] (also know as Watch tool), or an editor. + +It is also possible to use the [[Set slice size command|set slice size command]] with [[ref:libraries/base/reference/special_chart|SPECIAL]] objects or [[ref:libraries/base/reference/native_array_chart|NATIVE_ARRAY]] (.NET) objects. + + + +'''The toolbar buttons:'''
+* the [[Remove object command|remove object command]] [[Image:general-delete-icon]]
+* the [[Set slice size command|set slice size command]] [[Image:debugger-set-sizes-icon]] .
+* the button [[Image:debugger-expand-info-icon]] can give an [[Object Viewer (also known as Expanded display)|expanded display]] of the string relative to an object, by dropping the object onto the button (or pressing Ctrl+E on the selected value). Use it if an object has a very long string representation or a string representation that contains carriage returns, for example.
+* the button [[Image:debugger-show-hex-value-icon]] switches the display of integer values between decimal and hexadecimal format.
+* and the button [[Image:execution-object-storage-icon]] controls the [[Debuggee's Object Storage|remote object storage]] . + + +{{tip|The tool's layout can be customized to have 2 side-by-side "left" and "right" grids holding the various information. This can be done using the button ( [[Image:toolbar-dropdown-icon]] ) from the toolbar which open the objects tool menu and then select "Edit Layout". Then you can use the tool layout editor as shown below to adjust which information you want displayed in each of the two sides. }} + + +[[Image:object-tool-layout-editor]] + + +{{note| By default, the object tool displays the full generating type for object, but this can be changed for speed concern in the [[Debugging preferences|preferences]] . The same way, through the [[Debugging preferences|preferences]] , the user can enable or disable the evaluation of the [[Debug output|Debug Output]] feature. }} + +{{note|When a row displays a pink background, this indicates the value has changed as a result of the previous step. }} + +{{tip|The [[Expression evaluation|expression evaluator tools]] (also known as Watch tools) provide many of the same features as the object tool along with even more functionality. }} + + + + + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-reference/debugger/object-tool/object-viewer-also-known-expanded-display.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-reference/debugger/object-tool/object-viewer-also-known-expanded-display.wiki new file mode 100644 index 00000000..4f913097 --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-reference/debugger/object-tool/object-viewer-also-known-expanded-display.wiki @@ -0,0 +1,68 @@ +[[Property:title|Object Viewer (also known as Expanded display)]] +[[Property:weight|4]] +[[Property:uuid|62002ce3-37f9-22de-39f0-0930468a67be]] +You can either show the "Object Viewer" tool through the menu path + +Execution --> Tools --> Object Viewer + +or pop-up the object viewer dialog by clicking the button ( [[Image:debugger-expand-info-icon]] ) located in the tool bar of the [[Object tool|objects tool]] and [[Expression evaluation|watch tool]]. + +This command [[Image:debugger-expand-info-icon]] opens an object viewer dialog when an object is dropped onto the button. + +Depending the nature of the dropped object, you can view it with one or more of several viewers: +* '''Object dump''': dump a text representation of the value +* '''String display''': string representation +* '''XML display''': xml viewer +* '''Object browse''': browse the object, as you would do in the Object or watch tools +* '''Object internal''': display some internal data elements such as: +** class_name +** type_name +** dynamic_type +** field_count +** deep_physicial_size +** physical_size + +{{note|The "string display" viewer is available for objects with a string representation, for instance objects whose types conform to [[ref:libraries/base/reference/string_8_chart|STRING_8]] or conform to [[ref:libraries/base/reference/debug_output_chart|DEBUG_OUTPUT]] (see [[Debug output|Debug Output]]. )}} + +{{note|The "XML display" is available for objects eligible for "String display", and whose string representation has XML content. The viewer displays XML in a tree-enabled grid.}} + + +'''String display viewer:''': + + +[[Image:expanded-display-default]] + +Displays the object as a string, by default the displayed length is 50:
+If the limits are over the current slice limits, the displayed string will end by "..." to show there is more.
+If you click on the auto expand button [[Image:debugger-object-expand-icon]] , the slice limits will be set to the lower and upper limits of the string value. + +You can enable or disable the line wrapping by clicking onto [[Image:general-word-wrap-icon]] . + + + +'''Object dump viewer:''' + + +[[Image:object-viewer-dump]] + + +'''Object browse viewer:''' + + +[[Image:object-viewer-browse]] + + +'''Object internal viewer:''' + + +[[Image:object-viewer-internal]] + + +'''XML viewer:''' + + +[[Image:object-viewer-xml]] + + + + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-reference/debugger/object-tool/remove-object-command.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-reference/debugger/object-tool/remove-object-command.wiki new file mode 100644 index 00000000..96e312b9 --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-reference/debugger/object-tool/remove-object-command.wiki @@ -0,0 +1,10 @@ +[[Property:title|Remove object command]] +[[Property:weight|5]] +[[Property:uuid|42b5ea32-ef9c-207f-7dbe-c871a4515db3]] +Located in the [[Object tool|object tool]] toolbar, this command [[Image:general-delete-icon]] discards an object from the [[Object tool|object tool]]. All top-level objects can be removed, except the first one, which is the object relative to the [[Call stack tool|current call stack element]] . + +Left-clicking on this button removes the selected object from the [[Object tool|object tool]], if possible. It is also possible to [[Pick-and-drop mechanism|drop]] an object onto the button to remove the object. + + + + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-reference/debugger/object-tool/set-slice-size-command.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-reference/debugger/object-tool/set-slice-size-command.wiki new file mode 100644 index 00000000..04403c63 --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-reference/debugger/object-tool/set-slice-size-command.wiki @@ -0,0 +1,22 @@ +[[Property:title|Set slice size command]] +[[Property:weight|3]] +[[Property:uuid|ce2469a3-cf00-554e-47bd-5e8b2fdbc783]] +Located in the object tool toolbar, this command [[Image:debugger-set-sizes-icon]] changes the display size of special objects (i.e. objects whose class is [[ref:libraries/base/reference/special_chart|SPECIAL]], most importantly in the representation of arrays and strings). Because special objects may contain thousands of attributes, only the first fifty are displayed by default. If left-clicked, a dialog is popped up that sets the exploration indices of special objects that will be loaded in the future. + +This pop-up also shows the "Maximum displayed string size" in the grid ([[Object tool|object tool]], or the [[Expression evaluation|watch tools]]). + +This dialog changes the settings for future special objects: + + +[[Image:set-slice-size-dlg]] + + +You can affect the display of a single special object only by [[Pick-and-drop mechanism|dropping]] the object onto this ( [[Image:debugger-set-sizes-icon]] ) command. A dialog box appears, and the special object that is dropped is shrunk or expanded in the tree according to the new exploration indices you set in the dialog box. The dropped object may be any special object, top-level or not. + +This dialog changes the settings for a single special object (the dropped object) : + + +[[Image:set-default-slice-size-dlg]] + + + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-reference/debugger/stack-overflow-prevention.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-reference/debugger/stack-overflow-prevention.wiki new file mode 100644 index 00000000..e45d443e --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-reference/debugger/stack-overflow-prevention.wiki @@ -0,0 +1,24 @@ +[[Property:title|Stack overflow prevention]] +[[Property:weight|-6]] +[[Property:uuid|bd988599-a444-6090-c3c4-a5c7de20b294]] +Stack overflow prevention makes it possible to have the debugger detect stack overflow situations and warn you before they occur. + +You can control this option through a dialog accessible via the menu path: + + +Execution --> Overflow prevention... + + +The dialog lets you decide at which call stack depth a warning should be issued. + + +[[Image:stack-overflow-dlg]] + + +By default, a warning is issued when the debugged program reaches a stack depth of 1,000 elements. + + +{{note|Once an application has stopped at the selected level, it will not stop again until its stack depth goes below the critical stack depth again. }} + + + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-reference/debugger/threads-tool.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-reference/debugger/threads-tool.wiki new file mode 100644 index 00000000..fea7cb49 --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-reference/debugger/threads-tool.wiki @@ -0,0 +1,20 @@ +[[Property:title|Threads tool]] +[[Property:weight|-8]] +[[Property:uuid|457b71dc-4609-dac1-8458-cd9b64fd5945]] +This tool displays the list of current Eiffel threads.
+To show this tool, use the menu path: + +Execution --> Tools --> Threads + + +[[Image:threads-tool|Threads tool]] + + +By double clicking on a row, you change the current thread for the debuggee (application). If you double click on "Note" cell, you can edit a note, this can be useful to identify a thread during the debugging session. + + +The highlighted line shows the current thread. + + + + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-reference/diagram-tool/contexts.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-reference/diagram-tool/contexts.wiki new file mode 100644 index 00000000..5655707f --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-reference/diagram-tool/contexts.wiki @@ -0,0 +1,19 @@ +[[Property:title|Contexts]] +[[Property:weight|4]] +[[Property:uuid|6adec8c0-0eb4-d616-c7be-ef7480673b1c]] +A diagram in the diagram tool is always the context of a certain class or cluster. Context means the direct relations up to a certain depth. + +For clusters, the relations are: +* subclusters +* superclusters + +The relations for classes are: +* ancestors +* descendants +* clients +* suppliers +This is an example of the class LIST, with ancestor depth 2, descendant depth 2 and both client and supplier depth zero.
[[Image:bon-list-relations]]

+ + + + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-reference/diagram-tool/diagram-tool-code-generation.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-reference/diagram-tool/diagram-tool-code-generation.wiki new file mode 100644 index 00000000..d8f3342d --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-reference/diagram-tool/diagram-tool-code-generation.wiki @@ -0,0 +1,98 @@ +[[Property:title|Diagram tool: Code generation]] +[[Property:weight|5]] +[[Property:uuid|f0ed7470-cc28-a0e3-df16-36a47d34f852]] +All actions taken in the diagram tool that modify a part of the system are immediately reflected in the Eiffel system. Following is a summary of these actions. +* When you create a new class, this is the generated empty class:
+ +note + description: "Objects that ..." + author: "" + date: "$Date: 2008-09-02 13:54:45 +0200 (Tue, 02 Sep 2008) $" + revision: "$Revision: 74646 $" + +class + CLASS_NAME + +end -- class CLASS_NAME + + +* When you delete a class, the class file is removed from the disk. +* When you add a parent to a class, the parent is inserted in the existing inheritance clause, ''without'' any additional ( undefine/ select/etc.) clauses to solve possible conflicts.
+ +note + description: "Objects that ..." + author: "" + date: "$Date: 2008-09-02 13:54:45 +0200 (Tue, 02 Sep 2008) $" + revision: "$Revision: 74646 $" + +class + CLASS_NAME + +inherit + NEW_PARENT + +end -- class CLASS_NAME + + +* When removing an inheritance link, the entire parent clause is removed, i.e. including any redefine/undefine/etc. until the matching end. +* When creating a client link, a function or attribute is generated by the feature wizard. When creating a function, this code is generated:
+ +note + description: "Objects that ..." + author: "" + date: "$Date: 2008-09-02 13:54:45 +0200 (Tue, 02 Sep 2008) $" + revision: "$Revision: 74646 $" + +class + CLASS_NAME + +feature -- Access + + f: TYPE + -- Client from CLASS_NAME to TYPE. + do + end + +end -- class CLASS_NAME + + +* If you choose to create an attribute for the client link, and optionally specify to generate a set-procedure and an invariant, the following code will be pasted into the class text:
+ +note + description: "Objects that ..." + author: "" + date: "$Date: 2008-09-02 13:54:45 +0200 (Tue, 02 Sep 2008) $" + revision: "$Revision: 74646 $" + +class + CLASS_NAME + +feature -- Access + + f: TYPE + -- Client from CLASS_NAME to TYPE. + +feature -- Element change + + set_f (a_f: TYPE) + -- Client from CLASS_NAME to TYPE. + require + a_f_not_void: af /= Void + do + f := a_f + ensure + f_assigned: f = a_f + end + +invariant + f_not_void: f /= Void + +end -- class CLASS_NAME + + +* When removing a client link, only the matching function or attribute is removed. Any additionally generated set-feature or invariant is not removed. +* When removing a cluster, the associated directory is not erased, but the reference to the cluster is removed from the configuration file. At this time, it is not possible to create a cluster using the diagram tool, only to remove one. + + + + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-reference/diagram-tool/diagram-toolbar.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-reference/diagram-tool/diagram-toolbar.wiki new file mode 100644 index 00000000..b916e78a --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-reference/diagram-tool/diagram-toolbar.wiki @@ -0,0 +1,77 @@ +[[Property:title|Diagram toolbar]] +[[Property:weight|2]] +[[Property:uuid|c0ea47ac-e616-0762-b1bf-53d87df8ce9f]] +The toolbar of the diagram contains these buttons: +* [[Image:diagram-target-cluster-or-class-icon]] Target to cluster or class
+**Drop a class or a cluster on this icon to build the corresponding diagram. + +* [[Image:new-inheritance-link-icon]] [[Creating inheritance links|Create new inheritance links]]
+**Selecting this button allows you to create inheritance, client-supplier or aggregate links by picking from one class and dropping on the other. + +* [[Image:16x16--new-class-icon]] [[Creating a new class|Create a new class]]
+**Pick from this button and drop on the diagram to add a new class. + +* [[Image:general-undo-icon]] [[Undoing and redoing|Undo last action]]
+**Click to undo the last action. + +* [[Image:general-undo-history-icon]] [[Undoing and redoing|History tool]]
+**Click to open the '''History tool'''. + +* [[Image:general-redo-icon]] [[Undoing and redoing|Redo last action]]
+**Click to redo the last undone action. + +* [[Image:general-reset-icon]] [[Removing items from a view|Remove figure]]
+**Drop figures in this hole that you want to remove from the view only. + +* [[Image:diagram-choose-color-icon]] [[Changing colors of classes|Change color]]
+**Drop class bubbles in this hole to change their color, or click this button and change the color of all class bubbles at once. + +* [[Image:diagram-fill-cluster-icon]] [[Retrieving all classes into a cluster|Include all classes of cluster]]
+**Drop a cluster in this hole to show all classes of the cluster in this view. + +* [[Image:diagram-depth-of-relations-icon]] [[Changing system exploration depth|Select depth of relations]]
+**Click to bring up the '''Select depth''' dialog. + +* [[Image:diagram-zoom-out-icon]] [[Zooming a diagram|Zoom out]]
+**Shrink the diagram. + +* [[Image:diagram-fit-to-screen-icon]] [[Zooming a diagram|Fit Diagram to Screen]]
+**Fit the diagram to the screen dimensions so it is all visible. + +* [[Image:diagram-zoom-in-icon]] [[Zooming a diagram|Zoom in]]
+**Enlarge the diagram. + +* [[Image:diagram-inheritance-link-icon]] [[Showing or hiding links and labels|Show/hide inheritance links]]
+**Toggle visibility of all inheritance links in the view. + +* [[Image:diagram-supplier-link-icon]] [[Showing or hiding links and labels|Show/hide client-supplier links]]
+**Toggle visibility of all client-supplier links in the view. + +* [[Image:diagram-show-labels-icon]] [[Showing or hiding links and labels|Show/hide labels]]
+**Toggle visibility of all client link labels in the view. + +* [[Image:diagram-export-to-png-icon]] [[Exporting a diagram to PNG image file|Export diagram to.png]]
+**Click to generate a .png file from current view. + +* [[Image:diagram-toggle-quality-icon]] Toggles the drawing quality. + +* [[Image:diagram-toogle-physics-icon]] Toggles the physics mode on and off. + +* [[Image:diagram-view-uml-icon]] Toggles view between BON notation and UML. + +* [[Image:diagram-anchor-icon]] Allows to anchor or unanchor a class/cluster figure. + +* [[Image:diagram-physics-settings-icon]] Displays physics settings dialog to control physics behavour. + +* [[Image:16x16--general-delete-icon]] [[Deleting items|Delete]]
+**Drop items in this hole to remove them from the system. + +* [[Image:diagram-show-legend-icon]] Toggle cluster color legend. + +* [[Image:diagram-force-right-angles-icon]] [[Using the link tool|Put handles on a link]]
+**Click on this button to toggle right angles on all links in the view. Drop a link on it to bring up the link tool for that link. + +In addition to these toolbar buttons there is also a drop down list for selecting various zoom percentages on the current view, and a view list for switching between previously saved views/layouts of various parts of the system. + + + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-reference/diagram-tool/index.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-reference/diagram-tool/index.wiki new file mode 100644 index 00000000..e72d1ebe --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-reference/diagram-tool/index.wiki @@ -0,0 +1,12 @@ +[[Property:title|Diagram tool]] +[[Property:weight|-6]] +[[Property:uuid|a3ca34e5-10e9-fac3-4795-9222074273a6]] +The Diagram Tool of EiffelStudio is your graphical interface to system structures. You can use it both to ''examine'' systems already built or under development, and to ''build'' these systems graphically. EiffelStudio supports complete seamlessness and reversibility between the Diagram Tool's graphical view and the text view of other EiffelStudio tools: whenever you make a change or addition with the graphical tool, EiffelStudio will update the text; and when you change the text, EiffelStudio will update the Diagram Tool's representation on the next compilation. + +Use the diagram tool to design new Eiffel systems, or create [http://bon-method.com BON] (Business Object Notation) diagrams of existing ones. BON is a simple, clear, self-explanatory notation that you will learn in a few minutes just by looking at some examples. The Diagram Tool provides you with lots of features to manage different views of an Eiffel system, or parts of it. + + +
[[Image:devel-diagram]]
+ + + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-reference/diagram-tool/notation.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-reference/diagram-tool/notation.wiki new file mode 100644 index 00000000..715d2e82 --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-reference/diagram-tool/notation.wiki @@ -0,0 +1,99 @@ +[[Property:title|Notation]] +[[Property:weight|1]] +[[Property:uuid|615baff7-4dbe-2f2f-9a02-c05b20143478]] +The diagram tool uses the [http://bon-method.com BON] (Business Object Notation) to represent Eiffel systems. This article will give a summary of all components of an EiffelStudio diagram. For detailed information on BON, please read [http://bon-method.com/book.htm Seamless Object-Oriented Software Architecture] by Kim Walden and Jean-MarcNerson, Prentice Hall 1994. + +==Class== + +[[Image:bon-class]] + +A class is represented by an ellipse(sometimes referred to as ''bubble''). It contains the class name and formal generics of the Eiffel class it represents. Second, it displays information about properties of a class. These properties are: +* Deferred: class is declared as deferred. + + +[[Image:bon-class-deferred]] + + +* Effective: class is not deferred and has at least one deferred parent, or redefines one ore more features. + + +[[Image:bon-class-effective]] + + +* Persistent: class inherits STORABLE or has indexing tag persistent. + + +[[Image:bon-class-persistent]] + + +* Interfaced: class has one ore more external features. + + +[[Image:bon-class-interfaced]] + + +* Reused: class resides in a precompiled library or in a library cluster. + + +[[Image:bon-class-reused]] + + +* Root class: class has the program's entry point. + + +[[Image:bon-class-root]] + + +{{seealso|
+[[Rename Class|Changing class names]] }} + + +==Cluster== + +A cluster is a collection of classes and sub-clusters. It is represented by a stippled, rounded rectangle. The cluster name is in a similar rectangle, by default located at the top of the cluster just outside of it. + + +[[Image:bon-cluster]] + + +A cluster can be iconified, which means it is minimized to take up as less space as possible. + + +[[Image:bon-cluster-iconified]] + + + +{{seealso|
+[[Iconifying and restoring a cluster|Iconifying a cluster]] }} + + +==Inheritance links== + +Inheritance between classes is represented by an arrow from a class to its parent. Typically, inheritance links point upwards. +
[[Image:bon-inheritance]]

+
+ +{{seealso|
+[[Creating inheritance links|Creating inheritance links]] }} + + +==Client/supplier links== + +Client relationships between classes are represented by an arrow with a double line from the client to the supplier. Typically, these links point to the right. + + +[[Image:bon-client]] + + +A special kind of relationship is the aggregate client/supplier link. Aggregate means that the supplier is an integral part of the client. In the class text, it corresponds to expanded features. In the diagram, an aggregate link has a little line along the back side of the arrow. + + +[[Image:bon-agg-client]] + + +{{seealso|
+[[Creating client-supplier links|Creating client/supplier links]] }} + + + + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-reference/diagram-tool/views.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-reference/diagram-tool/views.wiki new file mode 100644 index 00000000..a1a7fb2a --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-reference/diagram-tool/views.wiki @@ -0,0 +1,23 @@ +[[Property:title|Views]] +[[Property:weight|3]] +[[Property:uuid|e31f55f4-907c-0df3-2144-3820765800a8]] +Every class or cluster has one or more views. Every view shows the [[Contexts|context]] of a class or cluster, a subset of the Eiffel system. For example, for a certain cluster, you can show only the hierarchy of the classes in it, but you could have a second view that shows only a couple of classes in it, but with all relations between them. +
[[Image:diagram-view-combo]]
+The view combo box, as seen in the image above, can be used to add a view or switch to a previously added one. Every class and cluster has a view "DEFAULT" that is generated automatically. If you create a new view and move for example a class around in it, the "DEFAULT" view is unaffected. + +The Diagram tool provides you with the following possibilities to manipulate views: +* [[Adding a view|Adding a view]] +* [[Deleting a view|Deleting a view]] +* [[Showing or hiding links and labels|Showing or hiding links and labels]] +* [[Removing items from a view|Removing items from a view]] +* [[Changing colors of classes|Changing colors of objects]] +* [[Using the link tool|Using the link tool]] +* [[Changing system exploration depth|Changing system exploration depth of objects]] +* [[Retrieving all classes into a cluster|Retrieving all classes into a cluster]] +* [[Iconifying and restoring a cluster|Minimizing a cluster and restoring it to its normal state]] +
+
+ + + + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-reference/eiffel-information-system/eis-incoming/eiffel-scheme-syntax.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-reference/eiffel-information-system/eis-incoming/eiffel-scheme-syntax.wiki new file mode 100644 index 00000000..d99de665 --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-reference/eiffel-information-system/eis-incoming/eiffel-scheme-syntax.wiki @@ -0,0 +1,27 @@ +[[Property:title|Eiffel Scheme Syntax]] +[[Property:weight|0]] +[[Property:uuid|503b260c-99c5-06fb-2953-8899866c1c51]] +The Eiffel scheme syntax is: + + + eiffel:? + + + +where is a combination of following parts, connected by '''&''' if more than one part are required: + +* , in the form of system=to_be_replaced, '''to_be_replaced''' consists of system_name or uuid of the system, or both connected by "'''.'''". +* , in the form of target=to_be_replaced, '''to_be_replaced''' consists of target_name or uuid of the system, or both connected by "'''.'''". +* , in the form of cluster=to_be_replaced, '''to_be_replaced''' is the name of the cluster. +* , in the form of class=to_be_replaced, '''to_be_replaced''' is the name of the class. +* , in the form of feature=to_be_replaced, '''to_be_replaced''' is the name of the feature. + + +{{note|All parts above are unordered. }} + +{{seealso|
+[[EIS incoming Examples|Examples]] }} + + + + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-reference/eiffel-information-system/eis-incoming/eis-incoming-examples.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-reference/eiffel-information-system/eis-incoming/eis-incoming-examples.wiki new file mode 100644 index 00000000..2dd169c1 --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-reference/eiffel-information-system/eis-incoming/eis-incoming-examples.wiki @@ -0,0 +1,14 @@ +[[Property:title|EIS incoming Examples]] +[[Property:weight|1]] +[[Property:uuid|24adee5e-7ccf-3280-b009-8e183ab9279c]] +The following are examples of EIS incoming URIs. +* eiffel:?class=STRING_8&feature=is_equal +* eiffel:?cluster=elks&class=STRING_8&feature=is_equal +* eiffel:?target=base&cluster=elks&class=STRING_8&feature=is_equal +* eiffel:?system=ec.D398E904-E3C8-4F8A-B9E7-6FE493CEA02F&target=base&cluster=elks&class=STRING_8&feature=is_equal +* eiffel:?class=STRING_8 +* eiffel:?cluster=elks + + + + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-reference/eiffel-information-system/eis-incoming/index.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-reference/eiffel-information-system/eis-incoming/index.wiki new file mode 100644 index 00000000..d323b5f5 --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-reference/eiffel-information-system/eis-incoming/index.wiki @@ -0,0 +1,5 @@ +[[Property:title|EIS: Incoming]] +[[Property:weight|3]] +[[Property:uuid|cf25a603-5446-9964-892c-227c4077a829]] +The EIS incoming mechanism is based on URI, and introduces a new URI scheme: '''eiffel'''. By entering the URI into the address field of a browser, or clicking on the hyperlink, an existing EiffelStudio instance or new EiffelStudio instance will try to resolve the URI and display corresponding resources. + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-reference/eiffel-information-system/eis-outgoing/index.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-reference/eiffel-information-system/eis-outgoing/index.wiki new file mode 100644 index 00000000..76986327 --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-reference/eiffel-information-system/eis-outgoing/index.wiki @@ -0,0 +1,59 @@ +[[Property:title|EIS: Outgoing]] +[[Property:weight|2]] +[[Property:uuid|773ef802-5f9f-107a-4c5d-8dcf17654d23]] +==Annotations== + +Annotations for outgoing EIS links may be applicable to: +* An individual class or feature. In this case the annotation appears in the class text, as part of an Eiffel note clause (the obsolete keyword indexing may still be supported, depending upon which syntax level is chosen in project preferences). +* A target, library or cluster. In this case the annotation appears in the associated ECF file. + +EiffelStudio provides support for entering annotations through the [[Information Tool|Information Tool]]. + +To specify a link between Eiffel and external information, you include such an annotation. + +The primary components of an annotation are: +# The '''EIS''' marker. +# The '''[[Protocols|protocol]]''', which indicates the type of external information, and making it possible for EIS to determine the associated external tool. If the '''protocol''' is omitted, its value defaults to "URI". +# The '''source'''. This is the location of the external information, for example a URL, or a file name. + +==Syntax for Annotations== + +Annotations can occur in Eiffel source code and in project configuration files (.ecf). The format of the '''EIS marker''' varies depending upon the context in which it is used. The rest of the annotation format is the same in both contexts. + +Individual annotations can be placed in Eiffel files either through the [[Information Tool]] or by manual editing of the files. + +Additionally, a special type of annotation called an '''Automatic annotation''' can be specified for Eiffel configuration [[general target options|targets]]. An automatic annotation on a target will put an implicit annotation with a variable source on each class in the target. An implicit annotation on any particular class can be overridden by an explicitly coded annotation, when necessary. + +The following example illustrates the form of an EIS annotation written in Eiffel source code. The annotation appears in the note part of a class or feature definition: + +EIS: "name=Project Requirement", "src=$(system_path)/docs/requirements.pdf", "protocol=PDF", "nameddest=4.1", "tag=requirement" + + +The '''EIS marker''' is the label '''EIS:''' (this label is called the ''Note_name'' in the ISO/ECMA Eiffel Standard syntax). The '''EIS marker''' tells the Eiffel Information System that this particular ''Note_entry'' is of interest to EIS. + +The '''name''' property assigns a name to this annotation. The name will be visible in the [[Information Tool]]. + +In this example, the '''source''' name (src) includes the string '''$(system_path)''', a reference to a [[Variable Definition|variable]], '''system_path''', which is a predefined variable for the the project location. + +The '''protocol''' is '''PDF'''. + +The '''nameddest''' property (name destination) is a specific property of PDF documents that tells the external tool for PDF documents to open the document at a particular named destination. + +The '''tag''' property associates a text tag, in this case "requirement" with this link. Tags show up in the [[Information Tool]] and can be used to organize annotations. + +The following is an example of an annotation Eiffel configuration (.ecf) file: + + + + + + + +Eiffel configuration files have XML definitions, so this is just an XML version of what was coded into an Eiffel class above. The annotation appears in a element. The '''''' element plays role of '''EIS marker''', just as '''EIS:''' does in the note entry in the source code example above. The '''''' element in Eiffel configuration files is supported in ECF schema version 1.4 and later. + + +{{seealso|
+[[Variable Definition|Variable Definition]] }} + + + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-reference/eiffel-information-system/eis-outgoing/information-tool/annotation-management.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-reference/eiffel-information-system/eis-outgoing/information-tool/annotation-management.wiki new file mode 100644 index 00000000..3050418d --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-reference/eiffel-information-system/eis-outgoing/information-tool/annotation-management.wiki @@ -0,0 +1,48 @@ +[[Property:title|Annotation Management]] +[[Property:weight|1]] +[[Property:uuid|696457ef-ac1f-40c1-a0da-54900d9cccf8]] +The Information Tool gives you the ability to '''add''', '''modify''', and '''remove''' annotations from within the tool. When you manage annotations via the Information Tool, the appropriate text changes are made to the annotation targets. So, for example, if you use the Information Tool to add an annotation to a class, you will see the annotation after a new '''EIS marker''' in the note part of the class text. + + +{{note|Annotation management is not available in lists corresponding to tag nodes in the information tree. That is, annotations listed in ''All tags'', ''Items without tag'', and nodes for specific named tags cannot be altered. }} + +Of course, you can also use the EiffelStudio editor or an external editor to manage annotations in Eiffel source code and configuration files using the annotation syntax described in [[EIS: Outgoing]]. The advantage to using the Information Tool is that the tool modifies the files for you, making the process less prone to error. + +==Adding== + +For each node in the information tree, the list of associated annotations is visible to the right. At the bottom the list, there is an entry that is blank, except for the '''Name''' column which contains an ellipsis (" ... "). Double clicking the blank line creates a new unnamed annotation. You can then modify the new entry as you wish. + +==Modifying== + +Select a line in the annotation list, then click into a column you wish to change. This will activate ''editing/choosing'' mode. Now you can edit text in the column or if the column is a drop down list, you can choose an alternative entry. Once the editing area drop down list is deactivated, the modification is done and synchronized into code automatically. + +==Removing== + +By pressing '''Delete''', or clicking the ''delete'' button [[Image:16x16--general-delete-icon]] on the bottom toolbar, you will delete any selected annotations in the list. This deletes the annotation entries from the list and also from the corresponding the Eiffel class or configuration text. + + +{{note|Multiple entries in the annotation list can be deleted by selecting them all prior to clicking ''delete''. }} + +==Enabling and disabling automatic annotation entries== + +Automatic annotations can be enabled for a particular project target. Once enabled, each class in the target will exhibit an implicit annotation with a particular source. You can define the source at the same time you enable automatic annotations for a target. + +To enable automatic annotations, select the desired target in the information tree. When you do this, the button on the bottom toolbar with the automatic annotation [[Image:automatic annotation icon]] icon becomes enabled. Click this button and you will see the '''Edit Automatic EIS Entry'' dialog box as in Figure 1. + + +[[Image:edit automatic eis entry dialog]] + +Figure 1. The Edit Automatic EIS Entry dialog + + +You enable automatic annotations by checking the box labeled '''Enable Auto-Entry'''. You construct an appropriate source from explicit strings and/or variable names in the are labeled '''Source'''. + +You can disable automatic annotation entries on a target by invoking the Edit Automatic EIS Entry dialog box and un-checking the '''Enable Auto-Entry''' checkbox. + + +{{note|Most changes made to annotations via the Information Tool are irreversible. However, changes made to annotations on a class or feature which is currently open in the Editor Pane may be reversed by using the editor's '''Undo''' command. The '''undo''' feature should be used with caution as the '''undo''' does not function in some early EIS versions.}} + + + + + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-reference/eiffel-information-system/eis-outgoing/information-tool/browsing-information.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-reference/eiffel-information-system/eis-outgoing/information-tool/browsing-information.wiki new file mode 100644 index 00000000..bfd75edc --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-reference/eiffel-information-system/eis-outgoing/information-tool/browsing-information.wiki @@ -0,0 +1,73 @@ +[[Property:title|Browsing Information]] +[[Property:weight|0]] +[[Property:uuid|2260eabd-cbc9-c385-6295-96474249953f]] +[[Image:information tool v71|1000px]] + +Figure 1: The Information Tool + + +==Information Tree== + +On the left of the tool window is the information tree. The tree displays all locations which contain annotations, as well as a subtree of tags by which annotations can be organized. Clicking or pressing enter on a node of the tree displays the list of annotations associated with that node. In Figure 1, the node APPLICATION, a class, has been selected, and its annotations are listed on the right. + +A node in the information tree that has annotations will be decorated with the small "i" icon [[Image:EIS information icon]], as you see in the case of APPLICATION. + +You can navigate to the following types of nodes in the information tree: +* Target +* Cluster +* Library +* Class +* Feature +* Items without tags + +==Annotation List== + +The annotation list appears on the right of the tool window. + +The following columns are available in the list: +* '''Target''' - the development object where that piece of annotation belongs to. Typical locations are target, cluster, class and feature. +* '''Source''' - the address of the resource, typically a URL or file path. Variables can be used. +* '''Parameters''' - additional information relevant to certain protocols, for example, a page number in a PDF document. +* '''[[Protocols|Protocol]]''' - the type of the Source. +* '''Name''' - the name of the annotation. +* '''Tags''' - terms or phrases used to categorize annotations. Tags are separated by '''","''' +* '''Override''' - checkbox is checked if an implicit, automatically generated annotation is being overridden by the annotation in this list entry. If this list entry is itself an implicit annotation, this column shows the automatic annotation [[Image:automatic annotation icon]] icon. Override is defined only for annotations on classes. + + + + +{{note|EIS ignores any parameters in '''Parameters''' which are not used by the '''protocol''' specified in the entry. }} + + +{{tip| Clicking on title of each column sorts the list based on the values in that column. }} + + +==Opening Resources== + +The most straightforward way of opening a resource from the Information tool is to select the annotation containing the resource and click the "Go to" button on the status bar below the annotation list. + +The resource associated with a particular annotation can also be opened by double-clicking on the annotation in the Information Tool list. Alternatively, you can use the arrow keys to highlight the annotation in the Information Tool list and then press enter. EIS opens the resource associated with the annotation using the external tool for the resource's protocol. So, for example, URI resources will be opened in the default web browser. + +While using EiffelStudio, pressing '''F1''' while the cursor is in the editor pane will access annotations associated with the Eiffel object that is currently shown in the editor pane. If only one annotation is available, then its resource is automatically opened by EIS. If more than one annotation is available, the '''Select help document''' dialog box (see Figure 2) appears providing the name and type of the available resources. You can use the dialog to choose which resources you wish to display. + + +[[Image:select help document dialog]] + +Figure 2: The Select Help Document dialog box + + +==Sweeping Information== + +Sweeping annotation information will update the Information Tool with current data for all the annotations in the current system. There are two approaches to sweeping information: +* '''Automatic''' - EIS automatically sweeps information at times when Information tool is visible. On the bottom toolbar, clicking the ''automatic sweeping'' toggle button [[Image:automatic sweeping icon]] to the ''down'' position activates automatic sweeping. Clicking the button back to the ''up'' position disables automatic sweeping. +* '''Manual''' - Clicking the ''manual sweeping'' button [[Image:manual sweeping icon]] on the bottom toolbar triggers an immediate manual sweep. + +The progress bar in the bottom of the tool indicates the progress of a currently executing sweep. + + +==Using Pick-and-Drop with the Information tool== + +You can use pick-and-drop with the information tool. If you drop a pebble on the information tree, the annotation list, the "Locate currently edited class/cluster" icon [[Image:EIS locate class or cluster icon]] on the mini-toolbar, or the Info tab [[Image:EIS info tab]], the Information tool will find and display any annotations associated with the dropped pebble. If you drop a pebble on the "Add" button [[Image:EIS add button]] a new entry will be created for the object represented by the pebble. Lastly, dropping a pebble representing a target or cluster on the "Edit EIS auto-node generation property" button [[Image:automatic annotation icon]] will display the automatic node generation dialog for the target or cluster associated with the pebble. + + + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-reference/eiffel-information-system/eis-outgoing/information-tool/change-analysis.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-reference/eiffel-information-system/eis-outgoing/information-tool/change-analysis.wiki new file mode 100644 index 00000000..808b6c94 --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-reference/eiffel-information-system/eis-outgoing/information-tool/change-analysis.wiki @@ -0,0 +1,32 @@ +[[Property:title|Change Analysis]] +[[Property:weight|0]] +[[Property:uuid|a503cf13-6374-9932-5ee2-a69b363e6701]] +[[Image:information tool change analysis]] + +The information tool can track changes in an Eiffel system or external resources side, and potentially affected items on either side are listed. + +== Major Features == +* '''Affected target:''' List of elements of the Eiffel system that would be affected by a change in external resources. +* '''Affected source:''' List of external resources that might be affected by changes in the Eiffel system. +* '''Change acknowledgement:''' Acknowledgement of the changes which will be ignored with no further actions. + +== Typical Work Flows == + +=== Affected external resources caused by a change in the Eiffel system === +# Open a class, add an Information entry with an external resource in the class. +# Start working on that class, save it at as you normally do on regular basis. +# Open the information tool, go to Affected source item in the left tree. +# Check the list of external resources that might be affected by last changes. +# Acknowledge the changes once you have updated the external resource accordingly (possibly no change is required in the case of simple system changes). + +=== Affected items in the Eiffel system caused by an external resource change === +# Open a class, add an Information entry with an external resource in the class. +# Start working on that external resource, save it at as you normally do on regular basis. +# Open the information tool, go to Affected target in the left tree. +# Check the list of classes that might be affected by last changes of the external resource. (You may need to click on the "sweep the system now." button to get a full list if auto-sweeping is not enabled.) +# Acknowledge the changes once you have updated the Eiffel system accordingly (possibly no change is required in the case of a simple edit in the external resource). + +== Current limitations == +The tracking of external resource changes is limited to external resources that are local files. If an external resource is a URL, it will not detect any potential changes done at that URL. + + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-reference/eiffel-information-system/eis-outgoing/information-tool/index.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-reference/eiffel-information-system/eis-outgoing/information-tool/index.wiki new file mode 100644 index 00000000..203ca86d --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-reference/eiffel-information-system/eis-outgoing/information-tool/index.wiki @@ -0,0 +1,10 @@ +[[Property:title|Information Tool]] +[[Property:weight|0]] +[[Property:uuid|26e2c799-b48a-c588-cdf1-dd47b1994b09]] +The Information tool is an EiffelStudio tool that helps you create outgoing annotations in your Eiffel projects. Read more about using the Information tool on the following pages. + + +[[Image:information tool v71|1000px]] + + + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-reference/eiffel-information-system/eis-outgoing/information-tool/protocols.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-reference/eiffel-information-system/eis-outgoing/information-tool/protocols.wiki new file mode 100644 index 00000000..bd89396a --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-reference/eiffel-information-system/eis-outgoing/information-tool/protocols.wiki @@ -0,0 +1,21 @@ +[[Property:title|Protocols]] +[[Property:weight|2]] +[[Property:uuid|69b4d9d4-570e-e7ac-087b-88449a608d0b]] +EIS supports following protocols: +* URI: This protocol does not need to specified. By default, it will be taken if nothing is specified or unknown protocol is specified. + +* PDF: PDF protocol supports three parameters: "type" "page" and "nameddest". (Windows only) +** '''type''' - "file" is used to open PDF files in PDF reader. Otherwise in a browser. +** '''page''' - a page number at which to open a document. +** '''nameddest''' - a named destination at which to open a document. + +* DOC: Represents a Microsoft Word document. +** '''bookmark''' - Name of a Microsoft Word document bookmark. + +The list of currently supported protocols is always available in a drop-down menu associated with entries in the '''Protocol''' column of the [[Browsing information|Information tool]]'s annotation list. + + +{{note|The status of supported protocols described above is as of EiffelStudio version 7.1. }} + + + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-reference/eiffel-information-system/eis-outgoing/information-tool/variable-definition.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-reference/eiffel-information-system/eis-outgoing/information-tool/variable-definition.wiki new file mode 100644 index 00000000..2ea1f419 --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-reference/eiffel-information-system/eis-outgoing/information-tool/variable-definition.wiki @@ -0,0 +1,38 @@ +[[Property:title|Variable Definition]] +[[Property:weight|3]] +[[Property:uuid|7705ab33-a505-7711-a106-5fedd2e1040e]] +==Sources of variables== + +EIS supports following types of variables which can be used in '''Source''' of annotation list. +* EiffelStudio installation built-in variables +** ISE_WIKI = http://dev.eiffel.com +** EIFFELROOM = http://www.eiffelroom.com +** ISE_DOC = http://docs.eiffel.com  +** ISE_DOC_UUID = http://doc.eiffel.com/isedoc/uuid  +** ISE_DOC_REF = http://doc.eiffel.com/isedoc/eis  + +* Other EiffelStudio built-in variables +** system_path = The path of the system being annotated + +* Context related built-in variables. These variables can be used in specific context. For instance, '''feature_name''' refers to the name of the feature with which an annotation is associated. +** feature_name +** class_name +** group_name +** target_name + +{{note|A context related built-in variable is only valid in a annotation that is associated with a component to which the variable name refers. For example, '''feature_name''' has no effect if used in a '''target''' component.}} + +* Individual system or library preference variables. This kind of variable is defined in your Project Settings. Manage these variables by following this path in the System tree on the left of the Project Setting dialog: + + System -> Target -> Advanced -> Variables + + +* Environment variables. Variables defined in the operating system environment. + + +==Accessing variables from the Information tool== + +When you use the Information tool, the list of all available variables is available through auto-completion when you are typing in an entry under the '''Source''' column of the annotations list. You may either type the dollar-sign '''"$"''' or '''"Ctrl + Space"''' to invoke auto-completion. What you will see in this case is the entire list of available variables, as enumerated above. Bear in mind that this includes all environment variables defined in your operating system environment, which means that some of the entries shown would not be appropriate for use as variables for EIS purposes. + + + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-reference/eiffel-information-system/index.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-reference/eiffel-information-system/index.wiki new file mode 100644 index 00000000..a7aee410 --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-reference/eiffel-information-system/index.wiki @@ -0,0 +1,32 @@ +[[Property:title|Eiffel Information System]] +[[Property:weight|-2]] +[[Property:uuid|7e0394e1-cb31-fae3-79b6-9d1847ef8db7]] +==Introduction== + +The Eiffel Information System (EIS) provides a unified mechanism for linking development objects - e.g., classes and features - of Eiffel systems with '''external''' information resources. External means information other than Eiffel program texts. Usually the tools associated with external resources are separate from Eiffel, such as web browsers. Examples of external information resources and possible corresponding external tools are: +* Resource: Web page -- External Tool: default web browser +* Resource: PDF document -- External Tool: Adobe Acrobat +* Resource: Microsoft Word document -- External tool MS Word + +EIS is also intended to be the standard mechanism for obtaining help on Eiffel and EiffelStudio, replacing previous solutions. In that case, external tools may actually be Eiffel tools. + +EIS makes two mechanisms available to users: '''Outgoing''' (from Eiffel to external tools), '''Incoming''' (the reverse). + +Examples of outgoing mechanisms include: +* Associating EIS '''annotations''' containing references to external resources with certain Eiffel components of Eiffel systems. +* Automatically opening the corresponding external tool to display or edit information associated with an annotation. +* Listing all external information (in a class, cluster or entire system) corresponding to a specified tag. + +Examples of incoming mechanisms include: +* For supported tools, selecting external information linked to an Eiffel developer object and having EiffelStudio open automatically and targeted to that object. + +==EIS supports the Eiffel method== + +EIS plays an important role in the Eiffel software development method. Eiffel's focus is software quality. One aspect of the Eiffel method that contributes to software quality is the '''Single Product Principle''' as described in the [[ET: The Software Process in Eiffel#The Single Product Principle|Eiffel Tutorial]]: viewing the software as a single product which is expected to be repeatedly refined, extended, and improved. + +The bulk of the Single Product Principle is made possible by the seamless nature of the Eiffel method and the elegant design of the Eiffel programming language. Eiffel allows multiple views of the single software product that are appropriate to certain phases of development and readable by those fulfilling certain development roles. For example, potential reuse consumers use the '''contract''' views to explore class specifications. Also in support of seamlessness and the single product is a single integrated set of tools, the EiffelStudio IDE, working across the entire lifecycle, providing, for example, automatic extraction of the contract views just mentioned. The EiffelStudio graphical views of software (BON and UML, as produced by the Diagram Tool) directly support these ideas through their "roundtrip style". That is, changes to the diagram immediately generate code and changes to the code are reflected in the diagram. Of course documents in other formalisms, for example software requirements specifications (SRS), remain necessary for human consumption; but they should be closely linked to the core project asset, the Eiffel code. + +Within EiffelStudio, EIS effects this by ensuring that any documents existing outside the software itself can be linked to the software text and vice versa. For example, if an external software requirements document exists, say in PDF format, it is essential to record precisely the associations between elements in the requirements document and the portion of the software text in which those elements are realized. Perhaps the requirements document contains a statement: "Whenever the tank temperature reaches 50 degrees, the valve shall be closed". In the software text, there will be some feature, for example, monitor_temperature in the class TANK, reflecting this requirement. The requirements statement and the software feature should be linked to one another. This is to ensure that dependencies appear clearly, and that any change in either the requirements or the code triggers the corresponding update to the other side. This is what EIS provides. + + + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-reference/eiffel-inspector/eiffel-inspector-analyzing-results.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-reference/eiffel-inspector/eiffel-inspector-analyzing-results.wiki new file mode 100644 index 00000000..0058d695 --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-reference/eiffel-inspector/eiffel-inspector-analyzing-results.wiki @@ -0,0 +1,21 @@ +[[Property:title|Eiffel Inspector - Analyzing Results]] +[[Property:link_title|Analyzing Results]] +[[Property:weight|-13]] +[[Property:uuid|e4670791-7885-b9a0-6a1c-0d9611eb5f5d]] += Sorting and Filtering = + +The list of rule violations can be sorted by any column by clicking on its header. Click it again to switch the sorting direction. You can hide and show errors, warnings, suggestions, and hints by clicking the corresponding toggle buttons in the middle of the toolbar. Typing in the text field on the right side of the panel toolbar filters the results. The filter takes into consideration the title, the ID, the affected class, and the description of the rule. It is a live filter that filters while you are typing. Press the button on the right of the text field to clear the filter and display again all violations. + +[[Image:CA Simple Analysis|center|978px|The Results of code analysis as a list of rule violations (example)]] + += Navigating Through the Results = + +In the list of rule violations, formatted elements like classes and features are clickable and draggable like anywhere else. In order to navigate to a specific rule violation just double-click the corresponding row. The corresponding class will be opened (if needed) and the cursor will jump to the exact location of the rule violation (some violations do not have an exact location because they refer to a whole class). You can also navigate through the results using the '''Go to next rule violation''' and '''Go to previous rule violation''' buttons on the right side of the panel toolbar. + += Fixing Rule Violations = + +[[Image:CA Fixing Rule Violation|center|484px|Fixing a rule violation.]] + +Some violations provide automatic fixing. Right-clicking the corresponding row in the tool panel opens a context menu where you can choose from one or more possible fixes. When you click on ''Fix: ...'' the source code will be adapted and the project will be recompiled. + + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-reference/eiffel-inspector/eiffel-inspector-customization.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-reference/eiffel-inspector/eiffel-inspector-customization.wiki new file mode 100644 index 00000000..87b4daf5 --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-reference/eiffel-inspector/eiffel-inspector-customization.wiki @@ -0,0 +1,51 @@ +[[Property:title|Eiffel Inspector - Customization]] +[[Property:link_title|Customization]] +[[Property:weight|-12]] +[[Property:uuid|ed86093e-fed0-04b8-6fd4-b05d5de849fc]] += General Preferences = + +The ''Preferences'' button in the toolbar opens a dialog containing all preferences for the Eiffel Inspector. There you can enable and disable all rules of a certain severity, you can choose colors for the results, and there are many preferences that control the behavior of individual rules. + +[[Image:CA Preference Dialog|center|640px|Preferences]] + += Rule-specific Preferences = + +The rule-specific preferences are located in the ''Rules'' subfolder. Two preferences can be found for every rule: ''Enabled/disabled'' and the ''severity score''. Some rules have additional integer or boolean preferences like thresholds. + +[[Image:CA Rule Preferences|center|572px|Rule-specific Preferences]] + += Exporting and Importing Preference Profiles = + +Using the buttons in the preferences dialog one can export these preferences to an XML file or import them. This can be used for creating profiles that stretch across multiple machines. Just set the desired preferences on one machine, export them to a file, distribute this file, and import it. + +{{note| The Eiffel Inspector preferences are separate from the general EiffelStudio preferences. Pressing ''Restore Defaults'', ''Import ...'', or ''Export ...'' ''only'' affects preferences for the Eiffel Inspector.''}} + += Class Options = + +There are cases in which you might want to customize the Eiffel Inspector for ''parts of your code'' only. The Eiffel Inspector provides a way to set options ''per class''. You can exclude a class from being checked by certain rules. Also you can declare a class to be a ''library'' or a ''non-library'' class. All class-wide options for the Eiffel Inspector are set in the ''note clause'' (after the note keyword). + +== Library and Non-Library Classes == + +If the programmer uses the default values then a rule checks all classes. But a rule can be defined (hard-coded) not to check either ''library'' or ''non-library'' classes. How does the Eiffel Inspector now know which classes are ''library'' classes and which classes are ''non-library'' classes? This is defined by the user. If, for a certain class, the user does ''not'' define anything then the class will be analyzed in every case. Only if the user declares a class to be a ''library'' class then this class will not be checked by a rule that has disabled checking library classes. The same goes for classes that are declared as ''non-library''. + +* To declare a class to be a ''library'' class add ca_library : "true" to the (top or bottom) indexing clause. +* To declare a class to be a ''non-library'' class add ca_library : "false" to the (top or bottom) indexing clause. + +note + ca_library: true +class TEST +end + + +== Classes Ignored by Rules == + +You can declare a class to be ''ignored'' by certain rules, which is equivalent to saying that some rules shall be ''disabled'' for a class. + +To let a class be ignored by certain rules, add the ca_ignoredby tag to the (top or bottom) note clause. Then put all the relevant ''rule IDs'' separated by commas in the content. It may look like this: + +note + ca_ignoredby : "CA005, CA092" +class TEST +end + + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-reference/eiffel-inspector/eiffel-inspector-getting-started.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-reference/eiffel-inspector/eiffel-inspector-getting-started.wiki new file mode 100644 index 00000000..80fc6328 --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-reference/eiffel-inspector/eiffel-inspector-getting-started.wiki @@ -0,0 +1,17 @@ +[[Property:modification_date|Mon, 09 Jul 2018 07:47:11 GMT]] +[[Property:publication_date|Mon, 09 Jul 2018 07:47:11 GMT]] +[[Property:title|Getting Started]] +[[Property:link_title|Getting Started]] +[[Property:weight|-15]] +[[Property:uuid|81ae12fd-f643-c5ba-825c-7750929f6978]] +==Code Analyzer== +After opening an existing project with EiffelStudio, go to Project->Analyze... to run the tool. + +== A Simple Analysis == + +Select the menu item '''Analyze System Target'''. If needed, the system will be compiled now. A successful compilation is required for the Code Analyzer to run. After a successful compilation the analysis will start and will check all classes of your system. The status bar shows the progress by displaying the class currently being analyzed. As soon as the analysis is complete, results will show up in the error panel as a list of ''rule violations''. + +The results of code analysis as a list of rule violations (example). +[[Image:CA Simple Analysis|center|978px|Code Analyzer - Simple Analysis]] + +A double-click on a row will update the EiffelStudio editor to go to the position in the code where the issue lies. You may expand the row to see more details. \ No newline at end of file diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-reference/eiffel-inspector/eiffel-inspector-rules/ca001-self-assignment.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-reference/eiffel-inspector/eiffel-inspector-rules/ca001-self-assignment.wiki new file mode 100644 index 00000000..6da50044 --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-reference/eiffel-inspector/eiffel-inspector-rules/ca001-self-assignment.wiki @@ -0,0 +1,37 @@ +[[Property:title|CA001 - Self Assignment]] +[[Property:link_title|CA001]] +[[Property:weight|0]] +[[Property:uuid|d98b7fb8-37a1-05b3-a58f-baacefd5dce6]] +__NOTOC__ +=Description= +Assigning a variable to itself is a meaningless instruction due to a typing error. Most probably, one of the two variable names was misspelled. One example among many others: the programmer wanted to assign a local variable to a class attribute and used one of the variable names twice. +:{| class="doctable" +|- +| '''Scope''' +| Instruction +|- +| '''Status''' +| Enabled +|- +| '''Severity''' +| Warning +|- +| '''Applicability''' +| All +|- +| '''Score''' +| 70 +|} + + +=Example of violation= +a := a + + +=Recommendation= +Replace left or right side with something else than the other element. + +In the example, replace one of the '''a''' by something else. + +{{SeeAlso| [[CA071 - Self-comparison]]}} + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-reference/eiffel-inspector/eiffel-inspector-rules/ca002-unused-argument.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-reference/eiffel-inspector/eiffel-inspector-rules/ca002-unused-argument.wiki new file mode 100644 index 00000000..83e04b8f --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-reference/eiffel-inspector/eiffel-inspector-rules/ca002-unused-argument.wiki @@ -0,0 +1,37 @@ +[[Property:title|CA002 - Unused argument]] +[[Property:link_title|CA002]] +[[Property:weight|0]] +[[Property:uuid|fc2cf9c2-76b5-5d2f-4d60-c8dfbc677427]] +__NOTOC__ +=Description= +A feature should only have arguments which are actually needed and used in the computation. +:{| class="doctable" +|- +| '''Scope''' +| Feature +|- +| '''Status''' +| Disabled +|- +| '''Severity''' +| Warning +|- +| '''Applicability''' +| All +|- +| '''Score''' +| 40 +|} + + +=Example of violation= +square (x, y: INTEGER): INTEGER + do + Result := x * 2 + end + +=Recommendation= +Remove argument and update callers. + +In the example, remove the argument '''y''' from the argument list. + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-reference/eiffel-inspector/eiffel-inspector-rules/ca003-feature-never-called.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-reference/eiffel-inspector/eiffel-inspector-rules/ca003-feature-never-called.wiki new file mode 100644 index 00000000..b7c2d726 --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-reference/eiffel-inspector/eiffel-inspector-rules/ca003-feature-never-called.wiki @@ -0,0 +1,33 @@ +[[Property:title|CA003 - Feature never called]] +[[Property:link_title|CA003]] +[[Property:weight|0]] +[[Property:uuid|21e52517-beb3-9843-8c39-dd0c8e11e945]] +__NOTOC__ +=Description= +There is no use for a feature that is never called by any class (including the one where it is defined). +:{| class="doctable" +|- +| '''Scope''' +| System +|- +| '''Status''' +| Disabled +|- +| '''Severity''' +| Warning +|- +| '''Applicability''' +| Non-library +|- +| '''Score''' +| 40 +|} + + +=Example of violation= +A feature defined in the system but never called. + +=Recommendation= +Remove feature from the system. + + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-reference/eiffel-inspector/eiffel-inspector-rules/ca004-command-query-separation.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-reference/eiffel-inspector/eiffel-inspector-rules/ca004-command-query-separation.wiki new file mode 100644 index 00000000..4943b136 --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-reference/eiffel-inspector/eiffel-inspector-rules/ca004-command-query-separation.wiki @@ -0,0 +1,55 @@ +[[Property:title|CA004 - Command-Query Separation]] +[[Property:link_title|CA004]] +[[Property:weight|0]] +[[Property:uuid|7d58b7d3-e7e5-d3ec-83c8-84fca33bf638]] +__NOTOC__ +=Description= +A function should never change the state of an object. A function containing a procedure call, an assignment to an attribute, or creating an attribute is a strong indication that this principle is violated. This rule applies exactly in these three cases. + +There are rather exceptional but sometimes useful class designs in which the externally visible state of an object (i. e. the values of exported queries) does not change even though the function contains a rule-violating instruction. + +:{| class="doctable" +|- +| '''Scope''' +| Class +|- +| '''Status''' +| Enabled +|- +| '''Severity''' +| Warning +|- +| '''Applicability''' +| All +|- +| '''Score''' +| 60 +|} + + +=Example of violation= + +height: INTEGER + -- Height in pixel of Current. + +width: INTEGER + -- Width in pixel of Current. + do + height := height + 10 + Result := 100 - height + end + +=Recommendation= +Ensures that no query changes the state of the current object. + +In the example, one could replace the routine `width` by an attribute and calling `update_width` before querying `width` where `update_width` would be: +update_width + -- Update `height' and `width' with .... + do + height := height + 10 + width := 100 - height + end + +Or you can remove the line `height := height + 10` from the body of `width`. + + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-reference/eiffel-inspector/eiffel-inspector-rules/ca005-useless-object-test-local.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-reference/eiffel-inspector/eiffel-inspector-rules/ca005-useless-object-test-local.wiki new file mode 100644 index 00000000..69d7a671 --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-reference/eiffel-inspector/eiffel-inspector-rules/ca005-useless-object-test-local.wiki @@ -0,0 +1,49 @@ +[[Property:title|CA005 - Useless object test local]] +[[Property:link_title|CA005]] +[[Property:weight|0]] +[[Property:uuid|56a54ef0-48e8-b58f-ac2c-09074782b9f7]] +__NOTOC__ +=Description= +For local variables and feature arguments it is unnecessary to use an object test to check their attachment status. + +:{| class="doctable" +|- +| '''Scope''' +| feature +|- +| '''Status''' +| Enabled +|- +| '''Severity''' +| Suggestion +|- +| '''Applicability''' +| All +|- +| '''Score''' +| 40 +|} + + +=Example of violation= +if attached a_local as another_local then + another_local.do_something +end + + +=Recommendation= +Remove the object test local, or replace the object test and use a comparison to Void. + +In the example, it can simply be: +if attached a_local then + a_local.do_something +end + + +or + +if a_local /= Void then + a_local.do_something +end + + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-reference/eiffel-inspector/eiffel-inspector-rules/ca006-object-test-typing-not-needed.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-reference/eiffel-inspector/eiffel-inspector-rules/ca006-object-test-typing-not-needed.wiki new file mode 100644 index 00000000..3b8aa70b --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-reference/eiffel-inspector/eiffel-inspector-rules/ca006-object-test-typing-not-needed.wiki @@ -0,0 +1,44 @@ +[[Property:title|CA006 - Object test typing not needed]] +[[Property:link_title|CA006]] +[[Property:weight|0]] +[[Property:uuid|32d6e539-9565-14c2-31b1-5a947a6841f9]] +__NOTOC__ +=Description= +In an object test if the expression conforms to the specified type, that type is redundant. + +:{| class="doctable" +|- +| '''Scope''' +| feature +|- +| '''Status''' +| Enabled +|- +| '''Severity''' +| Suggestion +|- +| '''Applicability''' +| All +|- +| '''Score''' +| 40 +|} + + +=Example of violation= +s: STRING_32 +... +if attached {READABLE_STRING_GENERAL} s as l_s then + l_s.do_something +end + + +=Recommendation= +Remove the specified type in the object test. + +In the example, it can simply be: +if attached s as l_sl then + l_s.do_something +end + + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-reference/eiffel-inspector/eiffel-inspector-rules/ca010-high-complexity-nested-branches-and-loops.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-reference/eiffel-inspector/eiffel-inspector-rules/ca010-high-complexity-nested-branches-and-loops.wiki new file mode 100644 index 00000000..6b4df92d --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-reference/eiffel-inspector/eiffel-inspector-rules/ca010-high-complexity-nested-branches-and-loops.wiki @@ -0,0 +1,59 @@ +[[Property:title|CA010 - High complexity of nested branches and loops]] +[[Property:link_title|CA010]] +[[Property:weight|0]] +[[Property:uuid|8b9aeeae-19cb-c0ce-4de9-ba3b0bbd7dca]] +__NOTOC__ +=Description= +When the number of nested branches or loops increases, the source code is less readable. This warning is controlled by a complexity threshold preference. + +:{| class="doctable" +|- +| '''Scope''' +| feature +|- +| '''Status''' +| Enabled +|- +| '''Severity''' +| Suggestion +|- +| '''Applicability''' +| All +|- +| '''Score''' +| 60 +|- +| '''Complexity threshold''' +| 5 +|} + + +=Example of violation= +if a > 0 then + from j = 1 until j >= s loop + from k = 7 until k < 0 loop + if enable_check = True then + foo (k, j-1) + if log_level = 3 then + foobar + end + else + bar (2 * j) + end + k := k - 1 + end + j := j + 1 + end +end + + +=Recommendation= +Encapsulate some of the inner branches or loops into a reusable routine. + +In the example, it can simply be: +if attached a_local then + a_local.do_something +end + + + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-reference/eiffel-inspector/eiffel-inspector-rules/ca011-too-many-arguments.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-reference/eiffel-inspector/eiffel-inspector-rules/ca011-too-many-arguments.wiki new file mode 100644 index 00000000..c768347f --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-reference/eiffel-inspector/eiffel-inspector-rules/ca011-too-many-arguments.wiki @@ -0,0 +1,45 @@ +[[Property:title|CA011 - Too many arguments]] +[[Property:link_title|CA011]] +[[Property:weight|0]] +[[Property:uuid|d25e2dc7-7a95-c13a-bfa2-ceb42a084fa6]] +__NOTOC__ +=Description= +A feature that has too many arguments should be avoided since it makes the class interface complicated and is not easy to use. The feature arguments may include options, which should be considered to be moved to separate features. + +:{| class="doctable" +|- +| '''Scope''' +| feature +|- +| '''Status''' +| Enabled +|- +| '''Severity''' +| Warning +|- +| '''Applicability''' +| All +|- +| '''Score''' +| 50 +|- +| '''Arguments threashold''' +| 4 +|} + + +=Example of violation= +my_document.print (printer_name, paper_size, postscript_level, print_resolution) + + +=Recommendation= +Detect arguments that are really options and create procedures to set them. + +In the example, one could write: + +my_document.set_paper_size (paper_size) +my_document.set_postscript_level (postscript_level) +my_document.set_print_resolution (print_resolution) +my_document.print (printer_name) + + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-reference/eiffel-inspector/eiffel-inspector-rules/ca013-exported-creation-procedure.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-reference/eiffel-inspector/eiffel-inspector-rules/ca013-exported-creation-procedure.wiki new file mode 100644 index 00000000..7d197c50 --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-reference/eiffel-inspector/eiffel-inspector-rules/ca013-exported-creation-procedure.wiki @@ -0,0 +1,61 @@ +[[Property:title|CA013 - Exported creation procedure]] +[[Property:link_title|CA013]] +[[Property:weight|0]] +[[Property:uuid|26455914-3b04-cacc-67bb-cd8e083ce947]] +__NOTOC__ +=Description= +If acreation procedure is exported then it may be called by clients after the object has been created. Usually, this is not intended. A client might, for example, by accident call x.make instead of create x.make, possibly causing a class invariant or postcondition to not hold anymore. + +:{| class="doctable" +|- +| '''Scope''' +| class +|- +| '''Status''' +| Enabled +|- +| '''Severity''' +| Warning +|- +| '''Applicability''' +| All +|- +| '''Score''' +| 50 +|} + + +=Example of violation= +class TEST +create + make +feature -- Initialization + make + -- Initialize Current + do + end + update + do + end +end + + +=Recommendation= +Make sure to export the creation procedure to NONE. + +In the example, add the export to NONE after the feature clause: +class TEST +create + make +feature {NONE} -- Initialization + make + -- Initialize Current + do + end +feature -- Initialization + update + do + end +end + + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-reference/eiffel-inspector/eiffel-inspector-rules/ca017-empty-conditional.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-reference/eiffel-inspector/eiffel-inspector-rules/ca017-empty-conditional.wiki new file mode 100644 index 00000000..70945961 --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-reference/eiffel-inspector/eiffel-inspector-rules/ca017-empty-conditional.wiki @@ -0,0 +1,40 @@ +[[Property:title|CA017 - Empty conditional]] +[[Property:link_title|CA017]] +[[Property:weight|0]] +[[Property:uuid|4616cef3-6eaf-1ab6-6071-d629443dfbf0]] +__NOTOC__ +=Description= +An empty conditional instruction is useless and should be removed. + +:{| class="doctable" +|- +| '''Scope''' +| Instruction +|- +| '''Status''' +| Enabled +|- +| '''Severity''' +| Warning +|- +| '''Applicability''' +| All +|- +| '''Score''' +| 50 +|} + + +=Example of violation= +if x and y then +end +do_something_else + + +=Recommendation= +Remove the useless conditional. +In the example, simply keep: + + +do_something_else + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-reference/eiffel-inspector/eiffel-inspector-rules/ca020-variable-not-read-after-assignment.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-reference/eiffel-inspector/eiffel-inspector-rules/ca020-variable-not-read-after-assignment.wiki new file mode 100644 index 00000000..f8f0a397 --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-reference/eiffel-inspector/eiffel-inspector-rules/ca020-variable-not-read-after-assignment.wiki @@ -0,0 +1,54 @@ +[[Property:title|CA020 - Variable not read after assignment]] +[[Property:link_title|CA020]] +[[Property:weight|0]] +[[Property:uuid|8de22b33-be9c-b946-ce39-709cf42f01c5]] +__NOTOC__ +=Description= +An assignment to a local variable has not effect at all if the variable is not read after the assignment, or reassigned. +{| class="doctable" +|- +| '''Scope''' +| Instruction +|- +| '''Status''' +| Enabled +|- +| '''Severity''' +| Warning +|- +| '''Applicability''' +| All +|- +| '''Score''' +| 70 +|} + + +=Example of violation= + +local + x, y: INTEGER +do + x := 3 + y := some_height_query + x := some_width_query + ... +end + + +=Recommendation= +Remove the assignment without effect. + +In the example, remove the first assignment to x: + +local + x, y: INTEGER +do + y := some_height_query + x := some_width_query + ... +end + + +{{SeeAlso | [[CA071 - Self-comparison]]}} + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-reference/eiffel-inspector/eiffel-inspector-rules/ca023-unneeded-parentheses.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-reference/eiffel-inspector/eiffel-inspector-rules/ca023-unneeded-parentheses.wiki new file mode 100644 index 00000000..77e39edc --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-reference/eiffel-inspector/eiffel-inspector-rules/ca023-unneeded-parentheses.wiki @@ -0,0 +1,43 @@ +[[Property:title|CA023 - Unneeded parentheses]] +[[Property:link_title|CA023]] +[[Property:weight|0]] +[[Property:uuid|9af7b35f-7e74-2bd1-8680-b59ab81d6791]] +__NOTOC__ +=Description= +Parentheses that are not needed should be removed. This helps enforcing a consistent coding style +:{| class="doctable" +|- +| '''Scope''' +| Instruction +|- +| '''Status''' +| Enabled +|- +| '''Severity''' +| Suggestion +|- +| '''Applicability''' +| All +|- +| '''Score''' +| 30 +|} + + +=Example of violation= +if (z > 3) then + z := (z - 5) +end + + +=Recommendation= +Remove the parenthesis that are not needed. + +In the example, it simply becomes: +if z > 3 then + z := z - 5 +end + + + + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-reference/eiffel-inspector/eiffel-inspector-rules/ca024-use-across-loop.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-reference/eiffel-inspector/eiffel-inspector-rules/ca024-use-across-loop.wiki new file mode 100644 index 00000000..9f04aa57 --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-reference/eiffel-inspector/eiffel-inspector-rules/ca024-use-across-loop.wiki @@ -0,0 +1,45 @@ +[[Property:title|CA024 - Use across loop]] +[[Property:link_title|CA024]] +[[Property:weight|0]] +[[Property:uuid|d24ebe87-3a57-105e-7900-e77608cac47c]] +__NOTOC__ +=Description= +When iterating on an instance of ITERABLE with a traditional from ... until ... loop ...end from beginning to end you should use an across loop to avoid forgetting to advance the cursor. +:{| class="doctable" +|- +| '''Scope''' +| Instruction +|- +| '''Status''' +| Enabled +|- +| '''Severity''' +| Suggestion +|- +| '''Applicability''' +| All +|- +| '''Score''' +| 30 +|} + + +=Example of violation= +from + list.start +until + list.after +loop + ... + list.forth +end + + +=Recommendation= +Replace with an across loop. In the example it becomes: +across list as l loop + ... +end + + + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-reference/eiffel-inspector/eiffel-inspector-rules/ca025-use-semicolons.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-reference/eiffel-inspector/eiffel-inspector-rules/ca025-use-semicolons.wiki new file mode 100644 index 00000000..b905bfc1 --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-reference/eiffel-inspector/eiffel-inspector-rules/ca025-use-semicolons.wiki @@ -0,0 +1,40 @@ +[[Property:title|CA025 - Use semicolons]] +[[Property:link_title|CA025]] +[[Property:weight|0]] +[[Property:uuid|41ec250b-3967-797e-9843-59eab795f391]] +__NOTOC__ +=Description= +Routine arguments should be separated with semicolons. Although this is optional, it is not a recommended style to not put semicolons. +:{| class="doctable" +|- +| '''Scope''' +| feature +|- +| '''Status''' +| Enabled +|- +| '''Severity''' +| Suggestion +|- +| '''Applicability''' +| All +|- +| '''Score''' +| 40 +|} + + +=Example of violation= +f (a: INTEGER b: INTEGER) + do + end + + +=Recommendation= +Add the missing semicolons between arguments. In the example, it becomes: +f (a: INTEGER; b: INTEGER) + do + end + + + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-reference/eiffel-inspector/eiffel-inspector-rules/ca028-combine-two-if-instructions.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-reference/eiffel-inspector/eiffel-inspector-rules/ca028-combine-two-if-instructions.wiki new file mode 100644 index 00000000..73084090 --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-reference/eiffel-inspector/eiffel-inspector-rules/ca028-combine-two-if-instructions.wiki @@ -0,0 +1,39 @@ +[[Property:title|CA028 - Combine two if instructions]] +[[Property:link_title|CA028]] +[[Property:weight|0]] +[[Property:uuid|47b9a80f-16d7-82c7-7d23-19f740fb2978]] +__NOTOC__ +=Description= +Two nested instructions, both not having an else clause, could be combined into a single if instruction using the and then boolean operator. +:{| class="doctable" +|- +| '''Scope''' +| Instruction +|- +| '''Status''' +| Enabled +|- +| '''Severity''' +| Suggestion +|- +| '''Applicability''' +| All +|- +| '''Score''' +| 40 +|} + +=Example of violation= +if user /= Void then + if user.age >= 18 then + ... + end +end + + +=Recommendation= +Combine the nested if instructions using and then. In the example, it becomes: +if user /= Void and then user.age >= 18 then + ... +end + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-reference/eiffel-inspector/eiffel-inspector-rules/ca032-long-routine-implementation.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-reference/eiffel-inspector/eiffel-inspector-rules/ca032-long-routine-implementation.wiki new file mode 100644 index 00000000..ae146c5c --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-reference/eiffel-inspector/eiffel-inspector-rules/ca032-long-routine-implementation.wiki @@ -0,0 +1,35 @@ +[[Property:title|CA032 - Long routine implementation]] +[[Property:link_title|CA032]] +[[Property:weight|0]] +[[Property:uuid|9edb21ce-ab0c-69ea-c494-a39dc7a26b15]] +__NOTOC__ +=Description= +A routine implementation that contains many instructions should be shortened to make it easier to understand. +:{| class="doctable" +|- +| '''Scope''' +| feature +|- +| '''Status''' +| Enabled +|- +| '''Severity''' +| Warning +|- +| '''Applicability''' +| All +|- +| '''Score''' +| 70 +|- +| '''Instructions threshold''' +| 70 +|} + + +=Example of violation= +A routine with many lines of code. + +=Recommendation= +Decompose the routine by creating new routines that will be used in the original long routine. + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-reference/eiffel-inspector/eiffel-inspector-rules/ca033-large-class.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-reference/eiffel-inspector/eiffel-inspector-rules/ca033-large-class.wiki new file mode 100644 index 00000000..af3d69d5 --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-reference/eiffel-inspector/eiffel-inspector-rules/ca033-large-class.wiki @@ -0,0 +1,39 @@ +[[Property:title|CA033 - Large class]] +[[Property:link_title|CA033]] +[[Property:weight|0]] +[[Property:uuid|93aaff4c-3406-311e-3760-facad969131e]] +__NOTOC__ +=Description= +A large class declaration might not be ideal for readability. Consider moving out features that are not really part of the class. +:{| class="doctable" +|- +| '''Scope''' +| class +|- +| '''Status''' +| Enabled +|- +| '''Severity''' +| Warning +|- +| '''Applicability''' +| All +|- +| '''Score''' +| 60 +|- +| '''Features threshold''' +| 20 +|- +| '''Instructions threshold''' +| 300 +|} + + +=Example of violation= +A class with too many routines or too many instructions. + +=Recommendation= +Refactor the class to reduce the number of routines or instructions. + + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-reference/eiffel-inspector/eiffel-inspector-rules/ca034-high-npath-complexity.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-reference/eiffel-inspector/eiffel-inspector-rules/ca034-high-npath-complexity.wiki new file mode 100644 index 00000000..4dfe09b6 --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-reference/eiffel-inspector/eiffel-inspector-rules/ca034-high-npath-complexity.wiki @@ -0,0 +1,35 @@ +[[Property:title|CA034 - High NPATH complexity]] +[[Property:link_title|CA034]] +[[Property:weight|0]] +[[Property:uuid|f6ffe1e0-2b46-66db-60de-0cdd5c42f453]] +__NOTOC__ +=Description= +NPATH is the number of acyclic execution paths through a routine. A routine's NPATH complexity should not be too high. In order to reduce the NPATH complexity one can move some functionality to separate routines. +:{| class="doctable" +|- +| '''Scope''' +| Feature +|- +| '''Status''' +| Enabled +|- +| '''Severity''' +| Warning +|- +| '''Applicability''' +| All +|- +| '''Score''' +| 60 +|- +| '''NPATH complexity threshold''' +| 200 +|} + + +=Example of violation= + +=Recommendation= +Reduce complexity of routine by refactoring parts of the routine into their own routines. + + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-reference/eiffel-inspector/eiffel-inspector-rules/ca071-self-comparison.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-reference/eiffel-inspector/eiffel-inspector-rules/ca071-self-comparison.wiki new file mode 100644 index 00000000..29d60572 --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-reference/eiffel-inspector/eiffel-inspector-rules/ca071-self-comparison.wiki @@ -0,0 +1,38 @@ +[[Property:title|CA071 - Self-comparison]] +[[Property:link_title|CA071]] +[[Property:weight|0]] +[[Property:uuid|02a649b3-0e4e-6fdf-388d-c411a06fc787]] +__NOTOC__ +=Description= +An expression comparing a variable to itself always evaluates to the same boolean value. The comparison is thus redundant. In an Until expression it may lead to non-termination. Usually it is a typing error. +:{| class="doctable" +|- +| '''Scope''' +| Instruction +|- +| '''Status''' +| Enabled +|- +| '''Severity''' +| Warning +|- +| '''Applicability''' +| All +|- +| '''Score''' +| 70 +|} + + +=Example of violation= +if a >= a then + ... +end + +=Recommendation= +Replace left or right side of comparison with something else than the other element. + +In the example, replace '''a''' by something else. + +{{SeeAlso| [[CA001 - Self Assignment]]}} + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-reference/eiffel-inspector/eiffel-inspector-rules/index.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-reference/eiffel-inspector/eiffel-inspector-rules/index.wiki new file mode 100644 index 00000000..79d4d5b3 --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-reference/eiffel-inspector/eiffel-inspector-rules/index.wiki @@ -0,0 +1,13 @@ +[[Property:title|Eiffel Inspector - Rules]] +[[Property:link_title|Rules]] +[[Property:weight|15]] +[[Property:uuid|109ca62a-212d-8a85-eea8-ddf0f89177a1]] +For each rule, you will find an English description of the purpose of the rule, followed by a table providing the following information: +* Scope: Instruction/ +* Status: Enabled/Disabled by default +* Severity: Warning/Error +* Applicability: All +* Score: Value used to + +In addition you will find an example for a rule violation as well as a suggested fix when available. + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-reference/eiffel-inspector/eiffel-inspector-running-analyzer.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-reference/eiffel-inspector/eiffel-inspector-running-analyzer.wiki new file mode 100644 index 00000000..45cac042 --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-reference/eiffel-inspector/eiffel-inspector-running-analyzer.wiki @@ -0,0 +1,69 @@ +[[Property:title|Eiffel Inspector - Running the Analyzer]] +[[Property:link_title|Running the Analyzer]] +[[Property:weight|-14]] +[[Property:uuid|d672c769-57fb-6b87-2781-83daff3ab9e7]] += General = + +There are several different ways of running the Eiffel Inspector. Most importantly, you can select the scope of the analysis. For example it is possible to analyze a single class, a cluster or a whole system. Also for the same scope there are different ways of running the analyzer depending on your personal preferences. To perform the analysis the Eiffel system which will be analyzed must compile without any error. + +There are two ways of running the Eiffel Inspector +# Using the GUI, the Eiffel Inspector Tool appears as a panel. The panel is mainly used for displaying analysis results. The command to perform the analysis can be found not only in the panel but also in various context menus making it easy to analyze specific classes or sets of classes. +# Using command-line arguments with the command-line version of EiffelStudio. The system is compiled (if necessary) and then analyzed. The output of the analysis will be directed to the terminal window. + += GUI = +== Analyzing the System == + +If you want to analyze the whole system of the currently open project press the '''Analyze System''' button in the toolbar. Every compiled classes of the system will be analyzed. +[[Image:CA Analysis Buttons|center|368px|Analyze System]] + + +== Analyzing a Class or Group == + +=== Current Class === +Left-clicking the '''Analyze Item''' button in the toolbar will start an analysis of the class that is currently opened in the editor. +[[Image:CA Analysis Buttons|center|368px|Analyze Item]] + +=== Any Class === +There are two ways of analyzing an arbitrary class (either from your system or from a library): +* Right-click on a class name and select '''Run Eiffel Inspector on Class...''' from the context menu: +[[Image:CA Class Context Menu|center|371px|Class Context Menu]] +* Pick a class and drop it on the '''Analyze Item''' button. + +=== Clusters === +To analyze a cluster there are two possibilities, like for classes: +* You can either right-click the cluster and select '''Run Eiffel Inspector on cluster''' from the context menu: +[[Image:CA Cluster Context Menu|center|247px|Cluster Context Menu]] +* Pick a cluster and drop it on the '''Analyze Item''' button. + +=== Others === +Not only clusters but any other elements of a project (such as a library) can be analyzed by pick-and-dropping it on the '''Analyze Item''' button in the panel. + + +=Command Line= +The Eiffel Inspector is also available from the EiffelStudio command line compiler by using the '''-code-analysis''' command. The results will be displayed in the terminal window or to a file. + +== Execution / Command Line Options == + +The following command will perform a code analysis: + + ec.exe -config project.ecf -code-analysis [-cadefaults] [-caloadprefs ''preffile''] [-caclass ''CLASS1 CLASS2 ...''] + [-caforcerules "RULE1 (First preference=1, Second preference=2) RULE2"] + +The arguments in brackets are optional. For a complete description of the Eiffel inspector command line options see [[EiffelStudio: Using command line options|Using command line compiler options]]. + +EiffelStudio will try to compile the system if needed. The analysis will only work with syntactically correct code and a compiled system. Should the compilation fail, EiffelStudio will abort and the analysis will not start. + +== Output == +Upon a successful compilation either the whole system or the classes mentioned in the arguments will be analyzed. The class that is currently being analyzed will be displayed so that the user can follow the progress. + +As soon as everything needed has been analyzed the results will be displayed as a list of rule violations. These rule violations are sorted by class and by location. In addition to the name of the violated rule and the rule ID, a description of the concrete violation will be displayed as well. + +[[Image:Eiffel Inspector Command Line|center|877px|Eiffel Inspector - Command Line]] + +=== Output to file === + +Appending "> ''filename''" to the command above will redirect the output to a text file. +In addition, a file '''last_analysis_result.csv''' will be saved in the 'EIFGENs/target' directory, with the same content as '''filename''', that can be processed by a spreadsheet tool. + + + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-reference/eiffel-inspector/index.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-reference/eiffel-inspector/index.wiki new file mode 100644 index 00000000..42514b97 --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-reference/eiffel-inspector/index.wiki @@ -0,0 +1,8 @@ +[[Property:modification_date|Wed, 04 Jul 2018 11:29:56 GMT]] +[[Property:publication_date|Wed, 04 Jul 2018 09:35:31 GMT]] +[[Property:title|Code Analyzer]] +[[Property:weight|-8]] +[[Property:uuid|3d9edb08-a7dd-7df9-2b1e-b5c30add6529]] +The Code Analyzer is a static analyzer that helps maintaining a high code quality. It is capable of detecting many different kinds of issues in the source code. These issues relate to possibly dangerous run-time behavior, performance problems, coding style, and more. + + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-reference/eiffelstudio-editor/Code-Templates.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-reference/eiffelstudio-editor/Code-Templates.wiki new file mode 100644 index 00000000..5b68617d --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-reference/eiffelstudio-editor/Code-Templates.wiki @@ -0,0 +1,263 @@ +[[Property:uuid|7CCF602E-0B79-49C2-93FE-39C90CBE4E35]] +[[Property:link_title|Code Templates]] +[[Property:title|Code Templates]] +[[Property:weight|7]] + + + +EiffelStudio's code templates facilitate the programmer’s task by offering program schemes that correspond to typical programming needs. Templates are a simple idea (section 1); you can use templates that others have defined (section 2); you can define your own templates (section 3); and you can share them, so that they will become part of future EiffelStudio deliveries (section 4). + +If all you need to know is how to use the template mechanism in EiffelStudio, you can just read sections 1 and 2. + += 1. What are code templates and how do they help me? = + +Code templates are contextual: based on the properties of some part of your code, EiffelStudio will offer a list of templates that could — just could! — do exactly what you need at that very place. + +For example, if you are using an integer array, EiffelStudio will offer a code template for a common operation: computing the array’s maximum. If you select the template, EiffelStudio will insert its code into your program, giving you the option of specifying the starting and ending indices (which it sets by default to the array’s bounds). You just have to specify the information relevant to your particular case; the template takes care of the implementation. + +EiffelStudio comes with a number of predefined templates; you can also contribute your own. +There are two kinds of template: + +* '''Targeted''' templates apply to a certain target entity. For example, if you have a variable of type ARRAY [INTEGER], EiffelStudio will offer you templates that work on that array (the “target”). +* '''Targetless''' templates, also called "global", are applicable in any context, without a target. + +Whether targeted or targetless, a template can be a fixed pattern or have '''arguments''' which enable you to parameterize to your needs. + + += 2. How do I use templates in EiffelStudio? = + +Code templates are part of EiffelStudio’s code completion mechanism. Code completion lets you choose a code template at the same place where it offers you features to call, typically after you type a dot character “.” after the name of an applicable local variable. attribute or function + + +==Targeted templates== +When you type a dot character “.” after the name of an applicable target, a menu appears: + +[[Image:target_template_1_0]] + +Figure 1. Auto-completion with code template option + +Except for the first one in this example, the entries of this menu list the ''features'' applicable to the current target. But if you are interested in templates, select the first entry, which only appears if there are any applicable templates, and says “Show templates (Ctrl+Space)” + +[[Image:target_template_1_1]] + +Figure 2. Auto-completion gives list of code templates + +As suggested, you can also type Control-space again to get the same effect. (Click "Show features" if you decide to go back to showing the applicable features, rather than templates.) + +If you find a template that you like, just select it. + + +== Targetless templates == +It is also possible to use code templates without a target. When you type Control-Space, if there are any applicable targetless templates, the first entry says “Show templates (Ctrl+Space)”: + +[[Image:targetless_template_1_3]] + +If you click this "Show templates" + +Figure 3. Targetless auto-completion with code template option + +When you insert a template into your code, it will often have some highlighted fields, corresponding to the template arguments, for example, the lower and upper bounds of the part of an array or ("slice") whose minimum you seek: + +[[Image:targetless_template_1_4|680px]] + +Figure 4. Targetless auto-completion with code templates option list. + + + +== Filling in arguments == + +Some templates let you parameterize their code by filling ''arguments'' in a highlighted field. Initially, the field contains the corresponding argument's default value; you can leave that default, or override it with your own choice. If the template uses the argument several times, you can fill in the value in any of the corresponding fields, and all others will automatically be updated. + +In the menu of targeted array templates shown above, the template slice_minimum is an example of template with arguments. It looks like this: + +[[Image:target_template_with_input_parameters_1_0|680px]] + +Figure 5. A template with arguments + +This template, used to compute the minimum of a part, or "slice", of an array, has two arguments, representing the bounds of the slice. If you select the template, you will see two highlighted fields, initialized with the respective default values default: "target.lower and target.upper" of these arguments: + +[[Image:target_template_with_input_parameters_1_1]] + +Figure 6. Inserted template code, with highlighted argument fields + +The reason for these defaults is that much of the time you will want the minimum of the ''whole'' array. If you are happy with that default, just leave the fields as they are But if you just need a different slice, for example from index 5 to index 10, just type the desired values in the corresponding fields: + +[[Image:target_template_with_defaults_overridden_1_1]] + +Figure 7. Inserted template code, with highlighted argument fields + +Note that each argument appears in two different fields; if you edit any of these fields, the other will get updated automatically. + + += 3. Can I define my own templates? = + +It is very easy to define a template. It is all done in Eiffel, of course. You simply define a class that inherits from TEMPLATE, with any number of routines, each of which introduces one template, applicable to targets of the corresponding type. If the routine has arguments, those will be the arguments of the template. + +== Where does EiffelStudio find the templates? == + +To offer templates as part of code completion, EiffelStudio looks in two locations: +* Standard templates, found in: +** Linux: $ISE_EIFFEL/studio/templates/code +** Eiffel: %ISE_EIFFEL%/studio/templates/code +* User-defined templates, which you can add at: +** Linux: ~/.es/eiffel_user_files/16.11/templates/code +** Windows: C:/Users/your_user_name/Documents/Eiffel User Files/16.11/templates/code + +If you define templates for your own specific use, store them in the second location. + +== Defining a targeted template == +Here is how we defined the template used in the above targeted example: + + +class ARRAY_TEMPLATE [T -> COMPARABLE] inherit + + TEMPLATE [ARRAY [T]] + +feature -- Templates + + maximum: T + -- Maximum of `target' array. + note + tags: "Algorithm, Maximum, ARRAY" + do + across target as element loop + Result := Result.max (element.item) + end + end + + slice_minimum (low, high: INTEGER): T + -- Minimum of `target' array, where the interval is defined by default by target.lower |..| target.upper. + note + title: "Array slice minimum" + tags: "Algorithm, Minimum, ARRAY" + default: "target.lower, target.upper" + do + Result := low + across low |..| high as i loop + Result := Result.min (target [i.item]) + end + end +end + + +This class defines two targeted templates: ''maximum'' for the maximum of an entire array, and ''slice_minimum'' for the minimum of some contiguous part of that array. + +To specify the target type, here arrays, just use it as the actual generic parameters of TEMPLATE (which is a generic class). Here indeed, the the definition starts as + + + class ARRAY_TEMPLATE [T -> COMPARABLE] inherit + + TEMPLATE [ARRAY [T]] + + + +The correspondence between what you write in the template definition and what appears in EiffelStudio, as shown in previous sections, is straightforward: + +# The list of templates will display the name of the feature, e.g. slice_minimum +# It will use the header comment as explanation in the tooltip (always write a header comment!) +#.On selection of a template, EiffelStudio will insert the template’s body into the code. +# Argument occurrences will appear as fields for the user to fill in. + +== Defining a targetless template == + + +For a targetless template, just just use TEMPLATE without a generic parameter: + + +class TEMPLATE_READ_FILE_GLOBAL + +inherit + + TEMPLATE + +feature -- Templates + + read_file_line_by_line + -- Read a file line by line., for binary files you can use {RAW_FILE}. + note + title: "Read a file line by line" + tags: "Algorithm, Read, Files, Path" + local + l_file: FILE + l_path: PATH + do + create l_path.make_current + create {PLAIN_TEXT_FILE} l_file.make_with_path (l_path) + if l_file.exists and then l_file.is_readable then + l_file.open_read + from + until + l_file.end_of_file + loop + l_file.read_line + -- Use entry `l_file.last_string` such as `io.put_string (l_file.last_string); io.put_new_line` + end + l_file.close + else + io.error.put_string ("Could not read, the file:[" + l_path.name + " ] does not exist") + io.put_new_line + end + end +end + + + +=4. Sharing code templates= +You can share your code templates using Github. + +== Fork the project == +Clone your fork, and configure the remotes.Eiffel Studio github repository at: [https://github.com/EiffelSoftware/EiffelStudio https://github.com/EiffelSoftware/EiffelStudio ] + +# Clone your fork of the repository into the current directory: git clone https://github.com// +# Navigate to the newly cloned directory: cd +# Assign the original repository to a remote one called "upstream": git remote add upstream https://github.com// + +If you cloned a while ago, get the latest changes from upstream: + + +git checkout +git pull upstream + + + +== New branch == +Create a new topic branch (off the main project development branch) to contain your new code template +git checkout -b +Commit your changes in logical chunks. Before to commit double check [http://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html Tim Pope's A Note About Git Commit Messages]. +Use Git's interactive rebase feature to tidy up your commits before making them public. + +Locally merge (or rebase) the upstream development branch into your topic branch: + +git pull [--rebase] upstream + +Push your topic branch up to your fork: + +git push origin + + +==Pull request== +Open a pull request with a clear title and description + +== Code template review == +For your work to be integrated into the project, the maintainers will review your work and either request changes or merge it. + + +=Associating a user interface with a template definition= +The following image shows the relationship between the template definition and how they will look in the GUI. + +[[Image:target_template_1_2|780px]] +Figure 8. UI and template relationship. + + +* Feature name or metadata `title` if present will be used as the value in the list of completion possibilities. +* Feature comment will be used in the tooltip description of a selected template. +* Feature body will be used in the tooltip code preview. + + + + + + + + + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-reference/eiffelstudio-editor/automatic-completion/class-name-auto-complete.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-reference/eiffelstudio-editor/automatic-completion/class-name-auto-complete.wiki new file mode 100644 index 00000000..368654b0 --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-reference/eiffelstudio-editor/automatic-completion/class-name-auto-complete.wiki @@ -0,0 +1,68 @@ +[[Property:title|Class name auto complete]] +[[Property:weight|3]] +[[Property:uuid|0f11a078-7dab-54d1-b624-4c04476564a5]] +==Overview== +The EiffelStudio editor will complete class names automatically. This means, for example, when you type in the editor pane: + + a_variable_name: LI +and then triggers the class name auto-completion, one of two things will happen: +* If there is only one accessible class name that begins `LI', then that class name will be automatically placed in the editor pane at the cursor. +* If there is more than one such class name, the editor will propose a list of possible valid class names, as seen in Figure 1. + +Class name auto-completion can be triggered by pressing Ctrl+Shift+Space or by following the [[Edit menu commands|edit menu]] path: + +Edit --> Advanced --> Complete Class Name + + +Class name auto-completion is most commonly used in the Editor Pane. But the same functionality is also available in other areas of EiffelStudio, for example: +* The "Entry:" text box on the New Class tool. +* Expressions in the editable grid of the Watch tool +* "Class name:" in the New Expression dialog of the Watch tool. +* "Edit Contract" in the Contract tool +* "Add New Contract" in the Contract tool +
+ +==The class auto-completion window== +Using the example above, when auto-completion is triggered, the class auto-completion window will pop up and display the list of class names which begin with the string "LI". So, you can think of the auto-completion as a search for class names using the characters you type followed by a wild card character, the asterisk ('*'). Of course, you don't have to put the asterisk at the end, it's always there by implication. Once you've triggered the auto-completion, you can however use the wild card character in the middle of a string, like this: + + a_variable_name: LI*R + +which would list all class names starting with "LI" and containing the character 'R' appearing at some point after the "LI". + + +{{note|Using the wild card character with auto-completion is valid only '''after''' auto-completion is triggered.}} + + +When the list appears, the first list item will be selected. You can select a class name from the list by double-clicking a name in the list or by using the keyboard Up and Down buttons to navigate the list, then pressing Enter to select a highlighted class name. You can also continue to type characters and the list will automatically narrow, provided that you have non-matching entries filtered out (see [[#Auto-completion list display options|Auto-completion list display options]] below.) + +To validate your choice, press Enter. + +If there is no selected item when you validate, then the content of the text you have type will be inserted. + +The auto-completion can be cancelled by clicking outside the window or pressing Esc. + + +[[Image:editor-class-auto-completion-window]] + +Figure 1. The class name auto-completion window + +===Auto-completion list display options=== + +At the bottom of the auto-completion window you will find a row of icons labeled "Options:". These icons help you control which choices are presented to you and the format of their presentation. + +Each icon can be toggled between an "up" position and a "down" position by clicking on it. You can also toggle the option icons up and down by using the function keys F1 through F7. + +Note that not all of the options are applicable to class name auto-completion. Some apply only to feature name completion or to both class names and feature names. + +* [[Image:hide non-matching entries icon]] (F1) Hide non-matching entries. +* [[Image:query return type icon]] (F2) Show query return types. +* [[Image:feature signatures icon]] (F3) Show feature signatures. +* [[Image:disambiguated name icon]] (F4) Show disambiguated names. (Applicable to .NET overloaded feature names.) +* [[Image:obsolete items icon]] (F5) Show obsolete items. +* [[Image:show descriptions icon]] (F6) Show description of selected item in the ''tool tip'' area at the bottom of the window. (See Figure 1) +* [[Image:remember list size icon]] (F7) Remember the size of the completion list between triggerings. + + + + + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-reference/eiffelstudio-editor/automatic-completion/feature-call-auto-complete.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-reference/eiffelstudio-editor/automatic-completion/feature-call-auto-complete.wiki new file mode 100644 index 00000000..1fa622ce --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-reference/eiffelstudio-editor/automatic-completion/feature-call-auto-complete.wiki @@ -0,0 +1,82 @@ +[[Property:title|Feature call auto complete]] +[[Property:weight|2]] +[[Property:uuid|40ae30a6-c033-dae7-8dae-2569e7ba0adc]] +==Overview== + +EiffelStudio editor provides automatic help for completing feature calls. + +With the default EiffelStudio preferences, feature call auto-completion occurs automatically when you type a dot ('.') character after a feature name. + +This means, for example, that in the Editor pane when you type: + + my_string. +the editor will propose a list of possible valid feature names from which to choose, as seen in Figure 1. + +Feature call auto-completion can also be triggered: + +# By pressing crtl+space +# By following the edit menu path: + + +Edit --> Advanced --> Complete word + + + +Feature call auto-completion is most commonly used in the Editor pane. But the same functionality is also available elsewhere in EiffelStudio, for example: + +* Expressions in the editable grid of the Watch tool. +* "Expression" in the New Expression dialog of the Watch tool. +* "Condition" in the Breakpoints dialog + + +==The feature call auto-completion window== + +Using the example above, when auto-completion is triggered, the feature call auto-completion window will pop up and display a list of feature names which can be applied in the current context. + + +[[Image:editor feature auto-completion window]] + +Figure 1. The feature auto-completion window. + + +When the auto-completion window appears, the first item in the list, if any, will be selected. To complete your code with the selected item, press "Enter" or "Ctrl+Space". To choose another item, use keyboard Up and Down arrows or the mouse. + +You can also continue typing characters and the list will automatically be narrowed provided that you have non-matching entries filtered out (see '''Auto-completion list display options''' below). So, you can think of the auto-completion as a search for feature names using the characters you type followed by a wild card character, the asterisk ('*'). Of course, you don't have to put the asterisk at the end, it's just always implied. Once you've triggered auto-completion, you can however use the wild card character in the middle of a string, like this: + + + my_string.a*int + +which would narrow the list to all feature names starting with "a" and also containing the string "int". + +To validate your choice, press "Enter" or "Ctrl+Space". + +If there is no selected item, the content of the text you have typed will be inserted. + +The auto-completion can be cancelled by clicking outside the window or pressing Esc. + +==Entering routine arguments== + +After you have selected a feature, if the feature is a routine requiring arguments, the argument prototypes will be included in the generated feature text, and the text for the first argument will be selected, as in Figure 2. + + +[[Image:feature_call_auto-complete_example_1]] + +Figure 2. Auto-completion of a routine with arguments. + + +Because the text for the first argument is already selected, you can go ahead and type a value for that argument. When you've completed the first argument, press Tab, and the next argument will be selected, and you can type a value for it. When you Tab after entering the final argument, the cursor will be positioned after the right parenthesis, so you are ready to move on. + +==Auto-complete list display options== + +At the bottom of the auto-completion window you will find a row of icons labeled "Options:". These options help you control which choices are presented to you and the format of their presentation. The options are described in the [[Class name auto complete#Auto-completion list display options|section on class name auto-completion]]. + + +{{tip|The following tips can help you get the most out of feature call automatic completion:
1) You can call the auto-complete without an identifier. The auto-complete window will then show the features of the current class.
2) The keyboard shortcut for automatic completion can be changed in the [[Keyboard shortcuts preferences|editor preferences]].
3) When the auto-completion window is open, typing any character (other than a wild card) that is not ordinarily valid in feature names automatically closes the window. So, you can type '.', ' ' or '(' to close the completion window and start typing the next token straight away.}} + + +{{note|There are just a few more things you should know about feature call automatic completion:
1) Only identifiers that were already defined when the class was compiled for the last time can be completed, except for local entity names that can always be completed.
2) Only compiled features will appear in the auto-complete window.
3) By default, features from class ANY will be ignored by the auto-complete window. This can be changed in the [[General Editor Preferences|editor preferences]]. }} + + + + + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-reference/eiffelstudio-editor/automatic-completion/index.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-reference/eiffelstudio-editor/automatic-completion/index.wiki new file mode 100644 index 00000000..7ace9d76 --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-reference/eiffelstudio-editor/automatic-completion/index.wiki @@ -0,0 +1,13 @@ +[[Property:title|Automatic completion]] +[[Property:weight|6]] +[[Property:uuid|eb89d090-6998-7dbe-6430-26d30eb87a32]] +EiffelStudio editor includes new features designed to help write Eiffel code. Automatic completion is one of those. This feature is available in three contexts: + +* [[Syntax auto complete]]: when the user types some expression defined in the Eiffel programming language. +* [[Feature call auto complete]]: when the user enters a feature call. +* [[Class name auto complete]]: when the user enters a class name. + +This feature is can be customized or disabled in the [[Editor Preferences]]. + + + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-reference/eiffelstudio-editor/automatic-completion/syntax-auto-complete.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-reference/eiffelstudio-editor/automatic-completion/syntax-auto-complete.wiki new file mode 100644 index 00000000..99cc891c --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-reference/eiffelstudio-editor/automatic-completion/syntax-auto-complete.wiki @@ -0,0 +1,66 @@ +[[Property:title|Syntax auto complete]] +[[Property:weight|1]] +[[Property:uuid|aafa7c51-7a4d-385d-9c34-5e9dbba075fe]] +Syntax auto-complete in EiffelStudio editor is twofold : + +* The editor can close brackets ("(", "{" and "[") and quotes(""", "'" and "`") automatically. This feature is disabled by default. It can be activated in the editor preferences. + +* The editor can complete syntactic structures or part of them. The auto-complete is triggered when "Enter" or "Space" keys are pressed after a reserved word included in the following list: +{| align="center" +|- +| class +| ensure +| invariant +| require else +|- +| check +| ensure then +| is +| rescue +|- +| create +| export +| local +| select +|- +| creation +| external +| loop +| then +|- +| debug +| feature +| obsolete +| undefine +|- +| deferred +| from +| once +| until +|- +| do +| if +| precursor +| variant +|- +| else +| indexing +| redefine +| when +|- +| elseif +| inherit +| rename +|- +| end +| inspect +| require +|} + + + +{{seealso|How the editor completes by default and how the default behavior can be changed, documented in the [[Syntax automatic completion preferences]] }} + + + + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-reference/eiffelstudio-editor/clipboard-functionality.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-reference/eiffelstudio-editor/clipboard-functionality.wiki new file mode 100644 index 00000000..3c970da3 --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-reference/eiffelstudio-editor/clipboard-functionality.wiki @@ -0,0 +1,15 @@ +[[Property:title|Clipboard functionality]] +[[Property:weight|3]] +[[Property:uuid|f1bd2fd2-c115-d4e8-cb3b-2118f25037bb]] +EiffelStudio editor provides common clipboard functionality, i.e. Cut, Copy and Paste commands. + +* To copy text to the clipboard, [[Selection|select]] it in the editor first. Then, you may either press the key combination "Ctrl+C" (or "Shift+Ins"), click on the copy icon [[Image:16x16--general-copy-icon]] or choose '''Copy''' in the '''Edit''' menu. + +* To cut text, i.e. copy it to the clipboard and delete it, [[Selection|select]] it and then either press "Ctrl+X" (or "Shift+Del"), click on the cut icon [[Image:general-cut-icon]] or choose '''Cut''' in the '''Edit''' menu. + +* To paste text from the clipboard, either press "Ctrl+V" (or"Ctrl+Ins"), click on the paste icon [[Image:general-paste-icon]] or choose '''Paste''' in the '''Edit''' menu. + + + + + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-reference/eiffelstudio-editor/cursor-moves.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-reference/eiffelstudio-editor/cursor-moves.wiki new file mode 100644 index 00000000..5ccf9f6c --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-reference/eiffelstudio-editor/cursor-moves.wiki @@ -0,0 +1,15 @@ +[[Property:title|Cursor moves]] +[[Property:weight|1]] +[[Property:uuid|f0e34ba8-cd06-3020-015e-c470fe63406f]] +There are two ways to position the cursor in EiffelStudio editor: you can use either the mouse or the keyboard. + +If you choose to use the mouse, just click in the text where you want the cursor to be moved. If the text is not entirely visible, you can use the scroll bar at the bottom and on the left of the edition zone to display the part you are interested in. + +The keys that you may use to move the cursor in EiffelStudio editor are "Home", "End", "Page up", "Page Down" and the four arrows. Pressing "Home" will make the cursor go to the beginning of the line. Pressing "End" will move the cursor to the end of the line. You can use "Page Up" to move the cursor one page closer to the beginning of the text. Pressing "Page down" will position the cursor one page further.
+Left and Right arrows can be used to move respectively to the character on the left or on the right of current position. Up and Down arrows allow you to move the cursor to the previous and next lines. + +{{tip|By maintaining "Ctrl" pressed as you use Left and Right arrows, you will move the cursor to the next or previous word instead of the next or previous character. }} + + + + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-reference/eiffelstudio-editor/edit-menu-commands.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-reference/eiffelstudio-editor/edit-menu-commands.wiki new file mode 100644 index 00000000..010de56c --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-reference/eiffelstudio-editor/edit-menu-commands.wiki @@ -0,0 +1,33 @@ +[[Property:title|Edit menu commands]] +[[Property:weight|8]] +[[Property:uuid|7c8b105c-47ac-d101-4235-8a65d2f43cb7]] +In the '''Edit''' menu, the following commands are available: +* [[History functionality|Undo]] : undo last change. +* [[History functionality|Redo]] : redo last undone change. +* [[Clipboard functionality|Cut]] : Cut [[Selection|selected]] text. +* [[Clipboard functionality|Copy]] : Copy [[Selection|selected]] text. +* [[Clipboard functionality|Paste]] : Paste text from the clipboard. +* [[Selection|Select All]] : Select the entire text. +* [[Search tool|Find]] : Show and go to the [[Search tool|search panel]] . +* [[Search tool|Replace]] : Show and go to the [[Search tool|search panel]] with replace option activated. +* Toggle Line Numbers: Show or hide the line numbers in the current editor. +* [[Search functionality|Search]] : +** [[Search functionality|Find next]] : Find the next occurrence of the last searched expression. +** [[Search functionality|Find previous]] : Find the previous occurrence of the last searched expression. +** [[Search functionality|Find selection]] : Find the next occurrence of the selected text. + +* Advanced +** [[Indent and unindent selection|Indent selection]] +** [[Indent and unindent selection|Unindent selection]] +** [[Comment and uncomment lines|Comment]] +** [[Comment and uncomment lines|Uncomment]] +** [[Embed lines in 'if then...end' or in 'debug...end'|Embed in if...]] +** [[Embed lines in 'if then...end' or in 'debug...end'|Embed in debug...]] +** [[Feature call auto complete|Complete word]] +** [[Class name auto complete|Complete class name]] + +* [[Preference window overview|Preferences]] + + + + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-reference/eiffelstudio-editor/editor-customization.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-reference/eiffelstudio-editor/editor-customization.wiki new file mode 100644 index 00000000..b9565022 --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-reference/eiffelstudio-editor/editor-customization.wiki @@ -0,0 +1,9 @@ +[[Property:title|Editor customization]] +[[Property:weight|9]] +[[Property:uuid|650993e4-65a7-9a7e-7d08-b4c17c14ff39]] +Many of the editor features, the [[automatic completion]] in particular, can be customized in the preferences.
+Please refer to the [[Editor Preferences|editor section]] of the preferences help for more details. + + + + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-reference/eiffelstudio-editor/history-functionality.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-reference/eiffelstudio-editor/history-functionality.wiki new file mode 100644 index 00000000..d16cc3b4 --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-reference/eiffelstudio-editor/history-functionality.wiki @@ -0,0 +1,13 @@ +[[Property:title|History functionality]] +[[Property:weight|4]] +[[Property:uuid|04edcfb7-3a63-e9e6-2ac6-8f5868b3ee10]] +EiffelStudio editor provides an history functionality, i.e. Undo and Redo commands. + +* To undo last change, press the key combination "Ctrl+Z", click on the undo icon [[Image:general-undo-icon]] or choose '''Undo''' in the '''Edit''' menu. If you repeat this operation, the editor will undo the last change and so on until there are no more changes to undo. + +* To redo last undone change, press the key combination "Ctrl+Y", click on the redo icon [[Image:general-redo-icon]] or choose '''Redo''' in the '''Edit''' menu. If you repeat this operation, the editor will redo the last undone change and so on until there are no undone changes left. + + + + + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-reference/eiffelstudio-editor/index.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-reference/eiffelstudio-editor/index.wiki new file mode 100644 index 00000000..afcf491b --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-reference/eiffelstudio-editor/index.wiki @@ -0,0 +1,13 @@ +[[Property:title|EiffelStudio Editor]] +[[Property:link_title|Editor]] +[[Property:weight|-12]] +[[Property:uuid|2594094b-af66-8cea-1d7f-629157c4aafa]] +EiffelStudio includes an editor which allows you to read and modify the text of Eiffel classes. + +The EiffelStudio editor offers usual [[Clipboard functionality]], [[History functionality]], and [[Search functionality]]. More advanced, class text specific functionalities such as [[Automatic completion]] and [[Operations on text blocks]] are also available. + + + + + + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-reference/eiffelstudio-editor/operations-text-blocks/comment-and-uncomment-lines.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-reference/eiffelstudio-editor/operations-text-blocks/comment-and-uncomment-lines.wiki new file mode 100644 index 00000000..f975cfd5 --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-reference/eiffelstudio-editor/operations-text-blocks/comment-and-uncomment-lines.wiki @@ -0,0 +1,16 @@ +[[Property:title|Comment and uncomment lines]] +[[Property:weight|1]] +[[Property:uuid|34aba497-1b5b-4dcc-f227-81dd9dbbc923]] +EiffelStudio editor offers the possibility to comment or uncomment several lines at a time. + +* The "Comment" command corresponds to the '''Comment''' entry in the '''Advanced''' sub-menu of the [[Edit menu commands| '''Edit''' Menu ]]. It may be called by using the keyboard shortcut "Ctrl+K". Its action is to insert two dashes in front of each [[Selection|selected]] line. + +* The "Uncomment" command corresponds to the '''Uncomment''' entry in the '''Advanced''' submenu of the [[Edit menu commands| '''Edit''' Menu ]]. It may be called by using the keyboard shortcut "Ctrl+Shift+K". Its action is to remove the two dashes in front of each [[Selection|selected]] line if there are such characters.
+ + + +{{note|If there is no selection, these commands will be applied to the current line. }} + + + + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-reference/eiffelstudio-editor/operations-text-blocks/embed-lines-if-thenend-or-debugend.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-reference/eiffelstudio-editor/operations-text-blocks/embed-lines-if-thenend-or-debugend.wiki new file mode 100644 index 00000000..5209ef1a --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-reference/eiffelstudio-editor/operations-text-blocks/embed-lines-if-thenend-or-debugend.wiki @@ -0,0 +1,14 @@ +[[Property:title|Embed lines in 'if then...end' or in 'debug...end']] +[[Property:weight|3]] +[[Property:uuid|c8024b95-376b-628f-1c13-c7fa279006e5]] +=Embed lines in "if then...end" or in "debug...end"= + +EiffelStudio editor offers the possibility to embed several lines in "if then...end" or in "debug...end" structures. +* The first command corresponds to the '''Embed in if''' entry in the '''Advanced''' submenu of the [[Edit menu commands]] [[Edit menu commands| Menu]] . It may be called by using the keyboard shortcut "Ctrl+I" too. Its action is to insert a line with "if then" before the [[Selection|selected]] lines and a line with "end" after those lines. The lines will be indented and the cursor positioned between "if" and "then". +* The second command corresponds to the '''Embed in debug''' entry in the '''Advanced''' submenu of the [[Edit menu commands]] [[Edit menu commands| Menu]] . It may be called by using the keyboard shortcut "Ctrl+D" too. Its action is to insert a line with "debug" before the [[Selection|selected]] lines and a line with "end" after those lines. The lines will be indented and the cursor positioned after "debug" and "then". + +{{note|If there is no selection, these commands will be applied to the current line. }} + + + + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-reference/eiffelstudio-editor/operations-text-blocks/indent-and-unindent-selection.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-reference/eiffelstudio-editor/operations-text-blocks/indent-and-unindent-selection.wiki new file mode 100644 index 00000000..1348a856 --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-reference/eiffelstudio-editor/operations-text-blocks/indent-and-unindent-selection.wiki @@ -0,0 +1,16 @@ +[[Property:title|Indent and unindent selection]] +[[Property:weight|2]] +[[Property:uuid|e0c1014b-1564-8225-9371-556e714848b0]] +EiffelStudio editor offers the possibility to indent or unindent selected lines. + +* The "Indent" command corresponds to the '''Indent selection''' entry in the '''Advanced''' sub menu of the [[Edit menu commands| '''Edit''' Menu ]]. It may be called by using the keyboard shortcut "Tab". Its action is to insert a tabulation in front of each [[Selection|selected]] line. + +* The "Unindent" command corresponds to the '''Unindent selection''' entry in the '''Advanced''' sub menu of the [[Edit menu commands| '''Edit''' Menu ]]. It may be called by using the keyboard shortcut "Shift+Tab". Its action is to remove the tabulation in front of each [[Selection|selected]] line if there is such a character.
+ + + +{{note|If there is no selection, you may still use the unindent shortcut "Shift+Tab". The command will be applied to the current line. }} + + + + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-reference/eiffelstudio-editor/operations-text-blocks/index.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-reference/eiffelstudio-editor/operations-text-blocks/index.wiki new file mode 100644 index 00000000..b97f3f79 --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-reference/eiffelstudio-editor/operations-text-blocks/index.wiki @@ -0,0 +1,9 @@ +[[Property:title|Operations on text blocks]] +[[Property:weight|7]] +[[Property:uuid|b8fccb5b-a3b4-ba11-0781-aa63cef5028e]] +Editing the text of classes sometimes implies highly repetitive tasks, such as commenting or indenting several lines at the same time. + +The commands of the editor of EiffelStudio should allow the user to perform these tasks faster and more easily. In addition to text block [[Comment and uncomment lines|commenting]] and [[Indent and unindent selection|indenting]], EiffelStudio editor makes it possible with one click to [[Embed lines in 'if then...end' or in 'debug...end'|embed]] several lines of code in "if ... then ... end" or "debug ... end" structures. + + + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-reference/eiffelstudio-editor/search-functionality.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-reference/eiffelstudio-editor/search-functionality.wiki new file mode 100644 index 00000000..d3890e2a --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-reference/eiffelstudio-editor/search-functionality.wiki @@ -0,0 +1,20 @@ +[[Property:title|Search functionality]] +[[Property:weight|5]] +[[Property:uuid|eecef577-ac83-610c-9ffd-cb20c4002346]] +EiffelStudio editor provides a search functionality. To search an expression in the edited text, you can either use the [[Search tool|Search tool]] or use a set of keyboard accelerators available directly from the editor. From the editor, you can: + +* Search the next occurrence of the last searched pattern. To do so, press "F3". You can change this key binding in [[Keyboard shortcuts preferences|the preferences]] . + +* Search the previous occurrence of the last searched pattern. To do so, press "Shift+F3". You can change this key binding in [[Keyboard shortcuts preferences|the preferences]] . + +* Search the next occurrence of the current selected pattern. To do so, press "Ctrl+F3". You can change this key binding in [[Keyboard shortcuts preferences|the preferences]] . + +* Search the previous occurrence of the current selected pattern. To do so, press "Ctrl+Shift+F3". You can change this key binding in [[Keyboard shortcuts preferences|the preferences]] . + + +{{seealso|
+[[Search tool|Search tool]] }} + + + + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-reference/eiffelstudio-editor/selection.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-reference/eiffelstudio-editor/selection.wiki new file mode 100644 index 00000000..ad9b578c --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-reference/eiffelstudio-editor/selection.wiki @@ -0,0 +1,19 @@ +[[Property:title|Selection]] +[[Property:weight|2]] +[[Property:uuid|d2da7848-75c5-1512-0e35-38247a71e803]] +In EiffelStudio editor, you can select text by using either the mouse or the keyboard. + +To select a text zone with the keyboard, [[Cursor moves|move the cursor]] to one end of the zone. Then press "Shift" and maintain the key pressed until you moved the cursor to the other end of the zone. The selected zone will appear in reverse video. If you want to select the entire text, press "Ctrl" and "A". + +{{tip|You can combine "Ctrl" and "Shift" when using Left and Right arrows to select text word by word }} + +If you choose to use the mouse, first [[Cursor moves|position the cursor]] to one end of the text zone you want to select, and click there without releasing the mouse button. Then move the mouse pointer to the other end of the zone and release the button. The selected text is shown in reverse video. If the other end of the zone is not visible, move the mouse pointer out of the edition area as you select text in the direction where the end is. EiffelStudio Editor will start scrolling automatically and will stop as soon as the mouse pointer enters the edition area again. + +There are other ways of using the mouse to select text in EiffelStudio editor: +* You can select a word by double-clicking on it. If you do not release the mouse button after the second click, then you will be able to select a text zone but the bound of the zone will move one word at a time. +* If you triple click in the edition area, then the pointed line will be selected. If you do not release the mouse button after the third click, you will be able to select text line by line. +* A quadruple click will select the entire text (this is an option that you can [[Editor Preferences|modify]] in the preferences dialog). + + + + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-reference/eiffelstudio-general-interface-description/eiffelstudio-interface-mechanisms/index.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-reference/eiffelstudio-general-interface-description/eiffelstudio-interface-mechanisms/index.wiki new file mode 100644 index 00000000..3110d799 --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-reference/eiffelstudio-general-interface-description/eiffelstudio-interface-mechanisms/index.wiki @@ -0,0 +1,5 @@ +[[Property:title|EiffelStudio interface mechanisms]] +[[Property:weight|0]] +[[Property:uuid|ae1b2f77-4853-b282-a80b-f9413bbe74a4]] + + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-reference/eiffelstudio-general-interface-description/eiffelstudio-interface-mechanisms/pick-and-drop-mechanism.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-reference/eiffelstudio-general-interface-description/eiffelstudio-interface-mechanisms/pick-and-drop-mechanism.wiki new file mode 100644 index 00000000..385ef587 --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-reference/eiffelstudio-general-interface-description/eiffelstudio-interface-mechanisms/pick-and-drop-mechanism.wiki @@ -0,0 +1,22 @@ +[[Property:title|Pick-and-drop mechanism]] +[[Property:weight|0]] +[[Property:uuid|68a85ff6-d28f-9ba5-0a5c-4eba546497b8]] +Pick-and-drop is one of Eiffel Software's exclusive technologies and is provided by [[EiffelVision Introduction|EiffelVision]]. In EiffelStudio it allows you to send data easily from a component of the interface to another. + +You can pick every reference to a '''development object''' (like a class, a feature or an execution object) with a single click on the '''right''' mouse button. Then as you start moving the mouse around - not pressing any of its buttons - a pebble tracks the cursor position, and a line continuously connects the pebble to the object's original position. The pebble's shape indicates the type of the development object that you picked (oval disk for a class, cross for a feature, folder for a cluster...). + +
[[Image:editor-pick-and-drop]]
+ +You may terminate this situation in either of two ways: +* If the pebble you are dragging is not crossed, you can right-click again to confirm the pick-and-drop and so effectively send the dragged development object to the targeted component. For a class, a droppable pebble looks like this: [[Image:context-class-cursor]] +Right-clicking when the pebble is crossed will only stop the pick-and-drop because the component you are hovering with the mouse does not accept your development object. For a class, a not droppable pebble looks like this: [[Image:context-disabled-class-cursor]] + +* If, for any reason, you change your mind, you can cancel the pick-and-drop by left-clicking anywhere or by pressing the Escape key. + +{{seealso|
+[[Pick-and-drop shortcut|Pick-and-drop shortcut]]
+}} + + + + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-reference/eiffelstudio-general-interface-description/eiffelstudio-interface-mechanisms/pick-and-drop-shortcut.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-reference/eiffelstudio-general-interface-description/eiffelstudio-interface-mechanisms/pick-and-drop-shortcut.wiki new file mode 100644 index 00000000..f8b99efa --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-reference/eiffelstudio-general-interface-description/eiffelstudio-interface-mechanisms/pick-and-drop-shortcut.wiki @@ -0,0 +1,14 @@ +[[Property:title|Pick-and-drop shortcut]] +[[Property:weight|1]] +[[Property:uuid|2cb70fcf-913c-0b74-d2a9-5928caa5904a]] +Pressing the '''control''' key while right-clicking on a development object opens a new editor tab which is centered on the clicked object. + +{{tip|The effect of control-picking is now configurable in the [[Preferences Reference|preferences]] . }} + + +{{seealso|
+[[Pick-and-drop mechanism|Pick-and-drop mechanism]] }} + + + + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-reference/eiffelstudio-general-interface-description/eiffelstudio-interface-mechanisms/toolbar-customization.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-reference/eiffelstudio-general-interface-description/eiffelstudio-interface-mechanisms/toolbar-customization.wiki new file mode 100644 index 00000000..6c52ed56 --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-reference/eiffelstudio-general-interface-description/eiffelstudio-interface-mechanisms/toolbar-customization.wiki @@ -0,0 +1,42 @@ +[[Property:title|Toolbar customization]] +[[Property:weight|2]] +[[Property:uuid|f02205ad-2d3e-a9f1-d104-ca96e1fd2d77]] +It is possible to choose which icons appear in the EiffelStudio [[Main toolbars|toolbars]]. + +If you right-click on any toolbar you will see a context menu that allows you to choose which toolbars are visible and to customize the visible icons for each: + + +[[Image:toolbar-context-menu]] + + +You can also choose to customize a toolbar by clicking on the '''Toolbar Options''' drop-down menu at the right end of the toolbar, and select '''Customize''': + + +[[Image:toolbar-options-dropdown]] + + + +Whenever you choose to customize a toolbar, two lists of icons are displayed in the '''Customize Toolbar''' dialog window. The list on the right shows the icons that are currently displayed in the toolbar. The list on the left gathers the icons that are currently not in the toolbar and that may be added. It also contains a separator that may be used to organize icons. In the figure below, you see the Customize Toolbar dialog targeted to the project toolbar. + + +[[Image:Customize toolbar dialog]] + + + +To add an icon or a separator to the toolbar, select it in the left list and click on the '''Add ->''' button. It will then be inserted in the right list after the selected item.
+To remove an icon, click on it in the right list and click on '''<- Remove'''. + +The order of the icons in the right list is the same as in the toolbar. If you want to move an icon in the list, select it and use '''Up''' and '''Down''' buttons. '''Up''' will move it to the top, i.e. to the left of the toolbar. '''Down''' will move it in the opposite direction. + + +{{tip|You can also pick-and-drop icons to organize them. }} + + +Once you made the changes you wanted, validate them by clicking on '''OK'''. You can also go back to the initial toolbar layout by clicking on '''Cancel'''. + + +{{seealso|
+[[Main toolbars|EiffelStudio toolbars]] }} + + + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-reference/eiffelstudio-general-interface-description/eiffelstudio-key-shortcuts.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-reference/eiffelstudio-general-interface-description/eiffelstudio-key-shortcuts.wiki new file mode 100644 index 00000000..cb1fdbd4 --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-reference/eiffelstudio-general-interface-description/eiffelstudio-key-shortcuts.wiki @@ -0,0 +1,230 @@ +[[Property:title|EiffelStudio: Key shortcuts]] +[[Property:weight|3]] +[[Property:uuid|8092b380-d7ca-2d99-d922-258fcdf6bd48]] +Many operations in EiffelStudio do not require the use of the mouse. The same effect can be achieved through the keyboard only. + +This page gathers all the keyboard shortcuts available in the environment. They are sorted in several categories, depending on their domain of application. + +==Editor shortcuts== + +===Clipboard shortcuts=== + +{| +|- +| '''Key shortcut''' +| '''Purpose''' +|- +| Ctrl+C +| Copy : Copy selected text into the clipboard. +|- +| Ctrl+Ins +| Equivalent to Ctrl+C. +|- +| Ctrl+X +| Cut: Copy selected text into the clipboard and remove it. +|- +| Shift+Del +| Equivalent to Ctrl+X. +|- +| Ctrl+V +| Paste: Insert clipboard content into the text. +|- +| Shift+Ins +| Equivalent to Ctrl+V. +|} + + +===Undo/redo shortcuts=== + +{| +|- +| '''Key shortcut''' +| '''Purpose''' +|- +| Ctrl+Z +| Undo last action. +|- +| Ctrl+Y +| Redo last undone action. +|} + + +===Search shortcuts=== + +{| +|- +| '''Key shortcut''' +| '''Purpose''' +|- +| Ctrl+F +| Display the quick search bar and give the focus to the "Search for..." text field.
+This shortcut may be customized. +|- +| Ctrl+H +| Display the Search tool and give the focus to the "Replace with..." text field.
+This shortcut may be customized. +|- +| F3 +| Search the next occurrence of the last searched expression.
+This shortcut may be customized. +|- +| Shift+F3 +| Search the previous occurrence the last searched expression.
+This shortcut may be customized. +|- +| Ctrl+F3 +| Search the next occurrence of the current selected expression.
+This shortcut may be customized. +|- +| Ctrl+Shift+F3 +| Search the previous occurrence the current selected expression.
+This shortcut may be customized. +|} + + +===Shortcuts to modify selected text=== + +{| +|- +| '''Key shortcut''' +| '''Purpose''' +|- +| Tab +| Indent selection (only if several lines are selected). +|- +| Shift+Tab +| Unindent the selected lines or the current line if there is no selection. +|- +| Ctrl+K +| Comment the selected lines or the current line if there is no selection. +|- +| Ctrl+Shift+K +| Uncomment the selected lines or the current line if there is no selection.
+A line is uncommented only if '--' is at its beginning. +|- +| Ctrl+I +| Embed selection (or the current line if there is no selection)
+in an "if...then...end" structure. +|- +| Ctrl+D +| Embed selection (or the current line if there is no selection)
+in an "debug...end" structure. +|} + + +===Other shortcuts=== + +{| +|- +| '''Key shortcut''' +| '''Purpose''' +|- +| Ctrl+A +| Select the entire text. +|- +| Ctrl+Space +| Auto-complete current word.
+This shortcut may be customized. +|} + + +{{note|These shortcuts are not available everywhere. All operations that do not imply changes in the text are available both in the editor and in the class and feature tabs of the context tool. Other operations are available only in the editor. }} + +==Compiler== + +{| +|- +| '''Key shortcut''' +| '''Purpose''' +|- +| F7 +| Melt the system. This is the standard way to compile a debuggable system. +|- +| Alt+F8 +| Look for externally added, unreferenced classes and recompile. This is normally not needed if classes are added in EiffelStudio or if they are referenced by another class that is in the system. +|- +| Shift+F8 +| Only check override clusters for changed classes and recompile. +|- +| Ctrl+F7 +| Freeze the system. This melts the system and recompile the generated C code. +|- +| Ctrl+Shift+F7 +| Finalize the system. This generates an optimized executable which is not debuggable. +|} + + +==Debugger== + +{| +|- +| '''Key shortcut''' +| '''Purpose''' +|- +| F5 +| Run. This is the standard way to run a system and debug it. +|- +| Ctrl+F5 +| Run without breakpoints. Same as run except that breakpoints are ignored. +|- +| Shift+F5 +| Kill the debugged application +|- +| Ctrl+Shift+F5 +| Pause the debugged application. +|- +| F11 +| Step into. +|- +| F10 +| Step by step. +|- +| Shift+F11 +| Step out. +|} + + +==Miscellaneous== + +===File shortcuts=== + +{| +|- +| '''Key shortcut''' +| '''Purpose''' +|- +| Ctrl+S +| Save the file currently edited in the editor. +|- +| Ctrl+N +| Open a new window. +|} + + +===Editor views shortcuts=== + +{| +|- +| '''Key shortcut''' +| '''Purpose''' +|- +| Ctrl+Shift+T +| Display the text view in the editor. +|- +| Ctrl+Shift+C +| Display the clickable view in the editor. +|- +| Ctrl+Shift+F +| Display the flat view in the editor. +|- +| Ctrl+Shift+O +| Display the contract view in the editor. +|- +| Ctrl+Shift+I +| Display the flat contract view in the editor. +|} + + + + + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-reference/eiffelstudio-general-interface-description/eiffelstudio-window-overview.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-reference/eiffelstudio-general-interface-description/eiffelstudio-window-overview.wiki new file mode 100644 index 00000000..7031ec9a --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-reference/eiffelstudio-general-interface-description/eiffelstudio-window-overview.wiki @@ -0,0 +1,74 @@ +[[Property:title|EiffelStudio window overview]] +[[Property:weight|1]] +[[Property:uuid|db4e1555-8bf3-7418-f754-9defe584044b]] +==Window layout== + +In EiffelStudio all windows have the same components. However, components to be displayed are chosen by the user. Moreover, windows have two modes: the edition mode and the debug mode. Basically, a standard window looks like this: + +[[Image:general-edition-mode]] + +As you can see, it is divided in several parts: a top section, a left panel, a right panel and a status bar. + +The top part is rather not surprising. It first contains a menu bar, which adapts itself to the context of the current project. It also contains two toolbars (the main toolbar and the project toolbar). Between the toolbars is located the main address bar. + +The left panel contains various ''tools'' that help the navigation in the system. + +The right panel contains two major tools: the editor and the context tool. + +The status bar supplies various information: +* Its first field gives punctual information concerning a recent operation (such as loading a project, syntax errors in a class text, etc.). +* The second field contains the name of the current project, which can come quite handy if you work on several projects simultaneously. +* The next field contains the current line and column in the main editor of the window (lines and columns start at position 1). +* The last three fields contain icons representing the state of the project, according to several points of view. +** The first icon indicates whether some class files have been edited since the last compilation. This makes it easy to know whether you have changes to take into account ( [[Image:16x16--general-edit-icon]] ) and whether you should recompile. +** The second icon gives the compilation state of the project. It may indicate either that the last compilation was successful [[Image:compile-success-icon]] , or that it failed [[Image:compile-error-icon]] or that the project is being compiled [[Image:compile-animation-6-icon]] . +** The last icon gives the state of the debugger. It may indicate that the application is running [[Image:run-animation-4-icon]] , paused [[Image:debug-pause-icon]] or dead (no icon). + + +In debug mode, a window looks like this: + +[[Image:general-debug-mode]] + +In debug mode, the same tools are present, but there are three extra tools. Two are located in the left panel, which display respectively the call stack and the dynamic value of expressions. The other is in the right panel and can be used to view the state of objects while debugging. + +==Layout configuration== + +===Tool configuration=== + +All tools have similar controls to give their display options. It is possible to minimize, restore and maximize all tools by using the proper button in their top right-hand corner. Most tools can also be closed. These tools have a close button in the corner. +* The minimize button [[Image:toolbar-minimize-icon]] +* The maximize button [[Image:toolbar-maximize-icon]] +* The restore button [[Image:toolbar-restore-icon]] +* The close button [[Image:toolbar-close-icon]] + +Tools that can be closed have a corresponding entry in the '''View/Explorer Bar''' menu. They also have a corresponding button in the main toolbar. + +The only tools that cannot be closed are the editor, and when in debug mode the debug tools. + +===Toolbar configuration=== + +Both main toolbars can be customized. This allows to select buttons that should be displayed in the toolbars, as well as whether an explanatory text should be displayed next to icons. + +==Context tool== + +The context tool, located in the right panel, is a major part of EiffelStudio. It itself contains several tabs that each correspond to some powerful functionality. +* The '''Output''' tab is where general information and error messages are displayed +* The '''Diagram''' tab uses the BON notation to analyze and design a project +* The '''Class''' tab gives advanced information concerning a class +* The '''Feature''' tab gives advanced information concerning a feature +* The '''Metrics''' tab provides quantitative information concerning a system or some of its components + +By default, the context tool is unlinked from the rest of the window, which means all left tools refer to the object that is in the editor and the main toolbar, while the context tool (and the debug tools if they are present) displays information concerning a different object. It is possible to link the context tool, so that the whole development window displays information relative to the same development object. + +{{seealso|
+[[Introducing EiffelStudio]]
+[[Browsing tools|Browsing tools]]
+[[Main toolbars|Toolbar customization]]
+[[EiffelStudio Editor]]
+[[Formatted information about compiled classes and features]]
+[[Diagram tool]]
+[[Metrics tool|Metric tool]] }} + + + + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-reference/eiffelstudio-general-interface-description/index.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-reference/eiffelstudio-general-interface-description/index.wiki new file mode 100644 index 00000000..1ab494bf --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-reference/eiffelstudio-general-interface-description/index.wiki @@ -0,0 +1,6 @@ +[[Property:title|EiffelStudio: General interface description]] +[[Property:link_title|General Description]] +[[Property:weight|-14]] +[[Property:uuid|9202a4d2-4fee-f4e6-1b7e-12dad9adc3d0]] +In addition to this information describing the EiffelStudio user interface, you may also want to check out the section on [[Docking|docking]] in the EiffelBuild documentation. + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-reference/eiffelstudio-general-interface-description/main-toolbars.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-reference/eiffelstudio-general-interface-description/main-toolbars.wiki new file mode 100644 index 00000000..2269dc6c --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-reference/eiffelstudio-general-interface-description/main-toolbars.wiki @@ -0,0 +1,49 @@ +[[Property:title|Main toolbars]] +[[Property:weight|2]] +[[Property:uuid|56116a68-5881-0393-63d3-dc2044dd4613]] +At the top of a development window, the toolbars are displayed by default. The four toolbars are: +# '''Standard buttons''' toolbar +# '''Project''' toolbar +# '''Address''' toolbar +# '''Refactoring''' toolbar + +You can choose which toolbars are displayed by right-clicking one of the toolbars, or by following the menu path: + + +View --> Toolbars + + +In the figure below, all four toolbars are visible. + + +[[Image:standard-toolbars]] + + +The standard buttons toolbar and the project toolbar are docked next to each other on the same toolbar line. So the standard buttons toolbar is indicated here: + +[[Image:standard-buttons-toolbar]] + + +and the project toolbar is indicated here: + + +[[Image:project-toolbar]] + + +The address toolbar shows the currently targeted class and feature, and has button-holes for advanced views: + + +[[Image:address-toolbar]] + + +The refactoring toolbar has button-holes for Pull-Up and Rename Class/Feature [[Refactoring|refactoring actions]]: + + +[[Image:refactoring-toolbar]] + + +{{note|For each toolbar, it is possible to choose which buttons are displayed and which ones are not. See the [[Toolbar customization|Toolbars customization page]] for more information. Also, you can change the location of the toolbars by undocking and/or redocking them. See more at [[Customizing the tools layout and toolbars]].}} + + + + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-reference/eiffelstudio-preferences/index.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-reference/eiffelstudio-preferences/index.wiki new file mode 100644 index 00000000..7791988f --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-reference/eiffelstudio-preferences/index.wiki @@ -0,0 +1,6 @@ +[[Property:title|EiffelStudio Preferences]] +[[Property:weight|1]] +[[Property:uuid|780757a6-f04a-97d4-5069-d22328e6492f]] +Many of EiffelStudio's properties may be customized. A tool has been designed to help you set your preferences.
+In this section, you will find a [[Preference window overview|description of this tool]]. You will also find [[Preferences Reference|an explanation of the different properties]] that may be modified by using it. + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-reference/eiffelstudio-preferences/preference-window-overview.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-reference/eiffelstudio-preferences/preference-window-overview.wiki new file mode 100644 index 00000000..081a92bb --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-reference/eiffelstudio-preferences/preference-window-overview.wiki @@ -0,0 +1,31 @@ +[[Property:title|Preference window overview]] +[[Property:weight|1]] +[[Property:uuid|52878474-02fd-c68f-0953-a785cac469c8]] +The preferences dialog provide the main table, a filter bar, a the bottom tool bar. + + +[[Image:dialogs-and-wizards--preferences-dialog]] + + +The table is used to display a grid with the preferences displayed in a tree or flat view. + +There are several kinds of preferences: +* Boolean preferences : their possible values are "True" and "False". A check box will allow you to choose between both. +* Color preferences : Their value is represented by three integers, which are the RGB code of the color. You do not have to use RGB codes though. When you double-click such a preference a color chooser dialog will display, allowing you to change the color value. +* Font preferences : A font selection window will appear if you double-click the value label. +* Shortcut preferences : edit the value cell, and press the wanted shortcuts.. +* Other preferences : They will be modified by typing their value directly into an editable text field. +If there is no message stating you need to restart EiffelStudio, changes will be taken into account immediately. + + +{{tip|below the table, you will find a text field with the internal name of the preference (for instance: ''editor.eiffel.auto-complete_...''). }} + + +{{tip|you can export preferences to xml file, and import from xml file, this can be convenient when reinstalling EiffelStudio). }} + + +{{warning|If you restore default preferences values by clicking on the "Restore Default" button, then ALL preferences will be reset. }} + + + + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-reference/eiffelstudio-preferences/preferences-reference/debugger-preferences.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-reference/eiffelstudio-preferences/preferences-reference/debugger-preferences.wiki new file mode 100644 index 00000000..c192fec5 --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-reference/eiffelstudio-preferences/preferences-reference/debugger-preferences.wiki @@ -0,0 +1,46 @@ +[[Property:title|Debugger Preferences]] +[[Property:weight|4]] +[[Property:uuid|79daaf39-447d-9437-8551-4ebbd78bd165]] +This category contains preferences that are specific to the EiffelStudio Debugger and the debugger tool. These preferences are:
+{| border="1" +|- +| '''Label in the preferences window''' +| '''Complete Description''' +|- +| Critical stack depth +| Stack overflow detection: depth of stack at which execution will pause and ask whether it is ok to continue (only works in classic Eiffel). +|- +| Debug output evaluation +| Display DEBUG_OUTPUT.debug_output for objects whose base class inherits from DEBUG_OUTPUT. +|- +| Default displayed string size +| Default number of displayed characters of a STRING (increasing this value might slow down debugging). +|- +| Default expanded view size +| Default number of displayed characters in the expanded view (increasing this value might slow down debugging). +|- +| Default maximum stack depth +| Default number of call stack elements shown in Call Stack tool (-1 to show all of them). +|- +| Delay before cleaning objects grid +| Delay in milliseconds before cleaning the Objects tool view. +|- +| Dotnet debugger +| Which .NET debugger to launch. +|- +| Expanded display background color +| Background color for expanded display view (default is white, change it to better see white spaces in displayed text). +|- +| Generating type evaluation +| Display the base type of an object if enabled, otherwise just the base class (disabling it might speed up debugging). +|- +| Interrupt every n instructions +| Number of instructions that will be executed before interrupting the execution. +|- +| Max evaluation duration +| Number of seconds to wait before cancelling an evaluation. +|} + + + + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-reference/eiffelstudio-preferences/preferences-reference/editor-preferences/eiffel-editor-preferences/index.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-reference/eiffelstudio-preferences/preferences-reference/editor-preferences/eiffel-editor-preferences/index.wiki new file mode 100644 index 00000000..4373cfb2 --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-reference/eiffelstudio-preferences/preferences-reference/editor-preferences/eiffel-editor-preferences/index.wiki @@ -0,0 +1,178 @@ +[[Property:title|Eiffel Editor Preferences]] +[[Property:weight|2]] +[[Property:uuid|0fd6b874-1a89-0acb-ee2e-47bab3b4c819]] +The Eiffel category under the main Editor category contains preferences for Eiffel specific editor values. For example, here you can customize the behavour of autocompletion in the editor, syntax completion on Eiffel keywords, or the colors of Eiffel keywords. +{| border="1" +|- +| '''Label in the preferences window''' +| '''Complete Description''' +|- +| Auto-complete brackets and parenthesis +| Brackets and parentheses are closed automatically? +|- +| Auto-complete quotes +| Quotes are closed automatically? +|- +| Auto auto-complete +| Auto complete appears automatically? +|- +| Auto-complete words +| Automatically completes words when a single best match is available? +|- +| Customized string 1 +| User customized string. +|- +| Customized string 2 +| User customized string. +|- +| Customized string 3 +| User customized string. +|- +| Filter completion list +| Completion list entries are filtered based on matches? +|- +| Once and constant in upper +| Complete once and constants with a first upper case character? +|- +| Show ANY features +| ANY features appear in the feature call complete window? +|- +| Show completion signature +| Completion list shows feature signatures? +|- +| Show completion type +| Completion list shows return type? +|- +| Syntax complete enabled +| Enable syntax autocomplete? +|- +| Text mode is windows +| Text files format: True = Windows / False = UNIX. +|- +| Underscore is separator +| Underscore ' ' is a word separator? +|} + + +==Display Colors== + +{| border="1" +|- +| '''Label in the preferences window''' +| '''Complete Description''' +|- +| Normal text color +| Foreground color for normal text. +|- +| Normal background color +| Background color for normal text. +|- +| Selection text color +| Foreground color for selected text. +|- +| Selection background color +| Background color for selected text. +|- +| String text color +| Foreground color for manifest strings. +|- +| String background color +| Background color for manifest strings. +|- +| Keyword text color +| Foreground color for keywords. +|- +| Keyword background color +| Background color for keywords. +|- +| Spaces text color +| Foreground color for spaces. +|- +| Spaces background color +| Background color for spaces. +|- +| Comments text color +| Foreground color for comments. +|- +| Comments background color +| Background color for comments. +|- +| Number text color +| Foreground color for numbers. +|- +| Number background color +| Background color for numbers. +|- +| Operator text color +| Foreground color for operators. +|- +| Operator background color +| Background color for operators. +|- +| Breakpoint background color +| Color for breakable marks and breakpoints. +|- +| Assertion tag text color +| Foreground color for assertion tags. +|- +| Assertion tag background color +| Background color for assertion tags. +|- +| Indexing tag text color +| Foreground color for indexing tags. +|- +| Indexing tag background color +| Background color for indexing tags. +|- +| Reserved text color +| Foreground color for reserved words. +|- +| Reserved background color +| Background color for reserved words. +|- +| Generic text color +| Foreground color for generics. +|- +| Generic background color +| Background color for generics. +|- +| Local text color +| Foreground color for locals. +|- +| Local background color +| Background color for locals. +|- +| Class text color +| Foreground color for classes. +|- +| Class background color +| Background color for classes. +|- +| Feature text color +| Foreground color for features. +|- +| Feature background color +| Background color for features. +|- +| Cluster text color +| Foreground color for clusters. +|- +| Cluster background color +| Background color for clusters. +|- +| Error text color +| Foreground color for errors. +|- +| Error background color +| Background color for errors. +|- +| Object text color +| Foreground color for objects. +|- +| Object background color +| Background color for objects. +|} + + + + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-reference/eiffelstudio-preferences/preferences-reference/editor-preferences/eiffel-editor-preferences/syntax-automatic-completion-preferences/default-values-keyword-completion-preferences.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-reference/eiffelstudio-preferences/preferences-reference/editor-preferences/eiffel-editor-preferences/syntax-automatic-completion-preferences/default-values-keyword-completion-preferences.wiki new file mode 100644 index 00000000..b1251080 --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-reference/eiffelstudio-preferences/preferences-reference/editor-preferences/eiffel-editor-preferences/syntax-automatic-completion-preferences/default-values-keyword-completion-preferences.wiki @@ -0,0 +1,505 @@ +[[Property:title|Default values for keyword completion preferences]] +[[Property:weight|3]] +[[Property:uuid|17738f37-4f85-c762-4074-5add286c9281]] +This document contains the description of default completion for recognized keywords. The [[Keyword completion customization|syntax]] used is the one used to redefine keyword completion in the preferences.
+Four tables list default values for each of the [[Keywords automatic completion preferences|four preferences]] attached to each keyword. +* Default value for [[Keywords automatic completion preferences|"Customized autocomplete (Space after keyword was typed)"]]
+ +{| border="1" +|- +| '''Keyword''' +| '''Value''' +|- +| indexing +| "$cursor$" +|- +| class +| "$cursor$" +|- +| inherit +| "$cursor$" +|- +| creation +| "$cursor$" +|- +| feature +| "$cursor$" +|- +| is +| "$cursor$" +|- +| require +| "$cursor$" +|- +| require else +| "$cursor$" +|- +| local +| "$cursor$" +|- +| do +| "$cursor$end" +|- +| once +| "$cursor$end" +|- +| deferred +| "end$cursor$" +|- +| external +| ""$cursor$"end" +|- +| rescue +| "$cursor$" +|- +| ensure +| "$cursor$" +|- +| ensure then +| "$cursor$" +|- +| if +| "$cursor$then%N$indent$%T%N$indent$end" +|- +| then +| "$cursor$" +|- +| elseif +| "$cursor$then%N$indent$%T" +|- +| else +| "$cursor$" +|- +| inspect +| "$cursor$%N$indent$when then%N$indent$%T%N$indent$else%N$indent$%T%N$indent$end" +|- +| when +| "$cursor$then%N$indent$%T" +|- +| from +| "$cursor$%N$indent$until%N$indent$loop%N$indent$end" +|- +| variant +| "$cursor$" +|- +| until +| "$cursor$" +|- +| loop +| "$cursor$" +|- +| debug +| "$cursor$end" +|- +| check +| "$cursor$end" +|- +| rename +| "$cursor$" +|- +| redefine +| "$cursor$" +|- +| undefine +| "$cursor$" +|- +| select +| "$cursor$" +|- +| export +| "$cursor$" +|- +| Precursor +| "{$cursor$}" +|- +| create +| "$cursor$" +|- +| obsolete +| ""$cursor$"" +|- +| invariant +| "$cursor$" +|- +| end +| "$cursor$" +|} +
+ +* Default value for [[Keywords automatic completion preferences|"Customized autocomplete (Return after keyword was typed)"]]
+ +{| border="1" +|- +| '''Keyword''' +| '''Return''' +|- +| indexing +| "%N$indent$%T$cursor$" +|- +| class +| "%N$indent$%T$cursor$" +|- +| inherit +| "%N$indent$%T$cursor$" +|- +| creation +| "%N$indent$%T$cursor$" +|- +| feature +| "%N$indent$%T$cursor$" +|- +| is +| "%N$indent$%T%T--$cursor$" +|- +| require +| "%N$indent$%T$cursor$" +|- +| require else +| "%N$indent$%T$cursor$" +|- +| local +| "%N$indent$%T$cursor$" +|- +| do +| "%N$indent$%T$cursor$%N$indent$end" +|- +| once +| "%N$indent$%T$cursor$%N$indent$end" +|- +| deferred +| "%N$indent$end$cursor$" +|- +| external +| "%N$indent$%T"$cursor$"%N$indent$end" +|- +| rescue +| "%N$indent$%T$cursor$" +|- +| ensure +| "%N$indent$%T$cursor$" +|- +| ensure then +| "%N$indent$%T$cursor$" +|- +| if +| "%N$indent$%T$cursor$%N$indent$then%N$indent$%T%N$indent$end" +|- +| then +| "%N$indent$%T$cursor$" +|- +| elseif +| "%N$indent$%T$cursor$%N$indent$then%N$indent$%T" +|- +| else +| "%N$indent$%T$cursor$" +|- +| inspect +| "%N$indent$%T$cursor$%N$indent$when then%N$indent$%T%N$indent$else%N$indent$%T%N$indent$end" +|- +| when +| "%N$indent$%T$cursor$%N$indent$then%N$indent$%T" +|- +| from +| "%N$indent$%T$cursor$%N$indent$until%N$indent$%T%N$indent$loop%N$indent$%T%N$indent$end" +|- +| variant +| "%N$indent$%T$cursor$" +|- +| until +| "%N$indent$%T$cursor$" +|- +| loop +| "%N$indent$%T$cursor$" +|- +| debug +| "%N$indent$%T$cursor$%N$indent$end" +|- +| check +| "%N$indent$%T$cursor$%N$indent$end" +|- +| rename +| "%N$indent$%T$cursor$" +|- +| redefine +| "%N$indent$%T$cursor$" +|- +| undefine +| "%N$indent$%T$cursor$" +|- +| select +| "%N$indent$%T$cursor$" +|- +| export +| "%N$indent$%T$cursor$" +|- +| Precursor +| "%N$indent$%T$cursor$" +|- +| create +| "%N$indent$%T$cursor$" +|- +| obsolete +| "%N$indent$%T"$cursor$"" +|- +| invariant +| "%N$indent$%T$cursor$" +|- +| end +| "%N$indent$$cursor$" +|} +
+ +* Default value for [[Keywords automatic completion preferences|"Customized autocomplete (Space, other cases)"]]
+ +{| border="1" +|- +| '''Keyword''' +| '''Space''' +|- +| indexing +| "$cursor$" +|- +| class +| "$cursor$" +|- +| inherit +| "$cursor$" +|- +| creation +| "$cursor$" +|- +| feature +| "$cursor$" +|- +| is +| "$cursor$" +|- +| require +| "$cursor$" +|- +| require else +| "$cursor$" +|- +| local +| "$cursor$" +|- +| do +| "$cursor$" +|- +| once +| "$cursor$" +|- +| deferred +| "$cursor$" +|- +| external +| "$cursor$" +|- +| rescue +| "$cursor$" +|- +| ensure +| "$cursor$" +|- +| ensure then +| "$cursor$" +|- +| if +| "$cursor$" +|- +| then +| "$cursor$" +|- +| elseif +| "$cursor$" +|- +| else +| "$cursor$" +|- +| inspect +| "$cursor$" +|- +| when +| "$cursor$" +|- +| from +| "$cursor$" +|- +| variant +| "$cursor$" +|- +| until +| "$cursor$" +|- +| loop +| "$cursor$" +|- +| debug +| "$cursor$" +|- +| check +| "$cursor$" +|- +| rename +| "$cursor$" +|- +| redefine +| "$cursor$" +|- +| undefine +| "$cursor$" +|- +| select +| "$cursor$" +|- +| export +| "$cursor$" +|- +| Precursor +| "$cursor$" +|- +| create +| "$cursor$" +|- +| obsolete +| "$cursor$" +|- +| invariant +| "$cursor$" +|- +| end +| "$cursor$" +|} +
+ +* Default value for [[Keywords automatic completion preferences|"Customized autocomplete (Return, other cases)"]]
+ +{| border="1" +|- +| '''Keyword''' +| '''Return''' +|- +| indexing +| "%N$indent$$cursor$" +|- +| class +| "%N$indent$$cursor$" +|- +| inherit +| "%N$indent$$cursor$" +|- +| creation +| "%N$indent$$cursor$" +|- +| feature +| "%N$indent$$cursor$" +|- +| is +| "%N$indent$$cursor$" +|- +| require +| "%N$indent$$cursor$" +|- +| require else +| "%N$indent$$cursor$" +|- +| local +| "%N$indent$$cursor$" +|- +| do +| "%N$indent$$cursor$" +|- +| once +| "%N$indent$$cursor$" +|- +| deferred +| "%N$indent$$cursor$" +|- +| external +| "%N$indent$$cursor$" +|- +| rescue +| "%N$indent$$cursor$" +|- +| ensure +| "%N$indent$$cursor$" +|- +| ensure then +| "%N$indent$$cursor$" +|- +| if +| "%N$indent$$cursor$" +|- +| then +| "%N$indent$$cursor$" +|- +| elseif +| "%N$indent$$cursor$" +|- +| else +| "%N$indent$$cursor$" +|- +| inspect +| "%N$indent$$cursor$" +|- +| when +| "%N$indent$$cursor$" +|- +| from +| "%N$indent$$cursor$" +|- +| variant +| "%N$indent$$cursor$" +|- +| until +| "%N$indent$$cursor$" +|- +| loop +| "%N$indent$$cursor$" +|- +| debug +| "%N$indent$$cursor$" +|- +| check +| "%N$indent$$cursor$" +|- +| rename +| "%N$indent$$cursor$" +|- +| redefine +| "%N$indent$$cursor$" +|- +| undefine +| "%N$indent$$cursor$" +|- +| select +| "%N$indent$$cursor$" +|- +| export +| "%N$indent$$cursor$" +|- +| Precursor +| "%N$indent$$cursor$" +|- +| create +| "%N$indent$$cursor$" +|- +| obsolete +| "%N$indent$$cursor$" +|- +| invariant +| "%N$indent$$cursor$" +|- +| end +| "%N$indent$$cursor$" +|} +
+ + +{{seealso|
+[[Keywords automatic completion preferences|Keywords automatic completion preferences]]
+[[Keyword completion customization|Keyword completion customization]]
+}} + + + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-reference/eiffelstudio-preferences/preferences-reference/editor-preferences/eiffel-editor-preferences/syntax-automatic-completion-preferences/index.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-reference/eiffelstudio-preferences/preferences-reference/editor-preferences/eiffel-editor-preferences/syntax-automatic-completion-preferences/index.wiki new file mode 100644 index 00000000..748a949a --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-reference/eiffelstudio-preferences/preferences-reference/editor-preferences/eiffel-editor-preferences/syntax-automatic-completion-preferences/index.wiki @@ -0,0 +1,6 @@ +[[Property:title|Syntax automatic completion preferences]] +[[Property:weight|-1]] +[[Property:uuid|9899c28c-c7c9-8d0d-1e83-e0d1741c7f3c]] +EiffelStudio editor can detect many keywords and trigger an automatic syntax completion.
+This section of the documentation contains a description of [[Keywords automatic completion preferences|what can be customized]]. You will also find an [[Keyword completion customization|explanation of the syntax]] to be used in completion preferences, [[Default values for keyword completion preferences|and their default values]]. + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-reference/eiffelstudio-preferences/preferences-reference/editor-preferences/eiffel-editor-preferences/syntax-automatic-completion-preferences/keyword-completion-customization.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-reference/eiffelstudio-preferences/preferences-reference/editor-preferences/eiffel-editor-preferences/syntax-automatic-completion-preferences/keyword-completion-customization.wiki new file mode 100644 index 00000000..5ab2b379 --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-reference/eiffelstudio-preferences/preferences-reference/editor-preferences/eiffel-editor-preferences/syntax-automatic-completion-preferences/keyword-completion-customization.wiki @@ -0,0 +1,91 @@ +[[Property:title|Keyword completion customization]] +[[Property:weight|2]] +[[Property:uuid|5e41f619-9a27-d7a3-c722-07f7227c8952]] +This document describes the syntax used to customize keyword automatic completion.
+[[Keywords automatic completion preferences|Four strings]] are used to define the completion of a keyword. The rules are the same for all of them: + +* These strings will be inserted right after the keyword. The key that triggers the automatic completion will not be taken into account, i.e. no space or "new line" character will be inserted even though you press Space or Return. The strings should therefore begin with a space or a "new line" character (see below for "newline"). + +* Two reserved words will allow you to position the cursor and to indent the text properly. Insert the word ''$cursor$'' in the string where you want the cursor to be moved once the completion is finished. Insert the word ''$indent$'' where you want to copy as many blank spaces as there were on the line where the keyword was typed. + +* Three special characters are available: +** ''%N'' represents the new line character. +** ''%T'' represents the tabulation +** ''%B'' represents the back space +
+ + +Examples : + +1) You want the lines of code : + + +if +next_line_of_code +
+ +to become: + + +if then + +end +next_line_of_code + + +as you press Space just after typing if. + +To make this happen, you should define the "Customized auto complete (Space after keyword was typed)" string for if as : + + +$cursor$ then%N$indent$%T%N$indent$end + + +First, EiffelStudio editor has to insert a blank space after if. The string begins therefore by a blank space.
+Then, ''$cursor$'' tells EiffelStudio to move the cursor to this position after the completion.
+then is inserted after the cursor position.
+''%N'' indicates that you want to insert a new line after then.
+''$indent$%T'' means that this line is filled with as many blank spaces as there are before if plus a tabulation.
+Another line is inserted with ''%N''.
+Then ''$indent$end'' means that end will be inserted in this new line with the same indentation as if. + + +2) You want the lines of code : + + +end +next_line_of_code + + +to become: + + +end + +next_line_of_code + + +as you press Return just after typing end. + +To make this happen, you should define the "Customized auto complete (Return after keyword was typed)" string for end as : + + +%B%B%B%Bend%N$indent$%B$cursor$ + + +The four ''%B'' will remove end plus one character before end (the tabulation character).
+end will be inserted at this new position.
+''%N'' indicates that you want to insert a new line.
+''$indent$%B$cursor$'' means that the cursor will be moved to the end of the line where one less blank space than before the original end will have been inserted. + + +{{note|EiffelStudio editor can insert spaces instead of tabulation when you use special character ''%T''. This is set in [[General Editor Preferences|another section of the preferences]] .}} + +{{seealso|
+[[Keywords automatic completion preferences|Keywords automatic completion preferences]]
+[[Default values for keyword completion preferences|Default values for keyword completion preferences]]
+}} + + + + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-reference/eiffelstudio-preferences/preferences-reference/editor-preferences/eiffel-editor-preferences/syntax-automatic-completion-preferences/keywords-automatic-completion-preferences.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-reference/eiffelstudio-preferences/preferences-reference/editor-preferences/eiffel-editor-preferences/syntax-automatic-completion-preferences/keywords-automatic-completion-preferences.wiki new file mode 100644 index 00000000..3bea70d2 --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-reference/eiffelstudio-preferences/preferences-reference/editor-preferences/eiffel-editor-preferences/syntax-automatic-completion-preferences/keywords-automatic-completion-preferences.wiki @@ -0,0 +1,74 @@ +[[Property:title|Keywords automatic completion preferences]] +[[Property:weight|1]] +[[Property:uuid|b54826e4-16f5-7ada-209c-4f7b77e02a29]] +==Description== + +Keywords completion preferences can be found in the subdirectories of "Automatic completion" (located in "Editor" ->"Eiffel"). Keywords are located in subdirectories as described below : +* Class structure keywords: +** class +** creation +** feature +** indexing +** inherit + +* Feature structure keywords +** is +** require +** require else +** local +** do +** deferred +** external +** rescue +** ensure +** ensure then + +* Control structures keywords +** if +** then +** elseif +** else +** inspect +** when +** from +** variant +** until +** loop +** debug +** check + +* Inherit clauses keywords +** rename +** redefine +** undefine +** select +** export + +* Other keywords +** Precursor +** create +** obsolete +** invariant +** end + + +==Usage== + +A directory is associated with each keyword. These directories contains six items which you may modify to customize the automatic completion of the keyword: + +* Autocomplete : If this is set to True, the automatic completion will be triggered when you type the keyword in the editor. If it is set to False, the keyword will be processed as a normal word. + +* Use default autocomplete: If this is set to True, the next preferences will be ignored and the default completion scheme will be used. Otherwise, the automatic completion will use the user-defined strings described below. + +* Customized autocomplete (Return after keyword was typed): This [[Keyword completion customization|string]] defines what will be inserted as you press Return just after typing the keyword if you chose not to use the [[Default values for keyword completion preferences|default value]] (see Use default autocomplete above). + +* Customized autocomplete (Space after keyword was typed): This [[Keyword completion customization|string]] defines what will be inserted as you press Space just after typing the keyword if you chose not to use the [[Default values for keyword completion preferences|default value]] (see Use default autocomplete above). + +* Customized autocomplete (Return, other cases): This [[Keyword completion customization|string]] defines what will be inserted as you press Return after a keyword which had been previously typed. It is effective only if you chose not to use the [[Default values for keyword completion preferences|default value]] (see Use default autocomplete above). + +* Customized autocomplete (Space, other cases): This [[Keyword completion customization|string]] defines what will be inserted as you press Space after a keyword which had been previously typed. It is effective only if you chose not to use the [[Default values for keyword completion preferences|default value]] (see Use default autocomplete above). + +The syntax used in the four last item is described in [[Keyword completion customization|Keyword completion customization]]. [[Default values for keyword completion preferences|Default values]] are accessible in Keyword completion default values. + + + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-reference/eiffelstudio-preferences/preferences-reference/editor-preferences/general-editor-preferences.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-reference/eiffelstudio-preferences/preferences-reference/editor-preferences/general-editor-preferences.wiki new file mode 100644 index 00000000..f1ee9a50 --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-reference/eiffelstudio-preferences/preferences-reference/editor-preferences/general-editor-preferences.wiki @@ -0,0 +1,120 @@ +[[Property:title|General Editor Preferences]] +[[Property:weight|1]] +[[Property:uuid|37b448fb-37a8-7996-1a8a-35b4e74b17d0]] +General Preferences +{| border="1" +|- +| '''Label in the preferences window''' +| '''Complete Description''' +|- +| Automatic update +| Automatic update when the file has not been modified. +|- +| Blinking cursor +| Does text cursor blink? +|- +| Editor font +| All-purpose editor font. +|- +| Keyword font +| Keyword editor font. +|- +| Left margin width +| Width of left margin in editor. Note: this is not the breakpoint margin, but the whitespace to the left of the editor. +|- +| Mouse wheel scroll full page +| Mouse wheel scroll full page? +|- +| Mouse wheel scroll size +| Mouse wheel scroll size. +|- +| Quadruple click enabled +| Does a quadruple click select the entire document? +|- +| Scrolling common line count +| Number of common lines staying on screen after scrolling by one page up or down. +|- +| Show line numbers +| Indicates if editor displays the line numbers by default. +|- +| Smart indentation +| Should editor perform auto-indenting? +|- +| Tab step +| Number of spaces that a tabulation character represents. +|- +| Use buffered line +| Indicates if editor line drawing is first buffered and then drawn, or just drawn directly to the screen. If true scrolling will be smoother, but performance will be slower. +|- +| Use tab for indentation +| Should tab character be used for auto-indentation? +|} + + +Display Colors +{| border="1" +|- +| '''Label in the preferences window''' +| '''Complete Description''' +|- +| colors.normal_text_color +| Color for normal text. +|- +| colors.normal_background_color +| Background color for normal text. +|- +| colors.selection_text_color +| Color of selected text. +|- +| colors.selection_background_color +| Background color of selected text. +|- +| colors.string_text_color +| Color of string text. +|- +| colors.string_background_color +| Background color of string text. +|- +| colors.keyword_text_color +| Color of keyword text. +|- +| colors.keyword_background_color +| Background color of keyword text. +|- +| colors.spaces_text_color +| Color of space characters. +|- +| colors.spaces_background_color +| Background color of space characters. +|- +| colors.comments_text_color +| Color of comments text. +|- +| colors.comments_background_color +| Background color of comments text. +|- +| colors.operator_text_color +| Color of operator text. +|- +| colors.operator_background_color +| Background color of operator text. +|- +| colors.number_text_color +| Color of number text. +|- +| colors.number_background_color +| Background color of number text. +|- +| colors.margin_background_color +| Background color of line number margin. +|- +| colors.margin_separator_color +| Color of separator between line number margin and editor. +|- +| colors.line_number_text_color +| Color of line number text. +|} + + + + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-reference/eiffelstudio-preferences/preferences-reference/editor-preferences/index.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-reference/eiffelstudio-preferences/preferences-reference/editor-preferences/index.wiki new file mode 100644 index 00000000..950b5620 --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-reference/eiffelstudio-preferences/preferences-reference/editor-preferences/index.wiki @@ -0,0 +1,5 @@ +[[Property:title|Editor Preferences]] +[[Property:weight|3]] +[[Property:uuid|fd7ec7c0-4c15-f2c2-70b7-82bc0a07a064]] +Some of the features of the EiffelStudio editor can be customized. This section of the documentation contains the necessary explanations to use the editor preferences. In addition to a description of [[General Editor Preferences|general preferences]] for the editor, you will find a document about [[Keyboard shortcuts preferences|user-definable keyboard shortcuts]] and a preferences for Eiffel specific preferences such as [[Syntax automatic completion preferences|automatic completion.]] + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-reference/eiffelstudio-preferences/preferences-reference/editor-preferences/keyboard-shortcuts-preferences.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-reference/eiffelstudio-preferences/preferences-reference/editor-preferences/keyboard-shortcuts-preferences.wiki new file mode 100644 index 00000000..1866becd --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-reference/eiffelstudio-preferences/preferences-reference/editor-preferences/keyboard-shortcuts-preferences.wiki @@ -0,0 +1,24 @@ +[[Property:title|Keyboard shortcuts preferences]] +[[Property:weight|2]] +[[Property:uuid|1fbfc5fe-cbaf-9a55-cd5c-672f9b7a3e24]] +Some of the keyboard shortcuts used in the editor can be customized. A subfolder of the "Keyboard Shortcuts" folder in the editor preferences corresponds to each of these customizable shortcuts. There are four values to set to define a shortcut: which key must be pressed and whether CTRL, ALT or SHIFT have to be pressed at the same time. You will find a combination of all in each shortcut subfolder. The customizable shortcuts are: +* Autocomplete: Shortcut to trigger the feature call automatic completion. The default key combination is CTRL+SPACE. +* Class name autocomplete: Shortcut to trigger the class name automatic completion. The default key combination is CTRL+SHIFT+SPACE. +* Search selection: Shortcut to launch a search of the currently selected item. If there is no selected item, the editor will look for the next occurrence of the last searched pattern. The default key combination for this command is F3. +* Search again: Shortcut to move to the next occurrence of the searched pattern. If the shortcut is the same as for Search Selection, the effect of the command will be to search for the next occurrence of the currently searched pattern unless something else is selected in the editor. In that case, the editor will look for the next occurrence of the selected text. The default key combination for this command is F3. +* Search backwards: Shortcut to move to the previous occurrence of the searched pattern. The default key combination for this command is SHIFT+F3. +* Show search panel: Shortcut to make the search panel appear if it is not displayed and to give the focus to the "Search for" field. The default key combination for this command is CTRL+F. +* Show search and replace panel: Shortcut to make the search panel with the "Replace with" field appear if it is not displayed. The focus will be given to the "Search for" field. The default key combination for this command is CTRL+H. + + +{{note|You should avoid using key combinations made of only ALT and another key as they are reserved for menu shortcuts. }} + + +{{Tip|You may use combinations made of only one key to create very fast shortcuts, for example with the function keys. To know what string corresponds to a given key, you can look up in the EV_KEY_CONSTANTS of EiffelVision2.The `key_strings` table links keys with a string representation. }} + + +There are three other categories in the shortcut preferences. These can be used to automatically insert a user-defined string in the editor. If you find yourself typing some strings very often, these preferences can be handy. + + + + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-reference/eiffelstudio-preferences/preferences-reference/eiffelstudio-tools-preferences/context-tools.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-reference/eiffelstudio-preferences/preferences-reference/eiffelstudio-tools-preferences/context-tools.wiki new file mode 100644 index 00000000..8ca20cc3 --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-reference/eiffelstudio-preferences/preferences-reference/eiffelstudio-tools-preferences/context-tools.wiki @@ -0,0 +1,111 @@ +[[Property:title|Context Tools]] +[[Property:weight|1]] +[[Property:uuid|40300782-f154-3a13-acd4-ee48184be315]] +This category gathers the preferences related to context tools. +{| border="1" +|- +| '''Label in the preferences window''' +| '''Complete Description''' +|- +| Default class formatter index +| Class view format that is selected by default (see table below for available format indexes). +|- +| Default feature formatter index +| Feature view format that is selected by default (see table below for available format indexes). +|- +| Excluded indexing items +| Indexing items that need not be included in formatted texts. +|- +| Formatters history size +| Number of cached formatted text in history. +|- +| Show all callers +| Show all callers (as opposed to local callers) in `callers` form. +|} + + +Class views indices: +{| border="1" +|- +| '''Index''' +| '''Class view''' +|- +| 1 +| Clickable view +|- +| 2 +| Flat view +|- +| 3 +| Contract view +|- +| 4 +| Interface view +|- +| 5 +| Ancestors +|- +| 6 +| Descendants +|- +| 7 +| Clients +|- +| 8 +| Suppliers +|- +| 9 +| Attributes +|- +| 10 +| Routines +|- +| 11 +| Deferred features +|- +| 12 +| Once routines and constants +|- +| 13 +| External features +|- +| 14 +| Exported features +|} + + +Feature views indices: +{| border="1" +|- +| '''Index''' +| '''Feature view''' +|- +| 1 +| Basic text view +|- +| 2 +| Flat view +|- +| 3 +| Callers +|- +| 4 +| Implementers +|- +| 5 +| Ancestor versions +|- +| 6 +| Descendants versions +|- +| 7 +| Homonyms +|} + + +{{seealso|
+[[EiffelStudio Tools Preferences|Preferences for other tools]] }} + + + + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-reference/eiffelstudio-preferences/preferences-reference/eiffelstudio-tools-preferences/eiffelstudio-diagram-tool-preferences.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-reference/eiffelstudio-preferences/preferences-reference/eiffelstudio-tools-preferences/eiffelstudio-diagram-tool-preferences.wiki new file mode 100644 index 00000000..93638261 --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-reference/eiffelstudio-preferences/preferences-reference/eiffelstudio-tools-preferences/eiffelstudio-diagram-tool-preferences.wiki @@ -0,0 +1,178 @@ +[[Property:title|EiffelStudio Diagram Tool Preferences]] +[[Property:weight|2]] +[[Property:uuid|6e2eed8e-b225-0dee-5ea0-e4c25a0c3d5a]] +This category gathers the preferences related to the EiffelStudio BON Diagram tool. Preferences for BON notation are under the 'Bon' category and for UML notation are under the 'UML' category. +==General Preferences== + +{| border="1" +|- +| '''Label in the preferences window''' +| '''Complete description''' +|- +| Ancestor depth +| Show ancestors of a class up to a level of preference value. +|- +| Autoscroll speed +| Color for UML inheritance links. +|- +| Client depth +| Show clients of a class up to a level of preference value. +|- +| Descendant depth +| Show descendants of a class down to a level of preference value. +|- +| Excluded class figures +| Names of classes that should not appear in generated diagrams. +|- +| Ignore excluded class figures +| Show ALL classes in the diagram (ignore the following list)? +|- +| Subcluster depth +| Show subclusters of a cluster down to a level of preference value. +|- +| Supercluster depth +| Show superclusters of a cluster up to a level of preference value. +|- +| Supplier depth +| Show suppliers of a class up to a level of preference value. +|} + + +==BON Preferences== + +{| border="1" +|- +| Bon class name font +| Font for class names in BON class figures. +|- +| Bon class name color +| Color for class names in BON class figures. +|- +| Bon class fill color +| Color for BON class figures. +|- +| Bon class uncompiled fill color +| Color for uncompiled BON class figures. +|- +| Bon class generics font +| Font for generics in BON class figures. +|- +| Bon class generics color +| Color for generics in BON class figures. +|- +| Bon client label font +| Font for feature names on BON client supplier links. +|- +| Bon client label color +| Color for feature names on BON client supplier links. +|- +| Bon client color +| Color for BON client supplier links. +|- +| Bon client line width +| Line width for BON client supplier links. +|- +| Bon cluster line color +| Color for BON cluster line. +|- +| Bon cluster iconified fill color +| Iconified BON Cluster fill color. +|- +| Bon cluster name area color +| BON cluster name area fill color. +|- +| Bon cluster name color +| BON cluster name color. +|- +| Bon cluster name font +| BON cluster name font. +|- +| Bon inheritance color +| Color for BON inheritance links. +|- +| Bon inheritance line width +| Line width for BON inheritance links. +|} + + +==UML Preferences== + +{| border="1" +|- +| Uml class name font +| Font for class names in UML class figures. +|- +| uml class deferred font +| Font for names of deferred classes in UML class figures. +|- +| Uml class properties font +| Font for class properties in UML class figures. +|- +| Uml class properties color +| Color for class properties in UML class figures. +|- +| Uml class name color +| Color for class names in UML class figures. +|- +| Uml class fill color +| Color for UML class figures. +|- +| Uml generics font +| Font for generics in UML class figures. +|- +| Uml generics color +| Color for generics in UML class figures. +|- +| Uml class features font +| Font for class features in UML class figures. +|- +| Uml class features color +| Color for class features in UML class figures. +|- +| Uml class feature section font +| Font for class feature sections in UML class figures. +|- +| Uml class feature section color +| Color for class feature sections in UML class figures. +|- +| Uml client line width +| Line width for UML client supplier links. +|- +| Uml client color +| Color for UML client supplier links. +|- +| Uml client label color +| Color for feature names on UML client supplier links. +|- +| Uml client label font +| Font for feature names on UML client supplier links. +|- +| Uml cluster line color +| Color for UML cluster line. +|- +| Uml cluster iconified fill color +| Iconified UML Cluster fill color. +|- +| Uml cluster name area color +| UML cluster name area fill color. +|- +| Uml cluster name color +| UML cluster name color. +|- +| Uml cluster name font +| UML cluster name font. +|- +| Uml inheritance line width +| Line width for UML inheritance links. +|- +| Uml inheritance color +| Color for UML inheritance links. +|} + + +{{seealso|
+[[EiffelStudio Tools Preferences|Preferences for other tools]] }} + + + + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-reference/eiffelstudio-preferences/preferences-reference/eiffelstudio-tools-preferences/index.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-reference/eiffelstudio-preferences/preferences-reference/eiffelstudio-tools-preferences/index.wiki new file mode 100644 index 00000000..bfcbbb23 --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-reference/eiffelstudio-preferences/preferences-reference/eiffelstudio-tools-preferences/index.wiki @@ -0,0 +1,7 @@ +[[Property:title|EiffelStudio Tools Preferences]] +[[Property:weight|2]] +[[Property:uuid|76e278d3-c15d-43ba-ac79-611b05761b76]] +This section of the help deals with preferences related to a tool in particular. These preferences are distributed in two categories: +* A [[Context Tools]] category used to change preferences related to context tools. +* A [[EiffelStudio Diagram Tool Preferences|Diagram Tools]] category used to customize some features of the diagram tool, mainlycolors and fonts for graphical element display. + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-reference/eiffelstudio-preferences/preferences-reference/general-preferences.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-reference/eiffelstudio-preferences/preferences-reference/general-preferences.wiki new file mode 100644 index 00000000..20b2930e --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-reference/eiffelstudio-preferences/preferences-reference/general-preferences.wiki @@ -0,0 +1,24 @@ +[[Property:title|General Preferences]] +[[Property:weight|0]] +[[Property:uuid|cc42c410-bec5-4a4e-c45f-e005213cb260]] +General preferences are non-graphical preferences and preferences that are not related to a particular tool. These preferences are: + + +{| border="1" +|- +| '''Label in the preferences window''' +| '''Complete description''' +|- +| Acrobat Reader +| Command to read Adobe Acrobat files. +|- +| Shell command +| You may open a class in an external editor by dropping the corresponding pebble on the external editor icon. This preference sets which command line will be used to launch the external editor. The parameter "$target"will be replaced in the command with the file name corresponding to the class, "$line" with the line number if this information is relevant, with 1 otherwise. +|- +| Internet browser (GTK platforms only) +| This sets the command line that should be used to open an internet browser on a given HTML page. If present, "$url" will be replaced with the URL of the HTML page. This is used to display help files. +|} + + + + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-reference/eiffelstudio-preferences/preferences-reference/index.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-reference/eiffelstudio-preferences/preferences-reference/index.wiki new file mode 100644 index 00000000..53ba3c10 --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-reference/eiffelstudio-preferences/preferences-reference/index.wiki @@ -0,0 +1,5 @@ +[[Property:title|Preferences Reference]] +[[Property:weight|2]] +[[Property:uuid|a93a61b7-4814-e8a8-0379-52c0012f5935]] +The top level preference categories for EiffelStudio preferences are listed below. + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-reference/eiffelstudio-preferences/preferences-reference/interface/development-window-preferences.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-reference/eiffelstudio-preferences/preferences-reference/interface/development-window-preferences.wiki new file mode 100644 index 00000000..64c973d7 --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-reference/eiffelstudio-preferences/preferences-reference/interface/development-window-preferences.wiki @@ -0,0 +1,67 @@ +[[Property:title|Development Window Preferences]] +[[Property:weight|1]] +[[Property:uuid|b939459c-2ffe-4037-fb54-dd4bd61aa603]] +This category gathers a list of preferences related to the development window in EiffelStudio.
+{| border="1" +|- +| '''Label in the preferences window''' +| '''Complete Description''' +|- +| Class completion +| Allow class name completion in the address combo boxes? +|- +| Ctrl right click receiver +| Receivers of control-right-click. +|- +| Dock tracking +| Docked tools track main window? +|- +| Editor left side +| Display editor on left? (Requires restart) +|- +| Expand feature tree +| Automatically expand the feature tree. +|- +| Feature clause order +| Order used to sort feature clauses in formatted texts. +|- +| Graphical output disabled +| Disable graphical output? +|- +| Left panel use explorer style +| Show only one tool (Features, Clusters, Search, Windows) at a time. (Requires restart) +|- +| Maximum history size +| Maximum number of items displayed in the history combo boxes. +|- +| Progress bar color +| Color for progress bar. +|- +| Remember completion list size +| Should size of completion list be remembered between completions in the editor? +|- +| Search tool show_options +| Should search tool be shown? +|- +| Show address toolbar +| Should address toolbar be shown? +|- +| Show all text in general toolbar +| Is text of toolbar items displayed? +|- +| Show general_toolbar +| Should general toolbar be shown? +|- +| Show project toolbar +| Should project toolbar be shown? +|- +| Show text in general_toolbar +| Should text be shown in general toolbar? +|- +| Unified stone +| Link the context tool with other components by default? +|} + + + + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-reference/eiffelstudio-preferences/preferences-reference/interface/discardable-dialogs.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-reference/eiffelstudio-preferences/preferences-reference/interface/discardable-dialogs.wiki new file mode 100644 index 00000000..84637775 --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-reference/eiffelstudio-preferences/preferences-reference/interface/discardable-dialogs.wiki @@ -0,0 +1,8 @@ +[[Property:title|Discardable dialogs]] +[[Property:weight|2]] +[[Property:uuid|c2e96013-d767-22a0-f5c3-2ecd8d3c66b1]] +Some dialogs in EiffelStudio include a check box labeled "Do not show me again". If you select it, the dialog will not be shown the next time the same situation occurs. The "dialogs" sub-category of "Interface" in the preferences lists the state of those discardable dialogs: a boolean preference is associated with each of them. The window will be shown if and only if the corresponding preference is set to True. + + + + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-reference/eiffelstudio-preferences/preferences-reference/interface/index.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-reference/eiffelstudio-preferences/preferences-reference/interface/index.wiki new file mode 100644 index 00000000..a08e5c14 --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-reference/eiffelstudio-preferences/preferences-reference/interface/index.wiki @@ -0,0 +1,5 @@ +[[Property:title|Interface]] +[[Property:weight|1]] +[[Property:uuid|e0fe1870-cf02-4ca9-e46a-e69c8db1ed48]] +This section of the documentation describes preferences that belong to the "Interface" category. This group contains two kinds of properties, some related to the preferences for the EiffelStudio [[Development Window Preferences|development window]], others that define which [[Discardable dialogs|dialog windows]] should or should not be displayed. You can also decide to use animated icons in the status bars whenever possible (that is, during compilations and executions). + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-reference/eiffelstudio-preferences/preferences-reference/recent-project-preferences.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-reference/eiffelstudio-preferences/preferences-reference/recent-project-preferences.wiki new file mode 100644 index 00000000..aaa2cfb0 --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-reference/eiffelstudio-preferences/preferences-reference/recent-project-preferences.wiki @@ -0,0 +1,19 @@ +[[Property:title|Recent Project Preferences]] +[[Property:weight|5]] +[[Property:uuid|ab64bb5a-5c92-bd3c-b6d4-c31361d4fd1d]] +This category gathers a list of recently opened projects in EiffelStudio. It also let's you decide how many recently opened projects to store in the list:
+{| border="1" +|- +| '''Label in the preferences window''' +| '''Complete description''' +|- +| Keep n projects +| This integral preference defines the maximum number of entries that should be displayed in the '''File/Recent projects''' menu. +|- +| Last opened projects +| A semi-colon separated list of the actual recently opened project +|} + + + + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-reference/eiffelstudio-project-settings-window/general-target-options/Language-and-Capabilities.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-reference/eiffelstudio-project-settings-window/general-target-options/Language-and-Capabilities.wiki new file mode 100644 index 00000000..c72e7f91 --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-reference/eiffelstudio-project-settings-window/general-target-options/Language-and-Capabilities.wiki @@ -0,0 +1,16 @@ +[[Property:modification_date|Mon, 10 Sep 2018 10:49:19 GMT]] +[[Property:publication_date|Mon, 10 Sep 2018 10:32:05 GMT]] +[[Property:uuid|81E6A18A-C7D8-4F80-8D08-8B2C0B6350C8]] +[[Property:weight|0]] +[[Property:title|Language and Capabilities]] +The sections '''Language''' and '''Capability''' list closely-related options that work together. The values in the section '''Language''' specify what rules or semantics the compiler should apply when compiling and running code. If not specified, the value of the corresponding option from the section '''Capability''' is used. A selected value in the section '''Language''' should be compatible with the value in the section '''Capability'''. In other words, the values listed in '''Capability''' tell what source code is capable of, whereas the values in '''Language''' tell what is used when compiling for a specific target. + +The values in the section '''Language''' are used only when the corresponding target is compiled as a root one. Otherwise, they are ignored. The values in the section '''Capability''' are used to verify that current project settings allow for using a particular library (or classes of the project itself). For example, the [https://www.eiffel.org/doc/uuid/a03568e8-eb79-70d7-04a3-6fd3ed7ac2b3 void-safe] library ''[https://www.eiffel.org/doc/uuid/0153c1de-bf88-fa0d-52a5-e50ffcc4e8c8 Base]'' can be used in a non-void-safe project, because project settings are compatible with capabilities of the library. On the other hand, the library ''[https://www.eiffel.org/doc/uuid/AAF0CEF9-7268-492F-9119-872164995898 Thread]'' cannot be used in a [https://www.eiffel.org/doc/uuid/5FE312E0-0AC6-465C-AD3B-D5D73AAE566F SCOOP] project, because the library is not SCOOP-capable. + +Capabilities are supported for the following settings, listed together with compatibility order, where ''X < Y'' means ''X'' is compatible with ''Y'': + +# CAT-call detection: None < Transitional < Complete. +# Concurrency: Thread < None < SCOOP. +# Void safety: None < Conformance < Initialization < Transitional < Complete. + +In addition to the restriction on the compilation setting specified in the section '''Language''', a project or a library with a higher level of capabilities cannot rely on a library with a lower level. \ No newline at end of file diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-reference/eiffelstudio-project-settings-window/general-target-options/advanced-options/debug-options.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-reference/eiffelstudio-project-settings-window/general-target-options/advanced-options/debug-options.wiki new file mode 100644 index 00000000..c0ea847e --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-reference/eiffelstudio-project-settings-window/general-target-options/advanced-options/debug-options.wiki @@ -0,0 +1,11 @@ +[[Property:title|Debug Options]] +[[Property:weight|6]] +[[Property:uuid|ea9cc7c3-0bdb-5ef8-e4a6-c66d5f3dd951]] +[[Image:debug-options|Debug dialog]] +* Enabled: globally enabled/disable debugs. +* Unnamed Debugs: debug clauses without a name +* Named Debugs: if the system is compiled, an entry for each name in a debug appears and can be enabled/disabled. + + + + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-reference/eiffelstudio-project-settings-window/general-target-options/advanced-options/externals-options.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-reference/eiffelstudio-project-settings-window/general-target-options/advanced-options/externals-options.wiki new file mode 100644 index 00000000..d599f55f --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-reference/eiffelstudio-project-settings-window/general-target-options/advanced-options/externals-options.wiki @@ -0,0 +1,25 @@ +[[Property:title|Externals Options]] +[[Property:weight|7]] +[[Property:uuid|0e46ef16-4946-8bc7-6481-0d069cbb506b]] +[[Image:external-options|Externals dialog]] + +In most cases this is not needed but for some C/C++ externals and in some .NET projects it is necessary to specify additional includes, objects or resources. + +If you use a library, externals of this library are automatically included. E.g. if you use vision2 the externals for vision2 don't need to be added to the project itself. +* Include: This is where you can enter the location of the directories where the C/C++ compiler will look for the header files that are required. The header files which the C/C++ compiler will look for are the ones that appear in an encapsulation of a C/C++ external in an Eiffel class. See the pages on "[[With other languages|interacting with other languages]]" to learn more about specifying C/C++ externals. +* Object: additional C/C++ object files +* Library: like object files, but will be added last, needed for some very strict C compilers +* Makefile: additional makefiles, if possible use tasks instead + +Resource: .NET resources +* The .resx resource file format is a XML based format to include objects (such as images and other binary formats) and strings. +* The .txt resource file format can only contains strings. + +Externals have three properties: +* Location: location of the external, will be copied verbatim into the makefile +* Description: an optional description about the external +* Condition: allows the same configuration with externals to work in different situations (e.g. windows and unix) (see [[General Target Options|conditions]] ) + + + + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-reference/eiffelstudio-project-settings-window/general-target-options/advanced-options/index.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-reference/eiffelstudio-project-settings-window/general-target-options/advanced-options/index.wiki new file mode 100644 index 00000000..797b0b32 --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-reference/eiffelstudio-project-settings-window/general-target-options/advanced-options/index.wiki @@ -0,0 +1,192 @@ +[[Property:title|Advanced Options]] +[[Property:weight|4]] +[[Property:uuid|be1dc034-2bca-3d3a-5dfc-8597b2cc7051]] +[[Image:advanced-options|Advanced dialog]] +* Address Expression: lets you pass `$(s.to_c)` to a feature instead of declaring `a` of type ANY, and then assigning `s.to_c` to `a` and passing `$a`. +{{Caution|Turn this option on only if you have advanced knowledge of the garbage collector internals, because using this syntax in some situations could lead to bugs that are very hard to trace. }} +* Automatic Backup: generate a backup of the class and configuration files during recompilation? +* Check VAPE: Enforce VAPE validity constraint: lets you disable type checking for VAPE errors in preconditions, which correspond to insufficiently exported features used in preconditions (ETL 2nd edition page 122). +* Check for Void target: Should "Feature call on Void target" exceptions be raised? +* Console Application: has no effect on Unix systems. It lets Windows users choose between creating a console application or a GUI application (in which case a console will be created if needed, instead of using the console the program was launched from). +* Dead Code Removal: should unused code be removed? (C code generation mode only) +* Dynamic Runtime: makes the generated executable use a shared library version of the runtime on both Windows (DLL) and Unix platforms (.so) that supports shared libraries.(C code generation mode only) + +{{note|On Windows, the dynamic run-time is available only if you compile with the Microsoft Visual compiler. }} +* Enforce unique class names: enforce all class names to be system wide unique? +* Exception Trace: makes it possible to see a complete exception trace in a finalized application. Because it is adding some code to remember where the application was during the crash it can slow down the performance of your application by a factor of 5% to 30% depending of your platform. (C code generation mode only) +* Inlining, Inlining Size: enables inlining on Eiffel features that can be inlined, i.e. whose size is less or equal to the specified size in the combo box. The size value given in parameter corresponds to the number of instructions as seen by the Eiffel compiler (for example a := b.f corresponds to 2 instructions). The inlining is very powerful since it can inline a function in all your Eiffel code, without scope limitation as found in C or C++ compilers. (C code generation mode only) +* Platform: override platform value used for checking conditions, useful for cross compilation +* Shared Library Definition: lets you specify a `file_name.def' as the file where the Eiffel compiler will look when it tries to generate the exported functions of the shared library you are developing (C code generation mode only). To have more information concerning definition files, see the [[Dynamic library generation]] . +* Total Order on REALs: Allow a total order on REAL data types? Allows NaN (Not a Number) equal NaN, and NaN to be the smallest number of all. +* Library Root: Absolute path to use as base for relative paths. If this is not defined, the path to the configuration file will be used. + +==.NET Options== +* Use Optimized Precompile: use an optimized version of a precompile +* Use Cluster Name as Namespace: See [[Advanced Options|Class and feature naming]] +* Use Recursive Cluster Name as Namespace: See [[Advanced Options|Class and feature naming]] +* .NET Naming Convention: See [[Advanced Options|Class and feature naming]] +* IL Verifiable: in the .NET world, verifiability is important. This is the only way to ensure that an application is not going to crash or to crash your system by accessing not authorized memory locations. Due to some semantic differences between Eiffel and.NET, our code generation is not always verifiable for performance reasons. If you want your code to be verifiable, you need to select this option. The compiler will then generate a code that will be slightly slower. +* CLS Compliant: mark generated assemblies as CLS compliant + +* Metadata Cache Path: Location where information about external assemblies is stored. +* Classes per Module: Number of classes generated per .NET module during incremental compilation. Increasing this value will slow down the incremental recompilation, but speed up the time to load the assembly while debugging in workbench mode. +* .NET Runtime Version: .NET version to use +* Generation Type: generate an exe or a dll (exe is default) +* Signing Key: specify a cryptographic key for your application so that the compiled assembly can be added to the Global Assembly Cache (GAC). If a non existing filename is chosen, a key will be automatically generated. +* Force 32bit: on a 64bit machine, forces compilation for 32 bit. + +===Class and feature naming=== + + +The standard naming conventions for .NET and Eiffel are different. To accommodate this difference Eiffel Studio provides a number of options to the developer, allowing for consistent naming of classes and features within and between .NET systems. To illustrate this we shall consider a system using the EiffelBase library and focus on the CURSOR class. The base cluster is included in the project settings Cluster tab as shown below, where $ISE_EIFFEL is the environment variable pointing to the location of Eiffel on your hard disk. + + +The CURSOR class is located at '$ISE_EIFFEL\library\base\structures\cursors'. + + +* Follow .NET naming guidelines: this option determines whether the generated .NET code uses the Eiffel or .NET naming convention. Using Ildasm, the IL disassembler tool provided with the .NET Framework, we can see the difference between them. The Eiffel naming convention uses uppercase characters for all classes whereas the .NET nomenclature uses the Camel Case style. Note that this option is only available in a non-compiled system. Once the system has been compiled the naming standard is fixed for the project. + +No .NET naming guidelines + +[[Image:ildasm-no-dotnet-naming]] + +.NET naming guidelines + +[[Image:ildasm-dotnet-naming]] + + +* Use cluster names and Use recursive cluster names: These options dictate how a class is known to the system. In our CURSOR example there are 4 main scenarios. For a quick overview of all scenarios refer to the table at the bottom of the page. If neither box is selected we just have 'CURSOR' or 'Cursor' (depending on whether the .NET naming guidelines are used), as seen above. If 'Use cluster names' is checked then the cluster name is pre-pended to the class name, so 'CURSOR' now becomes 'base.CURSOR'. + +[[Image:use-cluster-names]] + + + +If 'Use recursive cluster names' is true then the full cluster name is pre-pended to the class name, so it thus becomes 'base.structures.cursors.CURSOR'. + + + +[[Image:use-full-cluster-names]] + + + +The final scenario is where a namespace has been defined for the cluster in the Clusters tab of the Project Settings. In this situation the namespace overrides the name of the cluster. In the example below the namespace name 'MyBaseNameSpace' is used so the resulting name is 'MyBaseNameSpace.structures.cursors.CURSOR'. + + + +[[Image:use-namespace-name]] + + + +===Naming Scenarios=== + +This table shows how the class name generation is affected by the naming options using the CURSOR class found in '$ISE_EIFFEL\library\base\structures\cursors' as an example. +{| +|- +| Use .NET naming guidelines +| Use cluster names +| Use full cluster names +| Namespace Name +| Generated Name +|- +| no +| no +| no +| (empty) +| CURSOR +|- +| yes +| no +| no +| (empty) +| Cursor +|- +| no +| yes +| no +| (empty) +| base.CURSOR +|- +| yes +| yes +| no +| (empty) +| Base.Cursor +|- +| no +| no +| yes +| (empty) +| structures.cursors.CURSOR +|- +| yes +| no +| yes +| (empty) +| Structures.Cursors.Cursor +|- +| no +| yes +| yes +| (empty) +| base.structures.cursors.CURSOR +|- +| yes +| yes +| yes +| (empty) +| Base.Structures.Cursors.Cursor +|- +| no +| no +| no +| MyNameSpace +| MyNameSpace.CURSOR +|- +| yes +| no +| no +| MyNameSpace +| MyNameSpace.Cursor +|- +| no +| yes +| no +| MyNameSpace +| MyNameSpace.CURSOR +|- +| yes +| yes + +| no +| MyNameSpace +| MyNameSpace.Cursor +|- + +| no +| no +| yes +| MyNameSpace +| MyNameSpace.structures.cursors.CURSOR +|- +| yes +| no +| yes +| MyNameSpace +| MyNameSpace.structures.cursors.Cursor +|- +| no +| yes +| yes +| MyNameSpace +| MyNameSpace.structures.cursors.CURSOR +|- +| yes +| yes +| yes +| MyNameSpace +| MyNameSpace.Structures.Cursors.Cursor +|} + + + + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-reference/eiffelstudio-project-settings-window/general-target-options/advanced-options/tasks-options.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-reference/eiffelstudio-project-settings-window/general-target-options/advanced-options/tasks-options.wiki new file mode 100644 index 00000000..0ef1fad6 --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-reference/eiffelstudio-project-settings-window/general-target-options/advanced-options/tasks-options.wiki @@ -0,0 +1,26 @@ +[[Property:title|Tasks Options]] +[[Property:weight|8]] +[[Property:uuid|48d23a04-22cc-8676-f163-31c3848e86e7]] +[[Image:task-options|Tasks dialog]] + +It is possible to have a command executed before/after an eiffel compilation. +Tasks have these properties: +* Command: command to execute +* Description: an optional description about the external +* Working directory: an optional working directory, if nothing is specified, the path to the configuration file will be used +* Must succeed: does the task have to finish successful for the compilation to continue? +* Condition: allows the same configuration with tasks to work in different situations (e.g. windows and unix) (see [[General Target Options|conditions]] ) + +==Examples== + +===Windows=== +Execute a command and pause until user presses a key +{{sample|cmd /c "dir && pause"}} + +===Unix=== +Execute a command and pause for 10 seconds +{{sample|bash -c "ls;sleep 10"}} + + + + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-reference/eiffelstudio-project-settings-window/general-target-options/advanced-options/type-mapping.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-reference/eiffelstudio-project-settings-window/general-target-options/advanced-options/type-mapping.wiki new file mode 100644 index 00000000..7c74f6e5 --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-reference/eiffelstudio-project-settings-window/general-target-options/advanced-options/type-mapping.wiki @@ -0,0 +1,10 @@ +[[Property:title|Type mapping]] +[[Property:weight|10]] +[[Property:uuid|0c504ee9-fa7b-f425-0b80-53344618d995]] +[[Image:mapping-options|Type mappings dialog]] + +Type mappings map one class name to another. E.g. STRING can be mapped to STRING_32. So whenever STRING is used in a class, STRING_32 will be used instead. + + + + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-reference/eiffelstudio-project-settings-window/general-target-options/advanced-options/variables.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-reference/eiffelstudio-project-settings-window/general-target-options/advanced-options/variables.wiki new file mode 100644 index 00000000..8caf7775 --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-reference/eiffelstudio-project-settings-window/general-target-options/advanced-options/variables.wiki @@ -0,0 +1,10 @@ +[[Property:title|Variables]] +[[Property:weight|9]] +[[Property:uuid|af9e24a2-f3c6-17fd-b490-db5c93c8ccec]] +[[Image:variable-options|Variables dialog]] + +Variables specified here can be used in locations of groups and take precedence over environment variables. They can also be used in conditions. + + + + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-reference/eiffelstudio-project-settings-window/general-target-options/advanced-options/warning-options.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-reference/eiffelstudio-project-settings-window/general-target-options/advanced-options/warning-options.wiki new file mode 100644 index 00000000..ea54fbce --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-reference/eiffelstudio-project-settings-window/general-target-options/advanced-options/warning-options.wiki @@ -0,0 +1,21 @@ +[[Property:title|Warning Options]] +[[Property:weight|5]] +[[Property:uuid|0fa4cc8e-a96f-1044-e2d5-2bdf7884d462]] +[[Image:warning-options|Warning dialog]] +* Enabled: globally enabled/disable warnings. +* Old Syntax: warn about the use of old syntax +* Same UUID: different configuration files with the same uuid +* Old Verbatim Strings: warn about usage of old verbatim strings +* Assignment on Formal/Expanded: warn about assignment attempts on formal or expanded targets +* Options Unknown Class: class options for an unknown class +* Onces in Generics: once features in a generic +* Obsolete Features: features that are obsolete +* Missing Class Export: features are exported to a class that does not exist +* Obsolete Classes: classes that are obsolete +* Incompatible Types Equality: incompatible types in equality comparison +* Unused Locals: locals that are not used +* Renaming Unknown Class: renaming was defined for a class that does not exist + + + + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-reference/eiffelstudio-project-settings-window/general-target-options/assertion-options.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-reference/eiffelstudio-project-settings-window/general-target-options/assertion-options.wiki new file mode 100644 index 00000000..8b6ddaba --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-reference/eiffelstudio-project-settings-window/general-target-options/assertion-options.wiki @@ -0,0 +1,16 @@ +[[Property:title|Assertion Options]] +[[Property:weight|2]] +[[Property:uuid|12520e45-beb4-2200-9e60-91736a3ed092]] +'''Assertions''' allows you to configure the assertion checking levels for your project. This means that any assertion type marked '''True''' in the '''Assertions''' table will be checked at runtime. So, in the example screen shown below, only preconditions (denoted in the table by '''Require''') will be checked at runtime. All other assertion types will not be checked at runtime. + +Each assertion setting can be configured independently of the others. + +'''Supplier Precondition''' is a special case. When you develop new software, your software reuses libraries of existing software from other sources, such as the Eiffel Libraries. This library software is often well-established and highly reliable. Setting '''Supplier Precondition''' to '''True''' is a convenient way of setting only precondition checking on libraries, while allowing your own software to be checked to whatever degree you've determined by adjusting the other assertion level settings. + + +[[Image:assertion-options|Condition dialog]] + + + + + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-reference/eiffelstudio-project-settings-window/general-target-options/group-options.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-reference/eiffelstudio-project-settings-window/general-target-options/group-options.wiki new file mode 100644 index 00000000..a7735496 --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-reference/eiffelstudio-project-settings-window/general-target-options/group-options.wiki @@ -0,0 +1,79 @@ +[[Property:title|Group Options]] +[[Property:weight|3]] +[[Property:uuid|a321f24d-3158-d123-f2f6-cf7b38172877]] +This is where you can configure the groups of your project. A group is a container for classes and has some additional options associated. There are five types of groups +* Cluster: represents a directory or directory structure on the disk with class files in it +* Override cluster: similar to cluster but overrides classes in other clusters with the same name, can only appear in an application, never in a library +* Library: a configuration of a library is included, all classes in clusters are accessible +* Precompile: a [[Melting Ice Technology#Precompiling|precompile]] is similar to a library, but the contents of the library or libraries that make up the precompile have already been compiled and therefore the compilation of your project is faster. There can be only one precompile per project. +* Assembly: classes in an assembly (.NET code generation mode only) + +To add a new group, choose the corresponding add group button or context menu entry and enter a name and location or choose from a list (for assemblies and libraries). + +[[Image:group-options|Group dialog]] + +==Common Group Options== +* Name: name of the group +* Description: an optional description of the group +* Read Only: in a read only group, classes cannot be modified +* Location: directory for clusters, assembly file for assemblies and ecf file for libraries and precompiles +* [[Profiling]]: turn on the Eiffel profiler during the application execution (C code generation mode only). The results can be seen at the end of the execution in the profiler window. +* [[Tracing|Trace]]: display on the console all the features that are called during the system execution (C generation mode only). +* .NET Namespace: specify the namespace for this group (.NET code generation mode only) +* Assertions: [[Assertion Options|assertion level]] for this group +* Warning: [[Warning Options|warnings]] for this group +* Debug: [[Debug Options|debugs]] for this group + +===Advanced=== +* Condition: group nodes can be [[General Target Options|conditioned]] to only be used under certain conditions. +* Prefix: name prefix for classes in this group (see [[#Renaming|Renaming]] ) +* Renaming: renamings for classes in this group (see [[#Renaming|Renaming]] ) +* Class Options: options specific for certain classes + +==(Override) Cluster Options== +Clusters can be added as a sub clusters of other clusters, just select the parent cluster before adding the cluster. +* Recursive: should subdirectories automatically be included?. +* Hidden: Is this a hidden cluster that can not be used if the system is used as a library? +* Exclude Rules: [[General Target Options#file_pattern|exclude rules]] for this group +* Dependencies: specify which groups are checked for classes if the class cannot be found in the group itself +* Type Mapping: [[Type mapping|mapping]] of types, e.g. STRING is mapped to STRING_32 +* Visible Classes: visible classes (see [[#Visible classes|Visible classes]] ) + +==Override Cluster Options== +* Overrides: which groups are overridden by this override (default to all). + +==Library/Precompile Options== +If a library is not read only, the configuration can be directly edited by clicking on the edit library button. +* Visible Classes: visible classes (see [[#Visible classes|Visible classes]] ) +* Use Application Options: Should this library use options from the application instead of from the library? + +==Assembly Options== +It is possible (but not recommended) to specify an assembly only with GAC information. To do this set the location to ''none'' and specify: +* Assembly Name: Full name of the assembly as found in the GAC. +* Assembly Culture: Culture of the assembly. +* Assembly Version: Version of the assembly. +* Assembly Public Key Token: Public key token that identifies the asssembly. + +==Resolving Conflicts== + +There are multiple ways to resolve conflicts between different classes with the same name. + +===Renaming=== + +A class can be renamed with a renaming or a group can have a name prefix which will get added to every class. Outside of this group, the class can then be reached by the renamed name. + +===Dependencies=== + +It is possible to specify which other groups will be searched if a class cannot be found in the current group. + +==Visible classes== + +If a feature needs to be reachable from [[CECIL]], but the feature is not called from any Eiffel code, then it must be forced to be ''visible'', otherwise it will be removed by the dead code optimizer. This is done by using the ''Visible Classes'' option. In addition it is also possible, but rarely necessary, to rename a class or a feature. In most cases it suffices to make a class completely visible and renaming is unnecessary. + +[[Image:visible-dialog|Visible dialog]] + +To make a class visible, enter the class name and press ''Add class''. Optionally it is possible to specify a different name under which it is accessible. After a class has been added, it is possible to restrict the access to certain features only. To do this, enter the name of the feature (and optionally a renamed name), select the class it belongs to and click on ''Add feature''. + + + + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-reference/eiffelstudio-project-settings-window/general-target-options/index.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-reference/eiffelstudio-project-settings-window/general-target-options/index.wiki new file mode 100644 index 00000000..20b088b0 --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-reference/eiffelstudio-project-settings-window/general-target-options/index.wiki @@ -0,0 +1,58 @@ +[[Property:title|General Target Options]] +[[Property:weight|1]] +[[Property:uuid|a50e6063-8b23-0813-26d2-06b25f0a882e]] +This is where you can configure most general aspects of your target. + +Here is what you will see when you switch to the target section in the project settings of the calculator example: + +[[Image:target-options|General target properties]] + +You can change the name of the target and give it a description. A target can be marked as abstract if it should not appear in the list of targets when opening a configuration. + +Targets can inherit from each other, which means they take certain settings from a base target if they don't specify it themselves. Inherited values are displayed with a light grey, overridden values with a light red background. Overridden values can be reset to their inherited value, by right clicking on them and choosing ''Use inherited value'' from the context menu. + +An important setting that affects other settings is the compilation type. Here you can specify if you want to generate normal C/byte code (classic application) or if you want to generate .NET code. + +With the output name option you can change the name of the generated executable if you want this to be different than the name of the system. + +If you want to change the root of your system, you will see a dialog like this: + +[[Image:root-dialog|Root dialog]] + +You can specify a root class, root cluster and root feature. Both root cluster and root feature are optional. Instead of specifying a root class it is also possible to choose ''Compile all classes'' which doesn't generate a binary but checks all classes in the target. This can be used for making sure that a library doesn't have any compiler errors. + +The version dialog looks similar to this one: + +[[Image:version-dialog|Version dialog]] + +It allows a version number and some copyright information to be set. On .NET this information will be put into the generated assembly. + + +The Exclude Rules setting allows to define rules to exclude certain files from every cluster. This can be used to exclude CVS or SVN directories globally instead of excluding them on each cluster. The dialog looks like this: + +[[Image:exclude-dialog|Exclude Rules dialog]] + +Exclude rules are regular expressions which are matched against directories and file names. The basic semantics are that everything is included that either does not match an exclude pattern or does match an include pattern. Matching is done against the path relative to the location of the cluster and / is used as a directory separator. + +{{sample| We have a recursive cluster in c:\projects\calculator\cluster and in there we have a file c:\projects\calculator\cluster\interface\ignore_me.e
+Matching would now be first done against ''/interface'' and then against ''/interface/ignore_me.e''
+A rule like ''^/interface$'' would exclude the whole subdirectory, a rule like ''^/interface/ignore_me\.e$'' would only exclude the ignore_me.e class. }} + + +It is also possible to add conditions to a file rule (set of include and exclude file patterns). Adding conditions allows a file rule to be active only under certain conditions. The condition dialog looks like this: + +[[Image:condition-dialog|Condition dialog]] + +Conditioning possibilities are platform (e.g. only Windows or everything but windows), kind of build, .NET generation, dynamic runtime, multithreaded, version of compiler and version of msil clr. It is also possible to specify custom conditions where a [[variables|user defined variable]] has to have a certain value. + +Further options are +* [[Profiling]]: turn on the Eiffel profiler during the application execution (C code generation mode only). The results can be seen at the end of the execution in the profiler window. +* [[Tracing|Trace]]: display on the console all the features that are called during the system execution (C generation mode only). +* .NET Namespace: specify the namespace for this target (.NET code generation mode only) +* Line generation: generate some extra information that will enable a .NET debugger or a C debugger to step through the Eiffel code rather than MSIL code or C code. +* Full Class Checking, Void-safety, Are types attached by default?: These settings are generally associated with increasing the safety of compiled code, particularly [[Creating a new void-safe project#Project settings for void-safe projects|void-safety]]. +* Cat call detection: Attempts to identify at compile time the possibility of the system making a [[ET: Inheritance#Catcalls|catcall]]. +* Syntax: Allows you to select the [[Setting the syntax variant|syntax variant]] used by the compiler when compiling this target. +* Concurrency: Controls the level of concurrency support for this target. ''None'' means mono-threaded; ''EiffelThread'' means concurrent threads using the [[EiffelThread Tutorial|EiffelThread]] library. ''SCOOP'' means concurrency based on the [[Concurrent programming with SCOOP|SCOOP]] rules. + + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-reference/eiffelstudio-project-settings-window/index.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-reference/eiffelstudio-project-settings-window/index.wiki new file mode 100644 index 00000000..4d0854d4 --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-reference/eiffelstudio-project-settings-window/index.wiki @@ -0,0 +1,37 @@ +[[Property:title|EiffelStudio: Project settings window]] +[[Property:link_title|Project Settings]] +[[Property:weight|-10]] +[[Property:uuid|10b907f5-bd50-09e0-af40-68988fe93df1]] +This is where settings regarding your project are going to be made. In here you can specify: +* the different targets your project consists of +* the clusters that contain your classes +* the libraries and/or assemblies that you use +* which assertion level you want to check +* which debug clauses will be activated +* which warnings will be reported +* which C/C++ externals your project needs +* what kind of tasks should be executed before or after a compilation +* various other options such as multithreading + + + +The window is organized in eleven sections: +* [[System Options|System Options]] +* [[General Target Options|Target Options]] +** [[Assertion Options|Assertions]] +** [[Group Options|Groups]] +** [[Advanced Options|Advanced Options]] +*** [[Warning Options|Warnings]] +*** [[Debug Options|Debug]] +*** [[Externals Options|Externals]] +*** [[Tasks Options|Tasks]] +*** [[Variables|Variables]] +*** [[Type mapping|Type Mapping]] + + + +The changes you make are taken into account the next time you recompile your project. Instead of automatically performing the compilation each time you click Ok or Apply we decided to save the modifications and let the user decide when to recompile. + + + + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-reference/eiffelstudio-project-settings-window/system-options.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-reference/eiffelstudio-project-settings-window/system-options.wiki new file mode 100644 index 00000000..1c65b047 --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-reference/eiffelstudio-project-settings-window/system-options.wiki @@ -0,0 +1,22 @@ +[[Property:title|System Options]] +[[Property:weight|0]] +[[Property:uuid|cd9e01c6-dc0e-9ebe-a62a-a7d9d7c2d055]] +This is where you can configure the most general aspects of your system. For example you can set the name of your application and the targets in the system. + +Here is what you will see when opening the project settings window for the first time in a session when using the ecf file of the calculator example located at $ISE_EIFFEL|examples|base|calculator: + +[[Image:system-options|General system properties]] +* Name: specifies the name for the system and is also used as the default for the name of the generated executable. The name of the executable can be changed in the [[General Target Options|target settings]] . +* Description: an optional description of the system +* Library Target: the target that should be used if this system is used as a library +* Library Readonly: Is this system read only per default if it is used as a library? +* File Name: Location of the configuration file. +* UUID: unique identifier for this system + +A system also has one or multiple targets which are the main blocks that specify an application or library. A target can extend another target. For example in the calculator application we have three targets: common, classic and dotnet. The common target specifies the part of the application that is common to classic and .NET compilation. The dotnet and classic targets extend the common target and add their specific settings. + +To add a new target select the system node and click on '''Add Targe'''t. If a target should extend another target, select the parent target and click '''Add Target'''. + + + + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-reference/eiffelstudio-release-notes/Release-notes-for-EiffelStudio-15.12.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-reference/eiffelstudio-release-notes/Release-notes-for-EiffelStudio-15.12.wiki new file mode 100644 index 00000000..f07f9b53 --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-reference/eiffelstudio-release-notes/Release-notes-for-EiffelStudio-15.12.wiki @@ -0,0 +1,39 @@ +[[Property:uuid|05AF3CEC-7026-498F-9177-79D2BA4469A0]] +[[Property:weight|5]] +[[Property:title|Release notes for EiffelStudio 15.12]] +[[Property:link_title|15.12]] +==Graphical environment== + +===What's new=== +* EiffelStudio has been updated to support the new agent's type notation which removes the first actual generic parameter, this change impacts the various wizards and all the Eiffel code included in the EiffelStudio delivery. To help users migrating their code, the syntax_updater command line tool has been updated to allow an easy update of both the Eiffel classes and their corresponding ECFs. +* EiffelStudio is now integrated with the new support site entirely rewritten using EWF and in beta until now. + +===Improvements=== +* When displaying the flat of code involving conversions of manifest constants such as assigning 1 to an INTEGER_8 variable, we will simply show 1 and not `1.to_integer_8` which is not valid Eiffel code. + +===Bug fixes=== +* Fixed display of flat form involving a procedure agent. +* Improved preferences hanlding for the Eiffel Inspector tool. + +==Compiler== +* Click [[Major changes between ISE Eiffel 15.08 and ISE Eiffel 15.12|here]] for the compiler release notes. + +==Libraries== +===General=== +All libraries have been updated to the latest syntax for the agent's type. + +===Base=== +* Exported `read_to_string` from FILE to allow user side buffering. + +===Preferences=== +* Added a precondition to `add_parent_structure_preference_row` and `formatted_name` that a preference name cannot be empty (this might be the case when preference names get erroneously converted from non-ASCII strings, e.g. as it was with incorrect implementation of code analysis preferences). +* Avoided automatic formatting of a preference name if it has whitespace to allow for preference names with underscore characters or those that are pre-formatted. +* Added a creation procedure to pass a preference grid control explicitly in case some fine-tuning is needed. +* Changed type of preference values to READABLE_STRING_32 to avoid conversion when the values are loaded from XML where values are returned as READABLE_STRING_32. + +===XML=== +* Fixed issue with xml source file having the %R character for the custom parser which would be ignored. +* Fixed xml parsing issue with CDATA endings with ]]]. For instance +* Provided a basic implementation to output character data as <[!CDATA[ ... ]]> for xml printer. +[[EiffelStudio release notes|Click here to check out what was new in other versions]] + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-reference/eiffelstudio-release-notes/Release-notes-for-EiffelStudio-16.05.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-reference/eiffelstudio-release-notes/Release-notes-for-EiffelStudio-16.05.wiki new file mode 100644 index 00000000..5a1169f1 --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-reference/eiffelstudio-release-notes/Release-notes-for-EiffelStudio-16.05.wiki @@ -0,0 +1,40 @@ +[[Property:uuid|7AE5F7D4-DA75-4866-A4AE-2A18872032AE]] +[[Property:weight|4]] +[[Property:title|Release notes for EiffelStudio 16.05]] +[[Property:link_title|16.05]] + +==Graphical environment== +===What's new=== +* Ability to target more than one Microsoft C compiler. We now support VS 2015 and above.
A known issue with VS 2015 is that using the console in a graphical application will cause a crash. A separate runtime update will be available shortly. + +===Improvements=== +* Update wizards to allow setting the SCOOP concurrency setting +* Flat short involving conversions on numeric constants will not show the conversion calls. +* Add checks for validity of regular expressions used in include and exclude file rules in ECF specified in EiffelStudio dialog and rejecting invalid regular expression with the corresponding error dialog to avoid a possibility to store ECF that cannot be retrieved. +* The '''Add Library''' dialog was revisited to enhance the search which now looks into name, description, tags, ... . In addition, it is also possible to search for a library including a class name. +* The '''Execution Parameters''' are now saved as xml file. It is also possible to export/import such execution parameters xml file from the ''Execution Parameters'' dialog, using the drop-down menu. + +===Bug fixes=== +* Fix crash in bug report submission dialog when a network problem occurs +* Fix crash when trying to save an empty editor tab (see bug#19178) +* Fix metric tool that stopped working due to a change in the interface of the ROUTINE class in 15.12 (see bug#19212). + +==Compiler== +* Click [[Major changes between ISE Eiffel 15.12 and ISE Eiffel 16.05|here]] for the '''compiler release notes'''. + +==Libraries== +===General=== +* Update to the latest version of the Eiffel Gobo library +* New library ''etar'' located at $ISE_LIBRARY/contrib/library/utility/archive/etar. + +===Vision2=== +* upper_bar and lower_bar are now obsolete. Use instead a vertical box where the first item is the upper_bar and the last item the lower_bar. +* Vision will now keep windows open even if not referenced. This address a long standing gotcha for beginners. As a consequence, it is critical that code close or destroy windows when they are not needed anymore, otherwise they will be displayed until the application termination. +* Fix issue preventing Vision applications to work correctly in SCOOP mode +* For proper SCOOP handling, the last instruction in a creation procedure that initializes GUI objects should be {EV_APPLICATION}.launch. +* Use a passive region for an application cell to avoid creating a new thread for no reason. +* Fix minimum size computation of windows with Aero Glass. When compiling code using the latest versions of Visual Studio, the minimum size of a window was slightly smaller than what it should have been. + +===WEL=== +* Fix invalid computation of null_terminated_strings. +* Fix improper wrapping of WEL_HD_NOTIFY we used an INTEGER_32 when a POINTER should have been used (causing some possible loss of data and some memory access violation). diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-reference/eiffelstudio-release-notes/Release-notes-for-EiffelStudio-17.01.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-reference/eiffelstudio-release-notes/Release-notes-for-EiffelStudio-17.01.wiki new file mode 100644 index 00000000..faed6536 --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-reference/eiffelstudio-release-notes/Release-notes-for-EiffelStudio-17.01.wiki @@ -0,0 +1,37 @@ +[[Property:uuid|925835D5-E5F1-4FE2-BF6A-5F350C4083CC]] +[[Property:title|Release notes for EiffelStudio 17.01]] +[[Property:link_title|17.01]] +[[Property:weight|3]] + +==Graphical environment== +===What's new=== +* Added support for '''code templates''' via completion dialog. Code templates provide predefined but customizable program schemes for frequently encountered situations. Potentially applicable code templates come up automatically, as part of the completion mechanism; you can select any relevant one and then update the details that correspond to the specific situation (variable names etc.). The mechanism also includes an easy way to add your own code templates, to complement those included as part of the delivery (only a few at the moment). Code templates are a major new addition to EiffelStudio’s extensive existing mechanism to support software reuse.[https://www.eiffel.org/doc/eiffelstudio/Code%20Templates learn more]. +* Added new solution to '''import settings''' from previous installation. A dialog is popuped when a new version of EiffelStudio is first launched, and available at any time from the `Tools > Import Settings` menu. This functionality addresses a frequently expressed request. + +===Improvements=== +* Changed how the debugger objects tool displays the `Result` value, now it does not have any parent row. +* Added `ISE_COMPILE_ALL_FLAGS` environment variable support to the `compile_all` tool (its value is added to compile_all command line arguments). +* Modified `compile_all` tool, to exclude ecf redirection file from its scope. + +==Compiler== +* Added notion of '''capability''' for specifying what settings a particular '''library supports'''. The key advantage is that even if you compile in different settings and use libraries with different properties (for void safety, SCOOP concurrency etc.) you can now use a '''single ECF''' (Eiffel Configuration File) rather than maintaining different ECFs for different configurations. This mechanism fulfills a wish often expressed by Eiffel developers, particularly those in charge of large applications. At the moment the settings include cat-call detection, concurrency and void safety. A project or a library with a specific setting cannot rely on a library with insufficient capabilities. +* Configuration option "Are types attached by default?" defaults to True when reading non-void-safe projects so that if the project is changed to be void-safe, the recommended default for attachment status of class types without marks is used. +* Removed a possibility to set void safety level for a specific class or cluster, it can be done only for a whole library or project. + +==Libraries== +===General=== +* Added new JSON serialization solution under `contrib/library/text/parser/json/library/serialization`. + +===EiffelNet=== +* Added receive and send timeout. +* Added C functions to use socket functions without raising exception on I/O networking error. + +===EiffelWeb=== +* Changed the standalone connector implementation to avoid raising exception for any networking error (it brings better debugger experience). +* Added new websocket standalone connector to be able to build within the same processor a web service and a websocket service. +* Change the networking programing in EiffelWeb components, to benefit from recent improvements on EiffelNet. +* Added finer control on standalone connector. It is now possible to fine tune the standalone connector (concurrent settings, timeout values, ...) + +---- + +See [https://dev.eiffel.com/EiffelStudio_17.01_Releases change log]. for more details. \ No newline at end of file diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-reference/eiffelstudio-release-notes/Release-notes-for-EiffelStudio-17.05.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-reference/eiffelstudio-release-notes/Release-notes-for-EiffelStudio-17.05.wiki new file mode 100644 index 00000000..ea659ea8 --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-reference/eiffelstudio-release-notes/Release-notes-for-EiffelStudio-17.05.wiki @@ -0,0 +1,55 @@ +[[Property:uuid|A8615DC3-B389-44AA-9BCB-7E9B793A1599]] +[[Property:weight|2]] +[[Property:title|Release notes for EiffelStudio 17.05]] +[[Property:link_title|17.05]] +==Graphical environment== +===What's new=== +* The EiffelStudio Inspector was extended to check for '''obsolete features''' and '''obsolete calls''' and to make the users aware of coming removal. For that, the inspector checks for presence of well formatted '''date in obsolete message''' (following the ISO-like `[yyyy-mm-dd]` format). Reported '''severity of obsolete calls''' depends on the associated date ({{Inline-Info|suggestion}} when the date is in the future, {{Inline-Warning|warning}} for less than 1 year old, and {{Inline-Error|error}} for more than 1 year old). '''Removal of obsolete features''' is suggested when the specified date is more than 1.5 year old. +* Added a shortcut ({{Key|Ctrl-Shift-T}} by default) and a contextual menu item (on editor tabs) to '''restore a recently closed tab'''. +* Using Pick&Drop functionality, users can now '''pick token for local variables and arguments''' from the EiffelStudio editor and formatters. Drop it into editor, and cursor will be moved to related declaration. Note that for now only normal feature locals and arguments are supported (this excludes inline agent, inline separate, object tests, and across variables). + +===Improvements=== +* Improved the '''completion mechanism''' within the editor (especially when inline agent, or inline separate are before the cursor). + +==Compiler== +* Added '''Visual Studio 2017''' support for C compilation on Windows. +* Improved performance of object initialization checks in complete void safe mode when a class has hundreds of attributes and features (including inherited ones). +* On Windows, you may experience a '''breaking change''' with respect to the compilation of Eiffel libraries wrapping the Win32 API. +** Indeed, to allow users to use in the same system libraries such as cURL, SSL, zeroMQ, ... ; the C generated code is now compiled using `WIN32_LEAN_AND_MEAN`. +** As a result, it is not sufficient anymore to just include `` to use a Windows API, you should look at the MSDN documentation and include the header they say you should be using. +** The unfortunate result of this change is that you have to go through your externals and fix them according to the MSDN documentation. On the other hand, the positive aspect is that the change will be backward compatible with all the versions of EiffelStudio. +*Relaxed typing rules for conditional expressions to allow for different types to be used in different branches as soon as they are pair-wise conforming. Special care is taken about attachment and separateness statuses so that the expression `if foo then "Bar" else Void end` is valid and is of type `detachable STRING`. + +==Libraries== + +===Breaking changes=== +* To have a '''fully void-safe docking library''', some creation procedures were updated and '''now require a docking manager object''' as argument. + +===General=== +*Updated libraries and examples included with EiffelStudio installation to '''avoid obsolete feature calls'''. + +* Added a new creation procedure to `STRING_8` and `IMMUTABLE_STRING_8`: `make_from_c_substring (c_string: POINTER; start_pos, end_pos: INTEGER)` to initialize from a substring between two position of a `c_string`. + +===C_library=== +* Updated `libpng` library to version 1.6.28 +* Updated `zlib` library to version 1.2.11 + +===JSON=== +* Added `is_string`, `is_number`, ... query to `JSON_VALUE`. +* Fixed parsing of Integer 64 values when they are greater than maximum value of Integer 32. + +===EiffelWeb === +* Improved and fixed various issues in the libcurl and EiffelNet '''http_client''': fixed query, and form data encoding; better support for port number in net implementation, follow redirection only for 3** status code, allow forcing the encoding for the form data (`multipart/form-data` or `application/x-www-form-urlencoded`). +* Fixed computation of `path info` in WSF_REQUEST for extreme cases. + +===ROC CMS=== +* The ROC CMS solution (used for eiffel.org) got many '''improvements''': +** better control on '''published''' state, added notion of '''author and editor''' for content. +** User can set a human friendly '''profile name''' (for security, it is better that usernames do not appear in pages). +** Extracted '''administration''' pages from normal website (improved performance, and allow to use specific admin theme). +** Improved '''configuration of content formats''' by selecting various available filters. +** New '''modules''' (sitemap, messaging, wikitext, embedded feed aggregation, google search v2, ... ) + +---- + +See [https://dev.eiffel.com/EiffelStudio_17.05_Releases change log]. for more details. \ No newline at end of file diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-reference/eiffelstudio-release-notes/Release-notes-for-EiffelStudio-18.01.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-reference/eiffelstudio-release-notes/Release-notes-for-EiffelStudio-18.01.wiki new file mode 100644 index 00000000..9d5cd50e --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-reference/eiffelstudio-release-notes/Release-notes-for-EiffelStudio-18.01.wiki @@ -0,0 +1,62 @@ +[[Property:uuid|61F63EE2-58B1-4061-927B-35D4F66EDD9B]] +[[Property:title|Release notes for EiffelStudio 18.01]] +[[Property:link_title|18.01]] +[[Property:weight|1]] +==Graphical environment== +===What's new=== +* EiffelStudio has new menu entries and toolbar buttons to launch code analysis on a class (from active editor), on a previously analyzed item, on a parent cluster of a selected item, on a currently selected target. The results of the analysis go to the error list similar to compilation results. +* Added an experimental command line tool named `eiffel` used to build and launch an Eiffel project directly using the project.ecf file (in a single step). + +===Improvements=== +* EiffelStudio supports filtering of error messages by free text. +* Added auto-completion support for manifest values in parenthesis. +* The background colors in error list can be customize to distinguish between different kinds of messages: error, warning, hint, success. The colors can be set in the preferences. +* Improved style of the documentation generated with a filter for HTML with style-sheets. + +===User changes=== +* compiler: changed an algorithm to compute a type of a conditional expression, now it does not depend on the order of expressions used in the branches, and always exists, i.e. there is no VWCE error anymore (more details are available in the [[Conditional expression|documentation]]). +* compiler: Added a warning reported when a manifest array type is computed using a target type of the reattachment the array is involved in as a source. The warning can be disabled in the project settings during the first year after the release, cannot be disabled afterwards, and becomes an error after 1.5 year after the release. +* EiffelStudio: Disallowed application of automatic fixes to modified classes (changed either by external tools or in the editor). The project needs to be recompiled to apply the fixes. Application of several fixes to the same class is possible in one go. + +==Compiler== +* The compiler supports now typed manifest arrays of the form `{ARRAY [FOO]} << bar, qux>>`, that allows for explicit specification on the array type (see more in the [[Manifest array#Typed_manifest_array|documentation]]). +* Be aware, that now for manifest array without explicit specified type, the compiler no longer depends on the type of the target of a reattachment where the array is used as a source (see more in the [[Manifest array#Untyped_manifest_array|documentation]]). +* The compiler supports now class postconditions and instance-free features. A class postcondition consists of a single keyword `class` (with an optional leading tag). A feature with a class postcondition is known as a class feature and can be used in non-object calls of the form `{MY_CLASS_TYPE}.my_feature`. The restriction is that a class feature cannot access `Current`, a variable attribute, a non-qualified agent or make calls to non-instance-free features. Instance-free features include constant attributes, external and class features. +* Added support for Unicode white space characters in source code as token delimiters. This might be useful when copying code from the Internet where some servers/browsers replace ASCII white space and tab characters with no-break spaces. +* It is possible to modify the preferences of the code analyzer to control when obsolete feature calls are reported by the compiler as warnings that can be suppressed, when as warnings that cannot be suppressed, and when as errors. +* The compiler now provides precise location in error messages for `VPIR(1), VRLE(1), VREG, and VRFA`. + +==Libraries== + +===Breaking changes=== +* EiffelNet: now `set_timeout (0)` is accepted for `NETWORK_SOCKET` and do not set anymore the default timeout (20s). + +===General=== +* EiffelBase: Updated `CHARACTER_PROPERTIES` to use Unicode 10.0.0 instead of 6.2.0. +* The `event` library is now part of the `patterns` library that is now public in EiffelStudio delivery. The library includes other patterns that facilitate decoupling of different subsystems and could be used to build MVC frameworks on top of it. + +===EiffelNet=== +* Adopted `nanosecond` as timeout unit precision in EiffelNet (previous `second` unit precision features are available as obsolete features). To use nanoseconds precision, use the feature ending with "_ns". Note that depending on the platform, and associated C api, the precision may be only microseconds or milliseconds. + +===C_library=== +* Updated cURL C library to version 7_56_1. +* Updated OpenSSL C library to version 1.1.0f. + +===EiffelCurl=== +* It is now possible to compile with EiffelCurl based dynamic module, or static C library (with or without dependencies on .dll/.so). +* Updated cURL library to support static linking of cURL C library. It allows at compile time to choose between using the shared library version (i.e .dll/.so which is the default) or using the static library version (.lib/.a files not provided). + +===OpenSSL=== +* Added a new OpenSSL Eiffel wrapper library, used by EiffelNetSSL (version 1.1.0f). + +===EiffelWeb and related=== +* Introduced the new WSF_COMPRESSION and WSF_*_WITH_COMPRESSION interfaces. +* Added routing condition mapping (in addition to uri, uri-template, starts-with, ...). +* Added a handler to execute CGI scripts (useful mainly when using standalone connector). +* Added support for security protection against XSS injection or other similar threats (see new library wsf_security.ecf). +* Added new JSON Web Token library under `contrib/library/web/authentication/jwt` . +* Added support for embedded resources, reference fields to the HAL library. + +---- + +See [https://dev.eiffel.com/EiffelStudio_18.01_Releases change log] for more details. \ No newline at end of file diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-reference/eiffelstudio-release-notes/Release-notes-for-EiffelStudio-18.07.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-reference/eiffelstudio-release-notes/Release-notes-for-EiffelStudio-18.07.wiki new file mode 100644 index 00000000..8c508997 --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-reference/eiffelstudio-release-notes/Release-notes-for-EiffelStudio-18.07.wiki @@ -0,0 +1,40 @@ +[[Property:modification_date|Wed, 25 Jul 2018 07:17:36 GMT]] +[[Property:publication_date|Wed, 27 Jun 2018 08:33:05 GMT]] +[[Property:uuid|73F20392-AB22-4CD6-BFE5-83296B8BD64B]] +[[Property:title|Release notes for EiffelStudio 18.07]] +[[Property:link_title|18.07]] +[[Property:weight|0]] + +==Graphical environment== +===Improvements === +* Extended sets of constructs checked by some default rules of the code analyzer and made sure the checks do not trigger false positives. +* The execution parameters can be automatically loaded from the default file saved from a previous execution session (this way, an Eiffel project can have default execution parameters). +* The debugger string viewer now displays information about the current cursor (character, position, ...). In addition, a new "JSON" string debugger viewer is available. + +===User changes=== +* Made completion more consistent: the selection list is shown even when there is just one item. +* Used single-click for completion dialog. And show tool-tip when the pointer is over the entry. +* New icons for '''class''' features (implying minor changes on existing features icons). +* The auto-completion is not triggered anymore for `|.` or `..` cases. + +==Compiler== +* It is now possible to extend a project target from a different project (ECF). +* The rules for '''class''' features were relaxed. Re-declaration into or joining with a class feature is valid as soon as combined assertions satisfy the class feature conditions. A non-static external and constant feature automatically gets a class post-condition if its contracts do not involve constructs that can access Current object . +* Updated the Eiffel grammar to support bracket expressions as bracket targets (such as `table[x][y][z]`) +* Supported detection of '''VHPR(5)''' violations for arbitrary ancestors, not just for immediate parents. This may be a breaking change for classes that inherit different generic derivations of the same class. +* Added detection of a type mismatch between a manifest array and a target of the reattachment where the manifest array is used for projects created before 18.01 release to facilitate migration to the new typing rules for manifest arrays. A per-library option and a project-wide setting are available to control the checks. + +==Libraries== +* EiffelBase: +** Added `{EXECUTION_ENVIRONMENT}.available_cpu_count`. +** Relaxed a precondition of `{ARRAY}.subarray` to allow for calling it on empty arrays. +**Marked many features of Base library as class ones to make them usable for non-object calls. +**Added a feature `{ARRAY}.force_and_fill` that works like `{ARRAY}.force`, but fills previously unoccupied positions with the specified value rather than with a default one. +* EiffelProcess: Marked features of `BASE_PROCESS_FACTORY`, `PROCESS_FACTORY`, and `PROCESS_INFO` as class ones to make them usable for non-object calls. +* EiffelWeb: it is now possible to redefine the default http response when an exception occurs. + + + +---- + +See [https://dev.eiffel.com/EiffelStudio_18.07_Releases change log] for more details. \ No newline at end of file diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-reference/eiffelstudio-release-notes/Release-notes-for-EiffelStudio-18.11.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-reference/eiffelstudio-release-notes/Release-notes-for-EiffelStudio-18.11.wiki new file mode 100644 index 00000000..696299e4 --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-reference/eiffelstudio-release-notes/Release-notes-for-EiffelStudio-18.11.wiki @@ -0,0 +1,46 @@ +[[Property:modification_date|Fri, 07 Dec 2018 13:53:20 GMT]] +[[Property:publication_date|Mon, 26 Nov 2018 10:45:37 GMT]] +[[Property:uuid|4452B417-C538-49AF-960F-C3C2473A3AF8]] +[[Property:title|Release notes for EiffelStudio 18.11]] +[[Property:link_title|18.11]] +[[Property:weight|-1]] + +==Graphical environment== +* The debugger marks a class routine with a special icon in the call stack and prevents using non-class features in the watch tool inside a class routine. +* The completion popup dialog shows the associated target class (if any) at the top of the dialog. +* The class tool displays description of classes (if enabled). +* The diagram tool has improved drawing of figures and connectors. +* After refactoring, the editor restores current position as expected. +* A project can be recompiled from scratch from the ''Project'' menu. +* Editor tabs can be exported and imported via the hidden experimental menu ''Service > Import/Export tabs...'' ({{Key|Ctrl+Alt+D}}). + +==Compiler== +* Assertion expressions are used as tags for assertions without explicit tags. +* Concurrency and void-safety project settings can be overridden when compiling from the command line. +* Project settings can use conditions based on void safety level. +* Checks for void safety of object initialization take into account an assigner command. +* Exception traces in final and workbench mode use the same breakpoint indexes. +* Several code-generation and run-time bugs are fixed. + +==Libraries== +* All container classes are now `ITERABLE` that allows for iterating over them with the `across` loop and simplifies conversions between different types of containers. {{Inline-Warning|Potential incompatibility}} for descendant classes that did not implement`new_cursor`. +* `duplicate`, `duplicate_all` and related features of container classes are now obsolete to simplify inheritance from these classes in the future. The affected effective classes now have the feature `make_from_iterable`. +* Figures in Vision can be drawn with anti-aliasing (on Windows). +* `HASH_TABLE` now takes arguments of type `G` instead of `detachable G` and introduces a feature `definite_item` of type `G` (in addition to the existing feature `item` of type `detachable G`). +* OpenSSL binding uses OpenSSL 1.1.1a and supports new asymmetric algorithms (RSA). +* JWT (JSON Web Token) supports custom JWT algorithms. The associated extension library provides RSA signing algorithms. +* Performance of the JSON parser is improved by 40% on large regular files. +* The new function `JSON_VALUE.chained_item (a_key): JSON_VALUE` allows for expressions `json @ "person" @ "address" @ "city" ` to get associated JSON value. +* ''ROC CMS'' implements protection against cross-site scripting attacks. +* ''EiffelWeb'' adopts nanoseconds timeout precision and supports suffixes ns, us, ms, s for the standalone connector in the initialization file. +* ''EiffelWeb'' correctly uses the setting socket.timeout for ''httpd'' (before the misuse of the setting caused high CPU usage for WebSocket). +* Creation procedures of some container classes are now secret. {{Inline-Warning|Potential incompatibility}} for clients of the classes. + +==Tools== +* Code analyzer does not report false positives for the rules about an unread variable (CA020) and replacement of a regular loop with an iterative form (CA024). + +==Examples== +* `processor_pool` demonstrates how a pool of active SCOOP processors can be used to execute tasks from passive regions. +---- + +See [https://dev.eiffel.com/EiffelStudio_18.11_Releases change log] for more details. \ No newline at end of file diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-reference/eiffelstudio-release-notes/eiffelstudio-5-release-notes/index.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-reference/eiffelstudio-release-notes/eiffelstudio-5-release-notes/index.wiki new file mode 100644 index 00000000..23e43d20 --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-reference/eiffelstudio-release-notes/eiffelstudio-5-release-notes/index.wiki @@ -0,0 +1,6 @@ +[[Property:title|EiffelStudio 5 release notes]] +[[Property:link_title|5.x]] +[[Property:weight|15]] +[[Property:uuid|f4a705a2-86ac-013e-21f2-a99affd7b450]] + + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-reference/eiffelstudio-release-notes/eiffelstudio-5-release-notes/release-notes-eiffelstudio-50.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-reference/eiffelstudio-release-notes/eiffelstudio-5-release-notes/release-notes-eiffelstudio-50.wiki new file mode 100644 index 00000000..09cb5680 --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-reference/eiffelstudio-release-notes/eiffelstudio-5-release-notes/release-notes-eiffelstudio-50.wiki @@ -0,0 +1,63 @@ +[[Property:title|Release notes for EiffelStudio 5.0]] +[[Property:link_title|5.0]] +[[Property:weight|-8]] +[[Property:uuid|943526cc-28e6-748d-a790-502c05c723f6]] +==Graphical environment== +* New Look and feel. +* New way of starting EiffelStudio and simplified the process of compiling an existing project. +* New editor with: +** smart syntax highlighting +** feature completion (by pressing Ctrl+Space after an identifier). +** syntax completion of major control statement (if, from, is,...)and of symbols such as `{`, `[`, `(`, `"`,... +** smart auto indenting +** block indent and exdent. +** infinite level of Undo/Redo + +* When edition of a class text which has been successfully compiled, the class will be fully `pick-and-droppable`. +* Faster rendering for Clickable, Flat, Contract (previously known as Short) and Flat Contract views. +* System tool has been replaced by a `project settings` window. The underlying mechanism of the configuration file is kept, but all changes are done through a nice GUI making it simpler for beginners to create their first configuration file. +* Toolbars are now customizable +* EiffelCase has been merged within EiffelStudio to provide a true reverse engineering using the BON notation. + +==Compiler== +The compiler has been improved in many ways and some functionality have been added. [[Major changes between ISE Eiffel 4.5 and ISE Eiffel 5.0|Check it out]] . +==Debugger== +* New debugger functionalities: +** one can step-in, step-out, step-by-step when they want to. +** one can put a breakpoint on the fly (Windows Only) +** one can see all local variables and arguments. +** one can set breakpoints in all kind of assertion clauses except in invariants. + +* Debugging is faster. + +==Documentation== +* New documentation generation (limited now to HTML) which is completely clickable as if within EiffelStudio. It also includes an EiffelCase-like documentation generation. +* Generation of XMI which can be used in tools such as Rational Rose. + +==Libraries== + +===EiffelBase:=== +* No more GENERAL class as proposed by the NICE committee. It has been replaced by ANY which does not inherit any more from PLATFORM. +* Adaptation of the ARRAY class to the ELKS 2000 standard. +* This implies a change in our CONTAINER class where we renamed empty into is_empty and made empty obsolete. If you were inheriting from CONTAINER and redefining empty, make sure to update your code so that you redefine is_empty instead. That way your polymorphic calls will still work as expected without having to change all call to empty into calls to is_empty. +* New implementation of is_equal on LIST which will now check that two lists are identical if their items are identical. +* New implementation of copy on LIST. +* New implementation of an iterative is_equal on TREE which will now check that two trees are identical if their items are identical. +* New implementation of an iterative copy on TREE, which recursively copies the tree. +* New ROUTINE classes which perform better type checking on argument passing. +* Introduction of binary operations on INTEGER types: infix "&",infix "|", bit_xor, bit_not, bit_shift, infix "|>>", infix "|<<"and bit_text. +* Removed infix "^" from NUMERIC. It does not break any inheritance, but break clients that were using this operator on an entity declared of type NUMERIC. This is due to the different return type of this operator depending the NUMERIC type you are handling. +* Changed the signature of pruned in BINARY_SEARCH_TREE to take an extra argument. This was necessary to fix a problem that caused the `parent` attributes to become inconsistent under certain conditions when calling pruned. +* Re-implemented the features disjoint and symdif of SUBSET. These features caused problems under certain conditions and were also quite inefficient. The new implementation of these features uses the strategy pattern to choose among different versions of these calculations depending on the properties of the elements contained in the set. +* All features on SUBSET that take another subset as an argument(e.g. intersect) now accept any other subset type as an argument, independent of its underlying implementation, and not only subsets of type `like Current`. +* Many smaller bug fixes for bugs that were reported by our customers or that have been discovered during our development andtesting. + +===WEL:=== + +Modified classes relative to the use of registry keys to be written only using Eiffel and externals to Win32 API (no more C intermediates). In the process close_key and delete_key are now commands and not queries. To find out if it their call was successful, you can query last_call_successful. + +[[EiffelStudio release notes|Click here to check out what was new in other versions]] + + + + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-reference/eiffelstudio-release-notes/eiffelstudio-5-release-notes/release-notes-eiffelstudio-51.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-reference/eiffelstudio-release-notes/eiffelstudio-5-release-notes/release-notes-eiffelstudio-51.wiki new file mode 100644 index 00000000..e2bec516 --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-reference/eiffelstudio-release-notes/eiffelstudio-5-release-notes/release-notes-eiffelstudio-51.wiki @@ -0,0 +1,36 @@ +[[Property:title|Release notes for EiffelStudio 5.1]] +[[Property:link_title|5.1]] +[[Property:weight|-9]] +[[Property:uuid|cab7da39-416f-3330-0f67-b41cb425b537]] +==Graphical environment== +* Numerous improvements in usability and bug fixes. +* Richer class and cluster creation dialogs. +* Class name completion in the editor (by pressing Ctrl+Shift+Space half-way through the class name). +* Editor now supports drag-and-drop of the selection. +* When debugging a project from EiffelStudio, the current directory will be your project directory. It is a change from previous version where: +** on Windows, it used to be launched in the W_code subdirectory of your project directory +** on Unix, it used to be launched from the same directory where `estudio` (or `ebench`) was launched. + +* EiffelStudio GUI now also available on Unix platforms and Windows 9x/Me + +==Compiler and .NET== +* Click [[Major changes between ISE Eiffel 5.0 and ISE Eiffel 5.1|here]] for more details on compiler improvements and full Eiffel support on .NET + +==Libraries== + +===EiffelBase=== +* It is now forbidden to create a BIT_REF or a BIT X object using its creation procedure (before it was accepted but did not work) +* Added make_temporary_name in FILE_NAME +* Made to_c obsolete from class INTEGER_INTERVAL +* Changed semantic of split from class STRING +* Fixed a bug in clear_all from HASH_TABLE that kept a reference to the last found item. Now it does not keep the reference after a call to clear_all . + +===Vision2=== +* Support for Vision2 applications on GTK platforms. +* Some changes in the Vision2 library have been made, [[Revisions and Bug Fixes|check here on how to update your code]] . + +[[EiffelStudio release notes|Click here to check out what was new in other versions]] + + + + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-reference/eiffelstudio-release-notes/eiffelstudio-5-release-notes/release-notes-eiffelstudio-52.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-reference/eiffelstudio-release-notes/eiffelstudio-5-release-notes/release-notes-eiffelstudio-52.wiki new file mode 100644 index 00000000..1a4d8571 --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-reference/eiffelstudio-release-notes/eiffelstudio-5-release-notes/release-notes-eiffelstudio-52.wiki @@ -0,0 +1,110 @@ +[[Property:title|Release notes for EiffelStudio 5.2]] +[[Property:link_title|5.2]] +[[Property:weight|-10]] +[[Property:uuid|4e54c64b-d9a3-8683-d266-1972217a7a1a]] +==Graphical environment== +* Added a status bar, which gives a lot of information, such as the state of the compilation or the name of the current project. +* Clicking feature clauses in the feature tree now centers the editor on the selected feature clause. +* More specific icons in the feature and cluster trees, so that identifying deferred classes and the nature of features is now straightforward. +* Up to 10 [[External commands editor dialog|external commands]] can now be defined and called from the '''Tools''' menu. +* The new '''Quick compile''' command lets you recompile only the classes that have been edited in EiffelStudio, skipping the sometimes tedious degree 6, that looks for modified classes. +* Control picking now has a configurable effect. +* More improvements in usability and bug fixes. + +==Compiler== +* Click [[Major changes between ISE Eiffel 5.1 and ISE Eiffel 5.2|here]] for more details on compiler improvements and full Eiffel support on .NET + +==Debugger== +* Right-clicking on one of the run buttons will pop up a dialog enabling you to choose the command line argument (it is a shortcut for `Project Settings`-> Debug tab). +* Expressions can now be dynamically evaluated in the debugger. ( [[Expression evaluation|info]] ) +* Conditional breakpoints. ( [[Breakpoints|info]] ) +* Classes can now define debug_output , a feature inherited from DEBUG_OUTPUT , whose string result is automatically displayed in the debugger for all objects of that type. ( [[Debug output|info]] ) +* Possible stack overflows can now be detected in the debugger before they occur. ( [[Stack overflow prevention|info]] ) + +==Libraries== + +===EiffelBase=== +* Improved speed of search operations in ARRAYED_LIST and HASH_TABLE . +* Reduced number of exported features in TUPLE . +* Updated INTERNAL and TUPLE to accept INTEGER_XX based queries/commands. +* STRING changes: +** Fixed is_integer to return False for strings of the form "(-|+)[a-zA-Z]+[0-9]*)" +** Improved speed of to_lower and to_upper . +** Updated for ELKS 2001 conformance: +*** Changed signature of out and replace_substring to use STRING instead of `like Current`. +*** Added keep_tail , keep_head , remove_tail , remove_head and make head and tail obsolete. +*** Added string , same_string , has_substring , fill_with , insert_string , insert_character , as_lower , as_upper . +*** Modified make_from_string so that no sharing of internal string is done. +*** Made remake , replace_character and insert obsolete. + + + +===EiffelThread=== +* Fixed crashes when using join or terminated from THREAD_CONTROL . + +===EiffelTime=== +* Rewritten so that no additional C libraries is needed. Therefore you have to update your project configuration files to reflect this change, i.e. removing the include directory and the object file of the old EiffelTime library. + +===EiffelVision2=== +* [[Revisions and Bug Fixes|Click here to see list of update and modification to Eiffel Vision2]] . + +===WEL=== +* Changed type of non-exported feature internal_data of WEL_WINDOW from INTEGER to POINTER . +* Fixed a GDI memory leak when creating/releasing instances of descendant of WEL_CONTROL . + +==Patch releases== + +===Version 5.2.1402:=== +* Put Windows and Unix version to the same version number. +* Fixed EiffelWeb documentation and example. +* Fixed minor issues found with EiffelVision2 on Unix and Windows which were affecting EiffelBuild. +* Fixed incorrect configuration file specification for EiffelVision2 examples and wizards on Unix platforms where application could be linked dynamically with `libpng` but should not. +* Fixed EiffelStore handle for Oracle so that it works fine when compiled with the Borland C compiler. +* Fixed incorrect version number in VERSION file on Unix platforms. + +===Version 5.2.1313:=== +* Fixed resource leak on Windows 98 and Windows Me. +* Fixed incorrect implementation of area and substring for STRING in dotnet mode. +* Fixed issue with setting of arguments. After restarting EiffelStudio the command line argument contains an extra `]` character. +* Fixed issue with working directories where only the first one ever set was used even if new ones have been set afterwards. +* Fixed issue in IL code generation where having a class that inherits from a non-Eiffel .NET class. And the class has the following features:
+ +a: ARRAY [like f] +f: STRING is + do + end + +Then you could neither load nor execute the generated code. + +* Fixed issue with incorrect C code generation of inspect instruction based on character values above 128. +* Fixed bug in copy from STRING where following code was violating valid_count invariant from STRING : + +local + s, t: STRING +do + create s.make (9) + create t.make (10) + t.append ("1234567890") + s.copy (t) +end + +* Fixed incorrect C file naming when generating a .NET system that uses a C++ external (it should be .cpp, not just .c). +* Enabled support for Borland C compiler in .NET. +* Fixed issue where generating documentation for all/library cluster would stop during generation without completing. +* Fixed crash in diagram tool when moving label on client/supplier link between two classes. + +===Version 5.2.1123:=== +* Fixed issue when inheriting a .NET class that has some static constants defined. + +===Version 5.2.1122:=== +* Fixed issue when opening the about dialog of EiffelStudio. +* Enabled EiffelStudio for all users on a machine, not just for the one installing EiffelStudio. + +===Version 5.2.1118:=== +* First initial release of EiffelStudio 5.2 + +[[EiffelStudio release notes|Click here to check out what was new in other versions]] + + + + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-reference/eiffelstudio-release-notes/eiffelstudio-5-release-notes/release-notes-eiffelstudio-53.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-reference/eiffelstudio-release-notes/eiffelstudio-5-release-notes/release-notes-eiffelstudio-53.wiki new file mode 100644 index 00000000..78f08512 --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-reference/eiffelstudio-release-notes/eiffelstudio-5-release-notes/release-notes-eiffelstudio-53.wiki @@ -0,0 +1,98 @@ +[[Property:title|Release notes for EiffelStudio 5.3]] +[[Property:link_title|5.3]] +[[Property:weight|-11]] +[[Property:uuid|dd116cc7-40cf-b317-b9c0-b05d4fe0edf7]] +==Graphical environment== + +===Changes=== +* In project settings, we now accept a root class without creation procedure. +* In .NET code generation, we do not force the C compilation at each compilation. It is only done when necessary (for example when a C external has been added). +* Incremental .NET code generation (See [[Major changes between ISE Eiffel 5.2 and ISE Eiffel 5.3|compiler release notes]] for more info). +* Recoverable storable (See [[Major changes between ISE Eiffel 5.2 and ISE Eiffel 5.3|compiler release notes]] for more info). + +===Bug fixes=== +* Fixed issue with setting of arguments. After restarting EiffelStudio the command line argument contains an extra `]` character. +* Fixed issue with working directories where only the first one ever set was used even if new ones have been set afterwards. +* Fixed issue where generating documentation for all/library cluster would stop during generation without completing. +* Fixed crash in diagram tool when moving label on client/supplier link between two classes. +* Fixed resource leak on Windows 98 and Windows Me. +* Fixed issue in projects where clusters are specified with relative path would not compile after adding a local assembly. +* Fixed problem with cluster tool management where moving classes around or looking up a class will generate an error box instead of performing the requested operation. +* Fixed incorrect configuration file specification for EiffelVision2 examples and wizards on Unix platforms where application could be linked dynamically with `libpng` but should not. +* Fixed disappearance of EiffelStudio when debugging a routine `infix` or `prefix` in which an exception was raised. This issue was only occurring with melted code (usually noticeable when using a precompiled library). +* Changing the project specific command line arguments will not touch the project settings configuration file (ace file). + +==Compiler== +* Click [[Major changes between ISE Eiffel 5.2 and ISE Eiffel 5.3|here]] for the compiler release notes. + +==Libraries== + +===CECIL=== +* Enforced definition of EIF_OBJECT so that it is different from EIF_REFERENCE to better catch errors when passing a protected reference to a feature accepting an unprotected reference and vice versa. Because of this change some C code might not compile anymore which is good as it points out that code was doing something wrong that could corrupt the Eiffel memory. + +===EiffelBase=== +* Added in INTERNAL the following new features: field_static_type_of_type , class_name_of_type , type_name and type_name_of_type . +* Added truncated_to_integer_64 in REAL and DOUBLE . +* Added to_integer_64 in STRING . +* Added new classes MEMORY_STRUCTURE , MANAGED_POINTER and C_STRING to better manage access to C and C++ memory structure. +* Fixed incorrect implementation of area and substring for STRING in dotnet mode. +* Fixed bug in copy from STRING where following code was violating valid_count invariant from STRING : + +local + s, t: STRING +do + create s.make (9) + create t.make (10) + t.append ("1234567890") + s.copy (t) +end + +* Added support for storable in .NET. However .NET and classic implementation are completely different and independent_store will not be able to retrieve a storable file if not made using the same code generation. +* Fixed a bug in is_equal from LIST where comparing two lists of different counts could break the comparison:
+ +make is + local + a, b: LIST [INTEGER] + do + create {ARRAYED_LIST [INTEGER]} a.make (2) + a.extend (10) + + create {ARRAYED_LIST [INTEGER]} b.make (2) + b.extend (10) + b.extend (11) + + print (equal (b, a)) + end + +* Fixed .NET implementation of open_write and create_read_write in FILE . They were not resetting the file size to zero if file already existed. +* Added correct_mismatch on ANY used for `recoverable storable`. +* Added correct_mismatch on HASH_TABLE to enable retrieval of the 5.1 and older version of HASH_TABLE. +* Fixed bug in implementation of copy and is_equal for TREE and descendant classes. Now descendants of TREE that would like to compare additional attributes of their class needs to redefine node_is_equal whose default implementation will always result in a true value. +* Changed default semantic of make and put_child from FIXED_TREE, to preserve existing semantic, you should use make_filled and replace_child instead. + +===Eiffel2Java=== +* Updated library so that it works both in classic and dotnet mode. + +===EiffelCOM=== +* Fixed crash in ccom_set_name from FONT_IMPL_PROXY. + +===EiffelNet=== +* Fixed assertion violation of call to to_integer in feature get_content_length from HTTP_PROTOCOL if assertions are enabled on EiffelBase. + +===EiffelStore=== +* Updated library so that it works both in classic and dotnet mode. +* Fixed issue with oracle handle which did not work with the included Borland C compiler. +* Removed nb_classes from EXT_INTERNAL . +* Removed need for additional object file (`support.lib' on Windows and `libsupport.a` on Unix platforms), so make sure to remove it from your project configurations. + +===EiffelVision2=== +* [[Revisions and Bug Fixes|Click here to see list of update and modification to Eiffel Vision2]] . + +===WEL=== +* Removed inheritance to WEL_STRUCTURE in WEL_STRING, it now inherits from new C_STRING class. In the process removed the following features which were inherited from WEL_STRUCTURE and did not make sense to WEL_STRING memory_copy, structure_size, dispose, set_item, set_shared, set_unshared, shared, to_integer. No replacements have been provided for those features. Made initialize and initialize_with_character obsolete, instead we now provide two features inherited from C_STRING fill_blank and fill_value. + +[[EiffelStudio release notes|Click here to check out what was new in other versions]] + + + + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-reference/eiffelstudio-release-notes/eiffelstudio-5-release-notes/release-notes-eiffelstudio-54.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-reference/eiffelstudio-release-notes/eiffelstudio-5-release-notes/release-notes-eiffelstudio-54.wiki new file mode 100644 index 00000000..3a193447 --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-reference/eiffelstudio-release-notes/eiffelstudio-5-release-notes/release-notes-eiffelstudio-54.wiki @@ -0,0 +1,96 @@ +[[Property:title|Release notes for EiffelStudio 5.4]] +[[Property:link_title|5.4]] +[[Property:weight|-12]] +[[Property:uuid|185d86b7-8ddc-20ad-6343-eeb86f413739]] +==Graphical environment== + +===Improvements=== +* Added support for mouse wheel in editor and associated parameterization in preferences. +* Cluster tree is not collapsed anymore between compilation. +* All callers will not show empty entries. + +===Bug fixes=== +* Fixed issue where setting the string background color to `auto` in the preferences will set it to a black color next time your relaunch EiffelStudio. +* Fixed issue where typing in an empty features tree will close down EiffelStudio. +* Fixed issue with BON diagram where expanded client links were not properly displayed (the expanded bar was drawn on top of classes instead of on the link itself). + +==Debugger== + +===Improvements=== +* Ability to debug .NET applications from EiffelStudio. It behaves like the traditional debugger except with the current limitations: +** no conditional breakpoints +** no expression evaluation +** no expansion to see attributes of non-Eiffel objects + + +===Bug fixes=== +* Fixed issue on Unix platforms where passing more than 5 arguments will disable debugging and ultimately crash the environment. + +==EiffelBuild== +* Click [[EiffelBuild Version History|here]] for the EiffelBuild release notes. + +==Compiler== +* Click [[Major changes between ISE Eiffel 5.3 and ISE Eiffel 5.4|here]] for the compiler release notes. + +==Libraries== + +===Eiffel2Java=== +* Fixed incorrect memory freeing in get_string in JNI_ENVIRONMENT that could cause some memory corruption. +* Fixed VDRD error in method_id from JAVA_OBJECT. + +===EiffelBase=== +* Optimized i_th from PRIMES for the first 200 prime numbers. +* Fixed bug in generic_typecode from TUPLE in .NET implementation which fixed an issue with is_reference_item. +* Made TUPLE a descendant of HASHABLE and defined hash_code (based on the hash_codes of the elements of a TUPLE). +* Added default_create as creation procedure of TUPLE and made make obsolete. +* Added convenience features to TUPLE: put_XX_item where `XX` can be replaced by `character, boolean, integer, double,...`. +* Optimized ROUTINE, PROCEDURE and FUNCTION implementation to speed up agent calls by a factor of 2 to 3. Removed open_operand_type from ROUTINE as its specification was only used internally and specification was not precise enough to be used by clients of ROUTINE. +* Fixed append from SEQUENCE to not perform a deep_clone when passed argument is the same reference as Current. This was a problem when the base class of the type of the elements inherited from MEMORY and redefined dispose. You could possibly end up freeing twice an external resource. +* Changed implementation of INTERACTIVE_LIST to be based on ARRAYED_LIST rather than on LINKED_LIST. +* Added efficient implementation of append in ARRAYED_LIST. +* Fixed bug in multithreaded mode when you open in two different threads a different file with a different mode. For example one is in read mode, the other one is in write mode. If the operation happens at the same time, you could end up with two files open in read mode or two files open in write mode, which is not the expected behavior. + +===EiffelNet=== +* Fixed bug in set_delay and set_nodelay in NETWORK_STREAM_SOCKET, because their implementations were inverted. +* Fixed incorrect spelling of maximum_seg_size in NETWORK_STREAM_SOCKET. +* Added recoverable storable to EiffelNet (was not included in previous version although recoverable storable was available for files). +* Fixed SMTP_PROTOCOL to follow more closely SMTP RFCs. +* Added support for multi-line error codes in SMTP_PROTOCOL. + +===EiffelTime=== +* Improved speed of DATE and TIME comparison. +* In DATE_VALUE added ordered_compact_date and made compact_date obsolete. +* In DATE added make_by_ordered_compact_date and make_by_compact_date obsolete. +* In DATE_VALIDITY_CHECKER added ordered_compact_date_valid. +* Fixed C_DATE to buffer the current time rather than querying it for each of the time components. Not doing that was causing a bug in DATE, DATE_TIME and TIME where if the computation was done on December 31st at 23:59:59 2003, we could end up with a date of January 1st 2003, therefore being one year off. This is a breaking change from before and if you are using C_DATE, use update before each call to the *_now queries if you expected to reflect the time at the time of the query. + +===EiffelThread=== +* Added support for .NET +* Made OBJECT_OWNER obsolete +* Added wait_with_timeout in CONDITION_VARIABLE +* Added READ_WRITE_LOCK class to be used in a system where few writes are done compare to reads. A typical example of its use would be to have a thread safe lookup table where few insertions are done. +* Now a C externals that might block the execution of a system, should be marked `blocking`. [[Major changes between ISE Eiffel 5.3 and ISE Eiffel 5.4|See compiler changes for more details]] . + +===EiffelVision2=== +* [[Revisions and Bug Fixes|Click here to see list of update and modification to EiffelVision2]] . + +===EiffelWeb=== +* Fixed issue when sending exception trace to browser. On most servers you were getting an internal error rather than the exception trace. +* Fixed issue with cookies from CGI_ENVIRONMENT as keys were stored as items, now the keys are stored as keys, items as items. + +===WEL=== +* Renamed convert from CONVERTER class into extract_definition. +* Renamed convert from WEL_FONT_FAMILY_ENUMERATOR class into update_current. +* In WEL_TREE_VIEW, calling deselect_item will now really deselect the item, whereas previously, it only caused the item to be redrawn without selection. +* In WEL_REGISTRY, open_value_key will now accept an empty string so that the default key value can be read. +* Fixed issue with dword_value in WEL_REGISTRY_KEY_VALUE which returned incorrect values. +* Made make in WEL_REGISTRY_KEY_VALUE accepts only string values, if you want to create a new instance with a value of a different type you need to use the new creation procedure make_with_value. + +===.NET libraries=== +* Renamed THREAD and MUTEX into SYSTEM_THREAD and SYSTEM_MUTEX to avoid name conflicts with EiffelThread. + +[[EiffelStudio release notes|Click here to check out what was new in other versions]] + + + + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-reference/eiffelstudio-release-notes/eiffelstudio-5-release-notes/release-notes-eiffelstudio-55.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-reference/eiffelstudio-release-notes/eiffelstudio-5-release-notes/release-notes-eiffelstudio-55.wiki new file mode 100644 index 00000000..14594c47 --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-reference/eiffelstudio-release-notes/eiffelstudio-5-release-notes/release-notes-eiffelstudio-55.wiki @@ -0,0 +1,83 @@ +[[Property:title|Release notes for EiffelStudio 5.5]] +[[Property:link_title|5.5]] +[[Property:weight|-13]] +[[Property:uuid|0d5bdd1d-e35b-a37e-009f-f19fae0771db]] +==Graphical environment== + +===Improvements=== +* Added full configuration of colors used in editor +* Added docking facilities for various tools. It permits the re-ordering of tools within the interface, including making them "float" externally [[Docking|(See EiffelBuild documentation on docking mechanism for more details)]] . +* Ability to see when a class is deferred in the context tool formatters. It is shown by adding the `*' character at the end of the class name. + +===Changes=== +* One cannot add a .NET assembly from the GAC anymore, instead you have to specify the path to the assembly in the assembly references list. + +===Bug fixes=== +* Fixed a crash when performing feature completion on classes with errors. +* On Windows, prevented the EiffelStudio window to go to the back of all windows when you click Ok on the dialog box which appears when a syntax error occurs while compiling a project. + +==Debugger== +* Enabled conditional breakpoint and expression evaluation for .NET +* Improved expression evaluation abilities (full range of Eiffel expressions are now supported). +* Improved object viewer window (word wrapping for large text, ability to see the whole content in one click without having to enter the lower and upper index of a range). + +==EiffelBuild== +* Click [[EiffelBuild Version History|here]] for the EiffelBuild release notes. + +==Compiler== +* Click [[Major changes between ISE Eiffel 5.4 and ISE Eiffel 5.5|here]] for the compiler release notes. + +==Libraries== + +===CECIL=== +* Added ability to query type of a generic class where an actual generic parameter is expanded although its base class is not. It suffices to prefix the class name with "expanded ". Reciprocally, you can use the reference version of an expanded class by prefixing with "reference ". + +===EiffelBase=== +* Removed consistent and setup from ANY +* Removed Void from ANY as Void is now a keyword. +* Added for_all, do_all, do_if and there_exists to ARRAY. As a consequence descendants of ARRAY which also inherit from LINEAR have to select the proper version of those routines as they also appear in LINEAR. +* Fixed dynamic_type_from_string from INTERNAL under .NET which was not working if you were using the .NET naming convention or if you specified a namespace. +* Added generic_count, generic_count_with_type in INTERNAL to find out how many generic parameter a type has. +* Added generic_dynamic_type_with_type in INTERNAL to find out the type of the i-th generic parameter of a given type. +* Added memory_map and memory_count_map to give you a precise accounting of all living objects in the running system. It will help you find out any potential memory leak because objects are still referenced where they should not. +* Improved performance of FILE objects creation by not allocating the last_string internal buffer until it is needed. +* On Windows, removed side effects of put from EXECUTION_ENVIRONMENT. Before it was setting also some registry keys, now it only set the environment variable for the running process and its children when launched. +* Allowed zero sized MANAGED_POINTER. Allowed MANAGED_POINTER to share a pointer rather than doing a full memory copy at creation time. +* Fixed issue with agents where GC did not collect passed arguments to call or item from ROUTINE/FUNCTION. Thus arguments stayed alive until the next call to call or item. + +===EiffelNet=== +* Added close_socket in SOCKETwhich only close the socket for the current process. It will not close it for all processes which are using this socket (e.g. obtained after a fork on Unix platform). + +===EiffelTime=== +* Fixed incorrect display of the short year format when using the following code: +l_date: DATE_TIME +... +create l_date.make_now +print (l_date.formatted_out ("[0]mm/[0]dd/yy")) + + + +===EiffelThread=== +* Added a new C routine eif_thread_fork for Unix based system for users who would like to use a forking mechanism in a multithreaded system, as the default version of fork will most likely causes some deadlock. + +===EiffelVision2=== +* [[Revisions and Bug Fixes|Click here for EiffelVision2 release notes.]] + +===WEL=== +* Added various missing constants in WEL_*_CONSTANTS classes. +* Added creation procedure make_permanent in WEL_DLL so that the loaded DLL is loaded until the very end of program's execution. Now WEL_RICH_EDIT_DLL and WEL_COMMON_CONTROLS_DLL are using this new creation procedure. It fixes the issue where a program using WEL_RICH_EDIT would crash when exiting. +* Fixed a possible C compilation error when using WEL_RICH_EDIT due to a bug in the Microsoft Platform SDK header file for RichEdit. +* Fixed WEL_SCROLL_BAR to return a valid position when position is more than 65535. +* Added string_size_extended in WEL_FONT to better know where to draw a string using a specified font on screen, +* Added height_in_points, height_in_pixels, height_in_twips, and log_font in WEL_CHARACTER_FORMAT. Made height and set_height obsolete. +* Changed implementation of WEL_REGISTRY_KEY_VALUE in order to fix set_dword_valuewhich was writing incorrect data to the registry keys. Enhanced the typing of values, thus making the non-typed routines obsolete. +* Made default_key_value obsolete in WEL_REGISTRY. +* Properly defined is_equal and copy in WEL_STRUCTURE, possibly causing some compilation errors while analyzing the inheritance structure of your classes. +* Changed signature of non exported routine cwin_destroy_window from WEL_WINDOW to now return a value. +* Fixed issues when using WEL in a multithreaded application. It would crash if a non WEL thread was trying to destroy a WEL window. + +[[EiffelStudio release notes|Click here to check out what was new in other versions]] + + + + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-reference/eiffelstudio-release-notes/eiffelstudio-5-release-notes/release-notes-eiffelstudio-56.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-reference/eiffelstudio-release-notes/eiffelstudio-5-release-notes/release-notes-eiffelstudio-56.wiki new file mode 100644 index 00000000..2ea416ec --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-reference/eiffelstudio-release-notes/eiffelstudio-5-release-notes/release-notes-eiffelstudio-56.wiki @@ -0,0 +1,186 @@ +[[Property:title|Release notes for EiffelStudio 5.6]] +[[Property:link_title|5.6]] +[[Property:weight|-14]] +[[Property:uuid|c0aa1026-8c13-9975-0de4-3412624cf89a]] +==Graphical environment== + +===Improvements=== +* New implementation of the diagram tool with enhanced performance and functionalities +** Support for UML view. +** Physics: auto-arrangement of classes using force directed graph. +** Multiple selection of classes. +** Improved speed/behavior of drawing/scrolling operations especially on large diagram. + +* Added ability to find features performing an assignment to an attribute, or creating an attribute, as well as features using a procedure as creation procedure. +* Feature tree is now showing a different icon for frozen and obsolete features. +* Improved look and feel of applications using the EiffelVision library under Windows XP theme engine. +* Improved keyboard navigation in EiffelStudio windows/dialogs. +* Full support for 64 bits operating systems such as Windows, Linux, Solaris, Irix, OpenVMS,... +* Features tree is also available for classes which are part of the universe, but not yet compiled. +* New EiffelCOM wizard. Click [[EiffelCOM Wizard|here]] for more details. +* Improved speed of class completion for large system. +* Added new toggles for alias names and assigner commands to feature tree. + +===Changes=== +* Changed the default C compilation flags on Windows when using Visual Studio as a back-end C compiler. It will now compile C code using the -MT option. It may cause some linking problems if you are using C libraries compiled against the static C library. To solve those issues recompile your C code using the -MT option. +* Provided keyword highlighting in editor and different views for new keyword assign. + +===Bug fixes=== +* Fixed infinite loop in finish_freezing which could use all the available memory. +* Fixed some issues with formatting of agent using expressions as target, and display of character and string constants in context tool. +* Fixed issue where tools that have been externally docked were not properly restored when reopening EiffelStudio. +* Fixed issue where one could not remove entries added to the list of external commands. +* Supported keyword highlighting for the keywords infix and prefix in editor and different views. + +==Compiler== +* Click [[Major changes between ISE Eiffel 5.5 and ISE Eiffel 5.6|here]] for the compiler release notes. + +==Debugger== +===Graphical environment=== +* The stack, objects and evaluator tools now use a grid display instead of simply a tree view +* A mixed multicolumn list and tree view display which display item only when shown, this make debugger much faster to display values +* The evaluator tool renamed as "watch tool" has more features than previously, such as browsing the objects value directly in the tool, moving up and down the expression, dopped objects as them self, .... +* The new watch tool can be used instead of the objects view to display current, and dropped objects (and of course expressions). +* You can close and create new watch tools +* Each tool has its hexdecimal/decimal format switch command. +* Most of the debugging tools are now inside a notebook, and are dockable outside this notebook +* Various minor bug fixes and improvements regarding the interface + +===Debugger engine=== +* Fixed a memory leak with the `estudio` process when conditional breakpoints are enabled. +* Improved speed of execution when conditional breakpoints are enabled (about 20 times faster). +* Fixed a bug where after killing a debugged process, the debugger could not be launched anymore. +* Improved speed regarding STRING and SPECIAL manipulation in the debugger +* Dotnet: fixed memory/handle leak when debugging dotnet system +* Dotnet: fixed memory corruption while debugging dotnet system +* Dotnet: EiffelStudio do not hang (100% CPU) anymore during dotnet debugging. +* Dotnet: make EiffelStudio much more stable while debugging dotnet system. +* Dotnet: fixed various issues which occurred on killing debugged application +* Dotnet: improved support for dotnet v2.0.x debugging +* Dotnet: fixed expression evaluation on pure dotnet object +* Evaluation: fixed remaining error status on expression (sometimes when an expression has an error, changing the expression to a valid expression was not reseting the error status) +* Evaluation: improved error message reporting for expression evaluation +* Evaluation: improved the stability and the result validity of expression +* Breakpoint: fixed some issues related to setting, removing breakpoints, and remaining hidden breakpoints +* Breakpoint: now the debugger stops on a condition breakpoint when the condition's result is True, but also if the expression is not supported, or if it raises an exception + +==EiffelBuild== +* Click [[EiffelBuild Version History|here]] for the EiffelBuild release notes. + +==Libraries== + +===CECIL=== +* Due to renaming of EIF_REAL and EIF_DOUBLE into EIF_REAL_32 and EIF_REAL_64, we have also changed the names of some CECIL facilities. Although old names are still valid we may remove their definition in future releases of the compiler. Below is the list of old names and their corresponding new names: +{| +|- +| '''Old name''' +| '''New name''' +|- +| EIF_REAL_FUNCTION +| EIF_REAL_32_FUNCTION +|- +| EIF_DOUBLE_FUNCTION +| EIF_REAL_64_FUNCTION +|- +| eif_real_function +| eif_real_32_function +|- +| eif_double_function +| eif_real_64_function +|- +| EIF_REAL_TYPE +| EIF_REAL_32_TYPE +|- +| EIF_DOUBLE_TYPE +| EIF_REAL_64_TYPE +|- +| EIF_FN_FLOAT +| EIF_FN_REAL_32 +|- +| EIF_FN_DOUBLE +| EIF_FN_REAL_64 +|} + + +===EiffelBase=== +* Added new storable facility entierly written in Eiffel which enables you to exchange data between classic and .NET. Former version built-in in the Eiffel run-time did not apply for .NET. The classes are located in the new serialization cluster of EiffelBase. +* ARRAY: +** Changed signature of subarray to match ELKS specification. It now returns an ARRAY [G] instead of like Current. +** Fixed has to return True when searching for Void when comparing objects in an array containing a Void element. +** Fixed issue on .NET with clone/copy which were not really duplicating the internal of the array, and therefore enabling aliasing of its content by more than one array. +** Fixed a bug in feature occurences that returned 0 when called with void argument and object_comparision is true. +** Fixed a bug in feature is_equal that caused stack overflow when some array item is the array itself and object_comparision is true. + +* ARRAYED_LIST: +** Removed array_valid_index from ARRAYED_LIST. Descendants of ARRAYED_LIST may need to update their inheritance clause. This fixes ability to use put_i_th with indexes that may violate the invariant of ARRAYED_LIST, for example the code below should trigger a precondition and not violate the invariant of ARRAYED_LIST: +list: ARRAYED_LIST [INTEGER] + +create list.make (5) +list.put_i_th (3, 3) + +** Added implementation query new_filled_list in ARRAYED_LIST. Descendants of ARRAYED_LIST may need to update their inheritance clause. + +* HASH_TABLE: +** Added merge to HASH_TABLE. +** Now remove will reset found_item when an element is removed. + +* INTERNAL: +** Implemented all the routines in the .NET version. +** Added support for creating TUPLE types in dynamic_type_from_string. +** Added precondition to set_reference_field to ensure validity of reattachement to attributes. + +* STRING: +** Changed signature of infix "+" to match ELKS specification. It now returns like Current instead of STRING. +** Added implementation query new_string. Descendants of STRING may need to update their inheritance clause. +** Fixed a bug in .NET implementation of feature replace_substring that might produce incorrect result when argument and target of the call is the same object. +** Merged .NET and classic implementation of STRING so that all features of STRING are now properly implemented for both platforms. +** Fixed center_justify that would corrupt memory on classic. +** Changed character_justify, left_justify, right_justify and center_justify so that justification is now done on count instead of capacity. You might expect different results after upgrading, thus check all callers of those routines. +** Added is_case_insenstive_equal to compare two strings regardless of their case. +** Rewrote routines is_integer, is_real, is_double, to_integer, to_real and to_double so that they do not rely on C externals. This could breeak some existing code relying on specific locale to read floating numbers. + +* Changed behavior of item and eval in FUNCTION. They will not set last_result with their result. If you want to use last_result you should use call instead. +* Added new set of classes NATURAL_8, NATURAL_16, NATURAL_32 and NATURAL_64 to perform unsigned integer operations. +* Made implementations of cursor in descendants of CURSOR_STRUCTURE return a precise CURSOR type. +* Reduced feature exportation of routines also used as creation procedures of CURSOR descendants to NONE +* Removed make_sublist from TWO_WAY_LIST public creation procedures. +* Made file_prunable from FILE obsolete. Use prunable instead. +* Implemented features collect and full_collect of class MEMORY for .NET. +* Changed type of feature sign in classes INTEGER_8 and INTEGER_16 to INTEGER_8 and INTEGER_16 respectively. +* Added a subcluster refactoring with classes that can be helpful for performing code refactoring. +* Augmented many features that are used to access items by their index (such as ARRAY.item and TABLE.item) with a bracket alias and an assigner command. + +===EiffelNet=== +* Enable to open an URL on a virtual host. +* Enable to open an URL with login and password (for instance http://login:password@host/path/). +* Fixed wrong URL analysis. + +===EiffelThread=== +* Added feature sleep to class THREAD_CONTROL. +* Provided inheritance link between classes THREAD and THREAD_CONTROL on all platforms. + +===EiffelTime=== +* Breaking changes: +** In time format, the use of hh12 alone without specifying AM or PM will default to AM. +** Changed implementation of DATE_SET to use ordered_compact_date as storage. + +* Added support for [0]hh12 hour format. +* Added support for specifying hh12 as a standalone format string. +* Fixed a bug where calling TIME.make_by_fine_seconds would set fractional_second to zero rather than to the expected value. +* In TIME, comparison of fractional_second is done using a precision of 1.0e-10. +* Fixed is_positive in DATE_TIME_DURATION so that it is true when either the date or time is zero but the other is positive. +* Fixed incorrect postcondition of set_origine_date_time in DATE_TIME_DURATION which would fail when argument was Void. +* Fixed is_correct_date in DATE_VALIDITY_CHECKER to check that year is less than 65535. +* Fixed DATE_TIME_PARSER when handling time in 12h format, but internally we would convert it into 24h format thus making is_time and is_date_time return False where True was expected. + +===EiffelVision2=== +* [[Revisions and Bug Fixes|Click here for EiffelVision2 release notes.]] + +===WEL=== +* Made WEL 64 bits compliant. This required a breaking change in signatures. Some routines were actually using an INTEGER to represent a POINTER. On 64 bits platform this is not working as INTEGER is 32 bits and POINTER is 64 bits. As a consequence if you are using low level facilities of WEL your code might not compile anymore. Simply replace INTEGER by POINTER to make it compile. + +[[EiffelStudio release notes|Click here to check out what was new in other versions]] + + + + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-reference/eiffelstudio-release-notes/eiffelstudio-5-release-notes/release-notes-eiffelstudio-57.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-reference/eiffelstudio-release-notes/eiffelstudio-5-release-notes/release-notes-eiffelstudio-57.wiki new file mode 100644 index 00000000..e7ba2548 --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-reference/eiffelstudio-release-notes/eiffelstudio-5-release-notes/release-notes-eiffelstudio-57.wiki @@ -0,0 +1,158 @@ +[[Property:title|Release notes for EiffelStudio 5.7]] +[[Property:link_title|5.7]] +[[Property:weight|-15]] +[[Property:uuid|8adae9f2-9160-5f6e-bc81-f0763dfe963c]] +==Graphical environment== + +===What's new=== +* Dual licensing of EiffelStudio both commercial and open-source. +* Refactoring facilities: renaming and feature pull-up. +* Metric engine. It lets you define more advanced metrics. This is the first result of our new query engine. +* UUID library for generating UUID. +* Process library for launching, waiting, redirecting outputs of processes. +* Configuration system. It brings a new dimension to the way you manage multiple projects and simplifies it. + +===Improvements=== +* Output of C compilation now appears within the EiffelStudio environment. +* Improved tool for launching external commands from within the EiffelStudio environment. +* Introduced basic support for Unicode in Eiffel libraries, namely EiffelBase, EiffelVision2 and WEL. +* Improved display of clusters, libraries and assemblies. +* Added ability to see more relations in the diagram tool. For example, you can select a class and choose to see its descendants in the diagram. +* If a project that needs a precompile is opened and the precompile does not exist it will automatically be compiled. +* New projects use precompiles by default which speeds up the initial compilation. +* Improved search facility that has two faces: a quick search bar in the editor for finding text in the current editor, and a search panel to perform exhaustive search over your project. +* Profiler output is now sortable and can also be represented as a tree. +* Redesigned completion engine: +** Completion on wild-cards to quickly find a routine in a long list. +** Completion list is now available anytime a text field accepts a class or an expression (Class creation dialog, debugger evaluation expression, ...) +** On .NET, overloaded routines are all put together under one name. +** Hidden option can now be set with a toolbar at its bottom. +** Completion is available even if you have a syntax error in your class. + +* Formatters are now presenting results in a structured way with sorting capability. +* Overridden classes are now shown with the list of classes they are overriding. + +===Changes=== +* New configuration system. EiffelStudio will automatically convert your existing ace or epr files to the new format. +* Compilation progress is now displayed in the status bar and in the output pane, no more dialog box. +* Display of errors and warnings is now done in different panes, so that you do not lose their content when the output pane has changed. +* Pick and drop is now a dashed line. +* Redesigned the starting dialog to make it easier to create new projects as well as managing many existing projects. + +===Bug fixes=== +* When in a different format than the editable format, one can now select a feature and it will bring you to the feature in the selected format, rather than going back to the editable format. +* Fixed various formatting issue for our documentation format. +* Fixed some memory corruption that could cause EiffelStudio to randomly crash. + +==Compiler== +* Click [[Major changes between ISE Eiffel 5.6 and ISE Eiffel 5.7|here]] for the compiler release notes. + +==Debugger== +===Graphical environment=== +* More flexibility has been added for the layout in the debugging tool. One can merge the Current objects with the locals and arguments. +* The objects and watches tools restore the tree structure when stepping, and highlight value differences. +* New thread tool that let you switch from one thread to another while debugging. +* New Exception handling tool that let you ignore or catch certain kind of exceptions. +* New breakpoint tool to see at glance the status of all your breakpoints. +* Added ability to see the routine that defines an agent object (classic only for now). + +===Debugger engine=== +* One can debug multithreaded application. +* One can ignore certain kind of exceptions. +* One can disable Assertion checking during debugging (only classic system for now). +* Dotnet debugger is now much more stable for dotnet 2.0 +* Improved expression evaluation error reporting system to provide more information + +==EiffelBuild== +* Click [[EiffelBuild Version History|here]] for the EiffelBuild release notes. + +==Libraries== + +===EiffelBase=== +* STRING, STRING_8, STRING_32 and STRING_GENERAL: +** Added Unicode support through the addition of STRING_32. For the moment Unicode support is limited to the data-structure. +** Added STRING_GENERAL, a common ancestor to STRING_8 and STRING_32. It is useful if you want to handle both ASCII and Unicode string. For example this facility is used in EiffelVision2 and WEL. +** STRING can be either STRING_8 or STRING_32 depending on your configuration. Default is STRING_8. +** Added is_integer_xx, is_natural_xx, to_integer_xx and to_natural_xx where xx stands for 8, 16, 32 or 64. +** Added is_number_sequence which is semantically identical to the behavior of is_integer in 5.6. Changed behavior of is_integer to check that it fits into a 32-bit integer value. +** Updated is_double, is_real, is_real_32, is_real_64 so that the specification allows optional integral part or decimal part, but not both (as per the ECMA specification of a real constant). This fixes the bug where 1.e-4 was not considered a valid floating point value. +** Changed behavior of is_boolean to match the ELKS specification which says the lower case version of the string should either be true or false. +** Fixed issue in from_c_substring which would not properly if argument start_pos was greater than 1. + +* CHARACTER, CHARACTER_8 and CHARACTER_32: +** Removed WIDE_CHARACTER and WIDE_CHARACTER_REF; they are replaced by CHARACTER_32 and CHARACTER_32_REF. + +* REAL_32 and REAL_64: +** Renamed REAL into REAL_32, and DOUBLE into REAL_64. REAL can be either REAL_32 or REAL_64 depending on your configuration. Default is REAL_32. +** Added rounded_xxx, floor_xxx and ceiling_xxx where xxx is the current floating point type, as the version returning an INTEGER is definitely not precise for large numbers. + +* SED serialization facility: +** Fixed read_attributes in SED_INDEPENDENT_DESERIALIZER because we simply forgot to check that between the retrieved system and the stored system, a type has the same number of attributes. +** Fixed wipe_out in SED_OBJECTS_TABLE' which did not reset last_index. As a consequence if you were doing several storing in a row, then last_index kept being incremented but when retrieving the data it would fail because it would expect last_index to start at 1, not at the last incremented value. +** Changed SED_MEDIUM_READER_WRITER encoding so that it can also be used in a networking context. Basically now before sending the data, we first send the number of bytes of the data, and then the data. The old encoding is still available in SED_MEDIUM_READER_WRITER_1. + +* Added lock_marking and unlock_marking to use lock and unlock in INTERNAL in a multithreaded context. Currently used by the serialization classes. +* IO_MEDIUM: +** Added read_integer_XX, put_integer_XX, last_integer_xx and read_natural_XX, put_natural_XX, last_natural_XX where XX stands for 8, 16, 32, 64. + +* HASH_TABLE: +** Fixed an infinite cycle when using replace_key with a key which is not present in the table. +** Improved correct_mismatch to also retrieve HASH_TABLEs from version 5.4. +** Prevented catcalls in HASH_TABLE when you have keys which have a different type. + +* Added a bracket feature to item from ARRAY2. +* In ACTIVE_INTEGER_INTERVAL the action sequence will only be called if the range actually changes. +* Fixed launch from EXECUTION_ENVIRONMENT to not inherit handles on Windows. +* Moved list_eiffel3 and table_eiffel3 to the obsolete library. +* Changed .NET implementation of the feature FILE.read_line to follow the behavior of the feature in classic mode and to treat either single '%N' or a sequence of '%R' and '%N' as an end of line. +* Ensured that feature POINTER.out produces under .NET a hexadecimal number like in classic mode rather than a decimal number preceded by 0x. + +===EiffelNet=== +* Added in SOCKET read_integer_XX, put_integer_XX, last_integer_xx and read_natural_XX, put_natural_XX, last_natural_XX where XX stands for 8, 16, 32, 64. +* Modified put and read in NETWORK_RESOURCE, FTP_PROTOCOL, HTTP_PROTOCOL, FILE_PROTOCOL so that the error checking code is not using socket_ok which might triggers error when there are none. +* Improved handling of recipients and header_from in SMTP_PROTOCOL so that you can provide a nice `From` or `To` in the message since they are different from the addresses you have to pass from MAIL FROM and RCPT TO. +* Improved error handling in EiffelNet. Now each time an error occurs you get an exception and the operating system error code is preserved. +* Added ability to get the number of bytes read for all the read operation through the bytes_read query. This is useful to detect graceful shutdown of sockets. + +===EiffelThread=== +* Refactored the library so that even if you do not have the multithreaded option set, it will compile. However new preconditions have been added so that you know when you are using the library when you cannot. + +===EiffelVision2=== +* Added Unicode support. Read the WEL entry for Unicode below to see the impact on your code. +* [[Revisions and Bug Fixes|Click here for EiffelVision2 release notes.]] + +===Process=== +* New library to launch processes and redirect their output. + +===UUID=== +* New library to generate UUID. + +===WEL=== +* Added Unicode support: +** All routines taking an argument of type STRING or a generic type with STRING in one of the actual generic parameter have been changed to take an argument of type STRING_GENERAL which should not impact you at all, however make sure that if your redefine such a routine, you need to change the signature to STRING_GENERAL, otherwise you may introduce a CATCALL. +** All queries of type STRING have been changed to STRING_32. Because STRING_32 should not be convertible to STRING, it would break a lot of existing code, as a result and only for a transition period, we made STRING_32 convert to STRING. In the next release this conversion will be marked obsolete, and in the release after the next it will be removed. +** For queries whose type is a generic with STRING as one of the actual generic parameter, we changed STRING into STRING_32. Because no automatic conversion can be done in this case, we have introduced for a routine nnnnn following this pattern a new routine nnnnn_8 whose actual generic parameter is still STRING. + +* WEL_TREE_VIEW: +** Fixed get_item_rect which was always returning a 0,0,0,0 rect as we were not correctly initializing the rect structure with the pointer to the item. +** Added get_item_text_rect which returns a rect only for the text of the items. + +* WEL_WINDOWS_ROUTINES: +** Improved window_of_item to reduce the number of cases where we might get an exception. This makes debugging easier. +** Fixed resource_string_id which generated a call on Void target exception. + +* Added ability to have drop down menus in WEL_TOOL_BAR_BUTTON. +* Added the ability to add an icon to the SystemTray. +* Added ability to drop files to WEL_WINDOW components. +* Made all contextual menus being selectable from both left and right click (formerly it was only left click). +* Fixed issue with contextual menus which might not appear correctly, nor respond to click or Esc key properly because the menu is not at the front. +* Fixed in WEL_LIST_VIEW a bug where if the text of the string is too long, it would be displayed but truncated. +* Fixed incorrect result for title_bar_height in WEL_SYSTEM_METRICS. +* Fixed a memory corruption due to Windows not sending a WM_DESTROY or WM_NCDESTROY message in all cases when a window is actually destroyed. +* Fixed a bug in WEL_REGISTRY_KEY_VALUE.string_value that might cause assertion violation when a value is an empty string, because a check whether the last character is null was done without checking if string has at least one character. + +[[EiffelStudio release notes|Click here to check out what was new in other versions]] + + + + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-reference/eiffelstudio-release-notes/eiffelstudio-6-release-notes/index.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-reference/eiffelstudio-release-notes/eiffelstudio-6-release-notes/index.wiki new file mode 100644 index 00000000..b84b1aea --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-reference/eiffelstudio-release-notes/eiffelstudio-6-release-notes/index.wiki @@ -0,0 +1,6 @@ +[[Property:title|EiffelStudio 6 release notes]] +[[Property:link_title|6.x]] +[[Property:weight|14]] +[[Property:uuid|e06af7f1-dab6-85ec-0688-0b48c3f2e88b]] + + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-reference/eiffelstudio-release-notes/eiffelstudio-6-release-notes/release-notes-eiffelstudio-60.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-reference/eiffelstudio-release-notes/eiffelstudio-6-release-notes/release-notes-eiffelstudio-60.wiki new file mode 100644 index 00000000..4aa44739 --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-reference/eiffelstudio-release-notes/eiffelstudio-6-release-notes/release-notes-eiffelstudio-60.wiki @@ -0,0 +1,98 @@ +[[Property:title|Release notes for EiffelStudio 6.0]] +[[Property:link_title|6.0]] +[[Property:weight|-7]] +[[Property:uuid|41ef6135-ecad-ed55-9923-38901690a223]] +==Graphical environment== + +===What's new=== +* New docking facilities which let you control the layout of tools in EiffelStudio. One can also lock the layout to prevent unwanted changes. +* New tabbed editor. +* Added configurable pick and drop which lets you choose between traditional context menu or pick and drop for a mouse right click operation. +* EiffelStudio is now internationalized, it fully supports English, Chinese and German. A partial translation for French and Russian is provided. +* Shortcuts can now be customized. +* Added dependency view so supplier/client dependency of a group/folder/class can be investigated. Feature calls are included in dependency view. + +===Improvements=== +* The combo boxes in the address bar can now be resized to see more text (useful with long class names). +* Added ability to add new classes/clusters/assemblies early on in the compilation phase instead of waiting for a successful compilation. +* Faster rendering of EiffelStudio when running it through Remote Desktop. +* Auto-completion after bracketed expression. i.e. arr [i].* +* Added preference "Maximum processor usage" to dictate the maximum number of processors/cores to use when compiling c-code. +* Updated metrics documentation, see [[Metrics tool|for more details]] . + +===Changes=== +* Changed the diagram default color from light yellow to white for consistency with the background color of other tools. +* Improved history behavior. +* Project settings such as arguments/working directory/location are now stored in a user specific location that does not depend on the UUID of the project, but on its path. +* Favorites are now stored in the user settings. + +===Bug fixes=== +* EiffelStudio and various tools should better handle paths with spaces. +* Fixed add assemblies dialog not showing assemblies such as mscorlib on 64 bit systems. +* Fixed bug#12083 where classes in override clusters would not get recompiled properly when automatically saved by EiffelStudio when requesting a compilation. +* More bug fixes can be seen at [http://dev.eiffel.com/EiffelStudio_6.0_Releases the EiffelStudio open source site] . + +==Compiler== +* Click [[Major changes between ISE Eiffel 5.7 and ISE Eiffel 6.0|here]] for the compiler release notes. + +==Debugger== +===Graphical environment=== +* Added auto expressions on watch tools, it suffices to toggle the auto button in any of the watch tool's toolbar. +* Enhanced breakpoint mechanism by adding print message, hit count (condition), and provide '''Is True''' and '''Has Changed''' condition. +* Improved the debugging options dialog with the ability to define the environment variables passed down to the debugged application. +* Added some configuration of the Objects tool grid. It is now possible to change the order of 'Current, arguments, locals, ...'. +* Added start workbench and finalized system on Debugging option dialogs. +* Added a new way to look at objects with the object viewer. +* Added a rescue clause indicator in call stack tool's grid. +* One can decide to stay in debugging mode even when compiling. +* Added possibility to continue on conditional breakpoint evaluation failure. +* Removed useless ''Attributes'' row in debugger's objects tree. +* The once routines node now shows states of once procedures in addition of the state of once functions. +* Improved cosmetic of debugger's exception handling dialog. + +===Debugger engine=== +* Added support for creation of instance of class (including generic). +* Added support for manifest TUPLE, and manifest ARRAY. +* Added support for static routine evaluation. +* Added ability to disable/restore assertion checking during debugging. +* Added evaluation of instructions with the debugger (i.e: procedure call). +* Fixed bug#12934 where the debugger would cause a memory corruption in a running multithreaded program. +* Fixed bug#12750 where the stack overflow detection was not working on Linux. +* Fixed bug#11755 where empty strings with a large capacity were slow to be displayed. + +==EiffelBuild== +* Click [[EiffelBuild Version History|here]] for the EiffelBuild release notes. + +==Libraries== + +===EiffelBase=== +* Fixed issue with LINKED_QUEUE.twin which would violate its invariant. +* Revisited contracts of LINEAR_ITERATOR. +* Added facilities to read/write REAL_32 and REAL_64 values in big and little endian format in MANAGED_POINTER. +* Changed INTERNAL so that it does not have the is_pre_ecma_mapping_disabled attribute. If you were setting it to True, you should instead create an instance of ECMA_INTERNAL (fixes bug#11792). +* HASH_TABLE: +** Sped up HASH_TABLE iteration and lookup by about 8% or more. +** Added two new possibilities to detect/prevent catcalls, they can be enabled by enabling assertion checking and enabling the debug clauses ''prevent_hash_table_catcall'' and ''detect_hash_table_catcall''. + +* TUPLE can now compare items using reference equality (=) or object comparison (is_equal). +* Sped up SPECIAL.copy_data which was previously not inlined due to a change of signature preventing the inlining. +* EXECUTION_ENVIRONMENT.get will only retrieve environment variable. It won't retrieve a value from the registry key on Windows (from HKLM\Software\ISE\Eiffelxx\app_name). This also means that MELT_PATH on Windows cannot be set in registry; this is not really a problem because now you do not need to set it since the W_code knows where to find it. + +===EiffelNet=== +* Updated reading routines of EiffelNet so that for all basic types they would read all the required bytes, not just stop after reading the first. This is important as in some very bad network situation or if you have some signals you could mess up the reading by only reading half of the expected bytes. + +===EiffelThread=== +* Fixed bug#12838 where on Linux you could not create more than 2^15 threads even if they all exited. Now we force creation of threads in a detached mode to allow more than 2^15 thread creations. + +===EiffelVision2=== +* [[Revisions and Bug Fixes|Click here for EiffelVision2 release notes.]] + +===WEL=== +* Raised compatibility bar to Windows 2000 or greater. No more support for Windows 98 or NT 4.0. +* Added ability to convert image formats among all image formats on Windows (using WEL_GDIP_BITMAP). + +[[EiffelStudio release notes|Click here to check out what was new in other versions]] + + + + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-reference/eiffelstudio-release-notes/eiffelstudio-6-release-notes/release-notes-eiffelstudio-61.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-reference/eiffelstudio-release-notes/eiffelstudio-6-release-notes/release-notes-eiffelstudio-61.wiki new file mode 100644 index 00000000..e9e48c8f --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-reference/eiffelstudio-release-notes/eiffelstudio-6-release-notes/release-notes-eiffelstudio-61.wiki @@ -0,0 +1,63 @@ +[[Property:title|Release notes for EiffelStudio 6.1]] +[[Property:link_title|6.1]] +[[Property:weight|-8]] +[[Property:uuid|29bc2a0b-3327-dbd1-9d64-51484da2c40c]] +==Graphical environment== + +===What's new=== +* New default layout for EiffelStudio tools to highlight the most common used tools whereas other tools are still available at the bottom or via the View menu. +* New Errors and Warnings tool. It replaces the former Errors tool and Warnings tool and provides a nicer way to show errors and filtering them. +* Revisited all the dialogs to provide a nicer and consistent look and feel. +* Multiple errors are reported for each compilation degree. + +===Improvements=== +* Use the default OS font for displaying tooltips. +* C compilation failure will now show up as an error in the new Errors and Warnings tool. +* Completion list will now show immediately after pressing '.' when the completion list is active. +* Added ability to submit a problem report within EiffelStudio when it quits unexpectedly. + +===Changes=== +* Support for the MinGW C compiler on Windows 32-bit. Borland is officially not supported anymore. +* Completion list no longer shows obsolete items by default (set via a preference option). + +===Bug fixes=== +* Fixed incorrect results when using the profiler with a finalized system. +* More bug fixes can be seen at [http://dev.eiffel.com/EiffelStudio_6.1_Releases the EiffelStudio open source site] . + +==Compiler== +* Click [[Major changes between ISE Eiffel 6.0 and ISE Eiffel 6.1|here]] for the compiler release notes. + +==Debugger== +===Graphical environment=== +* Added debuggee object storage. This allow to store and retrieve debuggee's object. +* Added basic execution replay mechanism. This allows to record the execution, and replay the recording in EiffelStudio and see/browse the recorded values. +* Rename "debugging" into "execution" in EiffelStudio's message and title. +* Better dialog to change the layout of the Objects tool grid. It is possible to easily change the order of 'Current, arguments, locals, ...'. + +===Debugger engine=== +* Added support for creation of SPECIAL instances. +* Added support for creation of TYPE instances. (i.e: {FOO} will return a instance of TYPE [FOO]) + +==EiffelBuild== +* Click [[EiffelBuild Version History|here]] for the EiffelBuild release notes. + +==Libraries== + +===EiffelBase=== +* BINARY_SEARCH_TREE: Added tree_item which matches the item being searched. +* LINEAR: Added item_for_iteration as a synonym of item. +* STRING_8 and STRING_32: +** Improved speed of the to_xxx routines. +** Added starts_with and ends_with. + +* GC_INFO: Fixed non working computation of CPU time usage on Windows and added two new queries (cpu_total_time and sys_total_time) to find out the total CPU execution time of the program at the last GC cycle. +* MEMORY: Added execute_without_collection to execute a procedure with no GC. + +===EiffelVision2=== +* [[Revisions and Bug Fixes|Click here for EiffelVision2 release notes.]] + +[[EiffelStudio release notes|Click here to check out what was new in other versions]] + + + + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-reference/eiffelstudio-release-notes/eiffelstudio-6-release-notes/release-notes-eiffelstudio-62.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-reference/eiffelstudio-release-notes/eiffelstudio-6-release-notes/release-notes-eiffelstudio-62.wiki new file mode 100644 index 00000000..ea428c18 --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-reference/eiffelstudio-release-notes/eiffelstudio-6-release-notes/release-notes-eiffelstudio-62.wiki @@ -0,0 +1,74 @@ +[[Property:title|Release notes for EiffelStudio 6.2]] +[[Property:link_title|6.2]] +[[Property:weight|-9]] +[[Property:uuid|fc43b67d-46a0-6ab1-ed2c-9aaef186f333]] +==Graphical environment== + +===What's new=== +* Added new contract editor tool to ease edition of contracts on routines and classes. +* Added Eiffel Information System which let you connect external documentation to your Eiffel code and vice versa. +* Added ability to avoid comment duplication by using the in your descendant comment to reuse the parent one which is shown in all our formatter tools.. +* Added new light batch compiler `ecb`. It provides the same features as `ec` when using the batch mode. Currently projects compiled with `ec` are not compatible with those compiled with `ecb`. The main difference between the two is that `ec` is compiled with exception trace and multithreading support which could slow down the compiler by a factor of 20 to 40% depending on your platform. +* Added experimental unit testing tool. + +===Improvements=== +* Error list tool now supports multiple selection, for better copy to clipboard usage. +* Enhanced some errors to report better context information. +* Optimized adding of items to the Error List by circumventing an expensive search when adding single items. + +===Changes=== +* Error list items context now shows the full group name but after CLASS.feature because it is of lesser importance. +* Restructured layout of user files to support unification and user-override files of Eiffel compiler installation files. Relocated default Eiffel projects location into the user files folder (windows and mac only). + +===Bug fixes=== +* Fixed the EiffelCOM wizard so that it generates C code that compiles. + +==Compiler== +* Click [[Major changes between ISE Eiffel 6.1 and ISE Eiffel 6.2|here]] for the compiler release notes. + +==Debugger== +===Graphical environment=== +* New breakpoint editor, which centralizes in a unique dialog the parameters of the breakpoint. +* Added tag support for breakpoints. +* Added new "When hits.." actions (such as enable/disable breakpoints, start/stop execution recording, and others...). +* Better breakpoints tool, to see, sort or filter the breakpoints +* Enhanced execution record and replay mechanism. This allows to record the execution, and replay the recording in EiffelStudio and see/browse the recorded values, and the calls executed. +* Better dialog to change the layout of the Objects tool grid. It is possible to easily change the order of 'Current, arguments, locals, ...'. +* Added a toggle button, to ignore or not the breakpoints. +* Added dropdown menu on the "[Start]" button to have quicker access to useful features. + +===Debugger engine=== +* Watch tool: added support for "create .." expression. + +==EiffelBuild== +* Click [[EiffelBuild Version History|here]] for the EiffelBuild release notes. + +==Libraries== + +===EiffelBase=== +* Changed signature of {`SPECIAL`}.`same_items` and {`SPECIAL`}.`all_default` to take an extra argument. Our analysis shows that it was only used by `ARRAY` and that it should be harmless. If you have a compilation error, simply add `0` as first argument of your call. +* Changed `physical_size` in `INTERNAL` to return the real allocated size of an object along with its header size. +* Added `deep_physical_size` in `INTERNAL` to compute the size of an object and all its dependencies. +* Improved speed of `read_stream` in `FILE` so that it used underlying `fread` once rather than calling `getc` for each requested character. Our benchmarks show that you can save up to 2s for 1000 calls. +* Added an assigner routine for `item` in `ARRAY2`. This might break descendant classes of `ARRAY2` redefining `item`. +* Updated code toward Void-safety. + +===EiffelNet=== +* Fixed bug in {`SOCKET`}.`read_stream` where if there was a socket error, then it would cause a precondition violation in `C_STRING`. + +===EiffelTime=== +* Added support for `DEBUG_OUTPUT` for `DATE`, `TIME` and `DATE_TIME` objects making it easier to debug code based on them. +* Fixed bug where duration in days between two dates overlapping a leap year would yield a result off by +1 or -1. +* 10% speed improvement on certain date operations (can be seen on eweasel test#time002). + +===EiffelVision2=== +* [[Revisions and Bug Fixes|Click here for EiffelVision2 release notes.]] + +===EiffelVision2=== +* Fixed a bug in {`WEL_REGISTRY`}.`enumerate_key` where the routine would go in an infinite loop if the key name was larger than 64 characters. + +[[EiffelStudio release notes|Click here to check out what was new in other versions]] + + + + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-reference/eiffelstudio-release-notes/eiffelstudio-6-release-notes/release-notes-eiffelstudio-63.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-reference/eiffelstudio-release-notes/eiffelstudio-6-release-notes/release-notes-eiffelstudio-63.wiki new file mode 100644 index 00000000..94e1bd01 --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-reference/eiffelstudio-release-notes/eiffelstudio-6-release-notes/release-notes-eiffelstudio-63.wiki @@ -0,0 +1,77 @@ +[[Property:title|Release notes for EiffelStudio 6.3]] +[[Property:link_title|6.3]] +[[Property:weight|-10]] +[[Property:uuid|524a2b27-872c-1fd9-8de1-651128f11155]] +==Graphical environment== + +===What's new=== +* Innovative testing tools let you automatically test your software, extract test cases from failed execution as well as manually creating your own test cases. +* Added brace matching in the editor. +* Added ability to automatically license your Eiffel classes each time you save a class. +* Added the '''argument_parser''' library which provides an easy way to manipulate command line arguments. +* Added a new version of the EiffelNet library with IPv6 support. Because it has some breaking changes, the library is called '''net_ipv6''' and can be, in most cases, be used in place of the original EiffelNet library. + +===Improvements=== +* Improved the library choice dialog which can also be customized to include your own locations. +* Added support for note keyword and the updated variant keyword location in a loop through the environment. +* You can remove errors from the Warning and Error list tool which is practical when fixing many errors at once. +* Improved the problem report submission dialog. +* Better messaging about the installed C/C++ compiler on Windows. +* Improved cursor rendering colors, so that in all background colors. + +===Changes=== + +===Bug fixes=== +* Code completion works even if the obsolete is keyword is missing. +* Fixed an installation issue of the enterprise/evaluation release of EiffelStudio on Windows Vista. +* Properly refreshes the Feature tool after a save or a compilation. +* Fixed browsing of .NET classes in EiffelStudio. + +==Compiler== +* Click [[Major changes between ISE Eiffel 6.2 and ISE Eiffel 6.3|here]] for the compiler release notes. + +==Debugger== +===Graphical environment=== +*Watch tool: +** Changed the shortcut to move up/down expression (Shift+Alt+Up|Down). This can be changed in preferences. +** Multiple expressions can be moved up/down at the same time (instead of just one) +** Added export to/import from a file the expressions' text +** Pasting multi-lines text into the "..." expression cell, will create one expression per line. +*Interface: various bug fixes + +===Debugger engine=== +* added support for self initialized attributes +* fixed major issue of the dotnet debugger on Win32 (and potentially on win64 too) +* fixed retrieving of stack value when invariant is violated (now a _invariant stack will appear in the call stack to help debugging) + +==EiffelBuild== +* Click [[EiffelBuild Version History|here]] for the EiffelBuild release notes. + +==Libraries== + +===EiffelBase=== +* EiffelBase has been rewritten to be Void safe. To use the void safe version, one has to use the '''base-safe.ecf''' configuration file of EiffelBase. Not all libraries are void safe, so the void safe version can only be used for code that does not depend on other libraries. EiffelStudio 6.4 should provide void safe version of all libraries provided in EiffelStudio. +* Added sleep to EXECUTION_ENVIRONMENT and made sleep from THREAD_CONTROL obsolete. +* Added read_xxx_thread_aware in IO_MEDIUM so that reading a file is not blocking in a multithreaded context. +* Added the notion of read-only and immutable strings (respectively READABLE_STRING_8/32 and IMMUTABLE_STRING_8/32). Because READABLE_STRING_8 is deferred, some code using expression of the form '''STRING + SYSTEM_STRING''' in .NET mode will not compile anymore. Instead one has to do '''STRING + create {STRING}.make_from_cil (SYSTEM_STRING)'''. +* Added {READABLE_STRING_GENERAL}.same_string to compare any kind of strings together. +* Added ability to stop and start the Eiffel tracing mechanism from code using the new TRACING_SETTING class. +* Changed the default assigner for {TABLE}.item from put to force a new feature of TABLE. This allows the bracket operator on HASH_TABLE to work properly, that is to say hash_table [i] := j will indeed insert 'j' at key 'i' even if key 'i' is already present. Before it was silently doing nothing since it was using put. +* Fixed eweasel test#list012 which showed an invariant violation after twining a SORTED_TWO_WAY_LIST and then modifying the copy by adding an element. This introduces a breaking change in all descendants of SORTED_TWO_WAY_LIST. + +===EiffelNet=== +* EiffelNet can select on 256 ports at the same time +* Fixed on Unix improper handling of EWOULDBLOCK and EINPROGRESS error on Unix which would raise an exception instead of silently ignoring the error as it is done on Windows. +* New library for IPv6 support. + +===EiffelProcess=== +*Fixed an issue with the library when redirecting inputs/outputs of the child process. Sometime we would be missing some characters and cause a memory corruption at the same time. + +===EiffelVision2=== +* [[Revisions and Bug Fixes|Click here for EiffelVision2 release notes.]] + +[[EiffelStudio release notes|Click here to check out what was new in other versions]] + + + + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-reference/eiffelstudio-release-notes/eiffelstudio-6-release-notes/release-notes-eiffelstudio-64.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-reference/eiffelstudio-release-notes/eiffelstudio-6-release-notes/release-notes-eiffelstudio-64.wiki new file mode 100644 index 00000000..d078ac59 --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-reference/eiffelstudio-release-notes/eiffelstudio-6-release-notes/release-notes-eiffelstudio-64.wiki @@ -0,0 +1,94 @@ +[[Property:title|Release notes for EiffelStudio 6.4]] +[[Property:link_title|6.4]] +[[Property:weight|-11]] +[[Property:uuid|2f88d204-6e51-6150-8fbe-f6a3b41d5ec1]] +==Graphical environment== + +===What's new=== +* Initial support for the iPhone platform to develop command line applications. Support for graphical applications will be available in the next release. +* Added new libraries: '''api wrapper''', '''diff''', '''encoding''', and '''internationalization''' libraries. +* To minimize breaking changes, EiffelStudio comes with two sets of libraries. The first set, which is the default set, is compatible with previous versions of EiffelStudio. The second set, which is labeled '''experimental''', is void-safe and contains some breaking changes such as new ARRAY, ARRAYED_LIST, HASH_TABLE, SPECIAL classes. Users are encouraged to compile with the experimental libraries in order to prepare their code for the future when today's experimental libraries will become the de facto libraries. It is possible to adjust code so that a single version compiles against both sets of libraries. +* Added new tools to the EiffelStudio delivery. They are located under $ISE_EIFFEL/tools/spec/$ISE_PLATFORM/bin. The new tools are: +:*'''compile_all''': compile all the Eiffel Configuration File projects found under a directory and report which ones do and do not compile. +:*'''syntax_updater''': update the Eiffel code found under a directory to use the latest ECMA syntax in your code. + +===Improvements=== +* Added automatic completion of the attribute keyword to create an attribute body. +* The completion window will now show a feature or class description tool tip. +* Added support for new attached syntax for code completion. +* Better formatting of verbatim strings, guaranteeing that copy/pasting from the formatted text will yield the same string content as the one in the Eiffel source code. +* Improved display of ~ and /~ operators, as well as object test expressions. +* The project name is displayed in the status bar, when a configuration is loaded (i.e: even before any compilation) +* Vastly improved population of the error list tool when thousands of errors/warnings are generated. +* Added option in the new library dialog to show only void-safe libraries, for void-safe projects. + +===Changes=== +* The EiffelNet library with IPv6 support is now the default library. The old one is still available as part of our obsolete libraries. +* The project configuration format has a new version with new settings for void-safety compilation. The compiler will choose the default options based on the version of the project configuration file. Making it easy to have the same code compile identically with old versions of EiffelStudio. +* Changed the Eiffel Information System to use the note element in project configuraton file in this style: . +* The experimental version of gobo had its ECF removed and replaced by several corresponding to sub-libraries of the Gobo framework. + +===Bug fixes=== +* Fixed failure when generating the flat view of some classes. +* Fixed various issues with the testing tool. +* Fixed a bug which caused editor to disappear when debugging. +* Fixed some corruptions of the docking layout of EiffelStudio. + +==Compiler== +* Click [[Major changes between ISE Eiffel 6.3 and ISE Eiffel 6.4|here]] for the compiler release notes. + +==Debugger== +===Graphical environment=== +* Fixed various execution cursor issues in feature tool (especially with loop variant, and also inherited assertions) when debugging. +* EiffelStudio now remembers the breakpoints and profiles even after recompiling from scratch. + +===Debugger engine=== +* Added support for object test locals. +* Support void-safe expression evaluation. +* Fixed evaluation of is_equal, equal, =, ~ in expression (watch tool). + +==EiffelBuild== +* Click [[EiffelBuild Version History|here]] for the EiffelBuild release notes. + +==Libraries== + +===EiffelBase=== +* Changed the default assigner of {TABLE}.item from originally put to force. As a consequence, descendants of TABLE might get a VDRD error if redefining item +* Added same_keys to HASH_TABLE. You can redefine this feature to use a different comparison criterion for the keys. +* For object comparison, containers are now using the ~ operator instead of is_equal. As a result, if you had heterogeneous containers, then it might not find items that were found before (although it was a catcall). +* EiffelBase is now using the alias notation instead of infix/prefix. +* Updated the IMMUTABLE_STRING classes to have an efficient string extraction query shared_substring which will let you create a substring of an existing immutable string without actually duplicating the data. +* The creation procedure default_create from CELL has been removed to ensure that the same code can be compiled in both non-void-safe and void-safe mode. +* Implemented {EXCEPTION}.cause which returns the exception object that caused the current exception while executing the rescue clause. +* Fixed the inconsistent behaviors of {EXCEPTIONS}.original* with 5.7 potentially breaking code using exceptions. +* Ensured that in void-safe mode, one can call {INTERNAL}.set_reference_field to set a reference attribute to Void if the attribute is of a detachable type. +* In INTERNAL, fixed a bug that would not recognize a class name A_SOMETHING as a valid identifier for INTERNAL. +* Changed IO_MEDIUM.last_string to be attached so that existing code can easily be migrated to void-safe without changing the pattern read_line/last_string. +* The following classes have been excluded from the void-safe version of EiffelBase as they cannot be made void-safe under their current design: +:* COMPACT_CURSOR_TREE +:* LINKED_CURSOR_TREE +:* TWO_WAY_CURSOR_TREE +:* COMPACT_TREE_CURSOR +:* LINKED_CURSOR_TREE_CURSOR +:* TWO_WAY_CURSOR_TREE_CURSOR +* Fixed eweasel test#list003 where calling copy on a non-empty LINKED_LIST and providing the same list as argument would wipe out the content of the LINKED_LIST instead of preserving the elements. +* Fixed eweasel test#list014 where calling merge_left and merge_right on a TWO_WAY_LIST was violating the invariant. +* Fixed eweasel test#array005 where calling wipe_out on an ARRAY2 was violating the invariant. +* Fixed eweasel test#except035 where we incorrectly merged the code value for IO_EXCEPTION and RUNTIME_IO_EXCEPTION thus breaking existing code not based on Eiffel exception object. +* Fixed eweasel test#except033 that an exception thrown through rescues caused infinite loop. + +===EiffelNet=== +* Added ability to only listen on the loopback address in NETWORK_STREAM_SOCKET. +* Fixed some issues when trying to listen for either any address or the loopback address in both IPv4 and IPv6 mode on Windows. The fix also solves a security issue, because if you have IPv6 enabled, then listening to the loopback would also listen to any address on the IPv4 interface. +* Fixed a memory leak in read and receive from SOCKET caused by failure to free the temporary buffer used to hold the data. +* Renamed privately exported make_from_fd to make_from_descriptor_and_address. +* Re-enabled listening on 256 ports on Windows for the IPv6 library. + +===EiffelProcess=== +* Changed the redirection semantics so that the output is now appended to a file rather than recreating it. + +===EiffelVision2=== +* [[Revisions and Bug Fixes|Click here for EiffelVision2 release notes.]] + +[[EiffelStudio release notes|Click here to check out what was new in other versions]] + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-reference/eiffelstudio-release-notes/eiffelstudio-6-release-notes/release-notes-eiffelstudio-65.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-reference/eiffelstudio-release-notes/eiffelstudio-6-release-notes/release-notes-eiffelstudio-65.wiki new file mode 100644 index 00000000..53574c2f --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-reference/eiffelstudio-release-notes/eiffelstudio-6-release-notes/release-notes-eiffelstudio-65.wiki @@ -0,0 +1,90 @@ +[[Property:title|Release notes for EiffelStudio 6.5]] +[[Property:link_title|6.5]] +[[Property:weight|-12]] +[[Property:uuid|05D62D2D-7688-47C1-AC8A-796E6CA08A88]] +==Graphical environment== + +===What's new=== +* A new output tool that combines the Eiffel compilation output, the C compilation output, the testing output as well as the system information. +* When there is a C compilation error, the errors are now reported in the error list. Currently, we only support error reported by either the GNU C compiler or the Microsoft C compiler. The error is also linked to the source Eiffel feature when the information is available. + +===Improvements=== +* In the recent projects submenu, one can select the most recently compiled target. +* The automatic class licenser can now use the license.lic files next to an ECF instead of naming the license after the ECF. It makes it easier for projects that have multiple ECF. +* Double clicking on an ECF file will select the previously compiled target by default. +* Added tooltip to the precompilation wizard list to show item's ECF file path. + +===Changes=== +No changes in this release. + +===Bug fixes=== +* Addressed issue where the first change made to the diagram tool could not be undone. +* Fixed issue with ES crashing when trying to merge a license, when the class contains an empty note clause. +* Fixed issue where project settings would let you add twice the same include file rule. +* Fixed an issue where clicking in the project settings entry to display a dialog and then clicking cancel would show the dialog a second time. +* Fixed bug preventing the new features dialog from being displayed when using newer syntax. +* Fixed issue where one could not change an integer based preference entry in EiffelStudio. +* Many more issues have been fixed. For a more complete list, see the [http://dev.eiffel.com/EiffelStudio_6.5_Releases change logs]. + +==Compiler== +* Click [[Major changes between ISE Eiffel 6.4 and ISE Eiffel 6.5|here]] for the compiler release notes. + +== AutoTest== +* Library: EQA_TES_SET.on_prepare is now called during default_create, making it simpler to write void-safe tests. +* Library: Added the possibility to wrap the actual test routine call. +* AutoTest traverses all writeable clusters in the project for possible test classes, making <tests>-clusters obsolete. The traversal happens in the background allowing the user to continue to work on the project. +* Tags can be used to control the test execution flow. Tagging a test with "execution/isolated" makes the test execute in a separate evaluator process, meaning the evaluator is restarted before and after executing the corresponding test (useful for tests relying on the initial access to a once routine or tests which possibly leave the memory corrupted).
Also any tag of the form "execution/serial[/*]" groups the tests to ensure that they are not executed in parallel (useful when a group of tests shares a resource which has to be accessed sequentially). +* Any results are stored between EiffelStudio sessions. +* Improved the management of existing tests by merging the "View" and "Filter" box into one input field. +* Improved bottom part of AutoTest tool by only having two tabs displaying test execution and test creation results. + +==Debugger== +===Graphical environment=== +* To move a breakpoint, you can Ctrl+RightClick on the related breakpoint icon, and Ctrl+Drop on the wanted breakpoint location. +* Better support for attributes pick and drop into the watch tool +* The debugger will display as text/string all descendants of READABLE_STRING_8/32 (instead of just STRING_8/32). Including IMMUTABLE_STRING_... +* You can toggle the status of a breakpoint easily using shortcuts: +**F9: toggle between enabled/not-set. +**Shift+F9: toggle between enabled/disabled. +**Ctrl+F9: open the breakpoint dialog for editing. + +===Debugger engine=== +* Fixed several issues related to object test locals (especially in the expression) +* Fixed a major memory leak related to condition evaluation +* Fixed evaluation of is_equal, equal, =, ~ in expression (watch tool). +* It is now possible to unset an environment variable, or unset all variables, in the execution parameters dialog (see [[Execution profiles|doc]]) +* Improved support for expanded objects (especially SPECIAL of expanded) +* Fixed memory leak related to condition breakpoints, and improved the condition breakpoints performance. + +==EiffelBuild== +* Click [[EiffelBuild Version History|here]] for the EiffelBuild release notes. + +==Libraries== + +===EiffelBase=== +* In experimental mode, we have changed the signature of generating_type to return an instance of TYPE rather than an instance of STRING. Existing code should still compile out of the box since we have equipped TYPE with conversions and new features similar to those of STRING. In the few cases where it would still not compile, use `generating_type.out` to ensure that the code will compile fine regardless of the compiler mode chosen (i.e. experimental or non-experimental). +* Fixed an issue in copy from HEAP_PRIORITY_QUEUE which would not do anything because it was simply copying itself, not the other queue. +* Fixed a bug in remove from HEAP_PRIORITY_QUEUE which caused the internal structure to be referenced beyond its bounds. +* Made clear_all in STRING_8, STRING_32 and HASH_TABLE obsolete. One has to use wipe_outinstead. +* Strengthen precondition of resize in STRING_8/STRING_32 to forbid values that would shrink the string content. Use grow instead to preserve the former resize behavior. +* Added the base extension library that offers some extra functionality to EiffelBase: SEARCH_TABLE which is a HASH_TABLE where keys and items are the same (basically becoming a set), and sorting facilities for INDEXABLE containers. +* Added the "+" operator in READABLE_STRING_GENERAL. +* Added ability to create a directory recursively. +* Fixed bug#4118 where on .NET {EXECUTION_ENVIRONMENT}.put had no effect on the actual process environment variables because the API was only available in .NET 2.0 which is what we now support at the minimum. +* Fixed a bug in {MEMORY}.memory_map which would cause a precondition violation in one of its call. +* Fixed issue with {BINARY_SEARCH_TREE_SET}.remove which would not move the cursor and thus causing an infinite loop in subtract and intersect. +* Fixed issue with {PART_SORTED_SET}.put and {PART_SORTED_SET}.extend which had no effect and thus causing a postcondition violation. +* Fixed invalid retrieval of SPECIAL objects using the Eiffel SED serializer in experimental mode. +* Fixed a missing element in {BOUNDED_QUEUE}.linear_representation. + +===EiffelNet=== +* Fixed an issue with {NETWORK_STREAM_SOCKET}.make_server_by_port (0) which would not automatically get a port assigned. +* Fixed obsolete warnings in the library. +* Prevented a socket to change its blocking mode when connecting with a timeout (it would end up always being blocking even if requested otherwise before the call to `connect`. +* Ensured that a socket is indeed connected when successfully connecting to it while the socket is in non-blocking mode. + +===EiffelVision2=== +* [[Revisions and Bug Fixes|Click here for EiffelVision2 release notes.]] + +[[EiffelStudio release notes|Click here to check out what was new in other versions]] + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-reference/eiffelstudio-release-notes/eiffelstudio-6-release-notes/release-notes-eiffelstudio-66.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-reference/eiffelstudio-release-notes/eiffelstudio-6-release-notes/release-notes-eiffelstudio-66.wiki new file mode 100644 index 00000000..529964e7 --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-reference/eiffelstudio-release-notes/eiffelstudio-6-release-notes/release-notes-eiffelstudio-66.wiki @@ -0,0 +1,86 @@ +[[Property:title|Release notes for EiffelStudio 6.6]] +[[Property:link_title|6.6]] +[[Property:weight|-13]] +[[Property:uuid|16d03e3f-d0ff-c56e-6e77-232087ec3bfb]] +==Graphical environment== + +===What's new=== +* Added the parent clauses of a class in the "Features tool" making it easier to navigate/edit parent classes. + +===Improvements=== +* Double clicking in the editor tab ribbon will create a new tab of the editor. +* Pressing "Ctrl+Enter" while typing a class name in the address bar will open the class or feature in a new tab of the editor. +* Pressing the middle mouse button on a tab will now close that tab. +* Added shortcuts for "Run workbench system" and "Run finalized system" + +===Changes=== +* The experimental mode available in 6.5 and earlier version has become the default mode. To have access to the default mode of 6.5, one has to use the compatible version. It can be accessed on Windows via the Start menu shortcut or by using "-compat" on the command line. +* Gobo had its ECF removed and replaced by several corresponding to sub-libraries of the Gobo framework. This change was already present in 6.4 and 6.5 under the experimental mode. To upgrade, you need to adapt your project configuration file to use the right sub-library of the Gobo framework. +* The libraries (formerly the experimental mode of 6.4 and 6.5) contains some breaking changes to the compatible libraries. Those breaking changes were already part of 6.4 and 6.5. It affects the following classes: ARRAY, ARRAYED_LIST, HASH_TABLE, SPECIAL and TO_SPECIAL. It is possible to adjust your code so that a single version compiles against both sets of libraries. See below under EiffelBase how to adapt your code to those breaking changes. + +===Bug fixes=== +* Fixed an issue in which the error tooltip would keep flashing when the cursor is outside the EiffelStudio environment. +* Fixed an issue while searching text in the implementers or descendants view it would not scroll to the found text. +* Fixed an issue with the Error List pane in which the Error List would come up blank on error if it had been auto-hidden when EiffelStudio started. + +==Compiler== +* Click [[Major changes between ISE Eiffel 6.5 and ISE Eiffel 6.6|here]] for the compiler release notes. + +== AutoTest== +* Changed AutoTest Tool to store testing results permanently, and added the ability to export results to a text file. +* Added tool for displaying the result details of a single test execution. +* Added tool for comparing the current testing results to a previously exported set of results, highlighting tests for which the latest execution revealed a different result. +* Improved wizard/preferences dialog for creating and executing tests, also allowing the user to skip the wizard and create new tests from default settings. + +==Debugger== +===Graphical environment=== +* Now, only one breakpoint dialog is opened on the same breakpoint (avoid conflict). +* Moving a breakpoint within the same routine is now done using Drag & Dropping the breakable slot icon (red bullet). +* Object Viewer selector no longer auto-selects XML Viewer when the string looks like XML content. +* Added a context menu entry to "unset" an environment variable in the "Execution parameters" tool. +* Fixed issue with remaining popup window for grid's cell. +* Fixed regression "Keep Assertions Checking" settings for expression evaluation. +* Added an option in the "Edit Expression" dialog to show the "full error message" (i.e: include the exception trace) when an exception occurs during expression evaluation. By default, now only the short description is shown (to improve performance), but the full error message is available upon request. +* Added the capability of copying to the clipboard the text representation of selected call stack elements (from the call stack tool) using Ctrl+C or Ctrl+Ins (this also includes representations of local+arguments) + +===Debugger engine=== +* Fixed an issue in which EiffelStudio could hang when inspecting threads other than the current stopped one on platforms where thread identifiers are larger than 32-bit (e.g. Linux). +* Fixed issue related to setting conditional breakpoint resulting in unconditional breakpoint. +* Fixed issue in which execution is stopped in melted invariant. +* Added support for new [[ET: Other Mechanisms#Adjusting once semantics with "once keys"|once per object]]. + +==EiffelBuild== +* Click [[EiffelBuild Version History|here]] for the EiffelBuild release notes. + +==Libraries== + +===EiffelBase=== +* Added ability to traverse most containers in EiffelBase using the new iteration (across) [[ET: Instructions#A closer look at the iteration form| form of the loop construct]]. +* Added a new feature trim to the RESIZABLE class and its decendants to allow for minimizing the allocated storage. +* Modified ARRAYED_QUEUE to avoid using an extra slot that did not keep any value and was used only for implementation purposes. +* Added support for correct mismatch in the SED serialization cluster. +* Fixed ARRAY2 so that it can be used in void-safe mode too. Improved ARRAY2 resizing efficiency. +* Changed the display of REAL/DOUBLE fields to show REAL_32 or REAL_64. +* Changed the display of NaN/-Infinity/Infinity for real numbers so that it is the same on all our supported platforms. +* Adaptation of ARRAY, ARRAYED_LIST, HASH_TABLE and SPECIAL from the 6.5 to 6.6: +** {ARRAY}.make_from_special had its signature changed and only take a SPECIAL argument and the created array would have a range from 1 to the number of elements in the SPECIAL +** ARRAY: Some preconditions have been added for void-safety. In non-void-safe mode they are equivalent to the previous ARRAY behavior. +** {ARRAY}.auto_resize: a private routine has been removed. +** {ARRAYED_LIST}.count and {ARRAYED_LIST}.area are not an attribute anymore +** ARRAYED_LIST does not conform to ARRAY. One has to use {ARRAYED_LIST}.to_array to convert it to an ARRAY. +** HASH_TABLE internals have been changed so that order of traversal will be different from what it used to be. +** The non-void safe routine {SPECIAL}.make has been removed. Instead one has to use either {SPECIAL}.make_empty (which is not available in compatible mode) or {SPECIAL}.make_filled (which is available in both) +** To reflect the change in SPECIAL, TO_SPECIAL was also modified and `make_area` was replaced by `make_empty_area`. Again to have compatible code between both mode use `make_filled_area` instead. + +===EiffelThread=== +* Made the THREAD class thread-safe which prevents using the same object to launch a new thread. Now there is a precondition is_launchable and a status report is_last_launch_successful to help in determining whether a thread was actually launched. + +===EiffelNet=== +* Fixed precondition violation in {ARRAY}.force when compiling EiffelNet in void-safe mode. +* Changed internal of MEDIUM_POLLER to use HASH_TABLE, as a consequence the queries read_command_list, write_command_list and exception_command_list are now obsolete and should not be used. + +===EiffelVision2=== +* [[Revisions and Bug Fixes|Click here for EiffelVision2 release notes.]] + +[[EiffelStudio release notes|Click here to check out what was new in other versions]] + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-reference/eiffelstudio-release-notes/eiffelstudio-6-release-notes/release-notes-eiffelstudio-67.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-reference/eiffelstudio-release-notes/eiffelstudio-6-release-notes/release-notes-eiffelstudio-67.wiki new file mode 100644 index 00000000..5ad4bd0e --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-reference/eiffelstudio-release-notes/eiffelstudio-6-release-notes/release-notes-eiffelstudio-67.wiki @@ -0,0 +1,59 @@ +[[Property:title|Release notes for EiffelStudio 6.7]] +[[Property:link_title|6.7]] +[[Property:weight|-14]] +[[Property:uuid|17f0ad0d-6a8e-942c-37be-53466db120d5]] +==Graphical environment== + +===What's new=== +===Improvements=== +* Allows filtering of C compiler warnings in the Error and Warning tool. +* Accepts "license.lic" and "licence.lic" as a way to perform automatic licensing during saving. +* Added filter functionality to the "Add Library" dialog. +* Added a new XML (lite) library which is void-safe without Unicode support. + +===Changes=== + +===Bug fixes=== +* Fixed some formatting issues when using the new loop form using across. +* Fixed the saving of the diagrams to PNG. +* Fixed bug#16831: Picking and dropping class from Features window into Editor tab clears Features window. +* Fixed issue with `libraries.cfg` files used to know where to look for libraries (the trouble was only on Windows) + +==Compiler== +* Click [[Major changes between ISE Eiffel 6.6 and ISE Eiffel 6.7|here]] for the compiler release notes. + +==Debugger== +===Graphical environment=== +* More compact "Execution" (debugger) menu +* Now changing the catcall detection from the exception handling dialog has immediate impact (previously the user had to interrupt and continue the execution to see the impact) +* It is now possible to open the exception dialog to visualize the CAT call warning exception at the debugger level. +* Minor change, now Ctrl+Alt+C (or +Ins) will copy into clipboard the '''selected stacks''' '''without''' the (stack) values and Ctrl+C (or +Ins) will copy into clipboard the '''selected stacks''' '''with''' stack values (local and arguments) + +===Debugger engine=== +*Now handle correctly manifest string and string_32 in debugger (expression evaluation) +*Improved stepping in MT debugging session. Now the debugger stays in the same thread (instead of jumping from a thread to another without any coherence). +*Fixed void-safety issue, when trying to evaluate `Result` in watch tool (previously, it was reporting VEVI ...) + +==EiffelBuild== +* Click [[EiffelBuild Version History|here]] for the EiffelBuild release notes. + +==Libraries== + +===EiffelBase=== +* ARRAY: +** Made {ARRAY}.make and {ARRAY}.conservative_resize obsolete as they are not void safe. Alternative recommendation is to use {ARRAY}.make_empty, {ARRAY}.make_filled or {ARRAY}.conservative_resize_with_default. +** Added {ARRAY}.rebase that would help creating an empty array with a given `lower`. +** BOUNDED_QUEUE and BOUNDED_STACK have been rewritten to use the same implementation of ARRAYED_QUEUE and ARRAYED_STACK, the only difference is that `extendible` is defined to be False. The `correct_mismatch` feature has been updated to ensure retrieval. +* FORMAT_DOUBLE: +** Fixed eweasel test#lib036 in FORMAT_DOUBLE where `pad_fraction` did not process properly when one decided to not show the trailing zeros and there were only zeros after the decimal point. +** Fixed the post-condition of {FORMAT_DOUBLE}.pad_fraction to reflect that the count is set to `decimals` but only when one shows the trailing zeros. +* Added WEAK_REFERENCE to allow weak references in an Eiffel system. This supersedes the IDENTIFIED class which made it necessary to change one's code to allow weak referencing. Currently the class is only implemented for classic Eiffel; it is not available when compiling for .NET. +* Added new Eiffel tracing facility classes TRACING_HANDLER and TRACING_SETTING which let you capture some information about the current execution via callbacks. +* Fixed eweasel test#list010 with twinning and deep_twinning of a FIXED_LIST that would reset `capacity` to `count`. +* Added {TYPE}.is_expanded to find out if a type is expanded or not. + +===EiffelVision2=== +* [[Revisions and Bug Fixes|Click here for EiffelVision2 release notes.]] + +[[EiffelStudio release notes|Click here to check out what was new in other versions]] + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-reference/eiffelstudio-release-notes/eiffelstudio-6-release-notes/release-notes-eiffelstudio-68.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-reference/eiffelstudio-release-notes/eiffelstudio-6-release-notes/release-notes-eiffelstudio-68.wiki new file mode 100644 index 00000000..04a86b77 --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-reference/eiffelstudio-release-notes/eiffelstudio-6-release-notes/release-notes-eiffelstudio-68.wiki @@ -0,0 +1,56 @@ +[[Property:title|Release notes for EiffelStudio 6.8]] +[[Property:link_title|6.8]] +[[Property:weight|-15]] +[[Property:uuid|5b3df521-34a8-27a2-4261-830973a62673]] +==Graphical environment== + +===What's new=== +===Improvements=== +* Improved dialog that adds a new class to the system: +** Changed button label to be more explicit about its action +** Removed detachable status when it is not used +** Removed unnecessary frame boxes +** Simplified code that opens the dialog. +* Improved keyboard navigation in the Info tool. +* Avoided class counter increment in automatically generated class name if class addition is cancelled. +* Set file name of current class to the Save File As dialog. + +===Changes=== + +===Bug fixes=== +* Corrected output of the iteration (across) form of the [[ET: Instructions#Loop|loop construct]] in clickable views. +* Fixed feature call on void target when reopening a project with diagram tool that contains cluster legend. +* Fixed a bug in the Info tool: when deleting an EIS entry, selecting "No" did not actually cancel the deletion. + +==Compiler== +* Click [[Major changes between ISE Eiffel 6.7 and ISE Eiffel 6.8|here]] for the compiler release notes. + +==Debugger== +===Graphical environment=== +* It is now possible to [[Detach application|detach the debugger]] from the application (without killing the application). +* It is now possible to [[Attach application|attach the debugger]] to associated eiffel application launched outside EiffelStudio +** The application has to be launched in a specific way to wait for the debugger, that is, either +*** by setting ISE_DBG_PORTNUM environment variable to a specific port number, or +*** by calling {RT_DEBUGGER}.rt_workbench_wait_for_debugger (a_port_number) from the program itself +** Then with EiffelStudio, menu Execution->Attach Debuggee and provide the same port number. +** At this point EiffelStudio is able to debug the application + +==EiffelBuild== +* Click [[EiffelBuild Version History|here]] for the EiffelBuild release notes. + +==Libraries== + +===EiffelBase=== +* Minimized interface of ITERATION_CURSOR to simplify crafting cursors for iteration form of a loop on non-container classes, for example, on externally-driven input like files, sockets, etc. + +===EiffelVision2=== +* [[Revisions and Bug Fixes|Click here for EiffelVision2 release notes.]] + +===EiffelStore=== +* Various bug fixes. +* Extended types supported by EiffelStore, especially STRING_32 for Unicode string types. +* Improved memory management in EiffelStore, ODBC implementation. + + +[[EiffelStudio release notes|Click here to check out what was new in other versions]] + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-reference/eiffelstudio-release-notes/eiffelstudio-7-release-notes/index.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-reference/eiffelstudio-release-notes/eiffelstudio-7-release-notes/index.wiki new file mode 100644 index 00000000..8419b3ff --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-reference/eiffelstudio-release-notes/eiffelstudio-7-release-notes/index.wiki @@ -0,0 +1,3 @@ +[[Property:uuid|2775C71F-E609-42C7-9667-24B02BCBE1FB]] +[[Property:weight|13]] +[[Property:title|7.x]] diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-reference/eiffelstudio-release-notes/eiffelstudio-7-release-notes/release-notes-eiffelstudio-70.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-reference/eiffelstudio-release-notes/eiffelstudio-7-release-notes/release-notes-eiffelstudio-70.wiki new file mode 100644 index 00000000..8d5c3490 --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-reference/eiffelstudio-release-notes/eiffelstudio-7-release-notes/release-notes-eiffelstudio-70.wiki @@ -0,0 +1,84 @@ +[[Property:title|Release notes for EiffelStudio 7.0]] +[[Property:link_title|7.0]] +[[Property:weight|13]] +[[Property:uuid|302c6dc1-3ed0-cc25-0ec8-851ead074caf]] +==Graphical environment== + +===What's new=== +* [[EiffelRibbon]]: a Windows specific library and tool to add a ribbon to your EiffelVision2 applications. +* Debian packages available for downloads. +* Added external contributions: Decimal library, Json parser, arbitrary precision mathematics, encryption (SHA1, MD5, x509, ...). +* Added previews of libraries: sqlite3, regular expression, ... +* Added a command line option "-tests" to run all associated Autotest tests from the command line. + +===Improvements=== +* Better integration with the latest Linux Desktop environments: Unity from Ubuntu and KDE 4.0. +* SCOOP speed improvements. +* Added support for .NET 4.0 runtime. + +===Changes=== +* BIT type is now obsolete. +* Location of precompiled libraries has been moved to a user specific directory that can be referenced via the $ISE_PRECOMP variable in your project configurations. This addresses some permission issues depending on how and under which user EiffelStudio was installed. + +===Bug fixes=== +* Fixed a display issue of Unicode characters when reporting an error. (bug#17661). +* Fixed a pick and drop issue where it could be confused (e.g. select ARRAY in editor, switch to clickable format, try to pick various elements, it would always pick BOOLEAN instead) (bug#17666). +* Fixed issue with pick and drop of a feature from an override class whose position is further away than the original class would not scroll to this feature (bug#17406). +* Fixed some issues of window positioning when using EiffelStudio with multiple monitors. +* Fixed a case where you could have 2 editor panes open on the same class. + +==Compiler== +* Click [[Major changes between ISE Eiffel 6.8 and ISE Eiffel 7.0|here]] for the compiler release notes. + +==Debugger== +=== .NET debugging === +* It is now possible to use the EiffelStudio debugger to debug Eiffel applications targeted to Microsoft .Net 4.0. +{{caution|Currently, to debug Eiffel targeted to Microsoft .Net 4.0, it is necessary to set the preference "debugger.dotnet.keep_stepping_info_dotnet_feature" to "False" in order to avoid problems when using the debugger's "Step into" command.}} + +===Graphical environment=== +* Fixed a problem with missing tool content when an assertion violation was ignored. +* Instances of classes IMMUTABLE_STRING_* are now correctly displayed in the debugger's tools. +* Added a toolbar button for the "Attach" command. +* The exception trace is now included when watch evaluation fails due to an internal error. +* Fixed various issues in which the debugger is unable to retrieve information about an object, especially from the current object. +* Fixed various watch evaluation issues involving argument variables. + +===Developer changes=== +* The {DB_BREAKABLE_POINT_INFO}.text is no longer truncated, allowing the retention of the full line of Eiffel code. + +==EiffelBuild== +* Click [[EiffelBuild Version History|here]] for the EiffelBuild release notes. + +==Libraries== + +===EiffelBase=== +* Prevented creation of instances of PROCEDURE, FUNCTION, and PREDICATE using a creation instruction. An agent has to be created via the agent expression provided at the language level. +* Fixed a potential reporting of version mismatch when there is a mismatch but actually no version changes. +* Added TABLE_ITERATOR and TABLE_ITERATION_CURSOR to provide a common way for TABLE like datastructure to iterate over using the new across loop. +* Improved speed of `replace_substring_all` when replacing a smaller string by a larger one. +* Added support for string searches of a STRING_32 string (previously it was limited to STRING_8). +* Fixed {IMMUTABLE_STRING_XX}.shared_substring which would not be properly processed by many string operations (e.g. item, item_code, code, ...). +* Changed the behavior of {STRING_XX}.twin to create a new string where the capacity is set to the count of the twinned strings and not to its capacity. In scenarios where a large buffer is used but a frequent twin is used it has a big impact on speed and memory usage. +* Fixed an issue with {FILE}.read_to_string which would not change the hash_code of the string given as argument. +* Improved speed of HASH_TABLE lookups. +* Added {POINTER}.is_default_pointer. +* Excluded class BIT_REF from the default setup. In order to use type BIT one has to define a variable USE_BIT. +* Made {LINKED_STACK}.duplicate void-safe, made a postcondition in {INTERVAL}.intersection void-safe. + +===EiffelVision2=== +* [[Revisions and Bug Fixes|Click here for EiffelVision2 release notes.]] + +===EiffelStore=== +* Added support for INTEGER_xx and NATURAL_xx datatypes. +* Added support for transactions in the MySQL handle. +* Various speed improvements for SQL queries. +* Added support for multiple database connections. +* Added support for immutable and unicode strings. +* Added support for GUID type. +* Added support of DECIMAL type. + +===Argument parser=== +* Made feature {ARGUMENT_BASE_PARSER}.copyright deferred. + +[[EiffelStudio release notes|Click here to check out what was new in other versions]] + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-reference/eiffelstudio-release-notes/eiffelstudio-7-release-notes/release-notes-eiffelstudio-71.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-reference/eiffelstudio-release-notes/eiffelstudio-7-release-notes/release-notes-eiffelstudio-71.wiki new file mode 100644 index 00000000..d81693bc --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-reference/eiffelstudio-release-notes/eiffelstudio-7-release-notes/release-notes-eiffelstudio-71.wiki @@ -0,0 +1,113 @@ +[[Property:title|Release notes for EiffelStudio 7.1]] +[[Property:link_title|7.1]] +[[Property:weight|12]] +[[Property:uuid|551e30c1-395c-27cb-e81f-d57204e68cc5]] +==Graphical environment== + +===What's new=== +* New SCOOP processor garbage collection which now lets you create more than 1500 processors during one execution. There is still a limit on the number of concurrent processors you might have. +* Added the Eiffel Web Framework contribution to build web applications or services in Eiffel. +* Added support for specifying C compiler flags and linker flags. +* Preview of GTK3 support which includes a HTML5 back-end for EiffelVision applications. +* Added support for EIFFEL_LIBRARY environment variable, if set and ISE_LIBRARY is not set by the current user, the former will be used to locate libraries. +* Info tool: +** Added a new Add button and Go To button. Rearranged the position of Delete button. +** Added a new built-in variable SYSTEM_PATH that refers to the location of system in which current entry is written. +** Added new contextual menu "Info" and sub menus Add Info to and Copy URI from. +** Implemented "DOC" protocol, supporting "bookmark" parameter, as long as Word is installed and available. +** Synchronize stones into Into Tool when clicking "Synchronize Context Tool" +** Improved acceptance of stones in the tool. +** Remember selected item when the tree is rebuilt (for recompilation and so on) +** Added a button to choose a file from a dialog for "Source". +** Added a dropdown list of choices for protocols. +** Changed names and sequence of columns as following: Target Source Parameters Protocol Name Tags Override +** Drew signs on icons to show there is information related to a tree node. +** In addition to "Unnamed" as default name, put "URI" as default protocol and http://www.yourwebsite.com as default Source when creating a new entry. +** Added completion list for available variables in Source. + +===Improvements=== +* Better copy/paste of code to avoid useless reformatting after copying and pasting a block of text. The smart behavior is available via Ctrl+V or Shift+Ins. If the new behavior is not adequate, Ctrl+Shift+V will paste as is. +* Better formatting of Eiffel source code when using the pretty printer. +* Better performance of SCOOP runtime for certain types of concurrent calls. +* Printing in postscript mode now allowed on Unix (previously, printing always defaulted to RTF); added `use_postscript` preference. +* Take into account mice with high resolution wheels. +* Avoid flashing when completion window is updated at each keystroke. +* Avoid resizing the grid all the time in Info tool when grid items are recreated for sorting, or other operations. +* Avoid adding empty attributes in code like EIS: "name=" when editing EIS entries. + +===Changes=== +* Removed addition of .NET targets in our project configuration templates to make it easier on new users to compile a project out of the box. + +===Bug fixes=== +* Fixed support of non-ASCII keyboard characters on Unix platforms. +* Fixed issue with automatically generated tests which included tests that should have been excluded because they represented invalid tests (e.g. precondition failures). +* Fixed issue where EiffelStudio would fail while trying to generate tests for a generic type whose generic derivation doesn't exist in the system. +* Fixed a runtime issue when testing automatically generated tests for a void-safe program, they would always fail instead of passing (when they should be passing). +* Fixed a failure of EiffelStudio when trying to display the help of a compiler error. +* Fixed disappearance of dashed pick and drop lines on Windows. +* Fixed an issue where trying to perform a diff inside the console tool would crash EiffelStudio. +* Fixed a bug in EIS tool, when target was changed from class to feature or back, the column "Override" was not updated correctly. + +==Compiler== +* Click [[Major changes between ISE Eiffel 7.0 and ISE Eiffel 7.1|here]] for the compiler release notes. + +==Debugger== +===Graphical environment=== +* Improved speed for multiple rows selection in watch tool. +* Disable "ignore breakpoints" when launching debug session from "autotest" tool, or from execution parameters dialog. +* Fixed a "Call on Void target" due to missing dynamic type information (Grid item crash in debugger). +* Allowed evaluation of expressions which would not be valid if void-safety rules were applied (for example using a local that is detachable but the expression does not tell if at the evaluation time the local is attached or not). + +==EiffelBuild== +* Click [[EiffelBuild Version History|here]] for the EiffelBuild release notes. + +==Libraries== + +===EiffelBase=== +* Fixed a bug with {ARRAY}.force when the new lower index is less than the old lower index - count. +* Fixed a bug with {ARRAY}.force where if the items had to move, the newly allocated area was not reset. +* Corrected precondition of {ARRAY}.force that did not allow storing elements at existing indexes. +* Added {PLATFORM}.is_scoop_capable to find out if a system is compiled using a SCOOP capable runtime. +* Added ability to create a local string using a separate string. +* Moved most of the queries of strings descendants (e.g. is_real, is_integer, ...) to class READABLE_STRING_GENERAL to make it easier to handle all the various kinds of strings. +* Added {HASH_TABLE}.disjoint to find out if 2 tables have some common elements or not based on the key comparison criteria. +* Made explicit that the `area` is shared between an ARRAY and an ARRAYED_LIST created via conversion. +* Fixed improper implementation of `copy` for UNIX_FILE_INFO and BOOL_STRING which caused for the former a sharing of some FILE specific information. +* Fixed {STRING_32}.left_adjust that did not work properly when the string contained only white spaces. +* Fixed an issue with {FILE}.exists on Windows 32-bit when files are larger than 2GB. It only occurs with the latest version of the Microsoft C++ compiler (VS2010 or later). + +===EiffelStore=== +* Added support for XML data in ODBC. +* Fixed an issue with retrieving blob of null-size. +* Added ability to connect to several databases at once for the same database handle. +* Added ability to connect to an ODBC database using a connection string. +* Improved support for MySQL. +* Added query to find out how many rows have been affected by the last query. +* Made sure that errors are properly propagated when calling {DATABASE_MANAGER}.execute_query_without_commit. +* Properly handled {DB_CHANGE}.reset. +* Improved SQL string escaping. Fixed bug escaping ''' for ODBC. +* Added capability to enable multi-statements execution for MySQL. + +===EiffelThread=== +* Breaking change in class THREAD, descendants should now call {THREAD}.make in order to initialize threads properly. This change was required to have a project using SCOOP be able to use libraries that are only aware of multithreading. +* Fixed a memory corruption issue occurring when many threads are exiting at once, or that a child thread exits immediately after its parent but the parent is not yet finished in its termination. + +===EiffelTime=== +* Fixed improper parsing of 2 digit hours. + +===EiffelVision2=== +* [[Revisions and Bug Fixes|Click here for EiffelVision2 release notes.]] + +===Web Browser Library=== +* Fixed a C compilation issue when finalizing a project using this library. + +===WEL=== +* Added ability to print to a specific printer or the default printer without having to show the printer dialog. +* Added support for loading EMF files through WEL_GDIP_METAFILE. +* Fixed an issue with WEL_DISK_SPACE that was not working in 64-bit mode. The fix implies a breaking change in that now a NATURAL_64 is returned instead of an INTEGER_32. +* Added SCOOP support. + + + +[[EiffelStudio release notes|Click here to check out what was new in other versions]] + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-reference/eiffelstudio-release-notes/eiffelstudio-7-release-notes/release-notes-eiffelstudio-72.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-reference/eiffelstudio-release-notes/eiffelstudio-7-release-notes/release-notes-eiffelstudio-72.wiki new file mode 100644 index 00000000..609f94f8 --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-reference/eiffelstudio-release-notes/eiffelstudio-7-release-notes/release-notes-eiffelstudio-72.wiki @@ -0,0 +1,62 @@ +[[Property:title|Release notes for EiffelStudio 7.2]] +[[Property:link_title|7.2]] +[[Property:weight|11]] +[[Property:uuid|579e75a9-9e50-41ba-70e1-211a092d0f87]] +==Graphical environment== + +===What's new=== +* Added support for handling Unicode file names, environment variables, command line arguments and exception messages to your applications while preserving backward compatibility for existing code. + +===Improvements=== +* Usability improvements in the Eiffel Information System: +** Find elements in deeper levels of referenced libraries +** Try to locate links even if no system or cluster is specified +** Better error messages +* Allowed refactoring tool to rename a feature or a class by reusing an existing name. +* Added support of class text containing Unicode characters when prettifying code. + +===Changes=== +* To support Unicode file names a new class PATH was added, and most libraries using a string to represent a file name have been updated to also take a PATH instance as argument. + +===Bug fixes=== +* Fixed a crash during debugging that would cause an exception in {ES_OBJECTS_TOOL_PANEL}.real_update. +* Fixed a crash while trying to import preferences and no project was loaded yet. + +==Compiler== +* Click [[Major changes between ISE Eiffel 7.1 and ISE Eiffel 7.2|here]] for the compiler release notes. + +==Libraries== + +===EiffelBase=== +* Added new PATH class to represent a Unicode path. In addition it offers many features to compose or decompose a path in multiple components. +* STRING: +** Migrated many queries only found in STRING_8 or STRING_32 into parent class READABLE_STRING_GENERAL, for example: has, item, index_of, last_index_of, ... +** Added prepend_substring and append_substring for efficient insertion of substrings. +** Replaced commands tail and head (which have been obsolete since 2001) with queries creating a copy of the current string with characters removed at the beginning or at the end. +** Added caseless comparison of Unicode strings. +* Added new REPEATABLE class. +* Added is_first and is_last queries to iterators. +* Fixed bug#18272 where {MANAGED_POINTER}.copy did not properly set count and thus yielded a postcondition violation when duplicating an instance. +* Added new ARGUMENTS_32 class to handle Unicode arguments. +* Added new UTF_CONVERTER class to handle various Unicode encoding conversions. +* Changed definition of {DEBUG_OUTPUT}.debug_output to be READABLE_STRING_GENERAL, so that Unicode characters in the string representation of an object can be displayed in the EiffelStudio debugger. +* Fixed an issue with `incorrect_mismatch' when it was applied to a HASH_TABLE whose keys are expanded but do not have a default value: the retrieved HASH_TABLE had one more item than the original one. It should fix eweasel test#table013. + +===EiffelStore=== +* Added support for Unicode SQL queries. +* Added support for immutable strings. +* Fixed an issue where passing a DECIMAL as an argument of a procedure did not set the scale (thus storing 1.00 when 100.00 was expected). +* Added ability to perform a sequence of database select/update/delete as a transaction. +* Fixed some limitations on the length of columns, errors and warnings. + +===EiffelVision2=== +* [[Revisions and Bug Fixes|Click here for EiffelVision2 release notes.]] + +===WEL=== +* Added support for Unicode file names. +* Added support for properly handling UTF-16 surrogate pairs. +* Fixed a bug in WEL_FONT for the computation of the size of a string that could cause string access on an invalid index; and removed unused calculations. +* Fixed a bug in WEL_GDIP_METAFILE that would cause a C compilation error when compiled using GCC. + +[[EiffelStudio release notes|Click here to check out what was new in other versions]] + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-reference/eiffelstudio-release-notes/eiffelstudio-7-release-notes/release-notes-eiffelstudio-73.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-reference/eiffelstudio-release-notes/eiffelstudio-7-release-notes/release-notes-eiffelstudio-73.wiki new file mode 100644 index 00000000..63b60957 --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-reference/eiffelstudio-release-notes/eiffelstudio-7-release-notes/release-notes-eiffelstudio-73.wiki @@ -0,0 +1,56 @@ +[[Property:title|Release notes for EiffelStudio 7.3]] +[[Property:link_title|7.3]] +[[Property:weight|10]] +[[Property:uuid|8fd95935-df4c-22f6-56d3-b3ea559d0342]] +==Graphical environment== + +===What's new=== +* A [[change analysis]] for documents in the [[Eiffel Information System]] where one can be notified of which documents to update when a class is modified, and conversely whenever a document is modified which classes might need updating. +* EiffelStudio will now show you the contracts of a feature when completing code, letting you quickly find out the proper way to call it. +* When debugging, moving the mouse pointer over an expression will cause the debugger to evaluate the expression and display its computation result in a tooltip. + +===Improvements=== +* Used void-safety settings of a target to list libraries that are compatible with it and provided more details on their void-safety status in the dialog for adding libraries. + +===Changes=== +* In [[AutoTest]], tests will be executed under the location of the Eiffel configuration file (ECF) and not in the Testing subdirectory of the EIFGENs directory. + +===Bug fixes=== +* Fixed a memory corruption that would occur when you have multiple errors during a compilation and you are opening each error in its own tab editor: after opening 4 or 5 tabs, EiffelStudio could become unstable. +* Fixed a crash after saving a diagram as a PNG file. + +==Compiler== +* Click [[Major changes between ISE Eiffel 7.2 and ISE Eiffel 7.3|here]] for the compiler release notes. + +==Debugger== +===Graphical environment=== +* Added ability to evaluate expressions by simply hovering over the feature tool while debugging. + +==EiffelBuild== +* Click [[EiffelBuild Version History|here]] for the EiffelBuild release notes. + +==Libraries== + +===EiffelBase=== +* Updated TUPLE and depending classes to separate entities. +* Updated ROUTINE and descendants to be usable for agents with separate targets. +* Fixed a comparison bug with EQUALITY_TUPLE which actually would only compare the last elements. +* Made INTERNAL obsolete. It is now replaced by two sets of classes: a static introspection class and a dynamic one. The class that lets you examine the static content is REFLECTOR; most references to INTERNAL can easily be replaced by REFLECTOR. To inspect objects, you have a new set of classes starting with REFLECTED_OBJECT. This lets you inspect objects with copy semantics without actually causing a copy each time you access it, unlike what was happening before with INTERNAL. +* Fixed a reallocation bug in SED_MEMORY_READER_WRITER where if you retrieve a large chunk, we would not allocate enough memory. +* Added ability to store/retrieve expanded objects and objects with copy semantics with SED. +* Storables made using SED from version 6.6 or earlier of EiffelStudio not using the `is_for_fast_retrieval` setting won't be recoverable. + +===EiffelStore=== +* Do not remove trailing spaces for string content. +* Changed the type mapping for string objects to varchar instead of char at table allocation for ODBC. + +===EiffelVision2=== +* [[Revisions and Bug Fixes|Click here for EiffelVision2 release notes.]] + +===WEL=== +* Fixed a 64-bit truncation bug in the message dispatcher of WEL. +* Fixed a memory corruption that would occur when loading a 32-bit BMP image as a background image of a container in a 16-bit or lower display. +* Fixed an issue with WEL_CHOOSE_FOLDER_DIALOG where set_starting_path had no effect. + +[[EiffelStudio release notes|Click here to check out what was new in other versions]] + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-reference/eiffelstudio-release-notes/index.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-reference/eiffelstudio-release-notes/index.wiki new file mode 100644 index 00000000..383f3f85 --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-reference/eiffelstudio-release-notes/index.wiki @@ -0,0 +1,8 @@ +[[Property:title|EiffelStudio release notes]] +[[Property:link_title|Release Notes]] +[[Property:weight|-15]] +[[Property:uuid|E82AA751-6A14-4983-B9A3-9A7D1C7F9BB4]] + +Change-logs are available at [https://dev.eiffel.com/Category:Releases] . + + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-reference/eiffelstudio-release-notes/release-notes-eiffelstudio-1311.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-reference/eiffelstudio-release-notes/release-notes-eiffelstudio-1311.wiki new file mode 100644 index 00000000..ca606cee --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-reference/eiffelstudio-release-notes/release-notes-eiffelstudio-1311.wiki @@ -0,0 +1,77 @@ +[[Property:title|Release notes for EiffelStudio 13.11]] +[[Property:link_title|13.11]] +[[Property:weight|9]] +[[Property:uuid|6610b1df-9530-9850-d568-20f14d4eb044]] +==Graphical environment== + +===What's new=== +* Eiffel Information System links and other type of links are now clickable in the editor. +* Editor shows both the Unix style or Windows style for new lines. +* Added wrapper for the ZeroMQ messaging library. +* Added ABEL, an object persistent layer on top of in-memory or relational databases. +* Added support for Sun C compiler on Linux for RHEL, OL and Ubuntu 8.04. Other Linux distributions are not supported. + +===Improvements=== +* Improved debug tooltip for nested feature call evaluation. +* Improved completion window/tooltip positioning with respect to monitor coordinates and multiple displays. +* Improved command line behavior of running tests to automatically perform the necessary compilation steps to test compiled system. +* Completion and pick and drops will now work more reliably reliably after many edits. +* Added void-safe version of Gobo. Only arguments, test, tools and XML are not yet void-safe. + +===Changes=== +* We have changed our versioning scheme: we will use as the major revision the last 2 digits of the current year, here 13, and as minor the month of the release, here 11. Next release will therefore be 14.05. +* When a Unicode character as an ASCII equivalent we will not silently convert it to the ASCII equivalent. + +===Bug fixes=== +* Fixed "Evaluator Died" error when running tests in AutoTest when using certain combinations of root class and creation procedure. +* Fixed bug#18563: Supported renaming of features used in qualified anchored types when refactoring code. +* Fixed bug#16960: Fixed an exception when showing an inherited class invariant with qualified anchored types. +* Fixed bug#18606: When completing some code you can see that the entries are shifting by one pixel. It is only visible via remote desktop or when desktop composition is disabled. +* Fixed bug#18614: Moving text containing Unicode characters in the editor will lose the Unicode characters. +* Fixed bug#18611: Preventing an EiffelStudio hang when browsing ECF in the group tool when ECF refers to each other recursively. +* Fixed bug#18679: Clicking locate button in the Eiffel Information System tool when editor is empty would crash EiffelStudio. + +==Compiler== +* Click [[Major changes between ISE Eiffel 7.3 and ISE Eiffel 13.11|here]] for the compiler release notes. + +==Debugger== +N/A + +==EiffelBuild== +* Click [[EiffelBuild Version History|here]] for the EiffelBuild release notes. + +==Libraries== + +===EiffelBase=== +* Added parenthesis aliases for PROCEDURE.call and FUNCTION.item so that the calls to agents foo.call (1, 2, 3) and x := bar.item ("qux") can be replaced with foo (1, 2, 3) and x := bar ("qux"). +* Made TUPLE an iterable structure. +* Added {TUPLE}.plus which will concatenate 2 tuples. +* Fixed typo in {TUPLE}.is_uniform_character_32 +* Added features {TYPE}.is_conforming_to and {TYPE}.is_strictly_conforming_to as implementations of the comparison queries from PART_COMPARABLE to support partial order on type objects (rev#92913). +* Added functions {TUPLE}.new_tuple_from_special and {TUPLE}.new_tuple_from_tuple to create a tuple of a specified type filled with given values (rev#92917). +* Added features {ROUTINE}.flexible_call and {FUNCTION}.flexible_item that accept argument tuples whose type should not exactly match the type of the routine as soon as the types of arguments match (rev#92918). +* Marked {ROUTINE}.empty_operands as obsolete to be ready for removal in the future as non-void-safe (rev#92918). +* In HASH_TABLE, in the event of a mismatch, it is possible that the value of `control` was invalid (see bug#18670) so we reset it to 0. +* Introspection changes in OBJECT_GRAPH_TRAVERSABLE: +**Rewrote traverse to fix an issue with objects with expanded fields where we would not recurse into them. Added support for SPECIAL of expanded as well. We still have restrictions for TUPLE with expanded for which a copy be done. +** Added new callbacks on_processing_object_action and on_processing_reference_action each time a new object is traversed, that help building a graph of objects. +** Added has_failed to find if the traversal succeeded or not. +** Added the ability to trigger or not an exception when a copy of an expanded object is done when we do not want any. Also we let user choose if exceptions will be raised to callers. + +===EiffelVision2=== +* [[Revisions and Bug Fixes|Click here for EiffelVision2 release notes.]] + +===Eiffel Editor === +* Stop translating %R%N into %N on input, we now keep the original text to ensure positioning information can be easily converted by code reading text files. +* Draw a symbol for new lines when formatting marks are displayed: "¯" is used for Unix style new line and "¬" is used for Windows style new line. + +===Web Browser=== +* Added is_browser_usable to know if the browser library is available. +* Simplified compilation of unix side of the library to load the webkit shared library at runtime without requiring it at compile time. + +===XML=== +* Fixed XML cases where we have or ... take into account the attribute `att` but report missing value for attribute `att`. +* Add report_unsupported_bom_value routine to report unsupported BOM value error. + +[[EiffelStudio release notes|Click here to check out what was new in other versions]] + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-reference/eiffelstudio-release-notes/release-notes-eiffelstudio-1405.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-reference/eiffelstudio-release-notes/release-notes-eiffelstudio-1405.wiki new file mode 100644 index 00000000..f93320f3 --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-reference/eiffelstudio-release-notes/release-notes-eiffelstudio-1405.wiki @@ -0,0 +1,98 @@ +[[Property:title|Release notes for EiffelStudio 14.05]] +[[Property:link_title|14.05]] +[[Property:weight|8]] +[[Property:uuid|f82eb6d2-c4ee-7243-7295-80dcdc584db7]] +==Graphical environment== + +===What's new=== +* ''' [[Eiffel Inspector]]''': A static analysis tool to help you maintain a high code quality. Currently there are 35 rules that can detect coding style, performance, or runtime issues. +* '''Automatic Fixing''': EiffelStudio can fix some class of errors automatically. Currently we fix unused local variables and missing types to the declaration of local variables. +* Added support for SSL to EiffelNet. + +===Improvements=== +* Made sure to show the groups content very early in the compilation process. +* Reduced size of project file in EIFGENs directory to speed up loading and saving of Eiffel projects after each compilation. +* Better handling of multiple monitor to ensure EiffelStudio is opened on the same screen as it was at last launch. +* AutoTest: Made it possible to run test cases outside of the AutoTest framework by simply calling them from a normal class. +* compile_all: Made it easier to compile a project for the various platforms we support. This is done by using the new '''-platform''' option where a platform name can be either ''unix'', ''windows'', ''macintosh'', or ''vxworks''. If you suffix the platform name with '''!''' it will only compile projects that are sets for this platform. If a project specify a platform and the '''-platform''' has been set and is different, the project will be ignored. + +===Changes=== +* Support for .ACE and .EPR files have been dropped from EiffelStudio. A tool '''ace2ecf''' is now available to convert .ACE to .ECF if needed. +* AutoTest: EiffelStudio will never saved generated test classes in the EIFGENs directory, user will have to specify a directory. This is to avoid losing tests after deleting an EIFGENs directory. +* New created projects are set to the complete void-safety level. + +===Bug fixes=== +* Fixed slow formatting of classes/features after editing the corresponding class. +* Made sure to show the feature comment when showing the contracts during code completion. +* Fixed improper display of conditions in task and external nodes of the Eiffel Project Settings dialog. +* Fixed an issue with preferences where setting them to a value, you will never be able to set it back to its default value. +* Fixed an editor issue where saving a class would force a refresh of the editor instead of just saving. +* Fixed an editor where copy/pasting code containing new lines with some leading tabs, the cursor would be improperly positioned after pasting. +* Fixed crash when searching for a feature while the editor hasn't finished loading (bug#18792, bug#18501, and bug#17626) +* Fixed wrong newline characters on Windows when creating a new class from our templates. +* Fixed the "Evaluator Died" error when running AutoTest on Unix systems (bug#18078). +* Prevented a crash when trying to run AutoTest and no executable is present (e.g. case of compiling a project as a library instead of as an application) (bug#18838). +* Fixed crash when you start running a test that was just renamed it (bug#18686). + +==Compiler== +* Click [[Major changes between ISE Eiffel 13.11 and ISE Eiffel 14.05|here]] for the compiler release notes. + +==Debugger== +N/A + +==EiffelBuild== +* Click [[EiffelBuild Version History|here]] for the EiffelBuild release notes. + +==Libraries== +===General=== +Most libraries do now compile in the highest level of void-safety except the following ones: +* docking +* editor +* edk +* graph +* memory_analyzer + +===Arguments === +* Changed the default display of help by showing first the option arguments and then the non-switched arguments. + +===Base=== +* Added {READABLE_STRING_GENERAL}.is_whitespace and {READABLE_STRING_GENERAL}.is_substring_whitespace. +* Added epsilon and machine_epsilon queries as requested by users in REAL_32 and REAL_64. +* Added missing min_value and max_value from the .NET version of REAL_32 and REAL_64. +* Removed obsolete feature {TUPLE}.make. +* Fixed {FILE_UTILITIES}.files_end_with to respect the depth level specified in argument. +* Fixed issues with the handling of the Unicode escape character. If the escaped UTF-32 string contains the escape sequence and it is trying to escape something that could fit the UTF-16 or UTF-8 encoding, then we store the content as is. This is to avoid the case for UTF-16 where if you have: '''?61''' it would yield '''a''' after round-tripping. Now if the UTF-16 or UTF-8, contains the escape character, the resulting string would have it twice, which again preventing proper roundtriping. + +===Internationalization=== +* Removed get_locale and get_language from I18N_FILE_SCOPE_INFORMATION to use the Eiffel naming convention locale and language and also changed the types to be detachable. This requires updating callers to the new names and to also perform a check that the request yields an attached entity. + +===Regexp=== +* Renamed CHARACTER_SET and BYTE_CODE into PCRE_CHARACTER_SET and PCRE_BYTE_CODE to avoid name conflicts with libraries that have the same class names. + +===Ribbon=== +* Added ability to assign hot keys to ribbon elements. + +===Store=== +* Improved the behavior of storing binary data by not imposing the user to convert its binary stream to hexadecimal in the case of stored procedures and prepared statements. This is a breaking change as now it will store whatever you provide as is. For traditional SQL statements it remains the same and binary data needs to be converted. +* Better handling of conversion of REAL_32 and REAL_64 to decimal when the associated column is a decimal. +* Removed precondition is_allocatable, descriptor_available, or descriptor_is_available to many EiffelStore routines. If a descriptor cannot be allocated, the execution of the routine will fail and an error code and message will be reported. +* Fixed issue with ODBC when storing large strings when using a prepared statement or a stored procedure, only the first 4000 bytes would be stored. +* Fixed issue with ODBC when storing a string into a binary column of the database which would fail with a mismatch. +* Fixed issue when the length of a table or column name is more than 50 characters. +* Fixed issue with ODBC where a large ASCII data would have their first byte missing. +* Added support for handling NULL values in a database using ODBC when using a mapping in DB_SELECTION, DB_DYN_SELECTION, DB_CHANGE or DB_DYN_CHANGE. + +===Vision2=== +* [[Revisions and Bug Fixes|Click here for EiffelVision2 release notes.]] + +===WEL=== +* Optimized performance of WEL_RICH_EDIT_BUFFER_SAVER. +* Fixed issue in {WEL_STRING}.set_string_with_newline_conversion with Unicode characters above the 65535 range, the result of the conversion to UTF-16 requires more space and when you have to replace %N into %R%N we forgot to resize the content before inserting the %R%N characters. +* Fixed issue in {WEL_STRING}.set_string_with_newline_conversion where if the input string had only one character after the last %N, that character would be discarded. That is to say "%Na" would yield "%R%N" instead of "%R%Na" (bug#18783). +* Fixed incorrect signatures for the wrapping of PostMessage, GetCurrentProcessId and GetWindowThreadProcessID which do not return a pointer but an integer type. + +===XML=== +* Fixed XML parser when the input file is exactly the same size as the xml file input stream chunk size (default 4096 bytes). + +[[EiffelStudio release notes|Click here to check out what was new in other versions]] + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-reference/eiffelstudio-release-notes/release-notes-eiffelstudio-1501.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-reference/eiffelstudio-release-notes/release-notes-eiffelstudio-1501.wiki new file mode 100644 index 00000000..8f035a0d --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-reference/eiffelstudio-release-notes/release-notes-eiffelstudio-1501.wiki @@ -0,0 +1,8 @@ +[[Property:uuid|D8B8E272-0AA0-4050-BC9C-2D026E90320C]] +[[Property:title|Release notes for EiffelStudio 15.01]] +[[Property:link_title|15.01]] +[[Property:weight|7]] + +In Progress ... + +* In the meantime, please visit the [https://dev.eiffel.com/EiffelStudio_15.01_Releases 15.01 changelog]. diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-reference/eiffelstudio-release-notes/release-notes-eiffelstudio-1508.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-reference/eiffelstudio-release-notes/release-notes-eiffelstudio-1508.wiki new file mode 100644 index 00000000..66b164d5 --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-reference/eiffelstudio-release-notes/release-notes-eiffelstudio-1508.wiki @@ -0,0 +1,9 @@ +[[Property:uuid|840A8543-D111-4339-9232-43ABDC21C4D1]] +[[Property:title|Release notes for EiffelStudio 15.08]] +[[Property:link_title|15.08]] +[[Property:weight|6]] + +* See [[Release notes for EiffelStudio 15.12]]. + +* Please visit the [https://dev.eiffel.com/EiffelStudio_15.08_Releases 15.08 changelog]. + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-reference/error-list-tool.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-reference/error-list-tool.wiki new file mode 100644 index 00000000..7d66631b --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-reference/error-list-tool.wiki @@ -0,0 +1,74 @@ +[[Property:title|Error List Tool]] +[[Property:weight|-7]] +[[Property:uuid|62f36efa-1d3a-9e48-3a6a-7da40b7e2046]] +The Error List Tool is a general purpose tool for logging error and warning conditions raised when compiling or using other parts of the EiffelStudio interactive development environment. Optionally, the tool can aid in the process of fixing problems by filtering both errors and warnings. + + +==Accessing the Tool== + +The Error List Tool will be shown automatically at the end of a compilation if an error occurs during any part of the compilation, + +or it can be accessed via the EiffelStudio menu path: + +View --> Tools --> Error List + +or from the default shortcut key CTRL+ALT+E. + + +==Reading Errors and Warnings== + +There are numerous ways to gather information on the errors and warnings logged to the tool. Even when the tool is not shown directly, because it is displayed tabbed behind another tool or docked as a hidden slide-in tool on one of the EiffelStudio's bounding window edges, there's enough visible information to indicate how many errors and warnings were generated during the last compilation or in another processing task. + +By default, the tool's title (in the tab-docked tab or on the tool's title bar when visible) will read'' 'Error List'''. In its default state there are no errors or warnings. When performing a compilation resulting in the logging of any number of errors or warnings the tool title will be update to indicate the respective number of errors and warning as '''Error List (#Errors, #Warning)''' where '''#Errors''' indicates the number of logged errors and '''#Warnings''' indicates the number of logged warnings. When there are no errors or warnings the tool's title will be reset to the default title '''Error List'''. + +When the tool is visible, not only does the tab (if docked) and the title bar reflect the number of logged errors and warnings but the tool bar '''Errors''' and '''Warnings''' filter toggle buttons also reflect the number of respective logged errors and warnings. For more information on filtering error and warnings, see [[#filtering_errors_and_warnings|Filtering Errors and Warnings]] . + +===Reading Logged Error and Warning Reports=== + +When performing a task that produces errors and/or warning the tool will display a number of rows containing information on the logged errors and warnings. Error rows are indicated with the error icon ( [[Image:error]] ) and warnings with the exclamation icon ( [[Image:warning]] ). Both errors and warnings show a single-line, terse description of the offending issue. Error and warning entries can be expanded by clicking the adjacent (+) to reveal a verbose description and an indication on how possibly to fix the problem. You can also press RIGHT (right arrow) or + (plus) to expand a selected row. To collapse a row either click the (-), or press LEFT or - . + +Error can be automatically expanded to reveal the more verbose information immediately. Toggling the Expand Errors ( [[Image:expand-errors]] ) button will automatically expand or collapse when toggled on or off respectively. + +===Error and Warning Help=== + +If you are unsure exactly what the error or warning code means, then you can receive help by selecting the error and pressing the Error Info tool bar button ( [[Image:error-info]] ). Alternately [[Pick-and-drop mechanism|pick and drop]] may be used to pick the error code from the error or warning onto the Error Info button. + +==Filtering Errors and Warnings== + +There is no limit on the number of errors or warnings that can be shown in the tool. All the errors and warnings mean something and should be addressed. However, sometimes it is desirable to filter errors and warnings while you work through the process of fixing the causes of them. Also sometimes it is advantageous to set temporarily the level of warnings you receive without modifying the project configuration. + +There are two types of filtration, basic and fine-grained. Basic filtering can be applied to both warnings and errors. Fine-grained filtering applies only to warnings. + +Basic filtering of the errors and warnings can be achieved by toggling with tool bar '''Errors''' and/or '''Warnings''' button. Both are toggled on by default so all errors and warnings are displayed. Toggling either off will hide the error or warnings respectively. + +For warnings, it might be desirable to filter out specific warnings temporarily without modifying the project's configuration file. You can do this by using the Filter ( [[Image:filter]] ) tool bar button. Uncheck any warnings that you do not want to be shown in the tool. When warnings are being filtered, the Filter button is displayed with exclamation icon overlay ( [[Image:filter-active]] ) to indicate that some warnings may not appear in the tool because they are being filtered out. The fine-grained filter state is only effective during the current EiffelStudio project session. Anything more permanent should be done by changing the [[EiffelStudio: Project settings window|project settings]]. + +When performing any type of filtering, the error and warning count information is unaffected. This indicates that there can be more errors and warnings than are actually visible in the tool. + +==Navigating Errors and Warnings== + +There are multiple ways to navigate the logged errors and warnings in the Error List Tool and for some, it doesn't even require the tool to be in view or even opened at all. + +All navigation functions off of the currently selected logged error or warning. When the Error List tool is open and in view the most direct way to navigate between the errors and warnings is through the tool itself. There are four tool bar buttons designed for this purpose: +* Go to Next Error ( [[Image:next-error]] ) +* Go to Previous Error ( [[Image:previous-error]] ) +* Go to Next Warning ( [[Image:next-warning]] ) +* Go to Previous Warning ( [[Image:previous-warning]] ) + +These tool bar buttons are mirrored in the '''Project''' main menu. Those actions mirrored in the '''Project''' menu do not require the tool to be opened or be in view, providing a shortcut to their actual function. + +There are also a matching number of keyboard shortcuts that can be used with or without the Error List tool being in view; To go to the next error use CTRL+F8, To go to the previous error use CTRL+SHIFT+F8, to go to the next warning use CTRL+ALT+F8 and to go to the previous warning use CTRL+ALT+SHIFT+F8. + +In the event of no visible errors or warnings, the respective Next/Previous buttons and menu items will be unavailable. This is also effective when [[#filtering_errors_and_warnings|filtering errors and warnings]], as the unseen logged error and warnings are treated as if they had never been logged ensuring that, when navigating, the irrelevant errors and warnings are bypassed. + +When navigating between a logged error or warning the context where the error/warning occurred is shown. At anytime, double-left clicking on an error or warning will show the corresponding context to that logged error/warning. Pressing ENTER on the selected error or warning will also show the correspond context. + +The [[Pick-and-drop mechanism|pick and drop]] mechanism may also be used to navigate to any part of an error's or warning's context. Any colored text in the logged error/warning description is pickable, even the '''Position''' information. + +==Copying Errors and Warnings== + +From time to time it may be helpful to copy the information in one or more logger errors and/or warnings. To perform a copy of the information, select one or more logged errors and/or warning in the tool and press CTRL+C. The selected error and warning information will then be placed into the clipboard of the resident operating system. + + + + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-reference/formatted-information-about-compiled-classes-and-features/class-views/ancestors.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-reference/formatted-information-about-compiled-classes-and-features/class-views/ancestors.wiki new file mode 100644 index 00000000..d0b18131 --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-reference/formatted-information-about-compiled-classes-and-features/class-views/ancestors.wiki @@ -0,0 +1,13 @@ +[[Property:title|Ancestors]] +[[Property:weight|-9]] +[[Property:uuid|b30f3c56-dbeb-06ac-4775-30a5f1d56966]] +The ancestors view [[Image:class-ancestors-icon]] displays all the classes from which the current class inherits, directly or not, using a tree-like indented layout.
+It is available through the '''Class''' tab of the [[EiffelStudio window overview|context tool]]. + + +{{seealso|
+[[Descendants|Descendants]] }} + + + + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-reference/formatted-information-about-compiled-classes-and-features/class-views/attributes.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-reference/formatted-information-about-compiled-classes-and-features/class-views/attributes.wiki new file mode 100644 index 00000000..ca581155 --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-reference/formatted-information-about-compiled-classes-and-features/class-views/attributes.wiki @@ -0,0 +1,13 @@ +[[Property:title|Attributes]] +[[Property:weight|-5]] +[[Property:uuid|cbe3647a-ef50-3596-ccee-89d7c16c5d82]] +The attributes view [[Image:class-features-attribute-icon]] displays all the attributes of the current class, including inherited attributes.
+It is available through the '''Class''' tab of the [[EiffelStudio window overview|context tool]]. + + +{{seealso|
+[[Routines|Routines]] }} + + + + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-reference/formatted-information-about-compiled-classes-and-features/class-views/class-formatters-basic-text-view.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-reference/formatted-information-about-compiled-classes-and-features/class-views/class-formatters-basic-text-view.wiki new file mode 100644 index 00000000..8cfa450e --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-reference/formatted-information-about-compiled-classes-and-features/class-views/class-formatters-basic-text-view.wiki @@ -0,0 +1,21 @@ +[[Property:title|Class formatters: Basic text view]] +[[Property:weight|-14]] +[[Property:uuid|057df030-7dad-d0f6-7d13-c18021afa78b]] +Basic text view [[Image:view-editor-icon]] is the only editable view; this is why it is only available through the [[EiffelStudio Editor|editor]]. + + +[[Image:class-mini-format-bar]] + + +This is also the view selected by default when the editor is opened for the first time. +In this view, most of the development objects are [[Pick-and-drop mechanism|clickable]], except for special cases like assertions, anchored types, identifiers within a comment line... for which the [[Clickable view|clickable view]] might be needed. + +{{note|The generated text is not editable, but it is compilable. This view is not available to .NET classes which are imported through by means of an assembly. This is because the assembly '''.exe''' or '''.dll''' exposes only the interface methods and therefore is no implementation to display. Such classes may be viewed, in a clickable format using the Contract View or Interface View. }} + + +{{seealso|
+[[EiffelStudio Editor|Editor]] }} + + + + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-reference/formatted-information-about-compiled-classes-and-features/class-views/class-formatters-external-features.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-reference/formatted-information-about-compiled-classes-and-features/class-views/class-formatters-external-features.wiki new file mode 100644 index 00000000..a31d6ac7 --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-reference/formatted-information-about-compiled-classes-and-features/class-views/class-formatters-external-features.wiki @@ -0,0 +1,9 @@ +[[Property:title|Class formatters: External features]] +[[Property:weight|1]] +[[Property:uuid|a9f7327c-42dd-43fc-ea30-11c9482386e9]] +The external view [[Image:class-features-external-icon]] displays all the external features of the current class.
+It is available through the '''Class''' tab of the [[EiffelStudio window overview|context tool]]. + + + + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-reference/formatted-information-about-compiled-classes-and-features/class-views/class-formatters-flat-view.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-reference/formatted-information-about-compiled-classes-and-features/class-views/class-formatters-flat-view.wiki new file mode 100644 index 00000000..0ed562d5 --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-reference/formatted-information-about-compiled-classes-and-features/class-views/class-formatters-flat-view.wiki @@ -0,0 +1,18 @@ +[[Property:title|Class formatters: Flat view]] +[[Property:weight|-12]] +[[Property:uuid|14ad347a-db72-1194-346b-752e1cd0dc7d]] +The flat view [[Image:view-flat-icon]] displays all the features for the current class, i.e. including both written-in and inherited features; it is available either through the [[EiffelStudio Editor|editor]] or through the '''Class''' tab of the [[EiffelStudio window overview|context tool]]. This is also the only view where [[Breakpoints|breakpoints]] are displayed. + + +{{warning|For classes with many [[Ancestors|ancestors]], computation of the flat view may require a few seconds. }} + + +{{note|This view is not available to .NET classes which are imported through by means of an assembly. This is because the assembly '''.exe''' or '''.dll''' exposes only the interface methods and therefore is no implementation to display. Such classes may be viewed, in a clickable format using the Contract View or Interface View. }} + + +{{seealso|
+[[Flat Contract view|Flat Contract view]] }} + + + + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-reference/formatted-information-about-compiled-classes-and-features/class-views/clickable-view.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-reference/formatted-information-about-compiled-classes-and-features/class-views/clickable-view.wiki new file mode 100644 index 00000000..37e4d658 --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-reference/formatted-information-about-compiled-classes-and-features/class-views/clickable-view.wiki @@ -0,0 +1,10 @@ +[[Property:title|Clickable view]] +[[Property:weight|-13]] +[[Property:uuid|8ddd0d2a-d4db-b0b6-8ee1-63e205a53dcc]] +The clickable view [[Image:view-clickable-icon]] allows you to [[Pick-and-drop mechanism|pick]] every class or feature name in the class text and is available either through the [[EiffelStudio Editor|editor]] or through the '''Class''' tab of the [[EiffelStudio window overview|context tool]]. + +{{note|This view is not available to .NET classes which are imported through by means of an assembly. This is because the assembly '''.exe''' or '''.dll''' exposes only the interface methods and therefore is no implementation to display. Such classes may be viewed, in a clickable format using the Contract View or Interface View. }} + + + + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-reference/formatted-information-about-compiled-classes-and-features/class-views/clients.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-reference/formatted-information-about-compiled-classes-and-features/class-views/clients.wiki new file mode 100644 index 00000000..ece4afe4 --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-reference/formatted-information-about-compiled-classes-and-features/class-views/clients.wiki @@ -0,0 +1,14 @@ +[[Property:title|Clients]] +[[Property:weight|-7]] +[[Property:uuid|d5d21d9f-c88b-c1b3-d6fe-89de6487f29d]] +The clients view [[Image:class-clients-icon]] displays all the classes which are using features of the current class, and thus rely on its [[Flat Contract view|interface]].
+It is available through the '''Class''' tab of the [[EiffelStudio window overview|context tool]]. + + +{{seealso|
+[[Suppliers|Suppliers]]
+[[Feature formatters: Callers|Feature callers]] }} + + + + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-reference/formatted-information-about-compiled-classes-and-features/class-views/contract-view.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-reference/formatted-information-about-compiled-classes-and-features/class-views/contract-view.wiki new file mode 100644 index 00000000..de8da5be --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-reference/formatted-information-about-compiled-classes-and-features/class-views/contract-view.wiki @@ -0,0 +1,11 @@ +[[Property:title|Contract view]] +[[Property:weight|-11]] +[[Property:uuid|e8bbc475-d7f8-baa6-aba8-021c0e05c4b6]] +The contract view [[Image:view-contracts-icon]] displays the contracts of all written-in features of the current class. It is available either through the [[EiffelStudio Editor|editor]] or through the '''Class''' tab of the [[EiffelStudio window overview|context tool]]. + +{{seealso|
+[[Flat Contract view|Flat contract view]] }} + + + + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-reference/formatted-information-about-compiled-classes-and-features/class-views/creators.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-reference/formatted-information-about-compiled-classes-and-features/class-views/creators.wiki new file mode 100644 index 00000000..6e6feec9 --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-reference/formatted-information-about-compiled-classes-and-features/class-views/creators.wiki @@ -0,0 +1,9 @@ +[[Property:title|Creators]] +[[Property:weight|-2]] +[[Property:uuid|eb428ddf-d2dd-de8f-abc8-fb95970d92bd]] +The creators view [[Image:class-features-creator-icon]] displays all the creation procedure signatures of the current class.
+It is available through the '''Class''' tab of the [[EiffelStudio window overview|context tool]]. + + + + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-reference/formatted-information-about-compiled-classes-and-features/class-views/deferred-features.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-reference/formatted-information-about-compiled-classes-and-features/class-views/deferred-features.wiki new file mode 100644 index 00000000..b48aeec9 --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-reference/formatted-information-about-compiled-classes-and-features/class-views/deferred-features.wiki @@ -0,0 +1,9 @@ +[[Property:title|Deferred features]] +[[Property:weight|-1]] +[[Property:uuid|fd1bcb31-75a3-1bcb-9d4d-e9d006c5d851]] +The deferred view [[Image:class-features-deferred-icon]] displays all the deferred features of the current class.
+It is available through the '''Class''' tab of the [[EiffelStudio window overview|context tool]]. + + + + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-reference/formatted-information-about-compiled-classes-and-features/class-views/descendants.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-reference/formatted-information-about-compiled-classes-and-features/class-views/descendants.wiki new file mode 100644 index 00000000..7bdff883 --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-reference/formatted-information-about-compiled-classes-and-features/class-views/descendants.wiki @@ -0,0 +1,13 @@ +[[Property:title|Descendants]] +[[Property:weight|-8]] +[[Property:uuid|c3f44d3d-a3ea-9776-9626-1ecc090fd513]] +The descendants view [[Image:class-descendents-icon]] displays all the classes which inherit from the current class,directly or not, using a tree-like indented layout.
+It is available through the '''Class''' tab of the [[EiffelStudio window overview|context tool]]. + + +{{seealso|
+[[Ancestors|Ancestors]] }} + + + + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-reference/formatted-information-about-compiled-classes-and-features/class-views/exported-features.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-reference/formatted-information-about-compiled-classes-and-features/class-views/exported-features.wiki new file mode 100644 index 00000000..e93052b9 --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-reference/formatted-information-about-compiled-classes-and-features/class-views/exported-features.wiki @@ -0,0 +1,9 @@ +[[Property:title|Exported features]] +[[Property:weight|2]] +[[Property:uuid|af99ce57-a44d-6cfa-a933-89993e5d845c]] +The exported view [[Image:class-features-exported-icon]] displays all the features of the current class that all other classes may call.
+It is available through the '''Class''' tab of the [[EiffelStudio window overview|context tool]]. + + + + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-reference/formatted-information-about-compiled-classes-and-features/class-views/flat-contract-view.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-reference/formatted-information-about-compiled-classes-and-features/class-views/flat-contract-view.wiki new file mode 100644 index 00000000..b759e2ed --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-reference/formatted-information-about-compiled-classes-and-features/class-views/flat-contract-view.wiki @@ -0,0 +1,16 @@ +[[Property:title|Flat Contract view]] +[[Property:weight|-10]] +[[Property:uuid|dbbbb655-aa38-849f-62c5-e1bda6f83285]] +The Flat Contract view [[Image:view-flat-contracts-icon]] displays the contracts of all written-in and inherited features of the current class. It is available either through the [[EiffelStudio Editor|editor]] or through the '''Class''' tab of the [[EiffelStudio window overview|context tool]]. + + +{{warning|For classes with many [[Ancestors|ancestors]], computation of the Flat Contract view may require a few seconds. }} + + +{{seealso|
+[[Class formatters: Flat view|Flat view]]
+[[Contract view|Contract view]] }} + + + + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-reference/formatted-information-about-compiled-classes-and-features/class-views/index.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-reference/formatted-information-about-compiled-classes-and-features/class-views/index.wiki new file mode 100644 index 00000000..7dc13fa3 --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-reference/formatted-information-about-compiled-classes-and-features/class-views/index.wiki @@ -0,0 +1,28 @@ +[[Property:title|Class views]] +[[Property:weight|1]] +[[Property:uuid|dd076484-eccd-41d6-538e-bf261529b43e]] +[[Image:class-format-bar]] + +Class views are all available through the '''Class''' tab of the [[EiffelStudio window overview|context tool]] , and for some of them directly with the [[EiffelStudio Editor|editor]] .
+These views (with their associated icon) are: +* [[Image:view-editor-icon]] [[Class formatters: Basic text view|Basic text view]] +* [[Image:view-clickable-icon]] [[Clickable view|Clickable view]] +* [[Image:view-flat-icon]] [[Class formatters: Flat view|Flat view]] +* [[Image:view-contracts-icon]] [[Contract view|Contract view]] +* [[Image:view-flat-contracts-icon]] [[Flat Contract view|Flat Contract view]] +* [[Image:class-ancestors-icon]] [[Ancestors|Ancestors]] +* [[Image:class-descendents-icon]] [[Descendants|Descendants]] +* [[Image:class-clients-icon]] [[Clients|Clients]] +* [[Image:class-supliers-icon]] [[Suppliers|Suppliers]] +* [[Image:class-features-attribute-icon]] [[Attributes|Attributes]] +* [[Image:class-features-routine-icon]] [[Routines|Routines]] +* [[Image:class-features-invariant-icon]] [[Invariants|Invariants]] +* [[Image:class-features-creator-icon]] [[Creators|Creators]] +* [[Image:class-features-deferred-icon]] [[Deferred features|Deferred features]] +* [[Image:class-features-once-icon]] [[Once routines and constants|Once routines and constants]] +* [[Image:class-features-external-icon]] [[Class formatters: External features|External features]] +* [[Image:class-features-exported-icon]] [[Exported features|Exported features]] + + + + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-reference/formatted-information-about-compiled-classes-and-features/class-views/invariants.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-reference/formatted-information-about-compiled-classes-and-features/class-views/invariants.wiki new file mode 100644 index 00000000..01f80b7d --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-reference/formatted-information-about-compiled-classes-and-features/class-views/invariants.wiki @@ -0,0 +1,9 @@ +[[Property:title|Invariants]] +[[Property:weight|-3]] +[[Property:uuid|74a4cf46-cc07-d7b8-bce4-b8bf78b72b99]] +The invariants view [[Image:class-features-invariant-icon]] displays all the invariants of the current class.
+It is available through the '''Class''' tab of the [[EiffelStudio window overview|context tool]]. + + + + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-reference/formatted-information-about-compiled-classes-and-features/class-views/once-routines-and-constants.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-reference/formatted-information-about-compiled-classes-and-features/class-views/once-routines-and-constants.wiki new file mode 100644 index 00000000..8ab0c94f --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-reference/formatted-information-about-compiled-classes-and-features/class-views/once-routines-and-constants.wiki @@ -0,0 +1,9 @@ +[[Property:title|Once routines and constants]] +[[Property:weight|0]] +[[Property:uuid|05007945-20fd-99d6-95cb-ec96845c131f]] +The once view [[Image:class-features-once-icon]] displays all the [[Routines|routines]] declared as '''once''' and the constant [[Attributes|attributes]] in the current class (or in its [[Ancestors|ancestors]]).
+It is available through the '''Class''' tab of the [[EiffelStudio window overview|context tool]]. + + + + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-reference/formatted-information-about-compiled-classes-and-features/class-views/routines.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-reference/formatted-information-about-compiled-classes-and-features/class-views/routines.wiki new file mode 100644 index 00000000..9dbfc552 --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-reference/formatted-information-about-compiled-classes-and-features/class-views/routines.wiki @@ -0,0 +1,13 @@ +[[Property:title|Routines]] +[[Property:weight|-4]] +[[Property:uuid|3b0f4d50-3a62-37ca-fa36-20c606abb9e3]] +The routines view [[Image:class-features-routine-icon]] displays all the routine signatures of the current class, including inherited routines.
+It is available through the '''Class''' tab of the [[EiffelStudio window overview|context tool]]. + + +{{seealso|
+[[Attributes|Attributes]] }} + + + + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-reference/formatted-information-about-compiled-classes-and-features/class-views/suppliers.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-reference/formatted-information-about-compiled-classes-and-features/class-views/suppliers.wiki new file mode 100644 index 00000000..5993527e --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-reference/formatted-information-about-compiled-classes-and-features/class-views/suppliers.wiki @@ -0,0 +1,13 @@ +[[Property:title|Suppliers]] +[[Property:weight|-6]] +[[Property:uuid|deb168d4-1855-45d7-85c8-48f43ce5ce5e]] +The suppliers view [[Image:class-supliers-icon]] displays all the classes from which the current class is calling features.
+It is available through the '''Class''' tab of the [[EiffelStudio window overview|context tool]]. + + +{{seealso|
+[[Clients|Clients]] }} + + + + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-reference/formatted-information-about-compiled-classes-and-features/feature-views/feature-formatters-ancestor-versions.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-reference/formatted-information-about-compiled-classes-and-features/feature-views/feature-formatters-ancestor-versions.wiki new file mode 100644 index 00000000..603ad29a --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-reference/formatted-information-about-compiled-classes-and-features/feature-views/feature-formatters-ancestor-versions.wiki @@ -0,0 +1,12 @@ +[[Property:title|Feature formatters: Ancestor versions]] +[[Property:weight|10]] +[[Property:uuid|ca7f840d-30fb-c1cb-8f2f-6b45aa244f95]] +The '''ancestor versions''' view [[Image:feature-ancestors-icon]] displays all the features which the current feature is redefining. + + +{{seealso|
+[[Feature formatters: Descendant versions|Descendant versions]] }} + + + + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-reference/formatted-information-about-compiled-classes-and-features/feature-views/feature-formatters-assignees.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-reference/formatted-information-about-compiled-classes-and-features/feature-views/feature-formatters-assignees.wiki new file mode 100644 index 00000000..f7faf28d --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-reference/formatted-information-about-compiled-classes-and-features/feature-views/feature-formatters-assignees.wiki @@ -0,0 +1,9 @@ +[[Property:title|Feature formatters: Assignees]] +[[Property:weight|7]] +[[Property:uuid|98b4c8f2-272f-c2b6-1f8f-bd86aadbddc2]] +The '''assignees''' view [[Image:feature-assignees-icon]] lists all features which appear in the current feature as targets of assignments. + +As with [[Feature formatters: Assigners|assigners]], this includes true assignments to class features only, that is, it does not include "targets" of the assignment-like syntax of '''assignment commands'''. + + + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-reference/formatted-information-about-compiled-classes-and-features/feature-views/feature-formatters-assigners.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-reference/formatted-information-about-compiled-classes-and-features/feature-views/feature-formatters-assigners.wiki new file mode 100644 index 00000000..ffbf098d --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-reference/formatted-information-about-compiled-classes-and-features/feature-views/feature-formatters-assigners.wiki @@ -0,0 +1,9 @@ +[[Property:title|Feature formatters: Assigners]] +[[Property:weight|4]] +[[Property:uuid|6fdc5d59-d63b-39f7-68f8-13777077cbd2]] +The '''assigners''' view [[Image:feature-assigners-icon]] displays the features which assign to the current feature. + +This means that unless the current feature is an attribute, assignment is not defined and this view will be empty. + +Also, this view covers only true assignments to the current feature. So, you should not confuse the use of '''assignment commands''' with true assignments. An assignment command is an optional command associated with a query that allows assignment-like syntax to be used to set a new value for the query. Even though the use of assignment commands look like assignments, they are not true assignments. Rather, they are invocations of a command which sets a new value for the query. Therefore, they will not be visible in the assigners view. + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-reference/formatted-information-about-compiled-classes-and-features/feature-views/feature-formatters-basic-text-view.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-reference/formatted-information-about-compiled-classes-and-features/feature-views/feature-formatters-basic-text-view.wiki new file mode 100644 index 00000000..6e001b38 --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-reference/formatted-information-about-compiled-classes-and-features/feature-views/feature-formatters-basic-text-view.wiki @@ -0,0 +1,16 @@ +[[Property:title|Feature formatters: Basic text view]] +[[Property:weight|1]] +[[Property:uuid|ad171d9e-9d67-7fb9-10e5-db237b04e40e]] +The '''basic text''' view [[Image:view-editor-feature-icon]] displays the text of the current feature as it is written in the enclosing class.
+It does not work with [[Breakpoints|breakpoints]]; in order to do this the [[Feature formatters: Flat view|flat view]] has to be used. + + +{{note|This view is not available to .NET features which are imported through by means of an assembly. This is because the assembly '''.exe''' or '''.dll''' exposes only the interface methods and therefore is no feature implementation to display. The feature interface may be viewed, in a clickable format using the Flat View. }} + + +{{seealso|
+[[Class formatters: Basic text view|Class basic text view]] }} + + + + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-reference/formatted-information-about-compiled-classes-and-features/feature-views/feature-formatters-callees.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-reference/formatted-information-about-compiled-classes-and-features/feature-views/feature-formatters-callees.wiki new file mode 100644 index 00000000..6c24ee12 --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-reference/formatted-information-about-compiled-classes-and-features/feature-views/feature-formatters-callees.wiki @@ -0,0 +1,8 @@ +[[Property:title|Feature formatters: Callees]] +[[Property:weight|6]] +[[Property:uuid|0e81a9a8-9bce-91b3-3dce-b0c09186837e]] +The '''callees''' view [[Image:feature-callees-icon]] will list the names of all features used by the current feature. This includes those features called directly, and as appropriate, those features which are targets of assignments in the current feature (the feature's assignees [[Image:feature-assignees-icon]], those features which are the targets of creation instructions in the current feature (the feature's creations [[Image:feature-creations-icon]], and those features which are used by the current feature as arguments in calls to other features. + + + + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-reference/formatted-information-about-compiled-classes-and-features/feature-views/feature-formatters-callers.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-reference/formatted-information-about-compiled-classes-and-features/feature-views/feature-formatters-callers.wiki new file mode 100644 index 00000000..0ba35a88 --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-reference/formatted-information-about-compiled-classes-and-features/feature-views/feature-formatters-callers.wiki @@ -0,0 +1,20 @@ +[[Property:title|Feature formatters: Callers]] +[[Property:weight|3]] +[[Property:uuid|63b7a88c-86ff-7aef-bf31-05d0ed850e4e]] +The '''callers''' view [[Image:feature-callers-icon]] displays all the features which use the current feature in any way. + + +So the callers view includes features which actually call the current feature. + +Additionally, callers also includes, where appropriate, those features that assign to the current feature (the feature's assigners [[Image:feature-assigners-icon]]), those features that create the current feature (the feature's creators [[Image:feature-creators-icon]]), and those features that use the current feature as an argument to other features. So, for example, assigners and creators could show up only in a list of callers for a feature that is an attribute. + + +In the EiffelStudio preferences it is possible to choose whether callers of the feature's descendant versions should be displayed too (they are by default). + + +{{seealso|
+[[Clients|Class clients view]] }} + + + + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-reference/formatted-information-about-compiled-classes-and-features/feature-views/feature-formatters-creations.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-reference/formatted-information-about-compiled-classes-and-features/feature-views/feature-formatters-creations.wiki new file mode 100644 index 00000000..bb46d6a7 --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-reference/formatted-information-about-compiled-classes-and-features/feature-views/feature-formatters-creations.wiki @@ -0,0 +1,8 @@ +[[Property:title|Feature formatters: Creations]] +[[Property:weight|8]] +[[Property:uuid|97a25a8d-42c8-f968-fa66-1d270e82a8c8]] +The feature '''creations''' view [[Image:feature-creations-icon]] displays the names of any features which appear in the current feature as targets of creation instructions. + + + + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-reference/formatted-information-about-compiled-classes-and-features/feature-views/feature-formatters-creators.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-reference/formatted-information-about-compiled-classes-and-features/feature-views/feature-formatters-creators.wiki new file mode 100644 index 00000000..99fdc9b1 --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-reference/formatted-information-about-compiled-classes-and-features/feature-views/feature-formatters-creators.wiki @@ -0,0 +1,8 @@ +[[Property:title|Feature formatters: Creators]] +[[Property:weight|5]] +[[Property:uuid|ece55aae-5922-b6ec-7b50-b4c97cba7cc0]] +The '''creators''' view [[Image:feature-creators-icon]] shows all features in which the current feature appears as the target of a creation instruction. The creators view will be empty for any feature which is not an attribute. + + + + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-reference/formatted-information-about-compiled-classes-and-features/feature-views/feature-formatters-descendant-versions.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-reference/formatted-information-about-compiled-classes-and-features/feature-views/feature-formatters-descendant-versions.wiki new file mode 100644 index 00000000..cbd1a69c --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-reference/formatted-information-about-compiled-classes-and-features/feature-views/feature-formatters-descendant-versions.wiki @@ -0,0 +1,12 @@ +[[Property:title|Feature formatters: Descendant versions]] +[[Property:weight|11]] +[[Property:uuid|c232a74a-7264-c8e1-4613-a65d75302602]] +The '''descendant versions''' view [[Image:feature-descendents-icon]] displays all the features that redefine the current feature. + + +{{seealso|
+[[Feature formatters: Ancestor versions|Ancestor versions]] }} + + + + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-reference/formatted-information-about-compiled-classes-and-features/feature-views/feature-formatters-flat-view.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-reference/formatted-information-about-compiled-classes-and-features/feature-views/feature-formatters-flat-view.wiki new file mode 100644 index 00000000..2e30272a --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-reference/formatted-information-about-compiled-classes-and-features/feature-views/feature-formatters-flat-view.wiki @@ -0,0 +1,14 @@ +[[Property:title|Feature formatters: Flat view]] +[[Property:weight|2]] +[[Property:uuid|b325d97c-772d-8207-a901-a401c6a61376]] +The '''flat''' view [[Image:view-clickable-feature-icon]] displays the feature body as it is seen at run-time (according to ancestor versions, if any). This is why it is possible to add or remove [[Breakpoints|breakpoints]] in this view. + + +{{seealso| operations involving breakpoint, please visit the page [[Breakpoints]]}} + + +{{seealso| [[Class formatters: Flat view|Class flat view]] }} + + + + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-reference/formatted-information-about-compiled-classes-and-features/feature-views/feature-formatters-homonyms.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-reference/formatted-information-about-compiled-classes-and-features/feature-views/feature-formatters-homonyms.wiki new file mode 100644 index 00000000..649e3cd3 --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-reference/formatted-information-about-compiled-classes-and-features/feature-views/feature-formatters-homonyms.wiki @@ -0,0 +1,15 @@ +[[Property:title|Feature formatters: Homonyms]] +[[Property:weight|12]] +[[Property:uuid|933b22f0-c181-fd65-9b52-be20270b00af]] +The '''homonyms''' view [[Image:feature-homonyms-icon]] displays all the features in the system which have the same name as the current feature. + + +{{warning|: This operation may take a long time if the system has a lot of classes. }} + + +{{seealso|
+[[Feature formatters: Implementers|Implementers]] }} + + + + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-reference/formatted-information-about-compiled-classes-and-features/feature-views/feature-formatters-implementers.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-reference/formatted-information-about-compiled-classes-and-features/feature-views/feature-formatters-implementers.wiki new file mode 100644 index 00000000..e336549d --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-reference/formatted-information-about-compiled-classes-and-features/feature-views/feature-formatters-implementers.wiki @@ -0,0 +1,13 @@ +[[Property:title|Feature formatters: Implementers]] +[[Property:weight|9]] +[[Property:uuid|4032bef0-39e5-5fa6-0ffe-156392c0234e]] +The '''implementers''' view [[Image:feature-implementers-icon]] displays all the different versions of the current feature by exploring the [[Feature formatters: Ancestor versions|ancestor versions]] and the [[Feature formatters: Descendant versions|descendant versions]], and selecting among those the ones which are not inherited. + + +{{seealso|
+[[Feature formatters: Ancestor versions|Ancestor versions]]
+[[Feature formatters: Descendant versions|Descendant versions]] }} + + + + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-reference/formatted-information-about-compiled-classes-and-features/feature-views/index.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-reference/formatted-information-about-compiled-classes-and-features/feature-views/index.wiki new file mode 100644 index 00000000..a2a1742b --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-reference/formatted-information-about-compiled-classes-and-features/feature-views/index.wiki @@ -0,0 +1,22 @@ +[[Property:title|Feature views]] +[[Property:weight|2]] +[[Property:uuid|81c09c3a-0c0e-ecab-b708-0f5cd8860031]] +[[Image:feature-format-bar]] + +Feature views are all available through the '''Feature''' tab of the [[EiffelStudio window overview|context tool]].
+These views (and their associated icon) are: +* [[Image:view-editor-feature-icon]] [[Feature formatters: Basic text view|Basic text view]] +* [[Image:view-clickable-feature-icon]] [[Feature formatters: Flat view|Flat view]] +* [[Image:feature-callers-icon]] [[Feature formatters: Callers|Callers]] +* [[Image:feature-assigners-icon]] [[Feature formatters: Assigners|Assigners]] +* [[Image:feature-creators-icon]] [[Feature formatters: Creators|Creators]] +* [[Image:feature-callees-icon]] [[Feature formatters: Callees|Callees]] +* [[Image:feature-assignees-icon]] [[Feature formatters: Assignees|Assignees]] +* [[Image:feature-creations-icon]] [[Feature formatters: Creations|Creations]] +* [[Image:feature-implementers-icon]] [[Feature formatters: Implementers|Implementers]] +* [[Image:feature-ancestors-icon]] [[Feature formatters: Ancestor versions|Ancestor versions]] +* [[Image:feature-descendents-icon]] [[Feature formatters: Descendant versions|Descendant versions]] +* [[Image:feature-homonyms-icon]] [[Feature formatters: Homonyms|Homonyms]] + + + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-reference/formatted-information-about-compiled-classes-and-features/index.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-reference/formatted-information-about-compiled-classes-and-features/index.wiki new file mode 100644 index 00000000..2489e7b1 --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-reference/formatted-information-about-compiled-classes-and-features/index.wiki @@ -0,0 +1,11 @@ +[[Property:title|Formatted information about compiled classes and features]] +[[Property:weight|2]] +[[Property:uuid|487a89c3-14a7-26c4-ae87-f3442f315bc3]] +Different kinds of information about classes and features can be seen in EiffelStudio depending on the developer's needs. + + +{{SeeAlso|The Eiffel Software Learning Map [http://eiffel.com/developers/learning_maps/Training/Maps/HowDoYouView/index.html How do you view?]}} + + + + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-reference/index.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-reference/index.wiki new file mode 100644 index 00000000..d817e457 --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-reference/index.wiki @@ -0,0 +1,9 @@ +[[Property:modification_date|Thu, 21 Jun 2018 09:11:53 GMT]] +[[Property:publication_date|Thu, 21 Jun 2018 09:10:31 GMT]] +[[Property:link_title|Reference]] +[[Property:title|EiffelStudio Reference]] +[[Property:weight|3]] +[[Property:uuid|e34647c8-840e-159d-74b3-07353a27472e]] + +This EiffelStudio reference chapter contains topics with information about many technical aspects of the EiffelStudio product. + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-reference/metrics-tool/definitions/attributes-metrics-and-measures.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-reference/metrics-tool/definitions/attributes-metrics-and-measures.wiki new file mode 100644 index 00000000..bd0e25f8 --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-reference/metrics-tool/definitions/attributes-metrics-and-measures.wiki @@ -0,0 +1,35 @@ +[[Property:title|Attributes, metrics and measures]] +[[Property:weight|1]] +[[Property:uuid|4e35583c-25e8-63e7-2c11-ea4d3ed2e2a3]] +The most general notion is "attribute": + +{{definition|Attribute|An '''attribute''' is a property, qualitative or quantitative, of software products or processes. }} + +We may distinguish between the product and process cases: + +{{definition|Product attribute, process attribute|A '''product attribute''' is an attribute that characterizes a software product or set of products. A '''process attribute''' is an attribute that characterizes a software-related process, such as development, maintenance, documentation, management, or multiple instances of such a process. }} + +Examples of attributes include reliability (a product attribute, non-quantitative) and total project cost (process, quantitative). + +A metric is simply a quantitative attribute: + +{{definition|Metric|A '''metric''' is an attribute whose values are numbers (integers or reals), expressed relative to a certain '''unit''' specified as part of the metric definition. }} + +Examples of metrics include the number of source lines of a program (product) and the total cost of a project (process). The metric tool provides by default a set of metrics, they are available in the Metric Evaluation tab of the metric tool + +Attributes other than metrics will be called "qualitative": + +{{definition|Qualitative attribute|A '''qualitative attribute''' is an attribute other than a metric. }} + +An example of qualitative attribute is the reliability of a software product. + +The "process" vs. "product" distinction carries over to metrics: + +{{definition|Product metric, process metric|A metric is a '''product metric''' if it is a product attribute, a '''process metric''' if it is a process attribute. }} + +"Relevance", as defined in the previous section, suggests that the purpose of metrics is to help us gain information about attributes that are of direct interest to us. Often these will be qualitative; for example we may want to estimate the reliability of our software. Metrics provide us with numerical values that can serve to assess or predict such attributes. + +Applying a metric will give us measures: + +{{definition|Measure|A '''measure''' is the value of a metric for a certain process or product. }} + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-reference/metrics-tool/definitions/criterion-references.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-reference/metrics-tool/definitions/criterion-references.wiki new file mode 100644 index 00000000..d69a7263 --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-reference/metrics-tool/definitions/criterion-references.wiki @@ -0,0 +1,763 @@ +[[Property:title|Criterion References]] +[[Property:weight|12]] +[[Property:uuid|52790486-55e8-86dc-67d7-5530d1b342a3]] +==Text Criterion== + +'''name_is'''
+'''Syntax:''' name_is "pattern", matching strategy, case-sensitivity
+'''Applicable on:''' Target, Group, Class, Generic, Feature, Assertion, Argument, Local, Line
+'''Remark:''' This criterion will evaluate to True if name of the candidate code element matched the given pattern. For more details about matching strategy and case-sensitivity modifier, see the documentation of text criterion. + +'''text_is'''
+'''Syntax:''' text_is "pattern", matching strategy, case-sensitivity
+'''Applicable on:''' Class, Generic, Feature, Assertion, Argument, Local, Line
+'''Remark:''' This criterion will evaluate to True if text of a candidate code element matches the given pattern. + +'''top_indexing_contain'''
+'''Syntax:''' top_indexing_contain "pattern", matching strategy, case-sensitivity
+'''Applicable on:''' Class
+'''Remark:''' This criterion will evaluate to True if text (indexing tags are not included) of the top indexing clause in the candidate class matches the given pattern. + +'''top_indexing_has_tag'''
+'''Syntax:''' top_indexing_has_tag "pattern", matching strategy, case-sensitivity
+'''Applicable on:''' Class
+'''Remark:''' This criterion will evaluate to True if tags of the top indexing clause in the candidate class matches the given pattern. + +'''bottom_indexing_contain'''
+'''Syntax:''' bottom_indexing_contain "pattern", matching strategy, case-sensitivity
+'''Applicable on:''' Class
+'''Remark:'''This criterion will evaluate to True if text (indexing tags are not included) of the bottom indexing clause in the candidate class matches the given pattern. + +'''bottom_indexing_has_tag'''
+'''Syntax:''' bottom_indexing_has_tag "pattern", matching strategy, case-sensitivity
+'''Applicable on:''' Class
+'''Remark:'''This criterion will evaluate to True if tags of the bottom indexing clause in the candidate class matches the given pattern. + +'''indexing_contain'''
+'''Syntax:''' indexing_contain "pattern", matching strategy, case-sensitivity
+'''Applicable on:'''Class
+'''Remark:'''This criterion will evaluate to True if (top or bottom) indexing clause matches the given pattern. + +'''indexing_has_tag'''
+'''Syntax:''' indexing_has_tag "pattern", matching strategy, case-sensitivity
+'''Applicable on:''' Class
+'''Remark:''' This criterion will evaluate to True if tag of (top or bottom) indexing clause of the candidate class matches the given pattern. + +==Path Criterion== + +'''path_in'''
+'''Syntax:''' path_in "path"
+'''Applicable on:''' Class
+'''Remark:''' This criterion will evaluate to True if path (related to the class's written in group) of the class candidate is "path" or its subdirectory. "path" is in Unix format, i.e., different sections are separated by a "/". On Windows, path matching is case-sensitive, on other platforms, it's case-sensitive. + +'''path_is'''
+'''Syntax:''' path_is "path"
+'''Applicable on:''' Class
+'''Remark:''' This criterion will evaluate to True if path (related to the class's written in group) of the class candidate is "path". "path" is in Unix format, i.e., different sections are separated by a "/". On Windows, path matching is case-sensitive, on other platforms, it's case-sensitive. + +==Relation Criterion== + +'''ancestor_is'''
+'''Syntax:''' ancestor_is {domain}
+'''Applicable on:''' Class, Feature
+'''Remark:''' This criterion will evaluate to True if candidate class (or feature) is descendant of any (if more than one are possible) of the class (or feature) specified in the criterion domain.
+For example, in a class metric, +{{sample|ancestor_is {STRING_8} }} +
+will evaluate to True when a candidate class is a descendant of class STRING_8.
+In a class metric, +{{sample|ancestor_is {LINKED_LIST, DS_LINKED_LIST} }} +will evaluate to True when a candidate class is a descendant of either LINKED_LIST or DS_LINKED_LIST. + +'''proper_ancestor_is'''
+'''Syntax:''' proper_ancestor_is {domain}
+'''Applicable on:''' Class
+'''Remark:''' This criterion will evaluate to True if a candidate class is a proper descendant of any of the classes in criterion domain. First, let's use the following figure to demonstrate the concepts of ancestor, proper ancestor, parent and indirect parent. (Note: the hierarchy is not complete)
+ +[[Image:class-hie|class hierarchy]] +Ancestors of STRING_32 are: STRING_32, STRING_GENERAL, INDEXABLE, COMPARABLE and PART_COMPARABLE.
+Proper ancestors of STRING_32 are STRING_GENERAL, INDEXABLE, COMPARABLE and PART_COMPARABLE.
+Parents of STRING_32 are: STRING_GENERAL and INDEXABLE
+Indirect parents of STRING_32 are: COMPARABLE and PARTCOMPARABLE
+The related concepts of descendants, proper descendants, heirs, indirect heirs follow the same rule but are in the reversed direction.
+ + +'''descendant_is'''
+'''Syntax:''' descendant_is {domain}
+'''Applicable on:''' Class, Feature
+'''Remark:''' This criterion evaluates to True if candidate class is or feature is ancestor of any (if more than one are possible) of the class or feature specified in the criterion domain.
+ + +'''proper_descendant_is'''
+'''Syntax:''' proper_descendant_is {domain}
+'''Applicable on:''' Class
+'''Remark:''' This criterion evaluates to True if a candidate class is a proper ancestor of any of the classes in criterion domain.
+ + +'''parent_is'''
+'''Syntax:''' parent_is {domain}
+'''Applicable on:''' Class
+'''Remark:''' This criterion evaluates to True if a candidate class is a heir of any of the classes in criterion domain.
+ + +'''indirect_parent_is'''
+'''Syntax:''' indirect_parent_is {domain}
+'''Applicable on:''' Class
+'''Remark:''' This criterion evaluates to True if a candidate class is a indirect heir of any of the classes in criterion domain.
+ + +'''heir_is'''
+'''Syntax:''' heir_is {domain}
+'''Applicable on:''' Class
+'''Remark:''' This criterion evaluates to True if a candidate class is a parent of any of the classes in criterion domain.
+ + +'''indirect_heir_is'''
+'''Syntax:''' indirect_heir_is {domain}
+'''Applicable on:''' Class
+'''Remark:''' This criterion evaluates to True if a candidate class is a indirect parent of any of the classes in criterion domain.
+ + +'''client_is'''
+'''Syntax:''' client_is {domain}, directness, normally_referenced, syntactically_referenced
+'''Applicable on:''' Class
+'''Remarks:''' This criterion evaluates to True if a candidate class is supplier of any of the classes in criterion domain. Directness modifier is boolean modifier, if it's True only direct suppliers are picked, if indirect modifier is set, only indirect suppliers are picked. normally_referenced and syntactically_referenced modifiers are both boolean modifiers, they enable to specify how one class is used by another class. Let's use an example to demonstrate these ideas, for example, in class A, there is a feature foo:
+ + foo + local + l_str: STRING + l_file: FILE + do + create l_str.make_empty + end + +
+Then both STRING and FILE are suppliers of class A. STRING is normal supplier because a feature make_empty in STRING is invoked in class A, but FILE is a syntactically referenced supplier because no feature from FILE is called from A. Classes explicitly listed in inherit clause of a class are also considered as syntactically referenced suppliers. +Concepts of direct/indirect, normally referenced/syntactically referenced clients follow the same rule except in the other direction. + + +'''supplier_is'''
+'''Syntax:''' supplier_is {domain}, directness, normally_referenced, syntactically_referenced
+'''Applicable on:''' Class
+'''Remark:'''
+This criterion evaluates to True if a candidate class is client of any of the classes in criterion domain.
+For more information of directness modifier, normally_referenced modifier and syntactically_referenced modifier, see document for relation criterion client_is
+ + +'''callee_is'''
+'''Syntax:''' callee_is {domain}, only_current_version
+'''Applicable on:''' Feature
+'''Remark:'''
+This criterion evaluates to True if a candidate feature is calling any of the feature listed in criterion domain.
+only_current_verision modifier is a boolean modifier, if it's True, when the criterion is evaluated, only the candidate feature is taken into consideration, otherwise, the candidate feature and all its descendant versions are taken into consideration.
+ + +'''caller_is'''
+'''Syntax:''' caller_is {domain}, only_current_version
+'''Applicable on:''' Feature
+'''Remark:'''
+This criterion evaluates to True if a candidate feature is called by any of the feature listed in criterion domain.
+only_current_verision modifier is a boolean modifier, if it's True, when the criterion is evaluated, only the candidate feature is taken into consideration, otherwise, the candidate feature and all its descendant versions are taken into consideration.
+ + +'''assignee_is'''
+'''Syntax:''' assignee_is {domain}, only_current_version
+'''Applicable on:''' Feature
+'''Remark:'''
+This criterion evaluates to True if a candidate feature assigns to any of the feature listed in criterion domain.
+only_current_verision modifier is a boolean modifier, if it's True, when the criterion is evaluated, only the candidate feature is taken into consideration, otherwise, the candidate feature and all its descendant versions are taken into consideration.
+ + +'''assigner_is'''
+'''Syntax:''' assigner_is {domain}, only_current_version
+'''Applicable on:''' Feature
+'''Remark:'''
+This criterion evaluates to True if a candidate feature assigns to any of the feature listed in criterion domain.
+only_current_verision modifier is a boolean modifier, if it's True, when the criterion is evaluated, only the candidate feature is taken into consideration, otherwise, the candidate feature and all its descendant versions are taken into consideration.
+ + +'''createe_is'''
+'''Syntax:''' createe_is {domain}, only_current_version
+'''Applicable on:''' Feature
+'''Remark:'''
+This criterion evaluates to True if a candidate feature creates any of the feature (must be an attribute) listed in criterion domain.
+only_current_verision modifier is a boolean modifier, if it's True, when the criterion is evaluated, only the candidate feature is taken into consideration, otherwise, the candidate feature and all its descendant versions are taken into consideration.
+ + +'''creator_is'''
+'''Syntax:''' creator_is {domain}, only_current_version
+'''Applicable on:''' Feature
+'''Remark:'''
+This criterion evaluates to True if a candidate feature (must be an attribute) is created by any of the feature listed in criterion domain.
+only_current_verision modifier is a boolean modifier, if it's True, when the criterion is evaluated, only the candidate feature is taken into consideration, otherwise, the candidate feature and all its descendant versions are taken into consideration.
+ + +'''is_exported_to'''
+'''Syntax:''' is_exported_to {domain}
+'''Applicable on:''' Feature
+'''Remark:''' This criterion will evaluate to True if the candidate class is exported to all the classes listed in criterion domain.
+ + +'''is_implementors_of'''
+'''Syntax:''' is_implementors_of {domain}
+'''Applicable on:''' Feature
+ + +'''Remark:''' This criterion will evaluate to True if the candidate feature is an implementer of some features listed in criterion domain.
+ + +'''return_type_is'''
+'''Syntax:''' return_type_is {domain}
+'''Applicable on:''' Feature
+'''Remark:''' This criterion will evaluate to True if associated class of the return type of the candidate feature is listed in criterion domain.
+ + +==Value Criterion== + +''' value_of_metric_is'''
+'''Syntax:''' value_of_metric_is '''Metric''', {domain}, value_tester
+''' Applicable on:''' Target, Group, Class, Generic, Feature, Assertion, Argument, Local, Line
+'''Remark:'''The '''Metric''' modifier will be a specified metric name. This criterion will evaluate to True if the calculated metric (from metric modifier) over input domain (from criterion domain) satisfies some given value tester (from value_tester modifier). +For example, if we want to find classes whose code is over 1000 lines, we can create the following metric and run it over input domain {Application target}: + +[[Image:value-of-metric-is|Actual semantic for input domain item]] + +[[Image:value-tester|Actual semantic for input domain item]] + +In the above dialog, you can customize the value_of_metric_is criterion. A metric needs to be specified as well as its input domain. Sometimes, "Delayed item" is set in the input domain meaning that no matter what the current candidate code element is, use it as input domain to the selected metric and calculate that metric to see if it's value satisfies the given value testers which are also set in this dialog. + +You can specify more than one value tester and they can be anded (when "Match all" is selected) or ored (when "Match any" is selected). if no value tester is set, the value_of_metric_is criterion always evaluates to True. + +This metric reads, for every class from application target, calculate metric '''Lines of code''' over that class (this is the usage of "Delayed item"), and if the value of '''Lines of code''' over that class is larger than 1000, that class satisfies the '''value_of_metric_is''' criterion thus it's included in the result. + +Let's see another example of value_of_metric_is criterion which is more complicated and involves the use of the "Use external delayed domain" option. + +Suppose we are to construct a metric called '''Unused features''' which can finds unused features. First, it must be a feature metric because we want features in the result. Second, for every feature candidate, we want a predicate which evaluates to True if that candidate feature is not called by any feature. + +And this predicate is semantically equal to say: count all callers of the candidate feature and check if the value is zero. So now, we realize that we need a metric which returns the number of callers of a given feature. + +We can construct this feature metric as follows: + +[[Image:callee-is|value criterion]] + +Let's call it "callee_is" (note: here callee_is is a metric name instead of a criterion name). It uses "Delayed item" because we want that "Delayed item" to be replaced by the actual candidate feature at run-time. + +Then we can construct our '''Unused features''' metric as follows: + +[[Image:unused-feature|value criterion]] + +[[Image:unused-feature-criterion|value criterion]] + +In this dialog, note that the "Use external delayed domain" option is checked. It has to be checked. Let's see why. + +This value_of_metric_is criterion should check this: for every candidate feature, test if the number of callers of that feature in current application target scope is zero. + +Suppose now a feature named foo is the candidate feature. + +If the "Use external delayed domain" is not checked, then the metric '''callee_is''' is calculated over input domain {application target}. + +So when calculate callee_is metric, every feature (let's call the current candidate feature APPLICATION.goo) from current application target is checked to see if it satisfies the criterion: callee_is {APPLICATION.goo} (the "Delayed item" is replaced by the current candidate feature). This is actually checking if a feature is called by itself. + +As you can see, if "Use external delayed domain" option is not checked, during the period of value_of_metric_is criterion evaluation, the current feature candidate from the '''Unused features''' metrics is never involved. This of course yields wrong result. + +Now we select the "Use external delayed domain" option. Recall that current candidate feature of metric '''Unused features''' is APPLICATION.foo. + +When the value_of_metric_is criterion is evaluated, the delayed item from metric '''callee_is''' is replaced by APPLICATION.foo. So the metric '''callee_is''' now is equal to: + +[[Image:fake-callee-is|value criterion]] + +which reads: calculate the number of callers of feature APPLICATION.foo. And the value_of_metric_is criterion is now semantically equal to: test if number of callers of APPLICATION.foo is zero. This is what we want. + +As we can see, when the option "Use external delayed domain" is selected, the delayed item from the criterion metric will be replaced by the current candidate code element. Otherwise, it will be replaced by the candidate element from criterion metric input domain when criterion metric is calculated. + + +==Normal Criterion== + +'''false'''
+'''Syntax:''' false
+'''Applicable on:''' Target, Group, Class, Generic, Feature, Assertion, Argument, Local, Line
+'''Remark:''' This criterion will always evaluate to False.
+ + +'''has_argument'''
+'''Syntax:''' has_argument
+'''Applicable on:''' Feature
+'''Remark:''' This criterion will evaluate to True if the candidate feature has arguments.
+ + +'''has_assertion'''
+'''Syntax:''' has_assertion
+'''Applicable on:''' Feature
+'''Remark:''' This criterion will evaluate to True if the candidate feature has any precondition or postcondition.
+ + +'''has_assigner'''
+'''Syntax:''' has_assigner
+'''Applicable on:''' Feature
+'''Remark:''' This criterion will evaluate to True if the candidate feature (must be an attribute then) has assigner.
+ + +'''has_bottom_indexing'''
+'''Syntax:''' has_bottom_indexing
+'''Applicable on:''' Class
+'''Remark:''' This criterion will evaluate to True if candidate class has bottom indexing.
+ + +'''has_comment'''
+'''Syntax:''' has_comment
+'''Applicable on:''' Feature
+'''Remark:''' This criterion will evaluate to True if candidate feature has header comment.
+ + +'''has_constraint'''
+'''Syntax:''' has_constraint
+'''Applicable on:''' Generic
+'''Remark:''' This criterion will evaluate to True if the candidate generic has constraint.
+ + +'''has_creation_constraint'''
+'''Syntax:''' has_creation_constraint
+'''Applicable on:''' Generic
+'''Remark:''' This criterion will evaluate to True if the candidate generic has creation constraint
+ + +'''has_expression'''
+'''Syntax:''' has_expression
+'''Applicable on:''' Assertion
+'''Remark:''' This criterion will evaluate to True if the candidate assertion has associated expression.
+ + +'''has_indexing'''
+'''Syntax:''' has_indexing
+'''Applicable on:''' Class, Feature
+'''Remark:''' This criterion will evaluate to True if the candidate class or feature has indexing clause.
+ + +'''has_immediate_invariant'''
+'''Syntax:''' has_immediate_invariant
+'''Applicable on:''' Class
+'''Remark:''' This criterion will evaluate to True if the candidate class has immediate invariant clause (not inherited invariant clause).
+ + +'''has_local'''
+'''Syntax:''' has_local
+'''Applicable on:''' Feature
+'''Remark:''' This criterion will evaluate to True if the candidate feature has locals defined in it.
+ + +'''has_postcondition'''
+'''Syntax:''' has_postcondition
+'''Applicable on:''' Feature
+'''Remark:''' This criterion will evaluate to True if the candidate feature has immediate postconditions.
+ + +'''has_precondition'''
+'''Syntax:''' has_precondition
+'''Applicable on:''' Feature
+'''Remark:''' This criterion will evaluate to True if the candidate feature has immediate preconditions.
+ + +'''has_rescue'''
+'''Syntax:''' has_rescue
+'''Applicable on:''' Feature
+'''Remark:''' This criterion will evaluate to True if the candidate feature has rescue clause.
+ + +'''has_tag'''
+'''Syntax:''' has_tag
+'''Applicable on:''' Assertion
+'''Remark:''' This criterion will evaluate to True if the candidate has a descriptive tag associated with it.
+ + +'''has_top_indexing'''
+'''Syntax:''' has_top_indexing
+'''Applicable on:''' Class
+'''Remark:''' This criterion will evaluate to True if the candidate class has top indexing clause.
+ + +'''is_always_compiled'''
+'''Syntax:''' is_always_compiled
+'''Applicable on:''' Class
+'''Remark:''' This criterion will evaluate to True if the candidate class is an always compiled class. Some basic class such as INTEGER, REAL are always compiled no matter whether they are used in an application. These class will cause is_always_compiled criterion evaluate to True.
+ + +'''is_assembly'''
+'''Syntax:''' is_assembly
+'''Applicable on:''' Group
+'''Remark:''' This criterion will evaluate to True if the candidate group is an assembly.
+ + +'''is_attribute'''
+'''Syntax:''' is_attribute
+'''Applicable on:''' Feature
+'''Remark:''' This criterion will evaluate to True if the candidate feature is an attribute.
+ + +'''is_blank'''
+'''Syntax:''' is_blank
+'''Applicable on:''' Line
+'''Remark:''' This criterion will evaluate to True if the candidate line is blank.
+ + +'''is_cluster'''
+'''Syntax:''' is_cluster
+'''Applicable on:''' Group
+'''Remark:''' This criterion will evaluate to True if the candidate group is a cluster.
+ + +'''is_command'''
+'''Syntax:''' is_command
+'''Applicable on:''' Feature
+'''Remark:''' This criterion will evaluate to True if the candidate feature is a command.
+ + +'''is_comment'''
+'''Syntax:''' is_comment
+'''Applicable on:''' Line
+'''Remark:''' This criterion will evaluate to True if the candidate line is comment line.
+ + +'''is_compiled'''
+'''Syntax:''' is_compiled
+'''Applicable on:''' Target, Group, Class, Generic, Feature, Assertion, Argument, Local, Line
+'''Remark:''' This criterion will evaluate to True if the candidate code element is compiled. Target, group are considered to be compiled once they are referenced by the application. Class (if it is not an always-compiled class) is considered to be compiled if it's used somewhere in the application. always-compiled class are always compiled. and the compilation status of generic, feature, assertion, argument local and line are determined by the compilation status of their written in class.
+ + +'''is_constant'''
+'''Syntax:''' is_constant
+'''Applicable on:''' Feature
+'''Remark:''' This criterion will evaluate to True if the candidate feature is a constant.
+ + +'''is_creator'''
+'''Syntax:''' is_creator
+'''Applicable on:''' Feature
+'''Remark:''' This criterion will evaluate to True if the candidate feature is a creator feature.
+ + +'''is_deferred'''
+'''Syntax:''' is_deferred
+'''Applicable on:''' Class, Feature
+'''Remark:''' This criterion will evaluate to True if the candidate feature is deferred
+ + +'''is_effective'''
+'''Syntax:''' is_effective
+'''Applicable on:''' Class, Feature
+'''Remark:''' This criterion will evaluate to True if the candidate class or feature is effective.
+ + +'''is_ensure'''
+'''Syntax:''' is_ensure
+'''Applicable on:''' Assertion
+'''Remark:''' This criterion will evaluate to True if the candidate assertion is in ensure clause.
+ + +'''is_ensure_then'''
+'''Syntax:''' is_ensure_then
+'''Applicable on:''' Assertion
+'''Remark:''' This criterion will evaluate to True if the candidate assertion is in ensure then clause.
+ + +'''is_enum'''
+'''Syntax:''' is_enum
+'''Applicable on:''' Class
+'''Remark:''' This criterion will evaluate to True if the candidate class is an enumeration. Only has effect on .NET platform, on other platforms, this criterion always evaluates to False.
+ + +'''is_expanded'''
+'''Syntax:''' is_expanded
+'''Applicable on:''' Class, Generic
+'''Remark:''' This criterion will evaluate to True if the candidate class or generic is expanded.
+ + +'''is_exported'''
+'''Syntax:''' is_exported
+'''Applicable on:''' Feature
+'''Remark:''' This criterion will evaluate to True if the candidate feature is exported to ANY.
+ + +'''is_external'''
+'''Syntax:''' is_external
+'''Applicable on:''' Class, Feature
+'''Remark:''' This criterion will evaluate to True if the candidate class or feature is external.
+ + +'''is_feature'''
+'''Syntax:''' is_feature
+'''Applicable on:''' Feature
+'''Remark:''' This criterion will evaluate to True if the candidate feature is real feature. In metrics tool, invariant is treated as a special kind of feature. So if you count features in a class, it's invariant clause will be included. is_feature criterion is used to filter invariant clause out.
+ + +'''is_from_any'''
+'''Syntax:''' is_from_any
+'''Applicable on:''' Feature
+'''Remark:''' This criterion will evaluate to True if the candidate feature is from class ANY.
+ + +'''is_frozen'''
+'''Syntax:''' is_frozen
+'''Applicable on:''' Class, Feature
+'''Remark:''' This criterion will evaluate to True if the candidate feature is frozen.
+ + +'''is_function'''
+'''Syntax:''' is_function
+'''Applicable on:''' Feature
+'''Remark:''' This criterion will evaluate to True if the candidate is a function.
+ + +'''is_generic'''
+'''Syntax:''' is_generic
+'''Applicable on:''' Class
+'''Remark:''' This criterion will evaluate to True if the candidate class is a generic class.
+ + +'''is_hidden'''
+'''Syntax:''' is_hidden
+'''Applicable on:''' Feature
+'''Remark:''' This criterion will evaluate to True if the candidate feature is exported to NONE.
+ + +'''is_immediate'''
+'''Syntax:''' is_immediate
+'''Applicable on:''' Feature, Assertion, Argument, Local
+'''Remark:''' This criterion will evaluate to True if the candidate code element is immediate instead of inherited.
+ + +'''is_implementation_comment'''
+'''Syntax:''' is_implementation_comment
+'''Applicable on:''' Line
+'''Remark:''' This criterion will evaluate to True if the candidate line is implementation comment. Implementation comment is also called commented code. In Eiffel, the convention is that if the comment indicator "--" starts from the first column of a line, that line is an implementation comment line.
+ + +'''is_infix'''
+'''Syntax:''' is_infix
+'''Applicable on:''' Feature
+'''Remark:''' This criterion will evaluate to True if the candidate feature is infix.
+ + +'''is_invariant'''
+'''Syntax:''' is_invariant
+'''Applicable on:''' Assertion
+'''Remark:''' This criterion will evaluate to True if the candidate assertion is from invariant clause.
+ + +'''is_invariant_feature'''
+'''Syntax:''' is_invariant_feature
+'''Applicable on:''' Feature
+'''Remark:''' This criterion will evaluate to True if the candidate feature is an invariant. See the description of criterion is_feature for more detail.
+ + +'''is_library'''
+'''Syntax:''' is_library
+'''Applicable on:''' Group
+'''Remark:''' This criterion will evaluate to True if the candidate group is a library.
+ + +'''is_obsolete'''
+'''Syntax:''' is_obsolete
+'''Applicable on:''' Class, Feature
+'''Remark:''' This criterion will evaluate to True if the candidate class or feature is obsolete.
+ + +'''is_once'''
+'''Syntax:''' is_once
+'''Applicable on:''' Feature
+'''Remark:''' This criterion will evaluate to True if the candidate feature is once.
+ + +'''is_origin'''
+'''Syntax:''' is_origin
+'''Applicable on:''' Feature
+'''Remark:''' This criterion will evaluate to True if the candidate feature is origin instead of a inherited one.
+ + +'''is_override'''
+'''Syntax:''' is_override
+'''Applicable on:''' Group
+'''Remark:''' This criterion will evaluate to True if the candidate group overrides some other group.
+ + +'''is_overriden'''
+'''Syntax:''' is_overriden
+'''Applicable on:''' Class
+'''Remark:''' This criterion will evaluate to True if the candidate class is overridden by some other class.
+ + +'''is_overrider'''
+'''Syntax:''' is_overrider
+'''Applicable on:''' Class
+'''Remark:''' This criterion will evaluate to True if the candidate class overrides some other class.
+ + +'''is_partial'''
+'''Syntax:''' is_partial
+'''Applicable on:''' Class
+'''Remark:''' This criterion will evaluate to True if the candidate class is partical class. Only has effect on .NET platform, on other platforms, this criterion always evaluates to False.
+ + +'''is_postcondition'''
+'''Syntax:''' is_postcondition
+'''Applicable on:''' Assertion
+'''Remark:''' This criterion will evaluate to True if the candidate assertion is a postcondition.
+ + +'''is_precompiled'''
+'''Syntax:''' is_precompiled
+'''Applicable on:''' Class
+'''Remark:''' This criterion will evaluate to True if the candidate class is precompiled.
+ + +'''is_precondition'''
+'''Syntax:''' is_precondition
+'''Applicable on:''' Assertion
+'''Remark:''' This criterion will evaluate to True if the candidate assertion is a precondition.
+ + +'''is_prefix'''
+'''Syntax:''' is_prefix
+'''Applicable on:''' Feature
+'''Remark:''' This criterion will evaluate to True if the candidate is a prefix.
+ + +'''is_procedure'''
+'''Syntax:''' is_procedure
+'''Applicable on:''' Feature
+'''Remark:''' This criterion will evaluate to True if the candidate feature is a procedure.
+ + +'''is_query'''
+'''Syntax:''' is_query
+'''Applicable on:''' Feature
+'''Remark:''' This criterion will evaluate to True if the candidate feature is a query.
+ + +'''is_read_only'''
+'''Syntax:''' is_read_only
+'''Applicable on:''' Class
+'''Remark:''' This criterion will evaluate to True if the candidate class is read-only.
+ + +'''is_reference'''
+'''Syntax:''' is_reference
+'''Applicable on:''' Generic
+'''Remark:''' This criterion will evaluate to True if the candidate generic is reference.
+ + +'''is_require'''
+'''Syntax:''' is_require
+'''Applicable on:''' Assertion
+'''Remark:''' This criterion will evaluate to True if the candidate assertion is in require clause.
+ + +'''is_require_else'''
+'''Syntax:''' is_require_else
+'''Applicable on:''' Assertion
+'''Remark:''' This criterion will evaluate to True if the candidate assertion is in require else clause.
+ + +'''is_satisfied_by'''
+'''Syntax:''' is_satisfied_by command specification
+'''Applicable on:''' Target, Group, Class, Generic, Feature, Assertion, Argument, Local, Line
+'''Remark:''' +This criterion will invoke external command given in command specification to decide whether current item is evaluated to True. Placeholders are used as interface between current item and the external command. The following placeholders are supported: + +* $class_name: this will be replaced by class name of current item +* $directory_name: this will be replaced by the directory location of current item +* $file: this will be replaced by file name part, i.e., without heading directory, of $path of current item +* $file_name: this will be replaced by the path of current item +* $f_code: this will be replaced by the F_code directory of current target, if defined +* $group_directory: this will be replaced by the directory of the group of current item +* $group_name: this will be replaced by the group name of current item +* $path: same as $file_name +* $project_directory: this will be replaced by the directory of current project, if defined +* $target_directory: this will be replaced by the directory of current target, if defined +* $target_name: this will be replaced by name of current target, if defined +* $w_code: this will be replaced by the W_code directory of current target, if defined + + +Command specification can be set in the dialog associated to this criterion, shown in the following picture: [[Image:is-satisfied-by|system hierarchy]] + +'''Command name'''
+External command is specified here.
+The command shown in the picture will test the subversion status of the current class (suppose we are running a class metric). The class path is given by "$path". And the output of the "svn stat $path" command is redirected to grep so we can check if the output starts with a letter "M" which indicates tha the class is changed locally. + +'''Workding directory'''
+Working directory for the command is set here. + +'''Input'''
+Input, if any, of the command is set here.
+If the option "As file name" is checked, the text specified is treated as a file name in which actual input is stored. + +'''Output'''
+Expected output, if any, of the command is set here.
+If the option "As file name" is checked, the text specified is treated as a file name in which actual output is stored.
+If the option "Enabled" is not checked, the output will be ignored. + +'''Error'''
+Expected error, if any, of the command is set here.
+If the option "As file name" is checked, the text specified is treated as a file name in which actual error is stored.
+If the option "Enabled" is not checked, the error will be ignored.
+If the option "Redirected to output" is checked, error of the command will be redirected to output. + +'''Exit code'''
+Expected exit code of the command is set here.
+If the option "Enabled" is not checked, the exit code will be ignored.
+ + +In the above output, error, exit code sections, if more than one are enabled, they are treated as "and-ed". For example if output and exit code are enabled, this criterion is evaluated to True only if the actual output from the command matches the expected output and the exit code from the command matches the expected exit code. + + +'''is_unique'''
+'''Syntax:''' is_unique
+'''Applicable on:''' Feature
+'''Remark:''' This criterion will evaluate to True if the candidate feature is an unique feature.
+ + +'''is_used'''
+'''Syntax:''' is_used
+'''Applicable on:''' Local
+'''Remark:''' This criterion will evaluate to True if the candidate local is used.
+ + +'''is_used_in_library'''
+'''Syntax:''' is_used_in_library
+'''Applicable on:''' Group
+'''Remark:''' This criterion will evaluate to True if the candidate group is used in some library instead of only referenced by current application.
+ + +'''is_visible'''
+'''Syntax:''' is_visible
+'''Applicable on:''' Class, Generic, Feature, Assertion, Argument, Local
+'''Remark:''' This criterion will evaluate to True if the candidate code element is visible from the input domain of current calculated metric.
+Visibility of a class means that if that element is visible from the input domain of the metric. To explains it more clearly, let's see an example:
+ +[[Image:system-hierarchy|system hierarchy]] + +The figure shows the group hierarchy of a Vision2 application. library base and vision2 are used by the application. And notice that library wel is used internally by vision2 library but not by the application. This means that classes defined in wel library is not visible to the application thus one cannot use those wel classes in application. + +And if we create the following basic metric and run it with current application target as input domain: + +[[Image:visible-metric|visible]] + +We'll get all classes in the application including those classes in wel library because every class is descendant of class ANY. + +But if we do things a little bit differently, we create the following metric and run it with current application target as input domain: + +[[Image:visible-metric2|visible]] + +Then we will get all visible classes in current application target. i.e., those classes in wel library (any maybe some other invisible classes as well) are filtered out. + +Visibility of a generic, feature, assertion, argument, local is determined by its written in class. + + +'''true'''
+'''Syntax:''' true
+'''Applicable on:''' Target, Group, Class, Generic, Feature, Assertion, Argument, Local, Line
+'''Remark:''' This criterion always evaluates to True.
+ + + + + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-reference/metrics-tool/definitions/domains.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-reference/metrics-tool/definitions/domains.wiki new file mode 100644 index 00000000..1bbdbcd7 --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-reference/metrics-tool/definitions/domains.wiki @@ -0,0 +1,64 @@ +[[Property:title|Domains]] +[[Property:weight|9]] +[[Property:uuid|128ecc21-9d82-d590-fc3e-d0fe52991ac1]] +A domain is a list of code elements, it can contain different kinds of code elements. A domain is used as input to a metric, as output of a metric to review some details, and as an argument passed to some criteria. Domain is used to specify scope. + +==Domain Convention== + +Before we go to real domain examples, we introduce a simple convention to describe a domain: +* Group element is written in lower case, for example: base, thread +* Class element is written in UPPER case, for example: ANY, LINKED_LIST +* Feature element is written in CLASS_NAME.feature_name, i.e, its associated class will be presented also in upper case and the feature name will be in lower case. For example, ANY.is_equal, STRING_8.is_equal +* All items in a domain will be in curly braces + +For example, {ANY, STRING_8.as_lower, base} defines a domain with 3 elements, a class ANY, a feature as_lower which is in class STRING_8, and a group base. + +Suppose we have a basic metric called '''Classes''' which counts the number of classes. Before calculating the metric, we need to specify an input domain. This input domain tells metrics system over which scope the metric is calculated. And after calculating a basic metric, for sometimes, we not only want to know the value of that metric, but we are also interested in which are the actual items that adds up to that value. This detailed item list is also accessible for a basic metric if detailed results are specified to be kept before metric calculation, and it is called output domain. + +==Domain Examples== + +As a real example, go to Metrics tool in EiffelStudio, select Metric Evaluation panel, select metric '''Classes''' in the "Select metric" area, and set input domain in the "Setup input domain" area. See the following figure, in which the input domain is set to {base, APPLICATION}. + +[[Image:domain-example1|Defining an input domain]] + +After running the metric, you should see the following result in the Detailed Result panel shown in the following figure: + +[[Image:domain-example2|Metric detailed result]] + +{{note|an element can appear more than one time in a domain, but the detailed result list show only distinct items, so it is possible that the calculated metric value is not equal to the number of items in the detailed result list.}} + + +A domain can be used as an argument of a relation criterion, see the following example: + +[[Image:domain-example3|Domain criterion]] + +Here, we define a class basic metric, and in the definition area, we specify a criterion named ancestor_is which is a relation criterion. In that criterion, we set a domain {ANY} as its criterion domain. This metric reads: Count classes whose ancestor is class ANY. Put another way, this metric will find descendants of class ANY. + +Now, let's have a look at some examples using delayed item and input domain item. + +Suppose we have the following feature metric created in the following figure: + +[[Image:domain-example4|Delayed domain item]] + +When this metric is calculated over input domain {APPLICCATION}, this means that for every feature from class APPLICATIOIN, we check if it satisfies the defined criterion which is callee_is {Delayed item}. And because of this delayed item, the actual semantic is: For a feature from class APPLICATION, say foo, check if foo satisfies criterion callee_is {APPLICATION.foo}. i.e., the delayed item is replaced by the actual candidate feature. + +One may wonder why the concept of delayed item is useful. The answer is that it is powerful when used with other criteria, such as criterion value_of_metric_is. See documentation of value_of_metric_is for details. + +Now, an example of Input domain item. Suppose we created the following class basic metric in the following figure: + +[[Image:domain-example5|Input domain item]] + +And when this metric is calculated over input domain {APPLICATION}, the domain criterion Input domain in ancestor_is criterion will be replaced by the specified input domain, i.e., {APPLICATION}, and the metric will use the current application target as its input domain instead. Put another way, the metric is semantically equal to the following one shown in the following figure: + +[[Image:domain-example6|Actual semantic for input domain item]] + +{{note|Only code element target, group, folder, class, feature, delayed item, input domain item and application target can be specified through domain selector in Metrics tool. And code element generic, assertion, argument, local, line cannot be specified in domain selector, but they may present in the detailed result domain list.}} + + +{{seealso|
+[[Units|Units]]
+[[Scopes|Scopes]] }} + + + + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-reference/metrics-tool/definitions/elementary-and-composite-metrics.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-reference/metrics-tool/definitions/elementary-and-composite-metrics.wiki new file mode 100644 index 00000000..4d10f0c8 --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-reference/metrics-tool/definitions/elementary-and-composite-metrics.wiki @@ -0,0 +1,36 @@ +[[Property:title|Elementary and composite metrics]] +[[Property:weight|4]] +[[Property:uuid|ef89f3c3-180e-3390-74b5-d6d537921453]] +Some of our metrics will be elementary and some composite. An elementary metric is measured directly from the product or a project record: + +{{definition|Elementary product metric, elementary process metric|
+- An '''elementary product metric''' is a product metric whose values (integers) indicate the number of occurrences of a certain pattern in a product.
+- An '''elementary process metric''' is a process metric whose values reflect measurements drawn directly from project records. }} + +An example of elementary product metric is the number of source lines. An example of elementary process metric is the number of incremental compilations of a system. + +Elementary metrics are provided by default by the metric tool. There is no means to remove them or to define new ones since they are not expressed as a combination of other metrics. + +From these elementary metrics we may define composite ones: + +{{definition|Composite metric|A '''composite metric''' is a metric whose values are defined by a mathematical formula involving other metrics (elementary, or previously defined composite metrics). }} +A later section will introduce a number of operations for defining composite metrics out of elementary ones. +Again we may distinguish between product and process: + +{{definition|Composite product metric, composite process metric|
+- A '''composite product metric''' is a composite metric defined entirely in terms of product metrics.
+- A '''composite process metric''' is a composite metric whose definition involves one or more process metrics. }} + +By convention, this definition treats as process metric as a composite metric involving both product and process components. + +The classification introduced for metrics extends to measures, so that we may talk about an elementary product measure, a composite process measure and so on. + +{{seealso|
+[[Attributes, metrics and measures|Metrics]]
+[[Scopes|Scopes]]
+[[Domains|Domains]]
+[[Selection Criteria|Selection criteria]] }} + + + + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-reference/metrics-tool/definitions/index.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-reference/metrics-tool/definitions/index.wiki new file mode 100644 index 00000000..ef5f199d --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-reference/metrics-tool/definitions/index.wiki @@ -0,0 +1,7 @@ +[[Property:title|Definitions]] +[[Property:weight|2]] +[[Property:uuid|a562c37f-843c-cbbc-def5-32cda604f269]] +The metric tool needs a consistent metric theory on which to rely. Indeed, metrics are notoriously subject to abuse and we must be really accurate when defining metrics and related notions. + +This section introduces a set of definitions essential to handle the metric tool. + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-reference/metrics-tool/definitions/measurement-archive.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-reference/metrics-tool/definitions/measurement-archive.wiki new file mode 100644 index 00000000..da4f87a3 --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-reference/metrics-tool/definitions/measurement-archive.wiki @@ -0,0 +1,24 @@ +[[Property:title|Measurement archive]] +[[Property:weight|10]] +[[Property:uuid|e1e3e779-e4ca-faee-12b5-f47c8adde174]] +If you want to perform measurements on a system that you are building, the scopes of interest are the first four listed: Feature, Class, Cluster and System. Information on either of these scopes will be provided by the development environment (as with EiffelStudio 5.x); alternatively, you could get it simply by parsing the source of your system. But what if you also need quantitative data on other systems, if only for purposes of seeing how your results compare to the quantitative properties of other people's work? + +It would be impractical in this case to require tools that have access to as much information on external systems as on your own. All we really need is a record of previous measurements on these systems. This explains the fifth scope type, Archive: beyond the scope of the current system, all we require to define a scope is a '''measurement archive''', or just "archive" for short. This is simply a file (or part of a file) that retains, in a suitable format (XML-based), the results of measurements made earlier on one system. The file can be local or accessible as a URL on the Internet. + +The ability to use a measurement archive as a scope means that: + +* A project may set up a measurement archive as the record of its measures. + +* A department or company may set up a measurement archive for all projects on which it keeps metric information. + +* The provider of the development environment, such as Eiffel Software, may publish a set of measurement archives giving metric information for reference projects, such as the EiffelBase library (designed in part as a showcase of Eiffel technology). Eiffle Software indeed intends to include a '''metrics''' directory, with a set of measurement archives for reference tools and libraries, in forthcoming releases of EiffelStudio and at [http://www.eiffel.com/ http://www.eiffel.com/] . + +The metric tool provides an easy way to create, update or compare archives in the Metric Archive tab. Simply select tab archives. + +The metric tool automatically creates a sub folder named "Metrics" in the current location of the loaded project. It is recommended, but not compulsory, to save created archives in that folder, since it has been provided for metric needs. + +We hope that once the facilities described here are available users will adopt the practice of publishing measurement archives; it's a way of providing quantitative reference information, useful to everyone, without revealing anything critical about the actual contents of the software. (For further protection one may envision an independent group that anonymizes the data after verifying the authenticity of the source.) + + + + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-reference/metrics-tool/definitions/metric-framework-and-theory.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-reference/metrics-tool/definitions/metric-framework-and-theory.wiki new file mode 100644 index 00000000..be931885 --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-reference/metrics-tool/definitions/metric-framework-and-theory.wiki @@ -0,0 +1,25 @@ +[[Property:title|Metric framework and theory]] +[[Property:weight|3]] +[[Property:uuid|5e76bd87-b7a7-8307-0e9e-ca9bb31db0f9]] +You will want to rely not on a single metric but on a combination of metrics: + +{{definition|Metric framework|A '''metric framework''' is a set of definitions of metrics. }} + + +Any metric work should be backed by a theory: + +{{definition|Metric theory|A '''metric theory''' is a combination of:
+- A metric framework
+- A set of definitions of attributes (qualitative or quantitative)
+- A mapping from the framework to the set of attributes, representing the hypothesis that each metric is a good predictor of the associated attribute }} + +This note does not introduce a metric theory, but defines a metric framework by introducing a number of metrics. + + + +{{seealso|
+[[Attributes, metrics and measures|Attributes, metrics and measures]] }} + + + + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-reference/metrics-tool/definitions/predefined-raw-metrics.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-reference/metrics-tool/definitions/predefined-raw-metrics.wiki new file mode 100644 index 00000000..ee3c6209 --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-reference/metrics-tool/definitions/predefined-raw-metrics.wiki @@ -0,0 +1,197 @@ +[[Property:title|Predefined raw metrics]] +[[Property:weight|7]] +[[Property:uuid|12906fea-78e3-3539-27d7-83662829b59e]] +The environment should make it possible, for any project, to apply the elementary metrics in the following table, each with an associated unit and a one-identifier name. Each of the major divisions of the table starts with a raw metric, for example Classes, and, when appropriate, continues with selection criteria that yield derived metrics based on that raw metric, for example Deferred_classes. +{| +|- +| '''Basic Count''' +| '''Criterion''' +| '''What to count''' +| '''Unit''' +|- +| Classes +| +| Classes of a cluster or system +| Class +|- +| Deferred +| Deferred classes (not completely implemented, as opposed to "effective", completely implemented). +|- +| Invariant equipped +| Classes having an invariant +|- +| Obsolete +| Classes marked as superseded by newer alternatives +|- +| Dependents +| +| Classes on which a class depends, directly or indirectly +| Class +|- +| Clients +| Direct clients +|- +| Heirs +| Direct heirs in inheritance structure +|- +| Parents +| Direct parents in inheritance structure +|- +| Suppliers +| Direct suppliers +|- +| Indirect clients +| Indirect clients +|- +| Indirect heirs +| Indirect heirs in inheritance structure +|- +| Indirect parents +| Indirect parents in inheritance structure +|- +| Indirect suppliers +| Indirect suppliers +|- +| Self +| The class itself (value always 1) +|- +| Groups +| +| Groups of a system or sub-clusters of a cluster +| Group +|- +| Compilations +| +| Compilations since start of project +| Compilation +|- +| All features +| +| Inherited and immediate features of a class +| Feature +|- +| Attributes +| Attributes (features represented by fields in instances of the class, as opposed to routines, represented by algorithms) +|- +| Deferred +| Deferred routines (not implemented, as opposed to effective features, which are implemented) +|- +| Exported +| Features available to all clients +|- +| Functions +| Value-returning routines +|- +| Postcondition equipped +| Routines having a postcondition +|- +| Precondition equipped +| Routines having a precondition +|- +| Queries +| Value-returning features, including both attributes and functions (routines returning a result, as opposed to procedures) +|- +| Inherited +| Features obtained from a parent (possibly in a different form) +|- +| Immediate features +| +| Immediate features of a class +| Feature +|- +| Attributes +| Attributes (features represented by fields in instances of the class, as opposed to routines, represented by algorithms) +|- +| Deferred +| Deferred routines (not implemented, as opposed to effective features, which are implemented) +|- +| Exported +| Features available to all clients +|- +| Functions +| Value-returning routines +|- +| Postcondition equipped +| Routines having a postcondition +|- +| Precondition equipped +| Routines having a precondition +|- +| Queries +| Value-returning features, including both attributes and functions (routines returning a result, as opposed to procedures) +|- +| All feature assertions +| +| Clauses in routine's assertion, whether inherited or not +| Assertion +|- +| Postcondition clauses +| Clauses in postcondition +|- +| Precondition clauses +| Clauses in precondition +|- +| Immediate feature assertions +| +| Clauses in routine's assertion, not inherited +| Assertion +|- +| Postcondition clauses +| Clauses in postcondition +|- +| Precondition clauses +| Clauses in precondition +|- +| Invariant clauses +| +| Clauses in invariant +| Assertion +|- +| Formal generics +| +| Formal generic parameters of a class +| Generic +|- +| Constrained +| Formal parameters constrained by a type other than ANY +|- +| All formals +| +| Formal argument of a routine whether inherited or not +| Local +|- +| Immediate formals +| +| Formal argument of a routine. +| Local +|- +| Lines +| +| Source lines +| Line +|- +| All locals +| +| Local entities of feature whether inherited or not (excluding Result) +| Local +|- +| Immediate locals +| +| Local entities of feature (excluding Result) +| Local +|} + +A few comments on specific entries: +* The list of criteria for Features does not include Routines because a routine is a feature that is not an attribute; to obtain the number of routines, just count features that do not satisfy the Attributes criterion. +* The selection criteria Attributes and Deferred for Features are, a noted earlier, not independent, since attributes may not be deferred. +* Another case of dependency: a procedure is never part of Queries but always a command. Queries, however, include both Attributes and Functions. +* Two more cases of dependency: Redeclared and Renamed can only be satisfied for features that are inherited. A feature that is not inherited, but introduced fresh in the enclosing class, is called immediate. +* The Redeclared attribute has three values: a feature is redefined if it was effective in the parent, or it was deferred in the parent and the new class keeps it deferred with a different signature or contract; it is effected if it was deferred and the class makes it effective; or it may be neither of these. + +All metrics listed are product metrics with one exception: Compilations, the only process metric, counting the number of compilations of the project. There is room for more process metrics, such as cost estimates; this requires standard formats letting project managers enter the appropriate information, a point that future versions of the metrics policy described here may develop further. + +There is also room for elementary product metrics other than those in the preceding table. In fact, every syntactic construct is a candidate for an elementary metric that simply counts the number of its occurrences; but we should limit ourselves to those that we judge interesting. The metrics literature also suggests elementary metrics assessing complexity of the control structure through properties of the control graph (McCabe), or routine coherence through such properties as the number of attributes accessed by a routine; we should only add them if we can find convincing arguments for their theoretical soundness. + + + + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-reference/metrics-tool/definitions/raw-metrics-and-selection-criteria.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-reference/metrics-tool/definitions/raw-metrics-and-selection-criteria.wiki new file mode 100644 index 00000000..cc3609e6 --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-reference/metrics-tool/definitions/raw-metrics-and-selection-criteria.wiki @@ -0,0 +1,48 @@ +[[Property:title|Raw metrics and selection criteria]] +[[Property:weight|5]] +[[Property:uuid|99f51fd0-4439-08f5-9419-53c8771b50f8]] +Elementary metrics measure patterns whose occurrences (in a product or process) can be counted. We need to decompose this notion further to avoid an explosion of the number of elementary metrics. For example the features of a class can be classified along several lines: +* Some are attributes (object fields), others are routines (algorithms). +* Some are inherited from a parent, others immediate (defined in the class). +* Some are exported, others secret + +and so on. Many combinations of these properties may be worth counting on their own: you may ask for the number of secret attributes, of exported inherited features and so on. But if we define all of these metrics independently, we will soon have too many elementary metrics, while still failing to satisfy user needs if we have omitted a particular combination. + +To avoid this we must identify a subset of elementary metrics as '''raw metrics''': metrics whose results are counted directly. "Number of features in a class" is a raw metric. From a raw metric, we may then derive other elementary metrics by applying '''selection criteria''' such as "Is this feature an attribute?" or "Is this feature exported?" Here are the definitions: + +{{definition|Raw metric, selection criterion, derived metric|
+An elementary metric is either '''raw''' or '''derived'''. A '''selection criterion''' for a raw metric is a property, with a fixed set of possible values (two or more), characterizing the patterns or events being counted by the metric.
+A '''derived metric''' is an elementary metric defined from a raw metric by counting only the patterns satisfying a certain combination of its selection criteria. }} + +A set of raw metrics and selection criteria is provided by default by the metric tool, see [[Predefined raw metrics|predefined raw metrics and selection criteria]] + +To define a derived metric, we start from a raw metric, for example "number of features", and combine some of the associated selection criteria. The combination may be: +* An "or": for example, count all the features that are attributes or exported (or both). +* An "and": count all the features that are both attributes and exported. + +A selection criterion may have more than two possible values. Most, as in these examples, have just two: a feature is either an attribute or a routine; it is either exported or secret. + +The definition states that every derived metric is derived from a certain raw metric or from another derived metric. + +As a general guideline, we will try to keep the selection criteria for a given raw metric independent. For example, to distinguish the classes that inherit a given class we will use the following selection criteria: +* Heirs: count the number of direct heirs of a class. +* Indirect_heirs: count the number of indirect heirs. +* Self: count only the class itself. + +Other interesting notions are "proper descendant", covering direct and indirect heirs, and "descendant", covering proper descendants and descendants. We do not introduce these as separate criteria, since this would result in a non-independent set of criteria: every proper descendant is a descendant, every heir (direct or indirect) is a proper descendant. + +Instead we limit ourselves to the three criteria listed above. If you need a finer decomposition, it is easy, with the techniques discussed below, to define Proper_descendants and Descendants as composite metrics expressed in terms of the elementary metrics Heirs, Indirect_heirs and Self. + +This criterion independence principle is not absolute, however, and in some cases we may find it clearer to define a new criterion even though its value is entirely determined by certain values of another. For example one criterion on features determines whether it is an attribute or a routine, another whether it is deferred or effective. An attribute is always effective, so the two criteria are not independent. Even though we could remove the dependency by using a single criterion with three values (attribute, effective routine, deferred routine), it is more convenient to keep two criteria. Of course the underlying counting mechanisms must make sure never to count an element twice even in an "or" query, as when a user asks for the number of features that are attributes or effective. + +A metric is either elementary or composite. An elementary metric is either a raw metric, such as "number of features", or a derived metric obtained from slicing a raw metric by selection criteria. Composite metrics are obtained from existing metrics (elementary, or previously defined composite metrics) by applying some mathematical formula. + +{{seealso|
+[[Elementary and composite metrics|Elementary metrics]]
+[[Selection Criteria|Selection Criteria]]
+[[Criterion References|Selection criterion reference]]
+[[Defining derived metrics|Defining derived metrics]] }} + + + + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-reference/metrics-tool/definitions/scopes.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-reference/metrics-tool/definitions/scopes.wiki new file mode 100644 index 00000000..e576a61a --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-reference/metrics-tool/definitions/scopes.wiki @@ -0,0 +1,28 @@ +[[Property:title|Scopes]] +[[Property:weight|8]] +[[Property:uuid|303fb469-9f2b-d7cc-55e7-d657fb87b8fe]] +Every metric has a scope: + +{{definition|Scope of a metric|
+The '''scope''' of a metric is defined as follows:
+- For a raw product metric, the type of product over which the metric is counted, such as: a feature, a class, a group, an archive built for a given system to make it possible to compare systems.
+- For a raw process metric, the type of process on which the metric is measured, such as analysis, documentation, entire project etc.
+- For a derived metric (recursively), the scope of the raw metric from which it is derived.
+- For a composite metric (recursively), the largest of the scopes of all its constituent metrics, where cluster is "larger than" class and so on. }} + + + +This notion also applies to measures: + +{{definition|Scope of a measure|
+The '''scope''' of a measure is defined as follows:
+- For an elementary measure (the application of an elementary metric, raw or derived), the set of products or processes to which the associated metric has been applied to yield the measure.
+- For a composite measure, the union of (recursively) the scopes of its constituent measures. }} + +For both metrics and measures, the notion of scope will help us compare our quantitative assessments to some already on record. For example you may compare the value of a certain metric, such as number of invariant clauses in each class, with the values that have been archived for your project, for a reference project such as the EiffelBase library, for the previous projects of your company, or for a global set of previous projects maintained at some central location. You may also, with appropriate permissions, update such a shared archive with the values from your own measurements. + +In the environment, the notion of scope will be handled by defining an input domain. If the input domain contains a duplicated elements, the computation is done twice on the duplicated elements. + + + + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-reference/metrics-tool/definitions/selection-criteria.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-reference/metrics-tool/definitions/selection-criteria.wiki new file mode 100644 index 00000000..87b6b676 --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-reference/metrics-tool/definitions/selection-criteria.wiki @@ -0,0 +1,116 @@ +[[Property:title|Selection Criteria]] +[[Property:weight|6]] +[[Property:uuid|d492c7f5-71ec-ae04-c62b-6845f30ed762]] +A selection criterion is used to filter out candidate code elements and only leave and count those satisfied elements. For example, criterion is_deferred in a basic class metric is only satisfied when a candidate class is deferred. A selection criterion can have modifiers which indicate how the associated criterion will perform its filtering task. There are four kinds of modifiers, shown as follows: +* Text modifier - String text, and this text is called criterion text +* Domain modifier - Domain, and this domain is called criterion domain +* Metric modifier - Metric, and this metric is called criterion metric +* Normal modifier - modifier other than text, domain and metric + +Let's first introduce a convention to describe selection criteria: +* Criterion name will be followed by modifiers (separated by a comma) if any +* Text modifier will be in double quotes +* Domain modifier will follow the convention of domain +* Metric modifier will be in bold +* Normal modifier will be in normal font and face +* Braces will be added to avoid ambiguity + +Some examples: + +is_deferred + +text_is "some text", identity, case-sensitive + +ancestor_is {ANY} + +value_of_metric_is '''Class''', {base}, (>0 and <100) + +There are several kinds of selection criteria, namely, text criterion, path criterion, relation criterion, metric value criterion and normal criterion. + +==Text Criterion== + +Text criterion uses a text modifier, two normal modifiers (one to specify matching strategy and the other to specify case sensitivity) to perform text pattern matching. Criterion such as name_is and text_is are text criteria. + +Let's take text criterion name_is as an example: + +The syntax for name_is is: + +name_is "pattern", matching_strategy, case_sensitive + +The match_strategy modifier decides how criterion text "pattern" is matched, and can choose from one of the following four values: +* Identity - Pattern is matched if the text is identical to criterion text + +* Containing - Pattern is matched the text contains criterion text + +* Wildcard - Pattern is matched if it occurs in criterion text according to wildcard rules + +* Regular expression - Pattern is matched if it occurs in criterion text according to regular expression rules + + +The case_sensitive modifier can be True or False, it indicates if pattern matching is case sensitive or not. + +In the following two figures, name_is criterion is shown. That criterion will select all classes whose name starts with a letter A (using regular expression rules) case-insensitively. + +[[Image:selection-cri1|Text criterion]] + +[[Image:selection-cri2|Text criterion]] + +==Path Criterion== + +A path criterion uses a text modifier as path to test if a candidate class is located in that path. There are two path criteria, namely, path_is and path_in. + +The path uses Unix format. For example, criterion path_is "/kernel" will evaluate to True if a candidate class is located in kernel folder related to the class's group. On Windows, path matching will be case-insensitive, on other platforms, path matching will be case-sensitive. + +The following figure shows a path criterion used to find classes which locate in "kernel" folder: + +[[Image:selection-cri3|Path criterion]] + +==Relation Criterion== + +A relation criterion uses a criterion domain to check if a candidate code element is of some relationship between the criterion domain. Some other modifiers may also appear in a relation criterion. + +Let's have look at a class relation criterion client_is shown in the following two figures where a basic class metric with relation criterion client_is is defined. This client_is criterion will match all direct normally referenced as well as only syntactically referenced suppliers of class LINKED_LIST. + +[[Image:selection-cri4|Relation criterion]] + +[[Image:selection-cri5|Relation criterion]] + +For more information about normally referenced and only syntactically referenced suppliers, see document of relation criterion client_is. + +==Value Criterion== + +Value criterion is used to test if calculated value of a given metric satisfies some values. There is only one criterion named value_of_metric_is in this category. Please see the document for value criterion value_of_metric_is for more information. + +The following figure shows the use of value_of_metric_is criterion, where a class basic metric is defined to find classes whose lines of code is over 1000: + +[[Image:selection-cri6|Relation criterion]] + +The following figure shows the result of the above metric: + +[[Image:selection-cri7|Relation criterion]] + +==Normal Criterion== + +All other criteria except for those described above are called normal criteria. + +Some examples: + +is_library - test if a candidate group is a library + +is_deferred - test if a candidate class or feature is deferred + +is_comment - test if a candidate line is comment + +==Criterion Connector== + +There are three criterion connectors: and, or, not. They are self-explanatory. Just a simple example, see the following figure: + +[[Image:selection-cri8|Relation criterion]] + +{{seealso|
+[[Domains|Domains]]
+[[Criterion References|Selection criterion reference]] }} + + + + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-reference/metrics-tool/definitions/under-hood-how-metrics-work.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-reference/metrics-tool/definitions/under-hood-how-metrics-work.wiki new file mode 100644 index 00000000..013586ef --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-reference/metrics-tool/definitions/under-hood-how-metrics-work.wiki @@ -0,0 +1,52 @@ +[[Property:title|Under the Hood - How metrics work]] +[[Property:weight|11]] +[[Property:uuid|4b81b16a-0c46-8d5a-c5b5-346ea01c58ee]] +This part explains how a product basic metric is calculated. + +==Domain Transformation== + +As you have seen, before calculating a product basic metric, two things have to be specified: +* A metric, and every metric has a unit +* An input domain + +And two facts follows: +* the specified metric will count the number of the code elements specified by the metric unit +* An input domain can contain any kinds of code elements + +For example, in the following figure, a metric as well as its input domain are specified: + +[[Image:hood1|Actual semantic for input domain item]] + +Here the selected metric is '''Compiled classes''', and the input domain is {base}, and when calculating, all compiled classes in library base will be found and counted. The result is shown in the following figure: + +[[Image:hood2|Actual semantic for input domain item]] + +But how are those compiled classes found in library base? The answer is through an operation called domain transformation. + +A domain transformation will transform a source domain into a destination domain with a specified product unit. This means that a product unit has to be specified to indicate what kind of code element will appear in a destination domain. A product unit can be one of the following: target, group, class, generic, feature, argument, local, assertion, line. + +A domain transformation is done like this: For every code element in source domain, all code elements of the destination unit that can be found (with the help of the compiler) in that source code element are put into the destination domain. + +Let's continue to use the above '''Compiled classes''' example. The input domain {base} is source domain, and the result domain of the metric is the destination domain here. The destination unit is class which is the unit of the specified metric '''Compiled classes'''. + +So for a source code element (here it is base), find all classes in that element (base), and put them in the destination domain. Now we get a destination domain which contains all candidate classes. Those classes are called candidates because we only want some of them. And the filtering is done with the specified criterion is_compiled. After that, you get the actual result domain. + +It's quite easy to understand the group to class transformation. But what if I want some features now? Just do consecutive transformations: from group to class first, and then from class to feature. + +We call a transformation from an element to another element a route, consecutive transformations a path. All possible transformation paths are shown in the following figure: + +[[Image:hood3|Actual semantic for input domain item]] + +Some remarks on the transformation paths: +* If you go through the path from the end of an arrow to its head, you'll possibly find results, but if the transformation is done in the reversed direction, nothing will be found. For example, in any cases, the destination domain will be empty (indicating nothing is found) if you do a transformation from a line element to a class element. +* Code element line appears in the path: Target -> Group -> Class -> Line because typically in an Eiffel class, there are some lines that do not belong to any features, such as class note lines or inherit clauses. +* The shortest path will always be used. So if you transform a target element to a line element, the path: Target -> Group -> Class -> Line will be used instead of Target -> Group -> Class -> Feature -> Line +* Paths from element to the element of the same unit are omitted. i.e., there are paths such as Target -> Target, Group -> Group, Class -> Class + +==Domain Filtering== + +After domain transformation, we get a destination domain with all candidate code elements. Then we perform a filtering operation using the specified criterion in a basic metric to get rid of all unsatisfied candidates. At last, we'll get the desired result domain. Using the above example, for every class in the destination domain, we test if that class is compiled using the specified criterion is_compiled. If it's a compiled class, keep it in the destination domain, if not, remove it from the destination domain. + + + + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-reference/metrics-tool/definitions/units.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-reference/metrics-tool/definitions/units.wiki new file mode 100644 index 00000000..2f054159 --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-reference/metrics-tool/definitions/units.wiki @@ -0,0 +1,137 @@ +[[Property:title|Units]] +[[Property:weight|2]] +[[Property:uuid|fa08d5aa-7ea4-e7bb-bb59-e4982a583976]] +Metrics will be expressed in units, such as Line (numbers of source lines) or Feature (number of features). + +{{rule|name=Unit rule|text=The definition of any metric must specify an associated unit. }} + + +Different metrics may be marked with the same unit; for example metrics such as number of non-comment lines and number of comment lines may both be marked with the unit Line. + +Whenever we need to express ratios of one measurement to another, as in computing the average number of features per class by dividing the number of features by the number of classes, we will use a specific unit, Ratio: + +{{definition|Ratio unit|The name Ratio denotes a predefined unit, whose values are arbitrary real numbers, expressed either as numbers or in percentage style (as in 35.3%). }} + +As a result of this choice, we will consider every division to yield a result of unit, Ratio. + +The following predefined units are available in the metric tool: +{| +|- +| '''Unit''' +| '''Quantities measured''' +| '''Kind''' +|- +| Class +| Number of classes or types +| Product +|- +| Generic +| Number of class generics +| Product +|- +| Feature +| Number of features +| Product +|- +| Target +| Number of targets +| Product +|- +| Group +| Number of groups +| Product +|- +| Assertion +| Number of assertion clauses +| Product +|- +| Argument +| Number of arguments of a routine +| Product +|- +| Local +| Number of locals of a routine +| Product +|- +| Line +| Number of source lines +| Product +|- +| Compilation +| Number of compilations +| Process +|- +| Ratio +| Results of divisions +| Product +|} + +The units listed here are '''minimal''' in the sense that it is not possible to add the properties measured by any two of them; for example it makes no sense to add a number of features to a number of classes. + +In the future, it might be desirable to include more specific units, such as "features per class" , and an associated calculus of units (as in the physical sciences, where multiplying a quantity expressed in g /cm by one in cm yields a result in g). This has not appeared necessary for the typical uses of division envisioned in this note, answering such questions as "What percentage of routines have a header comment" can all be expressed simply as ratio. + +==Code Element== + +For most of units, an item of that unit represents a code element in a real system. For example, an item of class unit represents a class and an item of line unit represents a line of code. All supported code elements are listed as follows: +{| +|- +| '''Code Element''' +| '''Unit''' +| '''Description''' +|- +| Class +| Class +| Represents a class +|- +| Generic +| Generic +| Represents the piece of the code related to generics definition in a class definition. +|- +| Feature +| Feature +| A feature or an invariant clause. In metrics tool, a feature can be one of two things: a traditional feature, or an invariant clause. That is to say, an invariant clause is treated as a special feature. To avoid ambiguity, we call a traditional feature a "feature" and an invariant clause an "invariant feature". +|- +| Target +| Target +| Represents a target +|- +| Group +| Group +| Represents a group in system. A group can be either a cluster, a library or an assembly +|- +| Assertion +| Assertion +| Represents an assertion +|- +| Argument +| Argument +| Represents a formal argument in features +|- +| Local +| Local +| Represents a local defined in features +|- +| Line +| Line +| Represents a line of code +|- +| Folder +| - +| Represents a physical concept to store classes. The semantic of a folder in metrics tool is equal to a list all classes which are located in that folder (not recursively). So a folder item doesn't provide new functionality, it just facilitates the operation to select a set of classes. +|- +| Delayed item +| - +| A delayed item is a place holder, it will be replaced by the candidate code element over which a domain criterion is evaluated +|- +| Input domain item +| - +| An input domain item is a place holder, it will be replaced by the domain selected as input to the metric. In the case that the input domain is presents in a basic metric definition, when that metric is calculated, the metric will use the current application target as the input domain. +|- +| Current application item +| Target +| Represents the application target of the current Eiffel system +|} + + + + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-reference/metrics-tool/index.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-reference/metrics-tool/index.wiki new file mode 100644 index 00000000..be8b2e55 --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-reference/metrics-tool/index.wiki @@ -0,0 +1,13 @@ +[[Property:title|Metrics tool]] +[[Property:weight|-5]] +[[Property:uuid|e76d1c3b-773f-c051-bd94-3272f3ccadc6]] +One of the innovations of the EiffelStudio development environment is a set of metric facilities enabling developers and managers to obtain quantitative information about software systems and the process of producing them. +* Find out basic quantitative properties of a system, such as the number of classes, the number of features, how many times the system has been compiled and many others +* Define new properties as mathematical combinations of the basic ones, and compute the resulting values, to get the answers to such questions as what percentage of my system's routines have precondition clauses' or what is the average number of features, lines, or invariant clauses per class? +* Vary the scope of such measurements, so that the measured result may cover a single feature, a class, a cluster, an entire system or an archive of another system to make comparisons with other projects. +* Compare the result of the same metric over several of these scopes, to see for example how a project differs from those on record, or whether some parts of a project depart from the norms applied in others. + +The environment will support such measurements through a simple graphical interface, closely integrated with the rest of the Eiffel Explorer. Users of the environment can start applying these facilities to their systems without learning any theory. + +Metrics, however, are notoriously subject to abuse; we must be wary of the temptation to revere numbers just because they are numbers (lies, damn lies and metrics). This note presents a simple approach to software metrics designed to establish a clear and sound basis, so that we know what we are measuring, why we are measuring it, and how much value we may attach to the results. + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-reference/metrics-tool/requirements.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-reference/metrics-tool/requirements.wiki new file mode 100644 index 00000000..ff13c2cc --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-reference/metrics-tool/requirements.wiki @@ -0,0 +1,20 @@ +[[Property:title|Requirements]] +[[Property:weight|1]] +[[Property:uuid|834b134f-b4a5-08a7-e41c-804c0954b008]] +All engineering disciplines other than software rely on quantitative approaches to design their products, organize the production process, and assess the results. Software engineering too can benefit from measuring relevant properties of its products and processes. + +Measurements are not an end in themselves; they must be related to broader goals of software engineering: + +The purpose of software measurements is to provide quantitative assessments or predictions of properties of software products and processes + +For any numerical measure that we propose we must have precise information on four properties: coverage, trustworthiness, relevance, theory. + +Any quantitative report on software products or processes should satisfy the following properties: +* '''Coverage''': include a definition of what is being measured, sufficient to enable repetition of the measurements. +* '''Trustworthiness''': include an estimate of how much the results can be believed, in particular of their precision (expected variations in case of repetition). +* '''Relevance''': specify interesting properties of software products or processes on which the measurement may provide insight. +* '''Theory:''' include arguments backing the statement of relevance. + + + + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-reference/metrics-tool/user-interface-basics/detailed-result-panel.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-reference/metrics-tool/user-interface-basics/detailed-result-panel.wiki new file mode 100644 index 00000000..cdb57772 --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-reference/metrics-tool/user-interface-basics/detailed-result-panel.wiki @@ -0,0 +1,16 @@ +[[Property:title|Detailed Result Panel]] +[[Property:weight|1]] +[[Property:uuid|35018218-cf90-5aca-dc47-205bb351592e]] +The Detailed result panel is where detailed metric result and archive comparison result are displayed. In the following two figures, a detailed metric result and an archive comparison result are shown. + +Detailed metric result: + +[[Image:interface4|Defining an input domain]] + +Archive comparison result: + +[[Image:interface5|Defining an input domain]] + + + + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-reference/metrics-tool/user-interface-basics/index.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-reference/metrics-tool/user-interface-basics/index.wiki new file mode 100644 index 00000000..bba98147 --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-reference/metrics-tool/user-interface-basics/index.wiki @@ -0,0 +1,5 @@ +[[Property:title|User interface basics]] +[[Property:weight|3]] +[[Property:uuid|c2b8d8b6-661c-1cb5-a991-388e8374c696]] +EiffelStudio includes a Metric tool based on the previously defined metric theory. This tool provides many facilities like computing measures over a project, including smaller scopes, defining new metrics according to users needs, and handling archives to compare projects. + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-reference/metrics-tool/user-interface-basics/metric-archive-panel.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-reference/metrics-tool/user-interface-basics/metric-archive-panel.wiki new file mode 100644 index 00000000..39dc8ca3 --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-reference/metrics-tool/user-interface-basics/metric-archive-panel.wiki @@ -0,0 +1,34 @@ +[[Property:title|Metric Archive Panel]] +[[Property:weight|4]] +[[Property:uuid|c8793405-c91d-c04b-10ed-07739728f697]] +The metric archive panel is used to calculate and restore metric archives and to do metric archive comparison. + +==Metric Archive Calculation== + +Let's have a look at the buttons and options related to metric archive calculataion: + +[[Image:metrics-tool--debug-run-icon|calculate archive]] Start metric archive calculation
+After selecting the metrics you want to archive and the input domain, use this button to start a metric archive calculation. + +[[Image:metrics-tool--debug-stop-icon|stop archive]] Stop metric archive calculation
+Use this button to stop a metric archive calculation. + +[[Image:interface22|archive file location]] Specify archive file
+The file to store metric archive results is specified here. + +[[Image:interface23|reset archive]] Reset archive file
+If the specified archive file already contains some archive information, this option will be sensitive. If it's enabled, the information contained in that archive file will be cleaned before new archive information is written to that file, otherwise, new archive information will be appended to that file. + +==Metric Archive Comparison== + +After you specify two archive files you can compare them, as shown in the following image: + +[[Image:interface24|Compare archives]] + +The archive comparison result is shown in the following figure: + +[[Image:interface25|archive comparison result]] + + + + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-reference/metrics-tool/user-interface-basics/metric-definition-panel.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-reference/metrics-tool/user-interface-basics/metric-definition-panel.wiki new file mode 100644 index 00000000..afe6c501 --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-reference/metrics-tool/user-interface-basics/metric-definition-panel.wiki @@ -0,0 +1,87 @@ +[[Property:title|Metric Definition Panel]] +[[Property:weight|2]] +[[Property:uuid|5a778f15-cefe-182d-a296-545ee77d3028]] +In the metric definition panel, you can do the following: +* Manage user-defined metrics, such as defining new metrics and modify or remove existing ones. Metrics with a small lock in their icons are predefined metrics which cannot be changed or remvoed +* Import metrics from other systems +* Backup user-defined metrics + + +The following figure shows the layout of the metric definition panel: + +[[Image:interface6|Metric definition panel]] + + +Let's have a look at the buttons in the main toolbar which is highlighted in the following figure: + + +[[Image:interface7|Main toolbar buttons]] + + +[[Image:metrics-tool--new-metric-icon|New metric]] New metric +Use this button to create a new metric. First you need to select a metric type (basic, linear or ratio) and then you may need to select a unit (only for basic and linear metrics). Once a metric is created, its unit cannot be changed. + + +[[Image:metrics-tool--new-document-icon|Clone metric]] Clone selected metric to a new metric +If you want to define a new metric but the new metric is quite similar to an existing one, then you can use this button to simplify your work: just clone an existing one and do the modifications. + + +[[Image:metrics-tool--general-remove-icon|Remove metric]] Remove metric +Remove current selected metric. This button will be insensitive when the current selected metric is a predefined metric. + + +[[Image:metrics-tool--general-save-icon|Save metric]] Save metric +To make your newly defined or modified metric take effect, you need to save it first. This button will be insensitive when the current selected metric is a predefined metric. + + +[[Image:metrics-tool--command-send-to-external-editor-icon|External editor]] Open user-defined metric file in external editor +Metrics are stored in XML format, and this button opens the XML file of user-defined metrics in a an external editor which can be specified in the preferences. + + +[[Image:metrics-tool--general-open-icon|Reload metrics]] Reload metrics +This button reloads all metrics including predefined and user-defined metrics. It's useful when you modify the metric XML file in an external editor and want the changes to have an effect without restarting EiffelStudio. + + +[[Image:metrics-tool--metric-export-to-file-icon|import]] Import metrics +This button opens a dialog to backup or import metrics. + + +==Define New Metrics== + +To define a new metric, you need to choose the metric type and unit (for basic metric and linear metric). The following figure shows how to choose metric type and unit: + +[[Image:interface8|Choose metric type]] + +The following figure shows a new basic class metric: + +[[Image:interface9|basic metric]] + +When defining basic metrics, you can press CTRL+Space in a cell in the criterion column (the first column in "definition" area) to get a list of all applicable criteria. You can also type "and" or "or" in that cell to get criterion connectors. And you can put "not" in front of a criterion name to get its negation. After typing the criterion name and hitting enter, if the criterion needs further setup, the property cell of that criterion will be highlighted. For domain criterion such as ancestor_is, caller_is, you can pick an item and drop it into this property cell. + +The following figure shows a new linear feature metric: + +[[Image:interface10|linear metric]] + +For every metric referenced in a linear metric, you need to specify a coefficient. You can pick a metric and drop it into a cell of the "Metrics" column in the "Metric Definition" area. + +The following figure shows a new ratio metric: + +[[Image:interface11|ratio metric]] + +For the numerator or denominator metric, you need to specify a coefficient. When the denominator part evaluates to zero, the result of the ratio metric will be "Undefined". You can pick a metric and drop it into the numerator or denominator metric area. + +==Import Metrics== + +In order to reuse metrics defined in a different system, you need to import them into current system. The following figure shows how to import metrics: + +[[Image:interface12|Import metrics]] + +==Backup User-defined Metrics== + +The following figure shows how to back user-defined metrics: + +[[Image:interface13|Backup metrics]] + + + + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-reference/metrics-tool/user-interface-basics/metric-evaluation-panel.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-reference/metrics-tool/user-interface-basics/metric-evaluation-panel.wiki new file mode 100644 index 00000000..5e88ba7f --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-reference/metrics-tool/user-interface-basics/metric-evaluation-panel.wiki @@ -0,0 +1,39 @@ +[[Property:title|Metric Evaluation Panel]] +[[Property:weight|0]] +[[Property:uuid|c31fddbb-7421-fe4b-57d3-7eea32f5e9e0]] +The Metric Evaluation panel is the place to do metric evaluation. After selecting a metric from the "Select metric" area and setting an input domain in the "Setup input domain" area, you can click the run button to start metric evaluation. You can start metric evaluation with and empty input domain and the result will be always zero. + +[[Image:interface1|Defining an input domain]] + +Let's first have a look at the buttons in the main toolbar, see the following figure in which the main toolbar is highlighted: + +[[Image:interface2|Defining an input domain]] + +[[Image:metrics-tool--debug-run-icon|Defining an input domain]] Start metric evaluation
+Press this button to start evaluating the currently selected metric. + +[[Image:metrics-tool--debug-stop-icon|Defining an input domain]] Stop metric
+Press this button to terminate a running metric evaluation. + +[[Image:metrics-tool--metric-send-to-archive-icon|Defining an input domain]] Send last result to metric history
+After a metric evaluation this button will be sensitive and clicking it will record the evaluated metric as well as its input domain and result in the metric history. This facilitates evaluating it again and lets you compare different metric runs. + +[[Image:metrics-tool--metric-run-and-show-details-icon|Defining an input domain]] Keep detailed result when evaluating metric
+Normally, evaluating a metric will give you a number as result, but sometimes, you want to investigate into those items which make up that value. For example, evaluating '''Classes''' metric over the base library gives you 242, which means there are 242 classes in the base library, and sometimes, you want to know which they are. With this option enabled, you'll have a detailed result listed in the detailed result panel after a metric evaluation. This option only has effect when evaluating basic metrics, because the detailed result has no meaning for derived metrics (linear or ratio metrics) in general. Suppose you have a linear metric defined as 5 * Classes, then the notion of detailed result has no meaning. Another use of this option is for performance: keeping a detailed result can be quite expensive in some cases, such as when you calculate the metric '''Lines of code''' for a large system, which may result in hundred of thousands of lines in the result. So turning it off in such as case may be a good idea. + +[[Image:metrics-tool--metric-filter-icon|Defining an input domain]] Filter result which is not visible from input domain
+If this option is enabled, all non visible items from the input domain will be filtered. For definition of "non visible" items, please see documentation for criterion is_visible. + +[[Image:metrics-tool--context-sync-icon|Defining an input domain]] Automatically go to result panel after metric evaluation
+If this option is enabled, the metric tool will switch to the detailed result panel after a metric evaluation. + +[[Image:metrics-tool--metric-quick-icon|Defining an input domain]] Define quick metric
+Sometimes, you want to calculate some metrics which are not defined already. For example, find a feature which is named "foo". And it may be just a one time thing, so there is no need to go to metric definition panel, define and save a metric and then go back to evaluation panel and run it. Quick metric is designed for this situation, you can defined any basic metric in the quick metric definition area. It's the same as the basic metric definition area in the metric definition panel. Just define your metric and run it. +In the following figure, a defined quick metric is shown: + +[[Image:interface3|Defining an input domain]] + + + + + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-reference/metrics-tool/user-interface-basics/metric-history-panel.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-reference/metrics-tool/user-interface-basics/metric-history-panel.wiki new file mode 100644 index 00000000..4c15b595 --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-reference/metrics-tool/user-interface-basics/metric-history-panel.wiki @@ -0,0 +1,80 @@ +[[Property:title|Metric History Panel]] +[[Property:weight|3]] +[[Property:uuid|373d7403-eb3a-3c05-787e-b4a8cb5848cb]] +The metric history panel lists all recorded metric evaluations. You can select them and reevaluate them to see the new value and if it differs from the old result. + +Lets have a look at the buttons in the main toolbar highlighted in the following figure: + +[[Image:interface14|Metric history panel]] + + +[[Image:metrics-tool--debug-run-icon|Run history]] Recalculate history
Recalculate selected metric history items + + +[[Image:metrics-tool--debug-stop-icon|Stop history]] Stop history recalculation
Stop running metric history recalculation. + + +[[Image:metrics-tool--metric-run-and-show-details-icon|Keep detailed result]] Keep detailed metric result
+If this option is enabled, the detailed metric result will be kept and will be available after a metric history recalculation. + + +[[Image:metrics-tool--metric-unit-assertion-icon|Check warning]] Check metric history warnings
If this option is enabled, specified metric history warnings will be checked. + + +[[Image:metrics-tool--general-reset-icon|Remove detailed result]] Remove detailed metric result
Remove detailed metric result, if any. + + +[[Image:metrics-tool--general-remove-icon|Remove history]] Remove metric history item
Remove selected metric history items. + + +[[Image:metrics-tool--metric-group-icon|Show tree]] Display tree view
If this option is enabled, the metric history items will be displayed in a tree view. + + +[[Image:interface16|Hide old metrics]] Hide old metric history
Hide metric history items which are calculated before the specified number of days + + +[[Image:select-all|select all history]] Select All
Select all recorded metric history items. + + +[[Image:deselect-all|deselect all history]] Deselect All
Deselect all recorded metric history items. + + +[[Image:select-recalculatable|select all calculatable]] Select all recalculatable history items
Select all recalculatable metric history items. A metric history item is recalculatable if its associated metric is valid and its specified input domain is valid. + + +[[Image:deselect-recalculatable|deselect all calculatable]] Deselect all recalculatable history items
Deselect all recalculatable metric history items. + + +==Recalculate Metric History== + +To recalculate a metric history, you need to selected those items that you want to recalculate. In the following figure, a metric history item '''Uncommented features''' is selected. + +[[Image:interface17|Select metric history]] + +After recalculating the selected metric history items, the result will be highlighted, as shown in the following figure: + +[[Image:interface18|History recalculationg result]] + +In the above figure, the row '''Uncommented features''' is highlighted indicating that this item has been recalculated. And from the row, we can see that the current value is 1 while the previous value is 0, meaning that there is one uncommented feature in cluster sample now while there was no uncommented feature in cluster sample when this metric was calculated the last time. + +==Metric History Warning Checking== + +Another thing you can do in metric history is to assign a warning tester to each item. When the metric history is recalculated with metric history warning checking enabled, the warning tester will be evaluated against the metric value to see if it's condition is satisfied. + +Let's use an example to demonstrate the idea. Suppose we have set up a metric history warning shown in the following two figures: + +[[Image:interface20|warning tester]] + +[[Image:interface19|warning tester]] + +This warning means, when the metric '''Uncommented features''' is calculated over the input domain {sample}, the value should be zero, otherwise a warning should be emitted. + +After recalculating the metric history item, we get the following result: + +[[Image:interface21|warning tester]] + +From the above result, we can see that the value of the metric '''Uncommented features''' over the input domain {sample} is 1 while our warning says it should be 0. So we get a warning message. + + + + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-reference/outputs-tool/external-compilation-pane.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-reference/outputs-tool/external-compilation-pane.wiki new file mode 100644 index 00000000..675c087e --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-reference/outputs-tool/external-compilation-pane.wiki @@ -0,0 +1,54 @@ +[[Property:title|External compilation pane]] +[[Property:weight|3]] +[[Property:uuid|26525412-e8e5-8b1c-1074-58e00aed4c76]] + + +[[Image:External compilation pane 01]] + + +==Introduction== + +During the majority of ordinary development projects in Eiffel, it may be rare for programmers to need to know what's going on with the external compilation that occurs during freezing and finalization steps. However, during the development of some types of systems, particularly those that involve interfaces to non-Eiffel components, it is helpful to monitor the external compilation. + +The external compilation pane shows a log of the compilation output from the external (typically C language) compiler. But the external compilation pane is more than just a log. It has powerful features that help you deal with the results of external compilation. + +==Selecting your locale== + +If the external compiler uses a different locale than your default locale, you can select your particular locale in the "Locale" box on the bottom bar of the Outputs tool. + +==Opening a project folder== + +You can explore a project folder by using '''open folder''' ( [[Image:general-open-icon|open]] ) on the bottom bar. When you click the triangle ( [[Image:toolbar-dropdown-icon]] ) to the right of the '''open folder''' icon, you will see a list of project folders, as shown in the figure below. + +[[Image:Outputs tool Open folder|open]] + +Selecting one of this will cause the folder to be opened by the explorer appropriate to your platform, such as Windows Explorer in the case of the Microsoft Windows platform. + +==Starting a terminal session in a project folder== + +The Outputs tool gives you a way to create a new terminal or console window targeted to one of your project folders. To do this, click the triangle ( [[Image:toolbar-dropdown-icon]] ) to the right of the '''terminal''' icon ( [[Image:terminal-icon|terminal]] ). You'll see a list of project folders like the one shown [[#Opening a project folder|above]]. Choose a folder and a terminal window will be created and targeted to the folder you selected. + +==Opening a file mentioned in the external compilation output== + +You can open a file mentioned in the external compiler output in a specified external editor by selecting the file name and then clicking the '''send to external editor''' ( [[Image:metrics-tool--command-send-to-external-editor-icon|send to external editor]] ) button, shown in the bottom bar of the following figure: + +[[Image:External compilation pane file selection|Selecting a file to open]] + +If, as is often the case with C compilation errors, a line number is adjacent to the file name, you can select the line number and the file will be opened in the external editor and the cursor positioned at that line number. + +==View external code for a class/feature== + +You can view the external code for a particular Eiffel class or feature in an external editor. Pick the class or feature whose generated code you want to see, and drop it onto the [[Image:metrics-tool--command-send-to-external-editor-icon|send to external editor]] button. The external code for the class or feature will be shown in an external editor. + +The figure below shows an example of picking the feature make and dropping it on the '''send to external editor''' button. + +[[Image:External compilation pane edit feature]] + +You can also drop a class or feature pebble on the '''open folder''' or '''terminal''' icon. This will get you to the folder in which the generated code for the class or feature resides. + +===View external code from the finalized folder=== + +By default the code that you see in an external editor is from the workbench (W_code) folder. You can see the corresponding external code from the finalized (F_code) folder by holding the CTRL key while you drop the class or feature pebble. + + + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-reference/outputs-tool/general-output-pane.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-reference/outputs-tool/general-output-pane.wiki new file mode 100644 index 00000000..406147f2 --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-reference/outputs-tool/general-output-pane.wiki @@ -0,0 +1,7 @@ +[[Property:title|General output pane]] +[[Property:weight|0]] +[[Property:uuid|549e254e-3653-db7a-8874-c71b05c9295a]] +The General output pane contains information about the current EiffelStudio project. + +[[Image:Outputs tool General pane]] + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-reference/outputs-tool/index.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-reference/outputs-tool/index.wiki new file mode 100644 index 00000000..77f00a58 --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-reference/outputs-tool/index.wiki @@ -0,0 +1,61 @@ +[[Property:title|Outputs tool]] +[[Property:weight|-3]] +[[Property:uuid|4f35254c-9a22-7773-21ed-aa740c3eddd5]] +==Overview== + +[[Image:Outputs tool 01]] + + +Several EiffelStudio facilities log their progress to the various panes of the '''Outputs tool'''. + +You can view the outputs from different facilities by selecting the name of a pane from the '''Output:''' drop-down list, as shown below. + + +[[Image:Outputs tool 02]] + + +The output panes you see listed depend somewhat upon how you've been using EiffelStudio. A few of the panes are always present, but other panes only show up in the list after you used the facilities or tools that log information to those panes. For example, if during a session you edit and compile a project but never run it, you would not see the Debugger output pane. Then after you had run the system, the Debugger output pane would join the list. + +==Common functionality== + +On the top bar, the Outputs tool provides some functionality that is always present, and available to all output panes. +#The '''save''' button ( [[Image:16x16--general-save-icon]] )will allow you to save the content of the currently displayed output pane to a file. +#The '''search''' button ( [[Image:tool-search-icon]] ) will provide you with a search bar at the bottom of the current pane. +#The '''clear''' button ( [[Image:general-reset-icon]] ) clears the content of the output pane that is currently being displayed. + +==Transient functionality== + +As you work with EiffelStudio you will notice that some icons appear on the Outputs tool's top bar only occasionally. Generally, the Outputs tool will automatically change to the appropriate pane depending upon what's going on in EiffelStudio. For example, when you compile the Eiffel Compilation output pane appears, and when you run a system, the Debugger output pane appears. + +You can adjust how panes change to some extent as you will see in the [[#Relevant EiffelStudio preferences|section on preferences]]. + +But sometimes things happen that change more than one output pane during an action. When this occurs, one or more transient buttons will be added to the Outputs tool's top bar to the right of the search button. This lets you know that there have been modifications to a pane other than the one that is currently displayed. If you click on one of these buttons, you will be taken to that pane, and the button will be dismissed. + +The figure below shows the Outputs tool during an external compilation. Notice the transient button that has become visible indicating that new changes have been made in the Eiffel Compilation pane. + + +[[Image:Outputs tool transient functionality]] + + +==Relevant EiffelStudio preferences== + +There are two EiffelStudio preferences that can control some of the behavior of the Outputs tool. Both can be found in the preferences path ''Interface -> Development window''. + +===Outputs tool prompted=== + +The preference '''Outputs tool prompted''' controls whether the Outputs tool is made visible automatically whenever a compilation is launched. The value is '''True''' by default. So, in the default case, the Ouputs tool will be visible whenever you compile. If you have closed the tool, and recompile, the tool will reappear. + +If you choose a value of '''False''', then the Outputs tool will remain visible if it is already visible. But if you close it, a recompile will not cause it to reappear. + +===External compilation output prompted=== + +The preference '''External compilation output prompted ''' (''C output panel prompted'', in earlier versions) controls whether the [[External compilation pane|External compilation pane]] appears whenever an external compilation (usually a C compilation) occurs. + +The default value is '''False'''. In this case, the External compilation pane does not appear automatically when an external compilation occurs, except when both of the following conditions are ture: +# The Outputs tool is already displayed, and +# The Eiffel Compilation pane is active. + +So, regardless of the preference value, when an external compilation is performed, and the Eiffel Compilation output pane is already active in the Outputs tool, the External Compilation pane will become the active pane. When the external compilation completes, under most circumstances the Eiffel Compilation pane will become active again. However, the Eiffel Compilation pane will not become active if there were external compilation errors, or if you activated some other output pane during the external compilation. + + + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-reference/wizards-and-dialogs/dialogs/error-wizard.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-reference/wizards-and-dialogs/dialogs/error-wizard.wiki new file mode 100644 index 00000000..6a5ac030 --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-reference/wizards-and-dialogs/dialogs/error-wizard.wiki @@ -0,0 +1,24 @@ +[[Property:title|Error wizard]] +[[Property:weight|2]] +[[Property:uuid|0c9686a0-2b9b-291f-4f01-930d9017810b]] +More often than wanted, Eiffel compilations are not successful. The good point is that when an error is detected by the compiler, it will not be a problem at run-time. The bad point is that you have to fix compilation errors before being able to launch and debug your system. + +When an error occurs during an Eiffel compilation in EiffelStudio, the '''Output''' tab of the context tool displays a description of the error and its location, which looks more or less like this: + + +[[Image:error-message]] + + +In this case, the compiler tries to explain that the identifier "sessionid" is not a known identifier in the context where it was typed. This is a common error that mainly occurs when making typos in the code. Assuming the message does not make sense to you (which may happen in more complex cases), you can query more information about the encountered error. + +To do this: +* [[Pick-and-drop mechanism|Pick]] the code of the error, in this case VEEN. +* [[Pick-and-drop mechanism|Drop]] it either in the editor or on the error help button [[Image:command-error-info-icon]] . +* A dialog is then popped up that describes extended information concerning this error type: + + +[[Image:error-description-dialog]] + + + + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-reference/wizards-and-dialogs/dialogs/external-commands-editor-dialog.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-reference/wizards-and-dialogs/dialogs/external-commands-editor-dialog.wiki new file mode 100644 index 00000000..a2348574 --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-reference/wizards-and-dialogs/dialogs/external-commands-editor-dialog.wiki @@ -0,0 +1,60 @@ +[[Property:title|External commands editor dialog]] +[[Property:weight|4]] +[[Property:uuid|9f8de904-3d17-7ce2-1df8-f4824fab5ae3]] +From EiffelStudio, you can define up to 10 external commands. Those commands will execute and display their output in the [[Console tool]]. You can execute them through the Tools menu. A typical usage is to use those external commands to integrate with your source control management solution (e.g. CVS, Visual SourceSafe,...) + + +==Defining external commands== + +To define your own command, select "External commands..." in the Tools menu. Then the following dialog will appear: + + +[[Image:external-commands-dialog]] + + +With this dialog you can: +* add new commands +* edit existing commands +* delete existing commands + +To add your first command, simply click on the "Add..." button and the following command editor will appear: + + +[[Image:external-commands-dialog-editor]] + + +In this dialog you can give a name to the command, this name will be displayed in the Tools menu. The index (0 thru 9) is the position among the external commands of the command in the Tools menu. The command line is the command you want to execute. In order to execute correctly, the application you will execute needs to be in your PATH environment variable or if it is not you must provide an absolute path to the external command. And you can specify the working directory for that command. + +In addition to the external command name, you can pass as many options as you want. You can also use placeholders that will be translated before calling the external command. Some of those placeholders are: +* $class_name: this will be replaced by the name in lower case of the targeted class in editor +* $file_name: this will be replaced by the path to the targeted class in editor +* $file: this will be replaced by the simple file name without the path +* $directory_name: this will be replaced by the directory location of the targeted class in editor +* $group_name: this will be replaced by the group name of the targeted class in editor +* $line: this will be replaced by the line number of the cursor of the targeted class in editor +* $w_code: this will be replaced by the W_code directory of current system, if defined +* $f_code: this will be replaced by the F_code directory of current system, if defined +You can see the complete [[Console tool#Placeholders|list]] in the Console tool documentation. + +==Executing external commands== + +When you look at the EiffelStudio '''Tools''' menu, you will see that the external commands that you have added have also been added to the bottom of the menu. In the figure below, you see the command we added at index 4: + + +[[Image:External commands tools menu]] + + +To execute that command, you can select it from the '''Tools''' menu, or you can use the keyboard shortcut provided. In this case the keyboard shortcut is the default value of '''Alt+4'''. + +The shortcuts for the command indexes can be changed in the EiffelStudio preferences by following the preference path: + + shortcuts -> external_commands + + +External commands execute in the context of the [[Console tool]]. The Console tool should appear automatically, but you can make it visible by following the menu path: + + View -> Tools -> Console + +Then you can dock the console tool, if you would like to have it constantly visible. + + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-reference/wizards-and-dialogs/dialogs/index.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-reference/wizards-and-dialogs/dialogs/index.wiki new file mode 100644 index 00000000..cb755d96 --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-reference/wizards-and-dialogs/dialogs/index.wiki @@ -0,0 +1,5 @@ +[[Property:title|Dialogs]] +[[Property:weight|1]] +[[Property:uuid|5d543cd3-8e54-e090-44d4-ee3b51009fe6]] + + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-reference/wizards-and-dialogs/dialogs/new-feature-dialog/index.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-reference/wizards-and-dialogs/dialogs/new-feature-dialog/index.wiki new file mode 100644 index 00000000..d1942991 --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-reference/wizards-and-dialogs/dialogs/new-feature-dialog/index.wiki @@ -0,0 +1,14 @@ +[[Property:title|New feature dialog]] +[[Property:weight|0]] +[[Property:uuid|deb4901a-7b5a-f669-802e-de1efefcc1a0]] +The new feature dialog window lets you create simple Eiffel features using the coding standards described in [[Object-Oriented Software Construction, 2nd Edition]]. It automates the task of writing set-procedures for attributes and it makes it easy for you to find the right feature clause for a new feature. The new feature dialog can be invoked whenever you have a class open in a development window. It is also used by the diagram tool when creating a client-supplier link. + +==Use it when...== +* You want to be introduced to the style rules for Eiffel code as described in [[Object-Oriented Software Construction, 2nd Edition]], chapter 26.5 (page 891). +* You want to create an attribute and you also want an invariant and/or a set-procedure generated for it. +* You want to add a feature in a feature clause that is not in your class yet, and you do not remember the feature clause order, or you want to add it in a feature clause that is in your class, but you cannot find it. + +==Do not use it when...== +* You want to edit an existing feature. This is not possible, you can only create new features with it. +* You want to write a more advanced feature. With the feature wizard, you can enter only a single line of code. + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-reference/wizards-and-dialogs/dialogs/new-feature-dialog/new-attribute-layout.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-reference/wizards-and-dialogs/dialogs/new-feature-dialog/new-attribute-layout.wiki new file mode 100644 index 00000000..075af333 --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-reference/wizards-and-dialogs/dialogs/new-feature-dialog/new-attribute-layout.wiki @@ -0,0 +1,45 @@ +[[Property:title|New attribute layout]] +[[Property:weight|4]] +[[Property:uuid|b13c9004-c8a0-6628-5c70-42c3e2617c10]] +
[[Image:feature-wizard-attribute]]
+When clicking '''Attribute''', the window changes to the attribute layout. It has the following components: +* [[Feature clauses|Feature clause selection]] +* [[Name field|Feature name field]] +* [[Type selection|Type selection]] +* [[Header comment|Header comment field]] +* [[Invariant field|Invariant field]] +* [[Set-procedure|Set-procedure check box]] + +==Example== +This dialog box:
+
[[Image:feature-wizard-attribute-example]]

+Produces this feature:
+ +class + PRODUCT + +feature {NONE} -- Access + + price: DOUBLE + -- Cost in dollars. + +feature -- Element change + + set_price (a_price: DOUBLE) + -- Assign `a_price' to `price'. + require + a_price_non_negative: a_price >= 0.0 + do + price := a_price + ensure + price_assigned: price = a_price + end + +invariant + price_non_negative: price >= 0.0 + +end -- class PRODUCT + + + + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-reference/wizards-and-dialogs/dialogs/new-feature-dialog/new-feature-dialog-feature-properties-modification/argument-list.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-reference/wizards-and-dialogs/dialogs/new-feature-dialog/new-feature-dialog-feature-properties-modification/argument-list.wiki new file mode 100644 index 00000000..56c378e8 --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-reference/wizards-and-dialogs/dialogs/new-feature-dialog/new-feature-dialog-feature-properties-modification/argument-list.wiki @@ -0,0 +1,23 @@ +[[Property:title|Argument list]] +[[Property:weight|2]] +[[Property:uuid|f2d63c29-6be2-b3d9-a735-b18e08c5a678]] +For functions and procedures, you can build a formal argument list. You can do this by clicking on the '''New argument''' button as many times as you need arguments. + +{{note|Even though this dialog always shows parentheses, if the list is empty, empty parentheses will not generated. In other words, the dialog will generate the correct Eiffel syntax. }} + + +
[[Image:feature-wizard-3-arguments]]

+{{note|If you add arguments to a routine, it is not possible anymore to select routine type '''once'''. }} + + +For every attribute you selected, enter a name in the text box and a type using the [[Type selection|type selection]] . +
[[Image:feature-wizard-1-argument]]

+The code that is generated: + + set_name (s: STRING) + do + end + + + + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-reference/wizards-and-dialogs/dialogs/new-feature-dialog/new-feature-dialog-feature-properties-modification/feature-body.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-reference/wizards-and-dialogs/dialogs/new-feature-dialog/new-feature-dialog-feature-properties-modification/feature-body.wiki new file mode 100644 index 00000000..b87ed57c --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-reference/wizards-and-dialogs/dialogs/new-feature-dialog/new-feature-dialog-feature-properties-modification/feature-body.wiki @@ -0,0 +1,35 @@ +[[Property:title|Feature body]] +[[Property:weight|6]] +[[Property:uuid|8f9f0b70-e884-73f1-e270-f1b51ef672c6]] +What goes into the feature body field is dependent on what kind of feature you wish to generate. +* '''do''': this is the normal procedure type. Enter in the field below '''do''' a body for your feature. + + do_something + do + a := b + end + +* '''once''': this is the type for a routine that is executed once per execution. As a once routine cannot have arguments, it is disabled when you added one or more arguments. + + init + once + load + end + +* '''deferred''': this creates a routine of deferred type. The local and body fields gray out as they serve no use anymore. + + do_something + deferred + end + +* '''external''': this creates an Eiffel wrap routine around a routine written in another language. Use the body field to enter a string containing the necessary information about the routine using the external syntax. + + do_something + external + "C | %"location.h%"" + end + + + + + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-reference/wizards-and-dialogs/dialogs/new-feature-dialog/new-feature-dialog-feature-properties-modification/feature-clauses.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-reference/wizards-and-dialogs/dialogs/new-feature-dialog/new-feature-dialog-feature-properties-modification/feature-clauses.wiki new file mode 100644 index 00000000..5aabca52 --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-reference/wizards-and-dialogs/dialogs/new-feature-dialog/new-feature-dialog-feature-properties-modification/feature-clauses.wiki @@ -0,0 +1,39 @@ +[[Property:title|Feature clauses]] +[[Property:weight|0]] +[[Property:uuid|019ea318-e0e0-dae9-a818-e12232aa8431]] +The feature you create will be inserted in the feature clause you specified. If the feature clause was not already in your class, or not in the right place, EiffelStudio adds the feature clause to the class text based on the feature clause order specified in the [[Preferences Reference|preferences]] . By default, this is the order used by the Eiffel Software libraries, such as EiffelBase. +==Export status== +The export status is the class the feature is accessible for. Usually, this is ANY for public features, or NONE for implementation features, but you can specify any class here. + + +[[Image:feature-wizard-export]] + + + +{{note|In the class text, you can export a feature to more than one class but (for simplicity) not with this dialog. }} + + + +==Feature clause names== +For feature clause names it is recommended that you pick one from the standard ones, but it is also possible to create a new one. If you have introduced a special feature clause name in your project, add it to the feature clause order list in the [[Preferences Reference|preferences]] and it will also appear in this dialog. + + +[[Image:feature-wizard-clausenames]] + + +==Generated code== +The code that is inserted in your class as a result of the selections made for the feature clause, is of the form:
+ +feature {EXPORT} -- Clause name
+except if you specified ANY as export status, which has the same meaning as not specifying class names in the export status:
+ +feature --Clause name +
+ +For example, if you specified a the "Initialization" feature clause name, and specified NONE as export status, you get:
+ +feature {NONE} -- Initialization + + + + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-reference/wizards-and-dialogs/dialogs/new-feature-dialog/new-feature-dialog-feature-properties-modification/header-comment.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-reference/wizards-and-dialogs/dialogs/new-feature-dialog/new-feature-dialog-feature-properties-modification/header-comment.wiki new file mode 100644 index 00000000..d0084229 --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-reference/wizards-and-dialogs/dialogs/new-feature-dialog/new-feature-dialog-feature-properties-modification/header-comment.wiki @@ -0,0 +1,15 @@ +[[Property:title|Header comment]] +[[Property:weight|3]] +[[Property:uuid|45ecda88-003d-fe59-5d4c-3a84d488b6a2]] +In the header comment field you can type a description of the feature. For style guidelines in writing a header comment, see [[Object-Oriented Software Construction, 2nd Edition]], chapter 26, section 4. The description should be informative, clear and terse. + +For example, suppose you have an attribute count. You can enter the following header comment: +
[[Image:feature-wizard-comment]]

+When clicking '''OK''' this code is generated:
+ + count: INTEGER + -- Number of students in course + + + + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-reference/wizards-and-dialogs/dialogs/new-feature-dialog/new-feature-dialog-feature-properties-modification/index.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-reference/wizards-and-dialogs/dialogs/new-feature-dialog/new-feature-dialog-feature-properties-modification/index.wiki new file mode 100644 index 00000000..15ab8fa0 --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-reference/wizards-and-dialogs/dialogs/new-feature-dialog/new-feature-dialog-feature-properties-modification/index.wiki @@ -0,0 +1,5 @@ +[[Property:title|New feature dialog: feature properties modification]] +[[Property:weight|5]] +[[Property:uuid|60825ef4-7bc2-d472-8b09-25769689bb34]] + + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-reference/wizards-and-dialogs/dialogs/new-feature-dialog/new-feature-dialog-feature-properties-modification/invariant-field.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-reference/wizards-and-dialogs/dialogs/new-feature-dialog/new-feature-dialog-feature-properties-modification/invariant-field.wiki new file mode 100644 index 00000000..5c9ed3a4 --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-reference/wizards-and-dialogs/dialogs/new-feature-dialog/new-feature-dialog-feature-properties-modification/invariant-field.wiki @@ -0,0 +1,24 @@ +[[Property:title|Invariant field]] +[[Property:weight|9]] +[[Property:uuid|9f7ec967-0a45-4ad6-4393-521097467192]] +When creating an attribute, you can optionally enter or select an invariant for that feature. That invariant will be added to the end of the existing invariant clause. If the invariant clause did not exist before, it is now created. + + +[[Image:feature-wizard-invariant]] + + +If the attribute is of a reference type, you may select the invariant that the attribute may never be void. If it is of a basic expanded type, some other standard options may be chosen. For example, for INTEGER you may select that it should always be positive. + + +[[Image:feature-wizard-invariant-selected]] + + +The example above will generate the code: + +invariant + count_positive: count > 0 + + + + + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-reference/wizards-and-dialogs/dialogs/new-feature-dialog/new-feature-dialog-feature-properties-modification/local-variable.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-reference/wizards-and-dialogs/dialogs/new-feature-dialog/new-feature-dialog-feature-properties-modification/local-variable.wiki new file mode 100644 index 00000000..4217d693 --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-reference/wizards-and-dialogs/dialogs/new-feature-dialog/new-feature-dialog-feature-properties-modification/local-variable.wiki @@ -0,0 +1,13 @@ +[[Property:title|Local variable]] +[[Property:weight|5]] +[[Property:uuid|423aa67d-99f4-0f81-3709-161a6be43af9]] +Enter a local variable in the local field. A local variable clause will be added to the feature: + + ... + local + n: INTEGER + ... + + + + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-reference/wizards-and-dialogs/dialogs/new-feature-dialog/new-feature-dialog-feature-properties-modification/name-field.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-reference/wizards-and-dialogs/dialogs/new-feature-dialog/new-feature-dialog-feature-properties-modification/name-field.wiki new file mode 100644 index 00000000..81617b27 --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-reference/wizards-and-dialogs/dialogs/new-feature-dialog/new-feature-dialog-feature-properties-modification/name-field.wiki @@ -0,0 +1,11 @@ +[[Property:title|Name field]] +[[Property:weight|1]] +[[Property:uuid|850bd867-5cbf-34d0-f94c-97a75bfa244b]] +The feature name field is a text box that lets you enter a name for the feature. For help on how to choose the right name for a feature, see: [[Object-Oriented Software Construction, 2nd Edition]], chapter 26, section 2. + + +{{warning|EiffelStudio performs no validation on the name you choose. For example if you type a space in it, it will generate the code, and detect a syntax error only when compiling. }} + + + + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-reference/wizards-and-dialogs/dialogs/new-feature-dialog/new-feature-dialog-feature-properties-modification/postcondition.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-reference/wizards-and-dialogs/dialogs/new-feature-dialog/new-feature-dialog-feature-properties-modification/postcondition.wiki new file mode 100644 index 00000000..6b595a30 --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-reference/wizards-and-dialogs/dialogs/new-feature-dialog/new-feature-dialog-feature-properties-modification/postcondition.wiki @@ -0,0 +1,12 @@ +[[Property:title|Postcondition]] +[[Property:weight|7]] +[[Property:uuid|b8196d6c-2a0f-c06e-855f-d9fe23cbe950]] +Enter a postcondition in the ensure field. A postcondition clause will be added to the feature: + + ... + ensure + n = count + + + + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-reference/wizards-and-dialogs/dialogs/new-feature-dialog/new-feature-dialog-feature-properties-modification/precondition.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-reference/wizards-and-dialogs/dialogs/new-feature-dialog/new-feature-dialog-feature-properties-modification/precondition.wiki new file mode 100644 index 00000000..022b6b91 --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-reference/wizards-and-dialogs/dialogs/new-feature-dialog/new-feature-dialog-feature-properties-modification/precondition.wiki @@ -0,0 +1,13 @@ +[[Property:title|Precondition]] +[[Property:weight|4]] +[[Property:uuid|29b32f9e-799d-de91-d62d-79bdb509144b]] +Enter a precondition in the require field. A precondition clause will be added to the feature: + + ... + require + n >= 0 + ... + + + + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-reference/wizards-and-dialogs/dialogs/new-feature-dialog/new-feature-dialog-feature-properties-modification/set-procedure.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-reference/wizards-and-dialogs/dialogs/new-feature-dialog/new-feature-dialog-feature-properties-modification/set-procedure.wiki new file mode 100644 index 00000000..ba0e068c --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-reference/wizards-and-dialogs/dialogs/new-feature-dialog/new-feature-dialog-feature-properties-modification/set-procedure.wiki @@ -0,0 +1,32 @@ +[[Property:title|Set-procedure]] +[[Property:weight|10]] +[[Property:uuid|46b84038-099b-070c-15d7-2b7884a50e01]] +When creating an attribute, it is common that you will also need a set-procedure for it. For example, for attribute property you need a procedure set_property to set it. This feature takes one argument of the same type as property or is anchored to it. The only thing you have to do with the feature wizard is check the button '''Generate set procedure'''. + + +[[Image:feature-wizard-setprocedure]] + + +The feature that is generated in addition to the attribute itself is placed in feature clause Element change and is exported to all classes. If you have selected or entered an invariant, the precondition will protect this invariant. Example of a generated set-procedure: + + +[[Image:feature-wizard-setprocedure-example]] + + + +feature -- Element change + + set_button (a_button: EV_BUTTON) + -- Assign `a_button' to `button' + require + a_button_not_void: a_button /= Void + do + button := a_button + ensure + button_assigned: button = a_button + end + + + + + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-reference/wizards-and-dialogs/dialogs/new-feature-dialog/new-feature-dialog-feature-properties-modification/type-selection.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-reference/wizards-and-dialogs/dialogs/new-feature-dialog/new-feature-dialog-feature-properties-modification/type-selection.wiki new file mode 100644 index 00000000..7bb9a499 --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-reference/wizards-and-dialogs/dialogs/new-feature-dialog/new-feature-dialog-feature-properties-modification/type-selection.wiki @@ -0,0 +1,45 @@ +[[Property:title|Type selection]] +[[Property:weight|8]] +[[Property:uuid|b2bd8280-a738-dae4-73aa-c1e232245022]] +Whenever you need to give a type of something in the dialog, the type selection component is used. The type selection lets you type any class name or you can pick one from the list. + + +[[Image:feature-wizard-typeselection]] + + +When you select a class that is in the system and has formal generic parameters, the type selection component lets you specify an actual generic parameter in another type selection. + + +[[Image:feature-wizard-generictype]] + + +{{note|The window might grow in size because of the added component. }} + + +Since the actual generic type selection is also a type selection, you can select another class with generic parameters and nest them as deep as you need. + + +[[Image:feature-wizard-generictyperec]] + + +You can also select the type TUPLE, which is a special class that can have zero or more generic parameters. When you select it, it has no parameters, but you can add one by clicking on the '''Add parameter''' button. Click it as often as the number of generic parameters that you need. + + +[[Image:feature-wizard-tupletype2]] + + +{{warning|If you need a very complex type, it is better not to use the dialog, as the window might grow bigger than your screen. After you completed the feature, edit it manually in the class text. }} + + +The code generated for the selected type is quite straightforward, an example: + + +[[Image:feature-wizard-complextype]] + + + new_feature: FUNCTION [TUPLE [INTEGER], BOOLEAN] + + + + + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-reference/wizards-and-dialogs/dialogs/new-feature-dialog/new-feature-dialog-overview.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-reference/wizards-and-dialogs/dialogs/new-feature-dialog/new-feature-dialog-overview.wiki new file mode 100644 index 00000000..b2fa5ce3 --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-reference/wizards-and-dialogs/dialogs/new-feature-dialog/new-feature-dialog-overview.wiki @@ -0,0 +1,17 @@ +[[Property:title|New feature dialog overview]] +[[Property:weight|1]] +[[Property:uuid|c0708842-e5e0-5d5c-5746-0507d1709a3e]] +There are two parts in the window. The upper part allows you to choose what type of feature you want to create, a procedure, a function or an attribute. + + +[[Image:feature-wizard]] + + +The rest of the window is used to set the characteristics of the new feature. Information you will be asked depends on the type you chose. For more information, click on one of the links below: +* [[New procedure layout|New procedure layout]] +* [[New function layout|New function layout]] +* [[New attribute layout|New Attribute layout]] + + + + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-reference/wizards-and-dialogs/dialogs/new-feature-dialog/new-function-layout.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-reference/wizards-and-dialogs/dialogs/new-feature-dialog/new-function-layout.wiki new file mode 100644 index 00000000..d5b2e73f --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-reference/wizards-and-dialogs/dialogs/new-feature-dialog/new-function-layout.wiki @@ -0,0 +1,40 @@ +[[Property:title|New function layout]] +[[Property:weight|3]] +[[Property:uuid|ae292b6e-7274-47a5-59f1-0f625493474f]] +
[[Image:feature-wizard-function]]
+When clicking '''Function''', the dialog changes to the function layout. It has the following components: +* [[Feature clauses|Feature clause selection]] +* [[Name field|Feature name field]] +* [[Argument list|Argument list]] +* [[Type selection|Type selection]] +* [[Header comment|Header comment field]] +* [[Precondition|Precondition field]] +* [[Local variable|Local variable field]] +* [[Feature body|Selection for: normal, once, deferred or external routine]] +* [[Postcondition|Postcondition field]] + +==Example== +This dialog box:
+
[[Image:feature-wizard-function-example]]

+Produces this feature:
+ +class + PRODUCT + +feature -- Status report + + order_price (quantity: INTEGER): DOUBLE + -- Total price when ordering `quantity'. + require + quantity_non_negative: quantity >= 0 + do + Result := quantity * price + ensure + correct: Result = quantity * price + end + +end -- class PRODUCT + + + + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-reference/wizards-and-dialogs/dialogs/new-feature-dialog/new-procedure-layout.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-reference/wizards-and-dialogs/dialogs/new-feature-dialog/new-procedure-layout.wiki new file mode 100644 index 00000000..4e7deaeb --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-reference/wizards-and-dialogs/dialogs/new-feature-dialog/new-procedure-layout.wiki @@ -0,0 +1,41 @@ +[[Property:title|New procedure layout]] +[[Property:weight|2]] +[[Property:uuid|586fd664-1be4-f588-5350-c7c703145c11]] +
[[Image:feature-wizard-procedure]]
+When clicking '''Procedure''', the window changes to the procedure layout. It has the following components: +* [[Feature clauses|Feature clause selection]] +* [[Name field|Feature name field]] +* [[Argument list|Argument list]] +* [[Header comment|Header comment field]] +* [[Precondition|Precondition field]] +* [[Local variable|Local variable field]] +* [[Feature body|Selection for: normal, once, deferred or external routine]] +* [[Postcondition|Postcondition field]] + +==Example== + +This dialog box:
+
[[Image:feature-wizard-procedure-example]]

+ +Produces this feature:
+ +class + PRODUCT + +feature {PERSON} -- Element change + + place_order (person: PERSON; quantity: INTEGER) + -- Mail `quantity' to `person'. + require + person /= Void and quantity > 0 + do + person.mail_order (Current, quantity) + ensure + person.has_ordered (Current) + end + +end -- class PRODUCT + + + + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-reference/wizards-and-dialogs/index.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-reference/wizards-and-dialogs/index.wiki new file mode 100644 index 00000000..0658de31 --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-reference/wizards-and-dialogs/index.wiki @@ -0,0 +1,5 @@ +[[Property:title|Wizards and dialogs]] +[[Property:weight|0]] +[[Property:uuid|b216d12e-20a4-5479-18d2-02e622db5322]] + + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-reference/wizards-and-dialogs/profiler-wizard/index.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-reference/wizards-and-dialogs/profiler-wizard/index.wiki new file mode 100644 index 00000000..83052af0 --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-reference/wizards-and-dialogs/profiler-wizard/index.wiki @@ -0,0 +1,22 @@ +[[Property:title|Profiler Wizard]] +[[Property:weight|0]] +[[Property:uuid|f3509b1b-8ff1-c385-3bc1-4e800195f8a4]] +The profiler wizard lets you analyze the result of a profiling session. It helps you optimize your system by pointing out the features where your system spends most of its time. + +Before using the profiler wizard you must have generated a ''Run-time information record''. A ''Run-time information record'' is generated by a profiler when a program is executed under its control. Most of the time, the ''Run-time information record'' is generated by the profiler integrated into EiffelStudio. See [[Profiling|How to profile a system]] for more information about how to generate a ''Run-time information record'' with the integrated profiler. + +{{note|You can also use a ''Run-time information record'' generated by an external profiler such as GNU's gprof, Pure Atricia's Quantify, Visual C++ profiler, etc. }} +
+
+ +The diagram below summarizes the execution steps of the profiler wizard. +
+[[Image:profiler-process]]
+
+ +{{seealso|
+[[Profiling|How to profile a system]] }} + + + + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-reference/wizards-and-dialogs/profiler-wizard/profiler-how-tos/how-set-profiler-configuration-file.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-reference/wizards-and-dialogs/profiler-wizard/profiler-how-tos/how-set-profiler-configuration-file.wiki new file mode 100644 index 00000000..5dce04da --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-reference/wizards-and-dialogs/profiler-wizard/profiler-how-tos/how-set-profiler-configuration-file.wiki @@ -0,0 +1,50 @@ +[[Property:title|How to set up a Profiler Configuration File]] +[[Property:weight|0]] +[[Property:uuid|0cf0f7bc-1932-fe42-e62d-b37e2e0c424e]] +Once executing an instrumented system has generated the proper file, you must have a profile converter process it in order to produce the Execution Profile. The need for the converter comes from the various formats that profilers use to record run-time information during an execution; a simple Profiler Configuration File enables you to describe the format used by any particular profiler. + +The Profiler Configuration File is a file found in the directory $ISE_EIFFEL/studio/profiler where $ISE_EIFFEL is the location of the Eiffel installation. The name of the Profiler Configuration File in that directory is Eiffel for internal profiling and, for external profiling, the name of the profiler tool as specified in the profiler option. EiffelStudio comes with 3 preconfigured external profilers: +* '''gprof:''' GNU's gprof +* '''win32_ms:''' Visual C++ 5.0 or 6.0 +* '''profiler.info:''' Pure Atria's Quantify + +The Profiler Configuration File describes the structure of the file generated by the profiler. To create a new Profiler Configuration File for another profiler, just create a new file in the directory $ISE_EIFFEL/studio/profiler and fill it in. + +Here is a complete example showing the various options that maybe specified: +number_of_columns: 7 + -- Number of columns in the file. + +index_column: 1 + -- Column where the index is stored. + +function_time_column: 3 + -- Column where the time spent in the function is stored. + +descendent_time_column: 4 + -- Column where the time spent in the descendents of a function is stored. + +number_of_calls_column: 5 + -- Column where the number of calls to a function is stored. + +function_name_column: 6 + -- Column where the name of the function is stored. + +percentage_column: 2 + -- Column where the percentage of time spent in the function is stored. + +second_percentage_column: 0 + -- Column where the second percentage of time spent in the function is stored. + +generates_leading_underscore: no + -- Says whether the profiler generates leading underscores (yes) or not (no). + +As in Eiffel, -- introduces a comment, which has no effect on the specification. If one of the xxx_column options has a value of 0, this means that the files generated by the given profiler contain no such column. The order of the options is not significant. + +
+{{seealso|
+[[Select a Run-time information record to generate the Execution Profile|Select a Run-time information record to generate the Execution Profile]]
+[[Profiling|How to profile a system]] }} + + + + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-reference/wizards-and-dialogs/profiler-wizard/profiler-how-tos/index.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-reference/wizards-and-dialogs/profiler-wizard/profiler-how-tos/index.wiki new file mode 100644 index 00000000..302b59d3 --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-reference/wizards-and-dialogs/profiler-wizard/profiler-how-tos/index.wiki @@ -0,0 +1,5 @@ +[[Property:title|Profiler How To's]] +[[Property:weight|2]] +[[Property:uuid|f488bd8f-6d05-0487-a4c6-2e26a9a185ad]] + + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-reference/wizards-and-dialogs/profiler-wizard/profiler-wizard-guided-tour/index.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-reference/wizards-and-dialogs/profiler-wizard/profiler-wizard-guided-tour/index.wiki new file mode 100644 index 00000000..c1c46f22 --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-reference/wizards-and-dialogs/profiler-wizard/profiler-wizard-guided-tour/index.wiki @@ -0,0 +1,19 @@ +[[Property:title|Profiler wizard guided tour]] +[[Property:weight|1]] +[[Property:uuid|e6166282-aa91-e4a9-9951-819f32d50b88]] +Using the Profiler Wizard consists of activities in four "states", each of which is represented by a wizard dialog box: + +# [[Select the Compilation mode|Select which version of your system you ran using the profiler: ''Workbench'' or ''Finalized'']] . +# [[Reuse or Generate an Execution Profile|Select an existing ''Execution Profile'' or choose to generate a new ''Execution Profile'' from a ''Run-time information record'' (This step only applies when an ''Execution Profile'' has already been generated for this system)]] +# [[Select a Run-time information record to generate the Execution Profile|Generate a new ''Execution Profile'' from a ''Run-time information record'' (This step only applies when generating a new ''Execution Profile'')]] +# [[Select the information you need and formulate your query|Select the information you need and formulate your query.]] + +Results of your query are visible in the [[Profile query window|Profile query window]]. + + +{{seealso|
+[[Profiling|How to profile a system]] }} + + + + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-reference/wizards-and-dialogs/profiler-wizard/profiler-wizard-guided-tour/profile-query-window.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-reference/wizards-and-dialogs/profiler-wizard/profiler-wizard-guided-tour/profile-query-window.wiki new file mode 100644 index 00000000..e8ec7522 --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-reference/wizards-and-dialogs/profiler-wizard/profiler-wizard-guided-tour/profile-query-window.wiki @@ -0,0 +1,25 @@ +[[Property:title|Profile query window]] +[[Property:weight|4]] +[[Property:uuid|1158eeb3-ccf5-8f29-3551-4e511258fa80]] +The profile query window displays the results of the query you have formulated in the [[Select the information you need and formulate your query|Final state]] of the Profiler wizard. It also lets you change the sub queries of the current query. + +To add a new sub query to the current query, fill in the text field labeled '''Define new sub query''' (type in ''calls <20'' for example) and click the '''And''' or '''Or''' button. To display the results of the new query click on the '''Update''' button. + +To remove an existing sub query, select it in the '''Active query''' list and click on the '''Inactivate >''' button. + +To activate an existing sub query, select it in the '''Inactive query''' list and click on the '''< Activate''' button. + +To change the operator affecting an existing sub query, select it in either the '''Active query''' or the '''Inactive query''' list and click on the '''Or''' or '''And''' button. + +Click on the '''Save''' button to save the currently displayed results in a text file. + +{{tip|To visualize the result in Microsoft Excel or any other spreadsheet, select the entire text (except the first three lines where the Execution Profile file is specified), copy it and then paste it into Excel. }} +
+[[Image:profiler-query-window]]
+ +{{seealso|
+[[Profiling|How to profile a system]] }} + + + + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-reference/wizards-and-dialogs/profiler-wizard/profiler-wizard-guided-tour/reuse-or-generate-execution-profile.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-reference/wizards-and-dialogs/profiler-wizard/profiler-wizard-guided-tour/reuse-or-generate-execution-profile.wiki new file mode 100644 index 00000000..84ca4344 --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-reference/wizards-and-dialogs/profiler-wizard/profiler-wizard-guided-tour/reuse-or-generate-execution-profile.wiki @@ -0,0 +1,26 @@ +[[Property:title|Reuse or Generate an Execution Profile]] +[[Property:weight|1]] +[[Property:uuid|caa8ac1d-b17d-6b5b-1b16-7420a8d4404c]] +The second screen of the wizard lets you reuse a previously generated ''Execution Profile'' or generate a new ''Execution Profile'' from a ''Run-time information record''. + +The profiler wizard has detected that one or more ''Execution Profiles'' have already been generated for this system in this compilation mode. If you have executed your system after the generation of the existing profile, select '''Generate a profile from Run-time information record''' to create a new ''Execution Profile'' for the newly produced ''Run-time information record''. + +{{note|If you choose '''Generate a profile from Run-time information record''' the generated ''Execution Profile'' will be written into:

''/EIFGENa/target_name/W_CODE/profinfo.pfi''

if you have selected '''Workbench mode''' in the first step, or into:

''/EIFGENs/target_name/F_CODE/profinfo.pfi''

if you have selected '''Finalized mode'''. If a file with the same name already exists its content will be destroyed and replaced. }} +
+ +However, if you have not executed your system since the generation of the last ''Execution Profile'', there is no need to generate a new ''Execution Profile''. If you are in the latter case, select '''Use existing profile''' and choose the last ''Execution Profile'' you have generated. + +{{tip|If you want to archive different ''Execution Profiles'' (to compare them for example), rename the ''profinfo.pfi'' file into a new name but keep the .pfi extension. The profiler wizard detects existing Execution Profiles by checking the file extensions. }} +
+[[Image:profiler-wizard-second-state]]
+
+ +Clicking '''Next''' will lead you to the [[Select a Run-time information record to generate the Execution Profile|Third state]] if you have selected '''Generate a profile from Run-time information record'''. On the other hand if you have selected '''Use existing profile''' you will go to the [[Select the information you need and formulate your query|Final state]] . +
+ +{{seealso|
+[[Profiling|How to profile a system]] }} + + + + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-reference/wizards-and-dialogs/profiler-wizard/profiler-wizard-guided-tour/select-compilation-mode.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-reference/wizards-and-dialogs/profiler-wizard/profiler-wizard-guided-tour/select-compilation-mode.wiki new file mode 100644 index 00000000..2fbb9c64 --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-reference/wizards-and-dialogs/profiler-wizard/profiler-wizard-guided-tour/select-compilation-mode.wiki @@ -0,0 +1,20 @@ +[[Property:title|Select the Compilation mode]] +[[Property:weight|0]] +[[Property:uuid|b43f018b-b924-234b-727f-8d80c1d18fb4]] +The first screen of the wizard lets you specify the mode in which the profiled system was compiled. + +If you have run a finalized system under the control of the profiler then select '''Finalized mode''' and click '''Next'''. On the contrary if you have executed the system in Workbench mode then select '''Workbench mode''' and click '''Next'''. + + +[[Image:profiler-wizard-first-state]]
+
+ +Clicking '''Next''' will lead you to the [[Reuse or Generate an Execution Profile|Second state]] or to the [[Select a Run-time information record to generate the Execution Profile|Third state]] depending on whether an ''Execution Profile'' has already been generated for this compilation mode or not. If no ''Execution Profile'' has been generated so far (which happens the first time you execute this wizard for a specified project in a given compilation mode) you will go to the [[Select a Run-time information record to generate the Execution Profile|Third state]] , otherwise you will go to the [[Reuse or Generate an Execution Profile|Second state]] . +
+ +{{seealso|
+[[Profiling|How to profile a system]] }} + + + + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-reference/wizards-and-dialogs/profiler-wizard/profiler-wizard-guided-tour/select-information-you-need-and-formulate-your-query.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-reference/wizards-and-dialogs/profiler-wizard/profiler-wizard-guided-tour/select-information-you-need-and-formulate-your-query.wiki new file mode 100644 index 00000000..8bd58d09 --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-reference/wizards-and-dialogs/profiler-wizard/profiler-wizard-guided-tour/select-information-you-need-and-formulate-your-query.wiki @@ -0,0 +1,58 @@ +[[Property:title|Select the information you need and formulate your query]] +[[Property:weight|3]] +[[Property:uuid|708f745d-11af-4d3d-e857-159dad4bdeec]] +The final screen of the wizard lets you select the information you want to be displayed in the profile query window. + +==Select the information you need== + +Check or uncheck any of the check buttons in '''Output switches''' to select the columns you want to be displayed. Each switch turns on or off the corresponding column output. You should toggle columns on or off depending on what you would like to see in the result of the computation. Here are the explanations of each switch: +* '''Feature name''': Display the name of the current feature. +* '''Number of calls''': Display the number of times the current feature was called during the instrumented execution. +* '''Function time''': Display the time spent in the current feature (not counting the time spent in features called by the current feature). +* '''Descendant time''': Display the time spent in all features called during the execution of the current feature. +* '''Total time''': Display the total time spent in the feature. This value is equal to ''Function time + Descendant time''. +* '''Percentage''': Display the percentage of time spent in the current feature. This value is equal to ''Total time / Execution time''. + +Check or uncheck any of the check buttons in the '''Language type''' to select the type of features you want to be displayed. If you select only one language, the query result will not contain any information about routines written in the other language. The default is Eiffel only. +* Eiffel features: Display the features written in Eiffel. +* C functions: Display the functions written in C. +* Recursive functions: Display recursive functions. + +==Formulate your query== + +When running a query, you are able to type a complete query. After pressing the '''Next''' button, a new window will be displayed to show the result of the query. The total query can be either a single one or a set of sub-queries separated by one of the two operators 'or' or 'and'.
+
+Each sub-query must have the following syntax 'attribute operator value' where: +* 'attribute' is one of: +** feature name +** calls +** total +** self +** descendants +** percentage + +* 'operator' is one of: <, >, <=, >=, =, /=, in +* 'value' is one of: +** An integer (for calls) +** A string (for feature name). The string may contain wild card characters: ?, standing for arbitrary characters, and *, standing for arbitrary sub-strings. +** A real value (for other attributes) +** An interval, of the form a-b for two values a and b. +** max +** min +** avg + + +
+[[Image:profiler-wizard-fourth-state]]
+
+ + +Clicking '''Next''' will open the [[Profile query window|Profile query window]] and display the results of the formulated query. +
+ +{{seealso|
+[[Profiling|How to profile a system]] }} + + + + diff --git a/documentation/18.11/eiffelstudio/eiffelstudio-reference/wizards-and-dialogs/profiler-wizard/profiler-wizard-guided-tour/select-run-time-information-record-generate-execution-profile.wiki b/documentation/18.11/eiffelstudio/eiffelstudio-reference/wizards-and-dialogs/profiler-wizard/profiler-wizard-guided-tour/select-run-time-information-record-generate-execution-profile.wiki new file mode 100644 index 00000000..54cc3a37 --- /dev/null +++ b/documentation/18.11/eiffelstudio/eiffelstudio-reference/wizards-and-dialogs/profiler-wizard/profiler-wizard-guided-tour/select-run-time-information-record-generate-execution-profile.wiki @@ -0,0 +1,28 @@ +[[Property:title|Select a Run-time information record to generate the Execution Profile]] +[[Property:weight|2]] +[[Property:uuid|c3f3e068-2313-ff14-2a33-8bf5297b9779]] +The third screen of the wizard lets you generate an ''Execution Profile'' from a ''Run-time information record''. You should provide the ''Run-time information record'' produced by the profiler in the text field labeled '''Run-time information record'''. If the file provided by default is not the desired one change it by clicking on the '''Browse''' button or by directly entering it in the text field. + +Then, in the combo box labeled '''Profiler used to produce the above record''', select the profiler that has been used to produce the ''Run-time information record'' you have entered. If the profiler used to execute the system does not appear in the combo box, you have to add it. See [[How to set up a Profiler Configuration File|How to set up a Profiler Configuration File]] for more details on how to do so. + + +{{note|The Run-time information record must be located in the ''EIFGENs/target_name/W_code'' directory of your project. }} + +
+[[Image:profiler-wizard-third-state]]
+
+ + +Clicking '''Next''' will lead you to the [[Select the information you need and formulate your query|Final state]] if the provided ''Run-time information record'' is valid. If the ''Run-time information record'' is not valid or is not located in the ''EIFGENs/target_name/W_code'' directory of the project, you will go to the '''Run-time Information Record Error state''' as shown below. + + +[[Image:profiler-wizard-rtir-error-state]]
+
+ +{{seealso|
+[[Profiling|How to profile a system]]
+[[How to set up a Profiler Configuration File|How to set up a Profiler Configuration File]] }} + + + + diff --git a/documentation/18.11/eiffelstudio/getting_started/index.wiki b/documentation/18.11/eiffelstudio/getting_started/index.wiki new file mode 100644 index 00000000..7a2edfa5 --- /dev/null +++ b/documentation/18.11/eiffelstudio/getting_started/index.wiki @@ -0,0 +1,5 @@ +[[Property:title|Getting started]] +[[Property:description|Getting started with EiffelStudio]] +[[Property:weight|1]] +[[Property:uuid|ebcde1cb-df4a-44d0-aa9a-0df2d2fc0eb5]] + diff --git a/documentation/18.11/eiffelstudio/getting_started/introducing_eiffelstudio.wiki b/documentation/18.11/eiffelstudio/getting_started/introducing_eiffelstudio.wiki new file mode 100644 index 00000000..0f3a34db --- /dev/null +++ b/documentation/18.11/eiffelstudio/getting_started/introducing_eiffelstudio.wiki @@ -0,0 +1,88 @@ +[[Property:title|Introducing EiffelStudio]] +[[Property:weight|2]] +[[Property:uuid|acf5433b-14e9-1d21-c8cf-997db7821550]] +EiffelStudio is the central tool of Eiffel Software's implementation of Eiffel, letting you design, develop, debug, document, measure, maintain, test, revise and expand systems using the full power of object technology and Design by Contract™. + +This guided tour introduces the essential properties of EiffelStudio. It will take you through a tour of the environment, using a pre-existing example system. + +==What will I achieve?== + +Although it skips many specific or advanced facilities, this Tour will help you quickly become familiar with the way you can use the environment for your work. After reading it you will know the basics of working with EiffelStudio: +* '''Starting a project''' and '''retrieving an existing project'''. +* '''Entering new software elements''' -- clusters, classes and features. +* '''Compiling''' your software. +* '''Making changes''' and '''recompiling''' them immediately using the Melting Ice Technology™. +* Displaying a '''graphical representation''' of your software elements, and '''modifying''' the software through the graphical views (as well as through its text). +* Producing extensive '''documentation''' of your system, textual or graphical, under many different formats such as HTML, RTF, Postscript, XMI (for example Rational Rose) and others. +* '''Browsing''' through simple or complex software systems, to find out their various components, properties and relationships. +* '''Measuring''' quantitative properties of the software, by applying metrics predefined in EiffelStudio as well as new ones that you define. +* '''Executing''' a compiled system. +* Controlling execution through the '''debugging''' mechanisms of EiffelStudio. +* Creating an effective '''test suite''', with the automated assistance of '''AutoTest''' +* Add '''licensing''' text to your classes automatically. + +==About the scope of EiffelStudio== + +The most important property to keep in mind as you are discovering EiffelStudio is that it is neither just a "programming environment" nor just a "CASE tool" (Computer-Aided Software Engineering) for analysis and design. It encompasses both of these functions and many others. Most system builders today are used to a dichotomy between the high end and the low end: +* At the analysis and design levels, graphical tools help you clarify your thinking about the system, interacting with customers and end users, and devise high-level system architectures, usually in diagrammatic form. +* At the low end, programming tools help you edit, compile and debug your programs. + +Keeping these tools separate is, however, detrimental to the quality of the software process and the resulting products. If they are in the hands of different teams, communication problems may arise, leading to discrepancies between need and realization; this can be a source of bugs or even project failure. If it's the same people using tools of both kinds, they have to keep switching notations, tools and modes of thinking. The use of different frameworks at both ends makes it difficult to keep the high-level model and the implementation consistent; too often, a change decided at the implementation level is not reflected back in the higher model. After a while, the system gets into the state of disorder and inconsistency that good tools are precisely meant to avoid. + +EiffelStudio, in line with the principles of seamless development and reversibility of the Eiffel method, removes the gap by providing a single set of tools that accompany you throughout a project, from the most high-level initial stages to the most low-level aspects of implementation and maintenance. + +This generality is reflected throughout the environment by, for example, the dual use of text and graphics. As another example, you should think of the EiffelStudio compiler, not just as a tool for executing Eiffel software in its final form, but also, thanks to its extensive validity checking facilities, as a design consistency tool that performs many verifications commonly associated with CASE tools. + +Depending on your project needs, you may take advantage of EiffelStudio's versatility to address specific purposes: +* You may use EiffelStudio as a programming environment, with advanced tools for compiling, browsing and debugging. +* Some people use EiffelStudio as a modeling tool only, building system descriptions consisting only of deferred (abstract) classes with no implementation, and relying on the Diagram Tool to build, present and discuss these descriptions through graphical views. +* You may use EiffelStudio in both capacities, taking advantage of the seamlessness between all the affected phases. + +==Learning by doing== + +If you have access to EiffelStudio as you read this Tour, the most effective technique is to execute all the suggested operations as you read about them. + +Please execute user actions, such as clicking, only when asked to do so. + +==What should I already know?== + +This Tour assumes very little about what you know and what you don't. + +It does assume that you can do simple manipulations on your platform of choice, such as: on Windows, finding and drag-and-dropping folders and files in the Windows Explorer; on Unix, changing to a certain directory ( cd ) and listing the files of a directory ( ls ). + +The more you already know about object technology and object-oriented environments, the better. But remember, if you have used other environments before, keep a fresh outlook; EiffelStudio is different, and it may take a while before you fully understand why it does some things in a certain way. + +==A note on platform differences== + +EiffelStudio is one of the most portable environments in the industry, running in an almost identical fashion on Windows, on the new Microsoft .NET environment, on many variants of Unix, on Linux, on OpenVMS. + +Once an EiffelStudio session has been started, you can largely forget about the operating system. But a few operations -- mostly at the beginning, to launch EiffelStudio -- require platform-dependent mechanisms: starting a program, traversing the file structure, selecting a file. These cases will be marked accordingly below. + +Windows users should particularly note the following two conventions of terminology: +* Operating systems store files into hierarchically nested structures called folders or directories. Although "folder" is the more common term for Windows, we will mostly speak of "directories". It's exactly the same thing. +* A file has a full path name, used to describe how to reach it from the root of its file system, as in c:\d1\d2\f . This example uses the Windows notation, which separates successive components of a path name by a backward slash character \ . On Unix and Linux, the separator is a forward slash / , as in /d1/d2/f ; this is also the convention on the Internet for denoting addresses (URLs). Most file names in this manual appear in this Unix/Internet style. On Windows you will normally have to use the backslash convention, although EiffelStudio also accepts forward slashes. In any case you must be consistent: don't mix backward and forward slashes in the same path name. Also note that some names, such as those of object files to be linked with your system, will be passed to outside tools -- C compilers, loaders -- that may not accept the forward slash. + +OpenVMS users may similarly use either the Unix convention or the specific OpenVMS path naming convention. + +If you are a one-platform person, just ignore, for the next few pages, all references to any platform other than your heart's favorite. They will quickly go away. + +==What should I have done first?== + +To run the example you must have installed EiffelStudio and set up the environment. Check in particular the following: +* On Windows, you must have run the installation procedure; it will have put EiffelStudio in the Programs section of the start menu, subsection "EiffelStudio version", where version is the version number, e.g. 6.0. +* The environment variable ISE_EIFFEL must be set to the installation directory, and the environment variable ISE_PLATFORM to the platform. On Windows this is taken care of automatically by the installation procedure, but on Unix/Linux and OpenVMS you must update your path and environment manually. Throughout this discussion the notations $ISE_EIFFEL and $ISE_PLATFORM will refer to the values of these variables -- the installation directory, and the platform. (The Windows notation would be %ISE_EIFFEL% and %ISE_PLATFORM%.) +* On Unix/Linux and OpenVMS, your "path" must include the place where EiffelStudio executables reside. (On Windows the installation procedure takes care of this.) +* Also, the discussion assumes that as part of the installation you have included the EiffelBase library, in precompiled form. EiffelBase is automatically included if you have installed another precompiled library, such as WEL, the Windows Eiffel Library. The installation procedure takes care of precompiling EiffelBase. + +==Locating the example== + +Please take a moment to locate the example files on your installation. They all appear in the following directory, part of the Eiffel delivery: +$ISE_EIFFEL/examples/studio/tour + +(Windows users: remember that instead of the slash / your platform uses a backslash \ . OpenVMS users: this is to be replaced by the OpenVMS path naming conventions.) + + +{{seealso|For a quick introduction to EiffelStudio, see the online EiffelStudio presentation available on the Eiffel Software [http://www.eiffel.com/developers/presentations/ developers' presentations web page].}} + + + diff --git a/documentation/18.11/eiffelstudio/getting_started/setup-and-installation/index.wiki b/documentation/18.11/eiffelstudio/getting_started/setup-and-installation/index.wiki new file mode 100644 index 00000000..5b02ab77 --- /dev/null +++ b/documentation/18.11/eiffelstudio/getting_started/setup-and-installation/index.wiki @@ -0,0 +1,5 @@ +[[Property:title|Setup and installation]] +[[Property:weight|1]] +[[Property:uuid|90bc1970-bd1d-9707-3030-a4a9f613524a]] +For detailed installation instructions please follow the link for the product your are installing. + diff --git a/documentation/18.11/eiffelstudio/getting_started/setup-and-installation/software-installation-eiffelstudio/OpenBSD.wiki b/documentation/18.11/eiffelstudio/getting_started/setup-and-installation/software-installation-eiffelstudio/OpenBSD.wiki new file mode 100644 index 00000000..9531838c --- /dev/null +++ b/documentation/18.11/eiffelstudio/getting_started/setup-and-installation/software-installation-eiffelstudio/OpenBSD.wiki @@ -0,0 +1,117 @@ +[[Property:uuid|A98B98AA-B61C-464E-BD49-6E63C3249341]] +[[Property:weight|6]] +[[Property:title|OpenBSD]] +[[Property:link_title|OpenBSD]] +==Requirements== + +{| class="doctable" +|- +| '''Computer/Processor''' +| x86 or x86-64 +|- +| '''Operating System''' +| OpenBSD 6 with GTK+ 2.4 or greater +|- +| '''C compiler''' +| gcc +|- +| '''Memory''' +| 4GB of RAM +|- +| '''Hard Disk''' +| 1GB of free space +|- +| '''ISE_PLATFORM''' +| '''openbsd-x86''' for x86 based CPU and '''openbsd-x86-64''' for x64 based CPU. +|} + + +==Checking your environment== + +EiffelStudio requires GTK+ 2.4.0 or above to function properly. You can check that you have this installed correctly by typing the following command: +pkg-config --modversion gtk+-2.0 +The command should succeed and the version number of GTK+ should appear. If it is not 2.4.0 or above then you cannot continue the installation of EiffelStudio. You first need to install GTK+ 2.4.0. + +==Installing EiffelStudio from the Web== + +After downloading the installation package, you should manually extract its contents to your hard drive. For example, you can extract it into /usr/local using the following commands (assuming that you have permission to /usr/local and that the installation package was saved in /tmp/EiffelXX.tar.bz2, where XX corresponds to the EiffelStudio version number): + +cd /usr/local +tar xvfj /tmp/EiffelXX.tar.bz2 + +This will install EiffelStudio files into /usr/local/EiffelXX. Once this is done, jump to the [[#Setting up EiffelStudio|Setting up EiffelStudio]] section in order to complete the installation of EiffelStudio. + +==Installing EiffelStudio from a CD-ROM== + +Insert the CD into your CD-ROM drive. You should manually extract its contents to your hard drive. For example you can extract it in /usr/local using the following commands (assuming that you have permission to /usr/local and that the CD is mounted on /mnt/cdrom): +cd /usr/local +cp -r /mnt/cdrom/EiffelXX . + +This will install the EiffelStudio files into /usr/local/EiffelXX. To complete the installation of EiffelStudio, jump to the next section, [[#Setting up EiffelStudio|Setting up EiffelStudio]]. + +==Setting up EiffelStudio== + +Once the files have been installed, you should define the following environment variables in order to run EiffelStudio: +* '''ISE_EIFFEL''' to /usr/local/EiffelXX +* '''ISE_PLATFORM''' to openbsd-x86-64. +and add $'''ISE_EIFFEL'''/studio/spec/$'''ISE_PLATFORM'''/bin to your '''PATH''' environment variable. + +Using sh or bash as a shell, it suffices to type the following commands: + +export ISE_EIFFEL=/usr/local/EiffelXX +export ISE_PLATFORM=openbsd-x86-64 +export PATH=$PATH:$ISE_EIFFEL/studio/spec/$ISE_PLATFORM/bin + + +Using csh or tcsh as a shell, it suffices to type the following commands: + +setenv ISE_EIFFEL /usr/local/EiffelXX +setenv ISE_PLATFORM openbsd-x86-64 +set path = ($path $ISE_EIFFEL/studio/spec/$ISE_PLATFORM/bin) + + +If you are using the Enterprise edition, please follow the instructions of the next section, [[#Registering the Enterprise Edition|Registering the Enterprise Edition]], otherwise jump to the [[#Using EiffelStudio|Using EiffelStudio]] section at the end of this document. + +==Registering the Enterprise Edition== + +This step assumes you have followed the instructions in the [[#Setting up EiffelStudio|Setting up EiffelStudio]] section. Perform the following commands to start the registration process: +cd $ISE_EIFFEL +./register + +A dialog asking for your '''Username''' and '''CD Key''' should appear as it does below: + +
[[Image:56--unix-setup|Setup dialog]]
+ +Enter the information located inside the box that contains your copy of the EiffelStudio Enterprise Edition. Once the information is correct, the '''Register''' button will be enabled. Click '''Register''' to actually register EiffelStudio. + +The first time you launch EiffelStudio, you will be asked for an activation key through the following dialog: + +
[[Image:56--unix-registration|Registration dialog]]
+ +By clicking on the [http://activate.eiffel.com http://activate.eiffel.com] URL, a new web browser will appear with the requested fields automatically filled in with the appropriate information. Simply click '''Activate''' and a new page with an activation code will appear. Copy and paste the activation code in the first field and the '''Activate''' button should be enabled to let you activate your copy. + +You can activate your copy up to three times. Once you have reached this threshold and need to reinstall your copy, contact Eiffel Software to request one more activation. + +If no web browser appears, it is most likely because firefox is not installed on your machine or is not in your path. Instead you should manually launch a new web browser, go to the page [http://activate.eiffel.com http://activate.eiffel.com] , and enter the information manually. Then follow the above instructions as if the browser had been properly launched. + +You may receive the following dialog when launching EiffelStudio: + +
[[Image:56--unix-registration-error|Registration incomplete]]
+ +This probably means that the '''register''' program was not launched or did not succeed in storing data to the following file $'''ISE_EIFFEL'''/install/limand/.ec_license. To solve this, rerun the '''register''' program with a user account that has permissions to write at $'''ISE_EIFFEL'''/install/limand and enter your '''Username''' and '''CD Key'''. + +Once this is done, you can jump to the next section, [[#Using EiffelStudio|Using EiffelStudio]]. + +==Using EiffelStudio== + +===Starting EiffelStudio=== + +Now everything should be properly installed and you should be able to run the compiler. Launch '''estudio''' for the interactive graphical user interface of the compiler, or launch '''ec''' for the command line interface. If you are a new user to EiffelStudio, we recommend that you follow [[Introducing EiffelStudio|the EiffelStudio guided tour]]. + +===EiffelStudio Appearance=== + +EiffelStudio for Unix uses the GTK+ theme engine to allow for custom appearance such as changing the default font size and color of windows, etc. If you do not have a theme manager (such as that provided with Gnome) you can copy the .gtkrc-2.0 file from $'''ISE_EIFFEL'''/eifinit/studio/spec/gtk directory to your $'''HOME''' directory. + + + + diff --git a/documentation/18.11/eiffelstudio/getting_started/setup-and-installation/software-installation-eiffelstudio/eiffelstudio-freebsd.wiki b/documentation/18.11/eiffelstudio/getting_started/setup-and-installation/software-installation-eiffelstudio/eiffelstudio-freebsd.wiki new file mode 100644 index 00000000..b7fc60a4 --- /dev/null +++ b/documentation/18.11/eiffelstudio/getting_started/setup-and-installation/software-installation-eiffelstudio/eiffelstudio-freebsd.wiki @@ -0,0 +1,116 @@ +[[Property:title|FreeBSD]] +[[Property:weight|0]] +[[Property:uuid|b26ddd99-521b-6a10-79e6-e2a5d30f907c]] +==Requirements== + +{| class="doctable" +|- +| '''Computer/Processor''' +| x86 or x86-64 +|- +| '''Operating System''' +| FreeBSD 11 with GTK+ 2.4 or greater +|- +| '''C compiler''' +| gcc +|- +| '''Memory''' +| 4GB of RAM +|- +| '''Hard Disk''' +| 1GB of free space +|- +| '''ISE_PLATFORM''' +| '''freebsd-x86''' for x86 based CPU and '''freebsd-x86-64''' for x64 based CPU. +|} + + +==Checking your environment== + +EiffelStudio requires GTK+ 2.4.0 or above to function properly. You can check that you have this installed correctly by typing the following command: +pkg-config --modversion gtk+-2.0 +The command should succeed and the version number of GTK+ should appear. If it is not 2.4.0 or above then you cannot continue the installation of EiffelStudio. You first need to install GTK+ 2.4.0. + +==Installing EiffelStudio from the Web== + +After downloading the installation package, you should manually extract its contents to your hard drive. For example, you can extract it into /usr/local using the following commands (assuming that you have permission to /usr/local and that the installation package was saved in /tmp/EiffelXX.tar.bz2, where XX corresponds to the EiffelStudio version number): + +cd /usr/local +tar xvfj /tmp/EiffelXX.tar.bz2 + +This will install EiffelStudio files into /usr/local/EiffelXX. Once this is done, jump to the [[#Setting up EiffelStudio|Setting up EiffelStudio]] section in order to complete the installation of EiffelStudio. + +==Installing EiffelStudio from a CD-ROM== + +Insert the CD into your CD-ROM drive. You should manually extract its contents to your hard drive. For example you can extract it in /usr/local using the following commands (assuming that you have permission to /usr/local and that the CD is mounted on /mnt/cdrom): +cd /usr/local +cp -r /mnt/cdrom/EiffelXX . + +This will install the EiffelStudio files into /usr/local/EiffelXX. To complete the installation of EiffelStudio, jump to the next section, [[#Setting up EiffelStudio|Setting up EiffelStudio]]. + +==Setting up EiffelStudio== + +Once the files have been installed, you should define the following environment variables in order to run EiffelStudio: +* '''ISE_EIFFEL''' to /usr/local/EiffelXX +* '''ISE_PLATFORM''' to freebsd-x86. +and add $'''ISE_EIFFEL'''/studio/spec/$'''ISE_PLATFORM'''/bin to your '''PATH''' environment variable. + +Using sh or bash as a shell, it suffices to type the following commands: + +export ISE_EIFFEL=/usr/local/EiffelXX +export ISE_PLATFORM=freebsd-x86 +export PATH=$PATH:$ISE_EIFFEL/studio/spec/$ISE_PLATFORM/bin + + +Using csh or tcsh as a shell, it suffices to type the following commands: + +setenv ISE_EIFFEL /usr/local/EiffelXX +setenv ISE_PLATFORM freebsd-x86 +set path = ($path $ISE_EIFFEL/studio/spec/$ISE_PLATFORM/bin) + + +If you are using the Enterprise edition, please follow the instructions of the next section, [[#Registering the Enterprise Edition|Registering the Enterprise Edition]], otherwise jump to the [[#Using EiffelStudio|Using EiffelStudio]] section at the end of this document. + +==Registering the Enterprise Edition== + +This step assumes you have followed the instructions in the [[#Setting up EiffelStudio|Setting up EiffelStudio]] section. Perform the following commands to start the registration process: +cd $ISE_EIFFEL +./register + +A dialog asking for your '''Username''' and '''CD Key''' should appear as it does below: + +
[[Image:56--unix-setup|Setup dialog]]
+ +Enter the information located inside the box that contains your copy of the EiffelStudio Enterprise Edition. Once the information is correct, the '''Register''' button will be enabled. Click '''Register''' to actually register EiffelStudio. + +The first time you launch EiffelStudio, you will be asked for an activation key through the following dialog: + +
[[Image:56--unix-registration|Registration dialog]]
+ +By clicking on the [http://activate.eiffel.com http://activate.eiffel.com] URL, a new web browser will appear with the requested fields automatically filled in with the appropriate information. Simply click '''Activate''' and a new page with an activation code will appear. Copy and paste the activation code in the first field and the '''Activate''' button should be enabled to let you activate your copy. + +You can activate your copy up to three times. Once you have reached this threshold and need to reinstall your copy, contact Eiffel Software to request one more activation. + +If no web browser appears, it is most likely because firefox is not installed on your machine or is not in your path. Instead you should manually launch a new web browser, go to the page [http://activate.eiffel.com http://activate.eiffel.com] , and enter the information manually. Then follow the above instructions as if the browser had been properly launched. + +You may receive the following dialog when launching EiffelStudio: + +
[[Image:56--unix-registration-error|Registration incomplete]]
+ +This probably means that the '''register''' program was not launched or did not succeed in storing data to the following file $'''ISE_EIFFEL'''/install/limand/.ec_license. To solve this, rerun the '''register''' program with a user account that has permissions to write at $'''ISE_EIFFEL'''/install/limand and enter your '''Username''' and '''CD Key'''. + +Once this is done, you can jump to the next section, [[#Using EiffelStudio|Using EiffelStudio]]. + +==Using EiffelStudio== + +===Starting EiffelStudio=== + +Now everything should be properly installed and you should be able to run the compiler. Launch '''estudio''' for the interactive graphical user interface of the compiler, or launch '''ec''' for the command line interface. If you are a new user to EiffelStudio, we recommend that you follow [[Introducing EiffelStudio|the EiffelStudio guided tour]]. + +===EiffelStudio Appearance=== + +EiffelStudio for Unix uses the GTK+ theme engine to allow for custom appearance such as changing the default font size and color of windows, etc. If you do not have a theme manager (such as that provided with Gnome) you can copy the .gtkrc-2.0 file from $'''ISE_EIFFEL'''/eifinit/studio/spec/gtk directory to your $'''HOME''' directory. + + + + diff --git a/documentation/18.11/eiffelstudio/getting_started/setup-and-installation/software-installation-eiffelstudio/eiffelstudio-hp-openvms.wiki b/documentation/18.11/eiffelstudio/getting_started/setup-and-installation/software-installation-eiffelstudio/eiffelstudio-hp-openvms.wiki new file mode 100644 index 00000000..24853ee9 --- /dev/null +++ b/documentation/18.11/eiffelstudio/getting_started/setup-and-installation/software-installation-eiffelstudio/eiffelstudio-hp-openvms.wiki @@ -0,0 +1,88 @@ +[[Property:title|HP OpenVMS]] +[[Property:weight|1]] +[[Property:uuid|cccbd8cf-3bd6-8acb-e62d-7fb1ce0ef4c2]] +==Requirements== + +{| class="doctable" +|- +| '''Computer/Processor''' +| AlphaServer. +|- +| '''Operating System''' +| HP OpenVMS/Alpha version 7.3.2 with DECWindows and GTK+ 1.2.10. +|- +| '''C compiler''' +| Compaq C compiler V6 or later. +|- +| '''Memory''' +| 4GB of RAM +|- +| '''Hard Disk''' +| 1GB free disk space on an ODS-5 formatted volume, plus an additional 1GB of free space while performing the software installation. +|} + + +==Checking your environment== + +EiffelStudio requires GTK+ 1.2.10 or above to function properly. You can check that you have this installed correctly by typing the following command: +gtk-config --version +The command should succeed and the version number of GTK+ should appear. If it is not 1.2.10 or above then you cannot continue the installation of EiffelStudio. You first need to install GTK+ 1.2.10. + +==Installing the Enterprise Edition== + +===From the Web=== + +After downloading the '''eifXXvms.zip''' installation package (where XX stands for the EiffelStudio version number), unzip the distribution into temp:[dir] where where temp:[dir] is the location of a temporary directory: +unzip eifXXvms.zip temp:[dir] + +And use the following commands to install the files into eiffel_installation_path where eiffel_installation_path is a device:[directory] on an ODS-5 volume: +set file/attrib=(org:seq,rfm:fix,lrl:9216) temp:[dir]eifXXvms.save +backup temp:[dir]eifXXvms.save/save eiffel_installation_path + +===From a CD=== + +You must mount the installation CD-ROM volume with the following qualifier: +mount cd_dev:/media_format=cdrom/undefined_fat=fixed:cr:9216 + +where cd_dev: is the CD-ROM device. And use the following commands to install the files into eiffel_installation_path where eiffel_installation_path is a device:[directory] on an ODS-5 volume: +backup cd_dev:[000000]eifXXvms.save/save eiffel_installation_path + +===Completing the installation=== + +You must define a system-wide rooted logical name to reference the installation directory, for instance: +define/system EIFFELXX eiffel_installation_path:[directory.] /trans=conceal + +To use EiffelStudio for OpenVMS, run the setup procedure to define the environment: +@eiffel_installation_path:[000000]setup +This will define the logical names and DCL symbols required to run Eiffel. + +Once the files are copied and once the environment is setup up set, you need to register EiffelStudio. To do so type the following command: +RUN ISE_EIFFEL:[000000]register + +A dialog asking for your '''Username''' and '''CD Key''' should appear as it does below: + +
[[Image:56--unix-setup|Setup dialog]]
+ +Enter the information located inside the box that contains your copy of the EiffelStudio Enterprise Edition. Once the information is correct, the '''Register''' button will be enabled. Click '''Register''' to actually register EiffelStudio. + +The first time you launch EiffelStudio, you will be asked for an activation key through the following dialog: + +
[[Image:56--unix-registration|Registration dialog]]
+ +By clicking on the [http://activate.eiffel.com http://activate.eiffel.com] URL, a new web browser will appear with the requested fields automatically filled in with the appropriate information. Simply click '''Activate''' and a new page with an activation code will appear. Copy and paste the activation code in the first field and the '''Activate''' button should be enabled to let you activate your copy. + +You can activate your copy up to three times. Once you have reached this threshold and need to reinstall your copy, contact Eiffel Software to request one more activation. + +If no web broswer appears, it is most likely because netscape is not installed on your machine or is not in your path. Instead you should manually launch a new web browser and go to the page [http://activate.eiffel.com http://activate.eiffel.com] and enter the information manually. Then follow the above instructions as if the browser had been properly launched. + +You may receive the following dialog when launching EiffelStudio: + +
[[Image:56--unix-registration-error|Registration incomplete]]
+ +This probably means that the '''register''' program was not launched or did not succeed in storing data to the following file ISE_EIFFEL:[install.limand].ec_license. To solve this, rerun the '''register''' program with a user account that has permissions to write at ISE_EIFFEL:[install.limand] and enter your '''Username''' and '''CD Key'''. + +Once this is done you can jump to the next section "Using EiffelStudio." + + + + diff --git a/documentation/18.11/eiffelstudio/getting_started/setup-and-installation/software-installation-eiffelstudio/eiffelstudio-hp-tru64-unix.wiki b/documentation/18.11/eiffelstudio/getting_started/setup-and-installation/software-installation-eiffelstudio/eiffelstudio-hp-tru64-unix.wiki new file mode 100644 index 00000000..0c671ad7 --- /dev/null +++ b/documentation/18.11/eiffelstudio/getting_started/setup-and-installation/software-installation-eiffelstudio/eiffelstudio-hp-tru64-unix.wiki @@ -0,0 +1,115 @@ +[[Property:title|HP Tru64 UNIX]] +[[Property:weight|2]] +[[Property:uuid|f9ef1897-fa95-1c62-d905-54111ad234f1]] +==Requirements== + +{| class="doctable" +|- +| '''Computer/Processor''' +| AlphaServer. +|- +| '''Operating System''' +| HP Tru64 UNIX 5.1B with GTK+ 2.4. +|- +| '''C compiler''' +| HP C compiler +|- +| '''Memory''' +| 4GB of RAM +|- +| '''Hard Disk''' +| 1GB of free space +|- +| '''ISE_PLATFORM''' +| '''alpha'''. +|} + + +==Checking your environment== + +EiffelStudio requires GTK+ 2.4.0 or above to function properly. You can check that you have this installed correctly by typing the following command: +pkg-config --modversion gtk+-2.0 +The command should succeed and the version number of GTK+ should appear. If it is not 2.4.0 or above then you cannot continue the installation of EiffelStudio. You first need to install GTK+ 2.4.0. + +==Installing EiffelStudio from the Web== + +After downloading the installation package, you should manually extract its contents to your hard drive. For example, you can extract it into /usr/local using the following commands (assuming that you have permission to /usr/local and that the installation package was saved in /tmp/EiffelXX.tar.bz2, where XX stands for the EiffelStudio version): + +cd /usr/local +tar xvfj /tmp/EiffelXX.tar.bz2 + +This will install EiffelStudio files into /usr/local/EiffelXX. Once this is done, jump to the [[#Setting up EiffelStudio|Setting up EiffelStudio]] section in order to complete the installation of EiffelStudio. + +==Installing EiffelStudio from a CD-ROM== + +Insert the CD into your CD-ROM drive. You should manually extract its contents to your hard drive. For example you can extract it in /usr/local using the following commands (assuming that you have permission to /usr/local and that the CD is mounted on /mnt/cdrom): +cd /usr/local +cp -r /mnt/cdrom/EiffelXX . + +This will install the EiffelStudio files into /usr/local/EiffelXX. To complete the installation of EiffelStudio, jump to the next section, [[#Setting up EiffelStudio|Setting up EiffelStudio]]. + +==Setting up EiffelStudio== + +Once the files have been installed, you should define the following environment variables in order to run EiffelStudio: +* '''ISE_EIFFEL''' to /usr/local/EiffelXX +* '''ISE_PLATFORM''' to alpha. +and add $'''ISE_EIFFEL'''/studio/spec/$'''ISE_PLATFORM'''/bin to your '''PATH''' environment variable. + +Using sh or bash as a shell, it suffices to type the following commands: + +export ISE_EIFFEL=/usr/local/EiffelXX +export ISE_PLATFORM=alpha +export PATH=$PATH:$ISE_EIFFEL/studio/spec/$ISE_PLATFORM/bin + + +Using csh or tcsh as a shell, it suffices to type the following commands: + +setenv ISE_EIFFEL /usr/local/EiffelXX +setenv ISE_PLATFORM alpha +set path = ($path $ISE_EIFFEL/studio/spec/$ISE_PLATFORM/bin) + + +If you are using the Enterprise edition, please follow the instructions of the next section, [[#Registering the Enterprise Edition|Registering the Enterprise Edition]], otherwise jump to the [[#Using EiffelStudio|Using EiffelStudio]] section at the end of this document. + +==Registering the Enterprise Edition== + +This step assumes you have followed the instructions in the [[#Setting up EiffelStudio|Setting up EiffelStudio]] section. Perform the following commands to start the registration process: +cd $ISE_EIFFEL +./register + +A dialog asking for your '''Username''' and '''CD Key''' should appear as it does below: + +
[[Image:56--unix-setup|Setup dialog]]
+ +Enter the information located inside the box that contains your copy of the EiffelStudio Enterprise Edition. Once the information is correct, the '''Register''' button will be enabled. Click '''Register''' to actually register EiffelStudio. + +The first time you launch EiffelStudio, you will be asked for an activation key through the following dialog: + +
[[Image:56--unix-registration|Registration dialog]]
+ +By clicking on the [http://activate.eiffel.com http://activate.eiffel.com] URL, a new web browser will appear with the requested fields automatically filled in with the appropriate information. Simply click '''Activate''' and a new page with an activation code will appear. Copy and paste the activation code in the first field and the '''Activate''' button should be enabled to let you activate your copy. + +You can activate your copy up to three times. Once you have reached this threshold and need to reinstall your copy, contact Eiffel Software to request one more activation. + +If no web browser appears, it is most likely because firefox is not installed on your machine or is not in your path. Instead you should manually launch a new web browser, go to the page [http://activate.eiffel.com http://activate.eiffel.com] , and enter the information manually. Then follow the above instructions as if the browser had been properly launched. + +You may receive the following dialog when launching EiffelStudio: + +
[[Image:56--unix-registration-error|Registration incomplete]]
+ +This probably means that the '''register''' program was not launched or did not succeed in storing data to the following file $'''ISE_EIFFEL'''/install/limand/.ec_license. To solve this, rerun the '''register''' program with a user account that has permissions to write at $'''ISE_EIFFEL'''/install/limand and enter your '''Username''' and '''CD Key'''. + +Once this is done, you can jump to the next section, [[#Using EiffelStudio|Using EiffelStudio]]. + + +==Using EiffelStudio== + +===Starting EiffelStudio=== + +Now everything should be properly installed and you should be able to run the compiler. Launch '''estudio''' for the interactive graphical user interface of the compiler, or launch '''ec''' for the command line interface. If you are a new user to EiffelStudio, we recommend that you follow [[Introducing EiffelStudio|the EiffelStudio guided tour]]. + +===EiffelStudio Appearance=== + +EiffelStudio for Unix uses the GTK+ theme engine to allow for custom appearance such as changing the default font size and color of windows, etc. If you do not have a theme manager (such as that provided with Gnome) you can copy the .gtkrc-2.0 file from $'''ISE_EIFFEL'''/eifinit/studio/spec/gtk directory to your $'''HOME''' directory. + + diff --git a/documentation/18.11/eiffelstudio/getting_started/setup-and-installation/software-installation-eiffelstudio/eiffelstudio-hp-ux.wiki b/documentation/18.11/eiffelstudio/getting_started/setup-and-installation/software-installation-eiffelstudio/eiffelstudio-hp-ux.wiki new file mode 100644 index 00000000..c1e9d9ae --- /dev/null +++ b/documentation/18.11/eiffelstudio/getting_started/setup-and-installation/software-installation-eiffelstudio/eiffelstudio-hp-ux.wiki @@ -0,0 +1,118 @@ +[[Property:title|HP-UX]] +[[Property:weight|3]] +[[Property:uuid|c1982828-16bf-8984-bd8a-18df4b48cf27]] +==Requirements== + +{| class="doctable" +|- +| '''Computer/Processor''' +| HP-PA. +|- +| '''Operating System''' +| HP-UX 11 with GTK+ 2.4. +|- +| '''C compiler''' +| HP C compiler +|- +| '''Memory''' +| 4GB of RAM +|- +| '''Hard Disk''' +| 1GB of free space +|- +| '''ISE_PLATFORM''' +| '''hpux-11'''. +|} + + +==Checking your environment== + +EiffelStudio requires GTK+ 2.4.0 or above to function properly. You can check that you have this installed correctly by typing the following command: +pkg-config --modversion gtk+-2.0 +The command should succeed and the version number of GTK+ should appear. If it is not 2.4.0 or above then you cannot continue the installation of EiffelStudio. You first need to install GTK+ 2.4.0. + +==Installing EiffelStudio from the Web== + +After downloading the installation package, you should manually extract its contents to your hard drive. For example, you can extract it into /usr/local using the following commands (assuming that you have permission to /usr/local and that the installation package was saved in /tmp/EiffelXX.tar.bz2, where XX stands for the EiffelStudio version number): + +cd /usr/local +tar xvfj /tmp/EiffelXX.tar.bz2 + +This will install EiffelStudio files into /usr/local/EiffelXX. Once this is done, jump to the [[#Setting up EiffelStudio|Setting up EiffelStudio]] section in order to complete the installation of EiffelStudio. + +==Installing EiffelStudio from a CD-ROM== + +Insert the CD into your CD-ROM drive. You should manually extract its contents to your hard drive. For example you can extract it in /usr/local using the following commands (assuming that you have permission to /usr/local and that the CD is mounted on /mnt/cdrom): +cd /usr/local +cp -r /mnt/cdrom/EiffelXX . + +This will install the EiffelStudio files into /usr/local/EiffelXX. To complete the installation of EiffelStudio, jump to the next section, [[#Setting up EiffelStudio|Setting up EiffelStudio]]. + +==Setting up EiffelStudio== + +Once the files have been installed, you should define the following environment variables in order to run EiffelStudio: +* '''ISE_EIFFEL''' to /usr/local/EiffelXX +* '''ISE_PLATFORM''' to hpux-11. +and add $'''ISE_EIFFEL'''/studio/spec/$'''ISE_PLATFORM'''/bin to your '''PATH''' environment variable. + +Using sh or bash as a shell, it suffices to type the following commands: + +export ISE_EIFFEL=/usr/local/EiffelXX +export ISE_PLATFORM=hpux-11 +export PATH=$PATH:$ISE_EIFFEL/studio/spec/$ISE_PLATFORM/bin + + +Using csh or tcsh as a shell, it suffices to type the following commands: + +setenv ISE_EIFFEL /usr/local/EiffelXX +setenv ISE_PLATFORM hpux-11 +set path = ($path $ISE_EIFFEL/studio/spec/$ISE_PLATFORM/bin) + + +If you are using the Enterprise edition, please follow the instructions of the next section, [[#Registering the Enterprise Edition|Registering the Enterprise Edition]] , otherwise jump to the [[#Using EiffelStudio|Using EiffelStudio]] section at the end of this document. + +==Registering the Enterprise Edition== + +This step assumes you have followed the instructions in the [[#Setting up EiffelStudio|Setting up EiffelStudio]] section. Perform the following commands to start the registration process: +cd $ISE_EIFFEL +./register + +A dialog asking for your '''Username''' and '''CD Key''' should appear as it does below: + +
[[Image:56--unix-setup|Setup dialog]]
+ +Enter the information located inside the box that contains your copy of the EiffelStudio Enterprise Edition. Once the information is correct, the '''Register''' button will be enabled. Click '''Register''' to actually register EiffelStudio. + +The first time you launch EiffelStudio, you will be asked for an activation key through the following dialog: + +
[[Image:56--unix-registration|Registration dialog]]
+ + + +By clicking on the [http://activate.eiffel.com http://activate.eiffel.com] URL, a new web browser will appear with the requested fields automatically filled in with the appropriate information. Simply click '''Activate''' and a new page with an activation code will appear. Copy and paste the activation code in the first field and the '''Activate''' button should be enabled to let you activate your copy. + +You can activate your copy up to three times. Once you have reached this threshold and need to reinstall your copy, contact Eiffel Software to request one more activation. + +If no web browser appears, it is most likely because firefox is not installed on your machine or is not in your path. Instead you should manually launch a new web browser, go to the page [http://activate.eiffel.com http://activate.eiffel.com] , and enter the information manually. Then follow the above instructions as if the browser had been properly launched. + +You may receive the following dialog when launching EiffelStudio: + +
[[Image:56--unix-registration-error|Registration incomplete]]
+ +This probably means that the '''register''' program was not launched or did not succeed in storing data to the following file $'''ISE_EIFFEL'''/install/limand/.ec_license. To solve this, rerun the '''register''' program with a user account that has permissions to write at $'''ISE_EIFFEL'''/install/limand and enter your '''Username''' and '''CD Key'''. + +Once this is done, you can jump to the next section, [[#Using EiffelStudio|Using EiffelStudio]] . + +==Using EiffelStudio== + +===Starting EiffelStudio=== + +Now everything should be properly installed and you should be able to run the compiler. Launch '''estudio''' for the interactive graphical user interface of the compiler, or launch '''ec''' for the command line interface. If you are a new user to EiffelStudio, we recommend that you follow [[Introducing EiffelStudio|the EiffelStudio guided tour]]. + +===EiffelStudio Appearance=== + +EiffelStudio for Unix uses the GTK+ theme engine to allow for custom appearance such as changing the default font size and color of windows, etc. If you do not have a theme manager (such as that provided with Gnome) you can copy the .gtkrc-2.0 file from $'''ISE_EIFFEL'''/eifinit/studio/spec/gtk directory to your $'''HOME''' directory. + + + + diff --git a/documentation/18.11/eiffelstudio/getting_started/setup-and-installation/software-installation-eiffelstudio/eiffelstudio-linux.wiki b/documentation/18.11/eiffelstudio/getting_started/setup-and-installation/software-installation-eiffelstudio/eiffelstudio-linux.wiki new file mode 100644 index 00000000..4bd9b36a --- /dev/null +++ b/documentation/18.11/eiffelstudio/getting_started/setup-and-installation/software-installation-eiffelstudio/eiffelstudio-linux.wiki @@ -0,0 +1,141 @@ +[[Property:title|Linux]] +[[Property:weight|4]] +[[Property:uuid|db132d4c-7c65-59c0-6f9f-731b81c37373]] +==Requirements== + +{| class="doctable" +|- +| '''Computer/Processor''' +| x86 or x86-64, armv6 +|- +| '''Operating System''' +| Ubuntu 8.04 or any Linux system with glibc 2.7 and GTK+ 2.4. +|- +| '''C compiler''' +| gcc or SunStudio 12 Linux compiler +|- +| '''Memory''' +| 4GB of RAM +|- +| '''Hard Disk''' +| 1GB of free space +|- +| '''ISE_PLATFORM''' +| '''linux-x86''' for x86 based CPU, '''linux-x86-64''' for x64 based CPU. +|} + + +==Checking your environment== + +EiffelStudio requires GTK+ 2.4.0 or above to function properly. You can check that you have this installed correctly by typing the following command: +pkg-config --modversion gtk+-2.0 +The command should succeed and the version number of GTK+ should appear. If it is not 2.4.0 or above then you cannot continue the installation of EiffelStudio. You first need to install GTK+ 2.4.0. + +On some Linux distribution the Xtst library is required but not installed by default. You have to make sure it is installed by using the instruction of your Linux distribution. + +For example, on Debian based distribution you need to do: + +sudo apt-get install libgtk2.0-dev +sudo apt-get install libxtst-dev + + +==Installing EiffelStudio from the Web== + +After downloading the installation package, you should manually extract its contents to your hard drive. For example, you can extract it into /usr/local using the following commands (assuming that you have permission to /usr/local and that the installation package was saved in /tmp/EiffelXX.tar.bz2, where XX stands for the EiffelStudio version): + +cd /usr/local +tar xvfj /tmp/EiffelXX.tar.bz2 + +This will install EiffelStudio files into /usr/local/EiffelXX. Once this is done, jump to the [[#Setting up EiffelStudio|Setting up EiffelStudio]] section in order to complete the installation of EiffelStudio. + +==Installing EiffelStudio from a CD-ROM== + +Insert the CD into your CD-ROM drive. You should manually extract its contents to your hard drive. For example you can extract it in /usr/local using the following commands (assuming that you have permission to /usr/local and that the CD is mounted on /mnt/cdrom): +cd /usr/local +cp -r /mnt/cdrom/EiffelXX . + +This will install the EiffelStudio files into /usr/local/EiffelXX. To complete the installation of EiffelStudio, jump to the next section, [[#Setting up EiffelStudio|Setting up EiffelStudio]]. + + +==Setting up EiffelStudio== + +Once the files have been installed, you should define the following environment variables in order to run EiffelStudio: +* '''ISE_EIFFEL''' to /usr/local/EiffelXX +* '''ISE_PLATFORM''' to linux-x86 for the 32 bits version or linux-x86-64 for the 64 bits version. We will be using '''linux-x86-64''' in the examples below. +and add $'''ISE_EIFFEL'''/studio/spec/$'''ISE_PLATFORM'''/bin to your '''PATH''' environment variable. + +Using sh or bash as a shell, it suffices to type the following commands: + +export ISE_EIFFEL=/usr/local/EiffelXX +export ISE_PLATFORM=linux-x86-64 +export PATH=$PATH:$ISE_EIFFEL/studio/spec/$ISE_PLATFORM/bin + + +Using csh or tcsh as a shell, it suffices to type the following commands: + +setenv ISE_EIFFEL /usr/local/EiffelXX +setenv ISE_PLATFORM linux-x86-64 +set path = ($path $ISE_EIFFEL/studio/spec/$ISE_PLATFORM/bin) + + +If you are using the Enterprise edition, please follow the instructions of the next section, [[#Registering the Enterprise Edition|Registering the Enterprise Edition]], otherwise jump to the [[#Using EiffelStudio|Using EiffelStudio]] section at the end of this document. + +== Installing EiffelStudio on Ubuntu == +An alternative to previous solution for Ubuntu, is to use the ppa repository. +```shell +sudo add-apt-repository ppa:eiffelstudio-team/ppa +sudo apt-get update +sudo apt-get install eiffelstudio +``` +It installs EiffelStudio using the linux layout, so no specific environment variables are needed (note: ISE_EIFFEL and ISE_PLATFORM should not be set to use this linux layout). +The executable are located under `/usr/bin`, libraries under `/usr/lib/eiffelstudio`, ... + +To reinstall, or update: +```shell +sudo apt-get purge eiffelstudio +sudo apt-get update +sudo apt-get install eiffelstudio +``` + + +==Registering the Enterprise Edition== + +This step assumes you have followed the instructions in the [[#Setting up EiffelStudio|Setting up EiffelStudio]] section. Perform the following commands to start the registration process: +cd $ISE_EIFFEL +./register + +A dialog asking for your '''Username''' and '''CD Key''' should appear as it does below: + +
[[Image:56--unix-setup|Setup dialog]]
+ +Enter the information located inside the box that contains your copy of the EiffelStudio Enterprise Edition. Once the information is correct, the '''Register''' button will be enabled. Click '''Register''' to actually register EiffelStudio. + +The first time you launch EiffelStudio, you will be asked for an activation key through the following dialog: + +
[[Image:56--unix-registration|Registration dialog]]
+ +By clicking on the [http://activate.eiffel.com http://activate.eiffel.com] URL, a new web browser will appear with the requested fields automatically filled in with the appropriate information. Simply click '''Activate''' and a new page with an activation code will appear. Copy and paste the activation code in the first field and the '''Activate''' button should be enabled to let you activate your copy. + +You can activate your copy up to three times. Once you have reached this threshold and need to reinstall your copy, contact Eiffel Software to request one more activation. + +If no web browser appears, it is most likely because firefox is not installed on your machine or is not in your path. Instead you should manually launch a new web browser, go to the page [http://activate.eiffel.com http://activate.eiffel.com] , and enter the information manually. Then follow the above instructions as if the browser had been properly launched. + +You may receive the following dialog when launching EiffelStudio: + +
[[Image:56--unix-registration-error|Registration incomplete]]
+ +This probably means that the '''register''' program was not launched or did not succeed in storing data to the following file $'''ISE_EIFFEL'''/install/limand/.ec_license. To solve this, rerun the '''register''' program with a user account that has permissions to write at $'''ISE_EIFFEL'''/install/limand and enter your '''Username''' and '''CD Key'''. + +Once this is done, you can jump to the next section, [[#Using EiffelStudio|Using EiffelStudio]] . + +==Using EiffelStudio== + +===Starting EiffelStudio=== + +Now everything should be properly installed and you should be able to run the compiler. Launch '''estudio''' for the interactive graphical user interface of the compiler, or launch '''ec''' for the command line interface. If you are a new user to EiffelStudio, we recommend that you follow [[Introducing EiffelStudio|the EiffelStudio guided tour]]. + +===EiffelStudio Appearance=== + +EiffelStudio for Unix uses the GTK+ theme engine to allow for custom appearance such as changing the default font size and color of windows, etc. If you do not have a theme manager (such as that provided with Gnome) you can copy the .gtkrc-2.0 file from $'''ISE_EIFFEL'''/eifinit/studio/spec/gtk directory to your $'''HOME''' directory. + + diff --git a/documentation/18.11/eiffelstudio/getting_started/setup-and-installation/software-installation-eiffelstudio/eiffelstudio-mac-os-x.wiki b/documentation/18.11/eiffelstudio/getting_started/setup-and-installation/software-installation-eiffelstudio/eiffelstudio-mac-os-x.wiki new file mode 100644 index 00000000..f41924d0 --- /dev/null +++ b/documentation/18.11/eiffelstudio/getting_started/setup-and-installation/software-installation-eiffelstudio/eiffelstudio-mac-os-x.wiki @@ -0,0 +1,82 @@ +[[Property:title|Mac OS X]] +[[Property:weight|5]] +[[Property:uuid|7cf4e0e5-0858-58bb-351e-52becea59ede]] +==Requirements== + +{| class="doctable" +|- +| '''Computer/Processor''' +| x86-64 +|- +| '''Operating System''' +| Mac OS X 10.12 or above +|- +| '''C compiler''' +| Xcode 8.2 or greater +|- +| '''Memory''' +| 4GB of RAM +|- +| '''Hard Disk''' +| 1GB of free space +|- +| '''ISE_PLATFORM''' +| '''macosx-x86''' for x86 based CPU and '''macosx-x86-64''' for x64 based CPU. +|} + + +==Prerequisites== + +*You will need to install '''Xcode''' from the App Store.After installing Xcode, make sure to install the command line tools by going to the Xcode preferences and under '''Downloads''' install the '''Command Line Tools''' components. + +*You also need to install X11 from http://xquartz.macosforge.org. + +==Installing the GPL Edition== + +MacPorts is a tool that allows you to use many Unix applications on the Mac. We have created a package in the MacPorts repository that allows you to to install Eiffel Studio with all dependencies in a convenient way. First, install [http://guide.macports.org/#installing MacPorts]. + +Now simply type (from a bash [http://guides.macrumors.com/Terminal terminal]): +
+sudo port install eiffelstudio
+
+ + +When a new release of the same version EiffelStudio becomes available, you can upgrade like so: +
+sudo port selfupdate
+sudo port upgrade outdated
+
+ +==Installing EiffelStudio from a compressed package== +This section only applies if you have installed all the required prerequisites. If you are not sure, use the installation from MacPorts as described in the previous section. + +After downloading the compressed package, you should manually extract its contents to your hard drive. For example, you can extract it into /usr/local using the following commands (assuming that you have permission to /usr/local and that the installation package was saved in /tmp/Eiffel_X.Y.tar.bz2, where X.Y stands for the EiffelStudio version): + +cd /usr/local +tar xvfj /tmp/Eiffel_X.Y.tar.bz2 + +This will install EiffelStudio files into `/usr/local/Eiffel_X.Y` . Once this is done, jump to the [[#Setting up EiffelStudio|Setting up EiffelStudio]] section in order to complete the installation of EiffelStudio. + +== Setting up EiffelStudio == +Once the files have been installed, you should define the following environment variables in order to run EiffelStudio: +* ISE_EIFFEL to `/usr/local/Eiffel_X.Y` +* ISE_PLATFORM to `macosx-x86` for the 32 bits version or `macosx-x86-64` for the 64 bits version. We will be using `macosx-x86-64` in the examples below. +and add `$ISE_EIFFEL/studio/spec/$ISE_PLATFORM/bin` to your PATH environment variable. + +Using sh or bash as a shell, it suffices to type the following commands: +```shell +export ISE_EIFFEL=/usr/local/Eiffel_X.Y +export ISE_PLATFORM=macosx-x86-64 +export PATH=$PATH:$ISE_EIFFEL/studio/spec/$ISE_PLATFORM/bin +``` +(Note: you can write this into your .profile file). + +== Starting EiffelStudio == + +Now everything should be properly installed and you should be able to run the compiler. Simply navigate to /Applications/MacPorts/Eiffel''XX'' and double click the EiffelStudio icon. + +Alternatively, you can also start EiffelStudio from the command line by entering the command '''estudio''' or use the command-line eiffel compiler '''ec'''. + +If you are a new user to EiffelStudio, we recommend that you follow [[Introducing EiffelStudio|the EiffelStudio guided tour]]. + + diff --git a/documentation/18.11/eiffelstudio/getting_started/setup-and-installation/software-installation-eiffelstudio/eiffelstudio-sgi-irix.wiki b/documentation/18.11/eiffelstudio/getting_started/setup-and-installation/software-installation-eiffelstudio/eiffelstudio-sgi-irix.wiki new file mode 100644 index 00000000..d929ace2 --- /dev/null +++ b/documentation/18.11/eiffelstudio/getting_started/setup-and-installation/software-installation-eiffelstudio/eiffelstudio-sgi-irix.wiki @@ -0,0 +1,113 @@ +[[Property:title|SGI Irix]] +[[Property:weight|7]] +[[Property:uuid|f8de85e3-0786-071c-3ece-bbde6656dc20]] +==Requirements== + +{| class="doctable" +|- +| '''Computer/Processor''' +| MIPS. +|- +| '''Operating System''' +| Irix 6.5 with either Gnome 2.6 or GTK+ 2.4. +|- +| '''C compiler''' +| MIPSPro C compiler V2.4 or later. +|- +| '''Memory''' +| 4GB of RAM +|- +| '''Hard Disk''' +| 1GB of free space +|- +| '''ISE_PLATFORM''' +| '''irix-mips''' for 32 bits, '''irix-mips-64''' for 64 bits. +|} + + +==Checking your environment== + +EiffelStudio requires GTK+ 2.4.0 or above to function properly. You can check that you have this installed correctly by typing the following command: +pkg-config --modversion gtk+-2.0 +The command should succeed and the version number of GTK+ should appear. If it is not 2.4.0 or above then you cannot continue the installation of EiffelStudio. You first need to install GTK+ 2.4.0. + +==Installing EiffelStudio from the Web== + +After downloading the installation package, you should manually extract its contents to your hard drive. For example, you can extract it into /usr/local using the following commands (assuming that you have permission to /usr/local and that the installation package was saved in /tmp/EiffelXX.tar.bz2, where XX stands for the EiffelStudio version): + +cd /usr/local +tar xvfj /tmp/EiffelXX.tar.bz2 + +This will install EiffelStudio files into /usr/local/EiffelXX. Once this is done, jump to the [[#Setting up EiffelStudio|Setting up EiffelStudio]] section in order to complete the installation of EiffelStudio. + +==Installing EiffelStudio from a CD-ROM== + +Insert the CD into your CD-ROM drive. You should manually extract its contents to your hard drive. For example you can extract it in /usr/local using the following commands (assuming that you have permission to /usr/local and that the CD is mounted on /mnt/cdrom): +cd /usr/local +cp -r /mnt/cdrom/EiffelXX . + +This will install the EiffelStudio files into /usr/local/EiffelXX. To complete the installation of EiffelStudio, jump to the next section, [[#Setting up EiffelStudio|Setting up EiffelStudio]]. + +==Setting up EiffelStudio== + +Once the files have been installed, you should define the following environment variables in order to run EiffelStudio: +* '''ISE_EIFFEL''' to /usr/local/EiffelXX +* '''ISE_PLATFORM''' to irix-mips for the 32 bits version or irix-mips-64 for the 64 bits version. We will be using '''irix-mips''' in the examples below. +and add $'''ISE_EIFFEL'''/studio/spec/$'''ISE_PLATFORM'''/bin to your '''PATH''' environment variable. + +Using sh or bash as a shell, it suffices to type the following commands: + +export ISE_EIFFEL=/usr/local/EiffelXX +export ISE_PLATFORM=irix-mips +export PATH=$PATH:$ISE_EIFFEL/studio/spec/$ISE_PLATFORM/bin + + +Using csh or tcsh as a shell, it suffices to type the following commands: + +setenv ISE_EIFFEL /usr/local/EiffelXX +setenv ISE_PLATFORM irix-mips +set path = ($path $ISE_EIFFEL/studio/spec/$ISE_PLATFORM/bin) + + +If you are using the Enterprise edition, please follow the instructions of the next section, [[#Registering the Enterprise Edition|Registering the Enterprise Edition]], otherwise jump to the [[#Using EiffelStudio|Using EiffelStudio]] section at the end of this document. + +==Registering the Enterprise Edition== + +This step assumes you have followed the instructions in the [[#Setting up EiffelStudio|Setting up EiffelStudio]] section. Perform the following commands to start the registration process: +cd $ISE_EIFFEL +./register + +A dialog asking for your '''Username''' and '''CD Key''' should appear as it does below: + +
[[Image:56--unix-setup|Setup dialog]]
+ +Enter the information located inside the box that contains your copy of the EiffelStudio Enterprise Edition. Once the information is correct, the '''Register''' button will be enabled. Click '''Register''' to actually register EiffelStudio. + +The first time you launch EiffelStudio, you will be asked for an activation key through the following dialog: + +
[[Image:56--unix-registration|Registration dialog]]
+ +By clicking on the [http://activate.eiffel.com http://activate.eiffel.com] URL, a new web browser will appear with the requested fields automatically filled in with the appropriate information. Simply click '''Activate''' and a new page with an activation code will appear. Copy and paste the activation code in the first field and the '''Activate''' button should be enabled to let you activate your copy. + +You can activate your copy up to three times. Once you have reached this threshold and need to reinstall your copy, contact Eiffel Software to request one more activation. + +If no web browser appears, it is most likely because firefox is not installed on your machine or is not in your path. Instead you should manually launch a new web browser, go to the page [http://activate.eiffel.com http://activate.eiffel.com] , and enter the information manually. Then follow the above instructions as if the browser had been properly launched. + +You may receive the following dialog when launching EiffelStudio: + +
[[Image:56--unix-registration-error|Registration incomplete]]
+ +This probably means that the '''register''' program was not launched or did not succeed in storing data to the following file $'''ISE_EIFFEL'''/install/limand/.ec_license. To solve this, rerun the '''register''' program with a user account that has permissions to write at $'''ISE_EIFFEL'''/install/limand and enter your '''Username''' and '''CD Key'''. + +Once this is done, you can jump to the next section, [[#Using EiffelStudio|Using EiffelStudio]]. + +==Using EiffelStudio== + +===Starting EiffelStudio=== + +Now everything should be properly installed and you should be able to run the compiler. Launch '''estudio''' for the interactive graphical user interface of the compiler, or launch '''ec''' for the command line interface. If you are a new user to EiffelStudio, we recommend that you follow [[Introducing EiffelStudio|the EiffelStudio guided tour]]. + +===EiffelStudio Appearance=== + +EiffelStudio for Unix uses the GTK+ theme engine to allow for custom appearance such as changing the default font size and color of windows, etc. If you do not have a theme manager (such as that provided with Gnome) you can copy the .gtkrc-2.0 file from $'''ISE_EIFFEL'''/eifinit/studio/spec/gtk directory to your $'''HOME''' directory. + diff --git a/documentation/18.11/eiffelstudio/getting_started/setup-and-installation/software-installation-eiffelstudio/eiffelstudio-solaris.wiki b/documentation/18.11/eiffelstudio/getting_started/setup-and-installation/software-installation-eiffelstudio/eiffelstudio-solaris.wiki new file mode 100644 index 00000000..f1165b94 --- /dev/null +++ b/documentation/18.11/eiffelstudio/getting_started/setup-and-installation/software-installation-eiffelstudio/eiffelstudio-solaris.wiki @@ -0,0 +1,116 @@ +[[Property:title|Solaris]] +[[Property:weight|8]] +[[Property:uuid|3b85b8dc-c2b8-021a-f4bc-a8d19ad63b81]] +==Requirements== + +{| class="doctable" +|- +| '''Computer/Processor''' +| UltraSparc, x86 or x86-64 +|- +| '''Operating System''' +| Solaris 9.0 or greater for UltraSparc, Solaris 10 or greater for x86 and x86-64 with either Gnome 2.6 or GTK+ 2.4. +|- +| '''C compiler''' +| Sun Studio 12 C compiler +|- +| '''Memory''' +| 4GB of RAM +|- +| '''Hard Disk''' +| 1GB of free space +|- +| '''ISE_PLATFORM''' +| '''solaris-sparc''' for 32 bits version of Solaris on Sparc processor, '''solaris-sparc-64''' for 64 bits versions, '''solaris-x86''' and '''solaris-x86-64''' for the Intel processor on 32 and 64 bits. +|} + + +==Checking your environment== + +EiffelStudio requires GTK+ 2.4.0 or above to function properly. You can check that you have this installed correctly by typing the following command: +pkg-config --modversion gtk+-2.0 +The command should succeed and the version number of GTK+ should appear. If it is not 2.4.0 or above then you cannot continue the installation of EiffelStudio. You first need to install GTK+ 2.4.0. + +EiffelStudio requires the library file libmlib.so.2. If this file is missing from your Solaris installation, you can install it by installing medialib. + +==Installing EiffelStudio from the Web== + +After downloading the installation package, you should manually extract its contents to your hard drive. For example, you can extract it into /usr/local using the following commands (assuming that you have permission to /usr/local and that the installation package was saved in /tmp/EiffelXX.tar.bz2, where XX stands for the EiffelStudio version): + +cd /usr/local +tar xvfj /tmp/EiffelXX.tar.bz2 + +This will install EiffelStudio files into /usr/local/EiffelXX. Once this is done, jump to the [[#Setting up EiffelStudio|Setting up EiffelStudio]] section in order to complete the installation of EiffelStudio. + +==Installing EiffelStudio from a CD-ROM== + +Insert the CD into your CD-ROM drive. You should manually extract its contents to your hard drive. For example you can extract it in /usr/local using the following commands (assuming that you have permission to /usr/local and that the CD is mounted on /mnt/cdrom): +cd /usr/local +cp -r /mnt/cdrom/EiffelXX . + +This will install the EiffelStudio files into /usr/local/EiffelXX. To complete the installation of EiffelStudio, jump to the next section, [[#Setting up EiffelStudio|Setting up EiffelStudio]] . + +==Setting up EiffelStudio== + +Once the files have been installed, you should define the following environment variables in order to run EiffelStudio: +* '''ISE_EIFFEL''' to /usr/local/EiffelXX +* '''ISE_PLATFORM''' to solaris-sparc for the 32 bits version or solaris-sparc-64 for the 64 bits version, respectively solaris-x86 and solaris-x86-64 for Solaris on Intel processors. We will be using '''solaris-sparc''' in the examples below. +and add $'''ISE_EIFFEL'''/studio/spec/$'''ISE_PLATFORM'''/bin to your '''PATH''' environment variable. + +Using sh or bash as a shell, it suffices to type the following commands: + +export ISE_EIFFEL=/usr/local/EiffelXX +export ISE_PLATFORM=solaris-sparc +export PATH=$PATH:$ISE_EIFFEL/studio/spec/$ISE_PLATFORM/bin + + +Using csh or tcsh as a shell, it suffices to type the following commands: + +setenv ISE_EIFFEL /usr/local/EiffelXX +setenv ISE_PLATFORM solaris-sparc +set path = ($path $ISE_EIFFEL/studio/spec/$ISE_PLATFORM/bin) + + +If you are using the Enterprise edition, please follow the instructions of the next section, [[#Registering the Enterprise Edition|Registering the Enterprise Edition]] , otherwise jump to the [[#Using EiffelStudio|Using EiffelStudio]] section at the end of this document. + +==Registering the Enterprise Edition== + +This step assumes you have followed the instructions in the [[#Setting up EiffelStudio|Setting up EiffelStudio]] section. Perform the following commands to start the registration process: +cd $ISE_EIFFEL +./register + +A dialog asking for your '''Username''' and '''CD Key''' should appear as it does below: + +
[[Image:56--unix-setup|Setup dialog]]
+ +Enter the information located inside the box that contains your copy of the EiffelStudio Enterprise Edition. Once the information is correct, the '''Register''' button will be enabled. Click '''Register''' to actually register EiffelStudio. + +The first time you launch EiffelStudio, you will be asked for an activation key through the following dialog: + +
[[Image:56--unix-registration|Registration dialog]]
+ +By clicking on the [http://activate.eiffel.com http://activate.eiffel.com] URL, a new web browser will appear with the requested fields automatically filled in with the appropriate information. Simply click '''Activate''' and a new page with an activation code will appear. Copy and paste the activation code in the first field and the '''Activate''' button should be enabled to let you activate your copy. + +You can activate your copy up to three times. Once you have reached this threshold and need to reinstall your copy, contact Eiffel Software to request one more activation. + +If no web browser appears, it is most likely because firefox is not installed on your machine or is not in your path. Instead you should manually launch a new web browser, go to the page [http://activate.eiffel.com http://activate.eiffel.com] , and enter the information manually. Then follow the above instructions as if the browser had been properly launched. + +You may receive the following dialog when launching EiffelStudio: + +
[[Image:56--unix-registration-error|Registration incomplete]]
+ +This probably means that the '''register''' program was not launched or did not succeed in storing data to the following file $'''ISE_EIFFEL'''/install/limand/.ec_license. To solve this, rerun the '''register''' program with a user account that has permissions to write at $'''ISE_EIFFEL'''/install/limand and enter your '''Username''' and '''CD Key'''. + +Once this is done, you can jump to the next section, [[#Using EiffelStudio|Using EiffelStudio]] . + +==Using EiffelStudio== + +===Starting EiffelStudio=== + +Now everything should be properly installed and you should be able to run the compiler. Launch '''estudio''' for the interactive graphical user interface of the compiler, or launch '''ec''' for the command line interface. If you are a new user to EiffelStudio, we recommend that you follow [[Introducing EiffelStudio|the EiffelStudio guided tour]]. + +===EiffelStudio Appearance=== + +EiffelStudio for Unix uses the GTK+ theme engine to allow for custom appearance such as changing the default font size and color of windows, etc. If you do not have a theme manager (such as that provided with Gnome) you can copy the .gtkrc-2.0 file from $'''ISE_EIFFEL'''/eifinit/studio/spec/gtk directory to your $'''HOME''' directory. + + diff --git a/documentation/18.11/eiffelstudio/getting_started/setup-and-installation/software-installation-eiffelstudio/index.wiki b/documentation/18.11/eiffelstudio/getting_started/setup-and-installation/software-installation-eiffelstudio/index.wiki new file mode 100644 index 00000000..6bac21f2 --- /dev/null +++ b/documentation/18.11/eiffelstudio/getting_started/setup-and-installation/software-installation-eiffelstudio/index.wiki @@ -0,0 +1,5 @@ +[[Property:title|Software Installation for EiffelStudio]] +[[Property:weight|0]] +[[Property:uuid|b92cecd4-4a0c-e2f5-b63e-5d01d39ba990]] +Select the operating system you are using for detailed installation instructions: + diff --git a/documentation/18.11/eiffelstudio/getting_started/setup-and-installation/software-installation-eiffelstudio/windows.wiki b/documentation/18.11/eiffelstudio/getting_started/setup-and-installation/software-installation-eiffelstudio/windows.wiki new file mode 100644 index 00000000..de987469 --- /dev/null +++ b/documentation/18.11/eiffelstudio/getting_started/setup-and-installation/software-installation-eiffelstudio/windows.wiki @@ -0,0 +1,63 @@ +[[Property:title|Windows]] +[[Property:weight|9]] +[[Property:uuid|d177e0bc-63e6-63b3-7fdb-5e7136945e21]] +==Requirements== + +{| class="doctable" +|- +| '''Computer/Processor''' +| x86 or x86-64 +|- +| '''Operating System''' +| Windows 7, Windows 8, Windows 8.1 and Windows 10 +|- +| '''C compiler''' +| Microsoft Visual Studio 2010 or greater, or using MinGW (gcc) included in the EiffelStudio delivery +|- +| '''Memory''' +| 4GB of RAM +|- +| '''Hard Disk''' +| 1GB of free space. +|- +| '''ISE_PLATFORM''' +| '''windows''' for 32 bits version of Windows, '''win64''' for 64 bits version of Windows. +|} + + +==Installing EiffelStudio from the Web== + +After downloading the '''EiffelXX.msi''' installation package, right click on it and select '''Install'''. This will launch the installation procedure. Follow the steps indicated in the dialogs to complete the installation. + +==Installing the Enterprise Edition.== + +Insert the CD into your CD-ROM drive. If you have the autorun facility enabled, the installation process will automatically be launched. Otherwise you can launch it by executing '''EiffelXX.msi''' located at the root of the CD. During the installation you will be asked for your '''Username''' and '''CD Key''' + +Enter the information located inside the box that contains your copy of the EiffelStudio Enterprise Edition, or that you will have received via email. Once the information is correct, the '''Next''' button will be enabled. Click '''Next''' and follow the steps indicated in the dialogs to complete the installation. + +Once installed, the first time you launch EiffelStudio, you will be asked for an activation key through the following dialog: + +
[[Image:56--windows-registration|Registration dialog]]
+ +By clicking on the [http://activate.eiffel.com http://activate.eiffel.com] URL, a new web browser will appear with the requested fields automatically filled in with the appropriate information. Simply click '''Activate''' and a new page with an activation code will appear. Copy and paste the activation code in the first field and the '''Activate''' button should be enabled to let you activate your copy. + +You can activate your copy up to three times. Once you have reached this threshold and need to reinstall your copy, contact Eiffel Software to request one more activation. + +You may receive the following dialog when launching EiffelStudio: + +
[[Image:56--windows-registration-error|Registration incomplete]]
+ +This probably means that EiffelStudio was not properly installed using the '''setup.exe''' program. Uninstall EiffelStudio and rerun the installation procedure by making sure to launch '''setup.exe''' and enter your '''Username''' and '''CD Key'''. + +==.NET Support== + +To enable .NET support in EiffelStudio, it is necessary to install the Microsoft .NET Framework prior to starting the installation of EiffelStudio. EiffelStudio currently supports all the versions of the .NET Framework up to 4.0. + +==What about Windows 95, 98 and Me?== + +EiffelStudio will not run on Windows 95, 98 and Me. Contact Eiffel Software directly if you need support for those OSes. EiffelStudio generated code could run on 95, 98 and Me if no UI is being used. If the UI is used it could run but it requires installing the Microsoft Layer for Unicode. + +==Starting EiffelStudio== + +Now everything should be properly installed and you should be able to run the compiler. You can now launch EiffelStudio from the Start menu or from the EiffelStudio shortcut on your desktop. If you are a new user to EiffelStudio, we recommend that you follow [[Introducing EiffelStudio|the EiffelStudio guided tour]]. + diff --git a/documentation/18.11/eiffelstudio/getting_started/setup-and-installation/third-party-tools-installation-help.wiki b/documentation/18.11/eiffelstudio/getting_started/setup-and-installation/third-party-tools-installation-help.wiki new file mode 100644 index 00000000..137f8afd --- /dev/null +++ b/documentation/18.11/eiffelstudio/getting_started/setup-and-installation/third-party-tools-installation-help.wiki @@ -0,0 +1,11 @@ +[[Property:title|Third Party Tools Installation Help]] +[[Property:weight|1]] +[[Property:uuid|5896dc5f-a3dd-2535-e2c3-81593363d8e9]] +Here you can find help for installing third party tools and programs which may be necessary for your Eiffel programming needs. + +==[http://dev.eiffel.com/Installing_Microsoft_C_compiler Free Microsoft C Compiler ]== + + + + + diff --git a/documentation/18.11/eiffelstudio/index.wiki b/documentation/18.11/eiffelstudio/index.wiki new file mode 100644 index 00000000..feaa74db --- /dev/null +++ b/documentation/18.11/eiffelstudio/index.wiki @@ -0,0 +1,34 @@ +[[Property:title|EiffelStudio]] +[[Property:description|EiffelStudio Interactive Software Development Environment]] +[[Property:weight|2]] +[[Property:uuid|002fbffc-7aee-ea95-14fc-9f4fac1add82]] +==The EiffelStudio Interactive Software Development Environment== + +The material in this book is designed to help you apply the EiffelStudio interactive development environment to your software development challenges. + +EiffelStudio is specifically crafted to make it easier for developers to create high quality software systems using the Eiffel method and language. EiffelStudio is continually improving, with new features and capabilities added in every new release. + + +{| border="1" +|+'''EiffelStudio''' +|- +| valign="top"| +[[Image:es gt a development window 01|thumb|center|220px|[[Starting To Browse|Development Window]] ]] +| valign="top"| +[[Image:es gt class tool 01|thumb|center|220px|[[Viewing Classes|The Class tool]] ]] +| valign="top"| +[[Image:es gt docking in progress 01|thumb|center|220px|[[Customizing the tools layout and toolbars|Customizing the layout with docking]] ]] +|- +| valign="top"| +[[Image:es gt debug breakpoint reached 01|thumb|center|220px|[[Debugging and Run-time Monitoring|Debugging and runtime monitoring]] ]] +| valign="top"| +[[Image:AutoTest tool with failed test|thumb|center|160px|[[Using AutoTest|Automated testing]] ]] +| valign="top"| +[[Image:es gt testroot is client of heir|thumb|center|220px|[[Graphics-based Design|Graphics-based design]] ]] +|- +| valign="top"| +[[Image:Metrics tool Metrics evaluation pane|thumb|center|220px|[[Computing Project Metrics|Computing project metrics]] ]] +|} + + + diff --git a/documentation/18.11/faq/index.wiki b/documentation/18.11/faq/index.wiki new file mode 100644 index 00000000..12bb29bc --- /dev/null +++ b/documentation/18.11/faq/index.wiki @@ -0,0 +1,28 @@ +[[Property:modification_date|Fri, 07 Sep 2018 13:34:06 GMT]] +[[Property:publication_date|Fri, 07 Sep 2018 09:34:23 GMT]] +[[Property:title|FAQ]] +[[Property:description|Frequently Asked Questions]] +[[Property:link_title|FAQ]] +[[Property:weight|5]] +[[Property:uuid|e604c263-249d-48d2-8238-b3d027ed04dd]] + +== I have Visual Studio on my machine, but EiffelStudio cannot find it == + +Here is a summary of steps to make sure C code compiles using Visual Studio 2017 in 64-bit mode on 64-bit Windows 10: + +# Cleanup all projects by removing EIFGENs directories (including those in precompiles). +# Setup Visual Studio 2017 environment in 64-bit mode by running +#:...\vsdevcmd.bat -arch=amd64 +# Setup EiffelStudio environment by running (most probably, this step is unnecessary if using GUI only) +#:...\esvars.bat +# Tell EiffelStudio to use Visual Studio 2017-compatible libraries +#:set ISE_C_COMPILER=msc_vc140 +# Launch EiffelStudio from the command prompt: +#:estudio + + +=== See also: === +*[https://www.eiffel.org/doc/uuid/B2E4622A-2495-47DD-9C02-B9940A026EC1 Mini How-tos] +* [https://www.eiffel.com/resources/faqs/eiffel-language/ General Eiffel FAQ] +* [https://www.eiffel.com/resources/faqs/eiffel-studio/ EiffelStudio FAQ] + diff --git a/documentation/18.11/glossary/index.wiki b/documentation/18.11/glossary/index.wiki new file mode 100644 index 00000000..2242bc34 --- /dev/null +++ b/documentation/18.11/glossary/index.wiki @@ -0,0 +1,423 @@ +[[Property:title|Glossary]] +[[Property:link_title|Glossary]] +[[Property:description|Glossary of Object Technology]] +[[Property:weight|4]] +[[Property:uuid|b8c10baa-4f50-adfe-a6f8-9cb56a8f1917]] +This glossary provides brief definitions of the principal terms of object technology, discussed in detail in the book ''[[uuid:496983ef-b86e-772e-16b9-39b37ef80e37|Object-Oriented Software Construction, 2nd Edition]]'' and used in this website. ''Italics font'' in a definition marks a term or phrase, other than the ubiquitous "class", that is itself the subject of another definition. + +==Abstract class== +:See ''[[#Deferred class|deferred class]]''. + +==Abstract data type (ADT)== +:A set of mathematical elements specified by listing the functions applicable to all these elements and the formal properties of these functions. + +==Abstract object== +:An element of an [[#Abstract data type (ADT)|''abstract data type (ADT)'']]. + +==Ancestor (of a class)== +:The class itself, or one of its direct or indirect ''[[#Parent (of a class)|parents]]''. + +==Assertion== +:A formal condition describing the semantic properties of software elements, especially routines and loops. Used in expressing ''[[#Contract|contracts]]''. Assertions include in particular ''[[#Precondition|preconditions]]'', ''[[#Postcondition|postconditions]]'', ''[[#Class invariant|class invariants]]'' and ''[[#Loop invariant|loop invariants]]''. + +==Assignment attempt== +:An operation that conditionally attaches an ''[[#Object|object]]'' to a ''[[#Reference|reference]]'', only if the object’s type ''[[#Conformance|conforms]]'' to the type declared for the corresponding ''[[#Entity|entity]]''. + +==Asynchronous call== +:A call which lets its caller proceed before it completes. Antonym: ''[[#Synchronous call|synchronous call]]''. + +==Attribute== +:The description of a ''[[#Field|field]]'' present in all the ''[[#Instance (of a class)|instances]]'' of a class. Along with the ''[[#Routine|routine]]'', one of the two forms of ''[[#Feature|feature]]''. + +==Behavior class== +:A class, usually ''[[#Deferred class|deferred]]'', describing a set of adaptable behaviors through ''[[#Effective feature|effective routines]]'' relying on some components (usually ''[[#Deferred feature|deferred features]]'') that may be ''[[#Redeclaration|redeclared]]'' to capture specific variants of the general behaviors. + +==Class== +:A partially or totally implemented ''[[#Abstract data type (ADT)|abstract data type]]''. Serves both as a ''[[#Module|module]]'' and as a ''[[#Type|type]]'' (or type pattern if the class is ''[[#Generic class|generic]]''.) + +==Class invariant== +:An ''[[#Assertion|assertion]]'' which must be satisfied on creation of every ''[[#Instance (of a class)|instance]]'' of a class, and preserved by every exported routine of the class, so that it will be satisfied by all instances of the class whenever they are externally observable. + +==Client== +:A class that uses the features of another, its ''[[#Supplier|supplier]]'', on the basis of the supplier's interface specification (''[[#Contract|contract]]''). + +==Cluster== +:A group of related classes or, recursively, of related clusters. + +==Component== +:See ''[[#Reusable software component|reusable software component]]''. + +==Concurrent== +:Able to use two or more ''[[#Processor|processors]]''. Antonym: ''[[#Sequential|sequential]]''. + +==Conformance== +:A relation between types. A type conforms to another if it is derived from it by ''[[#Inheritance|inheritance]]''. + +==Constrained genericity== +:A form of ''[[#Genericity|genericity]]'' where a formal generic parameter represents not an arbitrary type, but one that is required to ''[[#Conformance|conform]]'' to a certain type, known as the constraint. See ''[[#Constrained genericity|constrained genericity]]''. + +==Container data structure== +:An ''[[#Object|object]]'' whose primary use is to provide access to a number of other objects. Examples include lists, queues, stacks, arrays. + +==Contract== +:The set of precise conditions that govern the relations between a ''[[#Supplier|supplier]]'' class and its ''[[#Client|clients]]''. The contract for a class includes individual contracts for the exported routines of the class, represented by ''[[#Precondition|preconditions]]'' and ''[[#Postcondition|postconditions]]'', and the global class properties, represented by the ''[[#Class invariant|class invariant]]''. See also ''[[#Design by Contract|Design by Contract]]''. + +==Contravariance== +:The policy allowing a feature ''[[#Redeclaration|redeclaration]]'' to change the ''[[#Signature (of a feature)|signature]]'' so that a new result type will ''[[#Conformance|conform]]'' to the original but the original argument types conform to the new. See also: ''[[#Covariance|covariance]]'', ''[[#Novariance|novariance]]''. + +==Covariance== +:The policy allowing a feature ''[[#Redeclaration|redeclaration]]'' to change the ''[[#Signature (of a feature)|signature]]'' so that the new types of both arguments and result ''[[#Conformance|conform]]'' to the originals. See also: ''[[#Contravariance|contravariance]]'', ''[[#Novariance|novariance]]''. + +==Current object (or: current instance)== +:During the execution of an ''[[#Object-oriented|object-oriented]]'' software system, the target of the most recently started routine call. + +==Defensive programming== +:A technique of fighting potential errors by making every module check for many possible consistency conditions, even if this causes redundancy of checks performed by ''[[#Client|clients]]'' and ''[[#Supplier|suppliers]]''. Contradicts ''[[#Design by Contract|Design by Contract]]''. + +==Deferred class== +:A class which has at least one ''[[#Deferred feature|deferred feature]]''. Antonym: ''[[#Effective class|effective class]]''. + +==Deferred feature== +:A feature which, in a certain class, has a specification but no implementation. May be declared as deferred in the class itself, or inherited as deferred and not ''[[#Effect|effected]]'' in the class. Antonym: ''[[#Effective feature|effective feature]]''. + +==Descendant (of a class)== +:The class itself, or one of its direct or indirect ''[[#Heir (of a class)|heirs]]''. + +==Design by Contract== +:A method of software construction that designs the components of a ''[[#System|system]]'' so that they will cooperate on the basis of precisely defined ''[[#Contract|contracts]]''. See also: ''[[#Defensive programming|defensive programming]]''. + +==Direct instance (of a class)== +:An ''[[#Object|object]]'' built according to the mold defined by the class. + +==Dynamic== +:Occurring during the execution of a ''[[#System|system]]''. See also ''[[#Run time (noun, two words)|run time]]''. Antonym: ''[[#Static|static]]''. + +==Dynamic binding== +:The guarantee that every execution of an operation will select the correct version of the operation, based on the type of the operation's target. + +==Dynamic typing== +:The policy whereby applicability of operations to their target ''[[#Object|objects]]'' is only checked at run time, prior to executing each operation. + +==Effect== +:A class effects a feature if it inherits it in ''[[#Deferred feature|deferred]]'' form and provides an ''[[#Effecting|effecting]]'' for that feature. + +==Effecting== +:A ''[[#Redeclaration|redeclaration]]'' which provides an implementation (as ''[[#Attribute|attribute]]'' or ''[[#Routine|routine]]'') of a feature inherited in ''[[#Deferred feature|deferred]]'' form. + +==Effective class== +:A class which only has ''[[#Effective feature|effective features]]'' (that is to say, does not introduce any ''[[#Deferred feature|deferred feature]]'', and, if it inherits any deferred feature, ''[[#Effect|effects]]'' it). Antonym: ''[[#Deferred class|deferred class]]''. + +==Effective feature== +:A feature declared with an implementation - either as a routine which is not ''[[#Deferred feature|deferred]]'', or as an ''[[#Attribute|attribute]]''. Antonym: ''[[#Deferred feature|deferred feature]]''. + +==Encapsulation== +:See ''[[#Information hiding|information hiding]]''. + +==Entity== +:A name in the software text that denotes a run-time value (''[[#Object|object]]'' or ''[[#Reference|reference]]''). + +==Event-driven computation== +:A style of software construction where developers define the control structure by listing possible external events and the system's response to each of them, rather than by specifying a pre-ordained sequence of steps. + +==Exception== +:The inability of a routine to achieve its ''[[#Contract|contract]]'' through one of its possible strategies. May result in particular from a ''[[#Failure|failure]]'' of a routine called by the original routine. Will be treated as ''[[#Resumption|resumption]]'', ''[[#Organized panic|organized panic]]'' or ''[[#False alarm|false alarm]]''. + +==Exporting a feature== +:Making the feature available to ''[[#Client|clients]]''. Exports may be selective (to specified classes only) or general. + +==Extendibility== +:The ability of a software system to be changed easily in response to different choices of requirements, architecture, algorithms or data structures. + +==Failure== +:The inability of a routine's execution to fulfill the routine's ''[[#Contract|contract]]''. Must trigger an ''[[#Exception|exception]]''. + +==False alarm== +:Along with ''[[#Resumption|resumption]]'' and ''[[#Organized panic|organized panic]]'', one of the three possible responses to an ''[[#Exception|exception]]''; resumes the execution of the current strategy, possibly after taking some corrective action. + +==Feature== +:The ''[[#Attribute|attributes]]'' and ''[[#Routine|routines]]'' of a class. + +==Feature renaming== +:The attribution, by a class, of a new name to an inherited feature, not changing any other property. See also ''[[#Redeclaration|redeclaration]]''. + +==Field== +:One of the values making up an ''[[#Object|object]]''. + +==Function== +:A ''[[#Routine|routine]]'' which returns a result. (The other form of routine is the ''[[#Procedure|procedure]]''.) + +==Garbage collection== +:A facility provided by the ''[[#Runtime (noun, one word)|runtime]]'' to recycle the memory space used by ''[[#Object|objects]]'' that have become useless. Garbage collection is automatic, that is to say does not require any change to the text of the ''[[#System|systems]]'' whose objects are being recycled. + +==Generalization== +:The process of turning specialized program elements into general-purpose, ''[[#Reusable software component|reusable software components]]''. + +==Generating class== +:Same as ''[[#Generator (of an object)|generator]]''. + +==Generator (of an object)== +:The class of which the ''[[#Object|object]]'' is a ''[[#Direct instance (of a class)|direct instance]]''. + +==Generic class== +:A class having formal parameters representing types. Such a class will yield a type only through ''[[#Generic derivation|generic derivation]]''. + +==Generic derivation== +:The process of providing a type for each formal generic parameter of a ''[[#Generic class|generic class]]'', yielding a type as a result. + +==Genericity== +:The support, by a software notation, for type-parameterized ''[[#Module|modules]]'; specifically, in an O-O notation, for ''[[#Generic class|generic classes]]''. Can be ''[[#Unconstrained genericity|unconstrained]]'' or ''[[#Constrained genericity|constrained]]''. + +==Heir (of a class)== +:A class that inherits from the given class. Antonym: ''[[#Parent (of a class)|parent]]''. + +==Identity== +:See ''[[#Object identity|object identity]]''. + +==Information hiding== +:The ability to prevent certain aspects of a class from being accessible to its ''[[#Client|clients]]'', through an explicit ''[[#Exporting a feature|exporting]]'' policy and through reliance on the ''[[#Short form (of a class)|short form]]'' as the primary vehicle for class documentation. + +==Inheritance== +:A mechanism whereby a class is defined in reference to others, adding all their features to its own. + +==Instance (of a class)== +:An ''[[#Object|object]]'' built according to the mold defined by the class or any one of its proper ''[[#Descendant (of a class)|descendants]]''. See also ''[[#Direct instance (of a class)|direct instance]]'', ''[[#Proper descendant (of a class)|proper descendant]]'', ''[[#Generator (of an object)|generator]]''. + +==Instance variable== +:Smalltalk term for ''[[#Attribute|attribute]]''. + +==Interface (of a class)== +:See ''[[#Contract|contract]]'', ''[[#Abstract data type (ADT)|abstract data type]]''. + +==Invariant== +:See ''[[#Class invariant|class invariant]]'', ''[[#Loop invariant|loop invariant]]''. + +==Iterator== +:A control structure describing preordained sequencing of some actions but not defining the actions themselves. Iterators often apply to data structures, such as an iterator describing the traversal of a list or a tree. + +==Loop invariant== +:An ''[[#Assertion|assertion]]'' which must be satisfied prior to the first execution of a loop, and preserved by every iteration, so that it will hold on loop termination. + +==Loop variant== +:An integer expression which must be non-negative prior to the first execution of a loop, and decreased by every iteration, so that it will garantee loop termination. + +==Message== +:Routine call. + +==Metaclass== +:A class whose instances are classes themselves. + +==Method== +:Smalltalk term for ''[[#Routine|routine]]''. + +==Module== +:A unit of software decomposition. In the ''[[#Object-oriented|object-oriented]]'' approach, classes provide the basic form of module. + +==Multiple inheritance== +:The unrestricted form of ''[[#Inheritance|inheritance]]'', whereby a class may have any number of [[#Parent (of a class)|parents]]. Antonym: ''[[#Single inheritance|single inheritance]]''. + +==Non-separate== +:Antonym of ''[[#Separate|separate]]''. + +==Novariance== +:The policy prohibiting any feature ''[[#Redeclaration|redeclaration]]'' from changing the ''[[#Signature (of a feature)|signature]]''. See also: ''[[#Contravariance|contravariance]]'', ''[[#Covariance|covariance]]''. + +==Object== +:A run-time data structure made of zero or more values, called ''[[#Field|fields]]'', and serving as the computer representation of an ''[[#Abstract object|abstract object]]''. Every object is an ''[[#Instance (of a class)|instance]]'' of some class. + +==Object identity== +:A property that uniquely identifies an ''[[#Object|object]]'' independently of its current contents (''[[#Field|fields]]''). + +==Object-oriented== +:Built from ''[[#Class|classes]]'', ''[[#Assertion|assertions]]'', ''[[#Genericity|genericity]]'', ''[[#Inheritance|inheritance]]'', ''[[#Polymorphism|polymorphism]]'' and ''[[#Dynamic binding|dynamic binding]]''. + +==Object-oriented analysis== +:The application of ''[[#Object-oriented|object-oriented]]'' concepts to the modeling of problems and systems from both software and non-software domains. + +==Object-oriented database== +:A repository of ''[[#Persistent object|persistent objects]]'', permitting their storage and retrieval on the basis of ''[[#Object-oriented|object-oriented]]'' concepts, and supporting database properties such as ''[[#Concurrent|concurrent]]'' access, locking and transactions. + +==Object-oriented design== +:The process of building the architecture of ''[[#System|systems]]'' through ''[[#Object-oriented|object-oriented]]'' concepts. + +==Object-oriented implementation== +:The process of building executable software systems through ''[[#Object-oriented|object-oriented]]'' concepts. Differs from ''[[#Object-oriented design|object-oriented design]]'' primarily by the level of abstraction. + +==Organized panic== +:Along with ''[[#Resumption|resumption]]'' and ''[[#False alarm|false alarm]]'', one of the three possible responses to an ''[[#Exception|exception]]''; abandons the execution of the current strategy, triggering an exception in the caller, after restoring the ''[[#Class invariant|class invariant]]'' for the ''[[#Current object (or: current instance)|current object]]''. + +==Overloading== +:The ability to let a feature name denote two or more operations. + +==Package== +:A ''[[#Module|module]]'' of non-object-oriented languages such as Ada, providing encapsulation of a set of variables and ''[[#Routine|routines]]''. + +==Parallel== +:See ''[[#Concurrent|concurrent]]''. + +==Parameterized class== +:See ''[[#Generic class|generic class]]''. + +==Parent (of a class)== +:A class from which the given class inherits. Antonym: ''[[#Heir (of a class)|heir]]''. + +==Persistence== +:The ability of a software development environment or language to make objects ''[[#Persistent object|persistent]]'' and support the retrieval of ''[[#Persistent object|persistent objects]]'' for use by systems. + +==Persistent object== +:An object that (through storage in a file or database or transmission across a network) survives executions of systems that create or manipulate it. Antonym: ''[[#Transient object|transient object]]''. + +==Polymorphic data structure== +:A ''[[#Container data structure|container data structure]]'' hosting ''[[#Object|objects]]'' of two or more possible types. + +==Polymorphism== +:The ability for an element of the software text to denote, at run time, ''[[#Object|objects]]'' of two or more possible types. + +==Postcondition== +:An ''[[#Assertion|assertion]]'' attached to a ''[[#Routine|routine]]'', which must be guaranteed by the routine's body on return from any call to the routine if the ''[[#Precondition|precondition]]'' was satisfied on entry. Part of the ''[[#Contract|contract]]'' governing the routine. + +==Precondition== +:An ''[[#Assertion|assertion]]'' attached to a ''[[#Routine|routine]]'', which must be guaranteed by every ''[[#Client|client]]'' prior to any call to the routine. Part of the ''[[#Contract|contract]]'' governing the routine. + +==Predicate== +:See ''[[#Assertion|assertion]]''. + +==Procedure== +:A ''[[#Routine|routine]]'' which does not return a result. (The other form of routine is the ''[[#Function|function]]''.) + +==Processor== +:A mechanism providing a single thread of computation. May be a physical device, such as the CPU of a computer, or a software device, such as a task or thread of an operating system. + +==Program== +:See ''[[#System|system]]''. + +==Proper ancestor (of a class)== +:A direct or indirect ''[[#Parent (of a class)|parent]]'' of the class. + +==Proper descendant (of a class)== +:A direct or indirect ''[[#Heir (of a class)|heir]]'' of the class. + +==Redeclaration== +:A feature declaration which, instead of introducing a new feature, adapts some properties (such as the ''[[#Signature (of a feature)|signature]]'', ''[[#Precondition|precondition]]'', ''[[#Postcondition|postcondition]]'', implementation, ''[[#Deferred feature|deferred]]''/''[[#Effective feature|effective]]'' status, but not the name) of a feature inherited from a ''[[#Parent (of a class)|parent]]''. A redeclaration may be a ''[[#Redefinition|redefinition]]'' or an ''[[#Effecting|effecting]]''. See also ''[[#Feature renaming|feature renaming]]''. + +==Redefinition== +:A ''[[#Redeclaration|redeclaration]]'' which is not an ''[[#Effecting|effecting]]'', that is to say, changes some properties of a feature inherited as ''[[#Effective feature|effective]]'', or changes the specification of a feature inherited as ''[[#Deferred feature|deferred]]'' while leaving it deferred. + +==Reference== +:A run-time value that uniquely identifies an ''[[#Object|object]]''. + +==Renaming== +:See ''[[#Feature renaming|feature renaming]]''. + +==Representation== +:The physical layout of data in RAM (or other storage), and the choices of what data is stored and what data is computed at run time, in order to represent the ''[[#Abstract data type (ADT)|abstract data type]]'' in question. + +==Representation Independence== +:The ability of a class to present an unchanging interface to its ''[[#Client|clients]]'', and implement alternate ''[[#Representation|representations]]'' of the underlying object without the clients needing to know or care about it. In the ''[[#Object-oriented|object-oriented]]'' method, ''[[#Dynamic binding|dynamic binding]]'' and ''[[#Polymorphism|polymorphism]]'' are major contributors to making this possible. + +==Resumption== +:See ''[[#Retrying|retrying]]''. + +==Retrying== +:Along with ''[[#Organized panic|organized panic]]'' and ''[[#False alarm|false alarm]]'', one of the three possible responses to an ''[[#Exception|exception]]''; tries a new strategy for achieving the routine's ''[[#Contract|contract]]''. + +==Reusability== +:The ability of a software development method to yield software elements that can be used in many different applications, and to support a software development process relying on pre-existing ''[[#Reusable software component|reusable software components]]''. + +==Reusable software component== +:An element of software that can be used by many different applications. + +==Reversible development== +:A software development process that lets insights gained in later phases affect the results obtained in earlier phases. Normally part of a ''[[#Seamless development|seamless development]]'' process. + +==Root class== +:The ''[[#Generator (of an object)|generator]]'' of a system's ''[[#Root object|root object]]''. Executing the system means creating an ''[[#Instance (of a class)|instance]]'' of the root class (the root object), and calling a creation procedure on that instance. + +==Root object== +:The first ''[[#Object|object]]'' created in the execution of a system. + +==Routine== +:A computation defined in a class, and applicable to the ''[[#Instance (of a class)|instances]]'' of that class. Along with the ''[[#Attribute|attribute]]'', one of the two forms of ''[[#Feature|feature]]''. + +==Runtime (noun, one word)== +:Any set of facilities supporting the execution of systems. See ''[[#Run time (noun, two words)|run time]]''. + +==Run time (noun, two words)== +:The time when a ''[[#System|system]]'' is being executed. Also used as an adjective, with a hyphen, as in "the run-time value of an ''[[#Entity|entity]]''". See also ''[[#Dynamic|dynamic]]'' and ''[[#Runtime (noun, one word)|runtime]]''. + +==Schema evolution== +:Change to one or more classes of which some ''[[#Persistent object|persistent]]'' instances exist. + +==Seamless development== +:A software development process which uses a uniform method and notation throughout all activities, such as problem modeling and analysis, design, implementation and maintenance. See also ''[[#Reversible development|reversible development]]''. + +==Selective export== +:See ''[[#Exporting a feature|exporting a feature]]''. + +==Separate== +:Handled by a different ''[[#Processor|processor]]''. Antonym: non-separate. + +==Sequential== +:Running on only one ''[[#Processor|processor]]''. Antonym: ''[[#Concurrent|concurrent]]''. + +==Short form (of a class)== +:A form of class documentation generated from the class text, showing only interface properties of the class. The short form documents the ''[[#Contract|contract]]'' attached to the class and the underlying ''[[#Abstract data type (ADT)|abstract data type]]''. + +==Signature (of a feature)== +:The type part of the feature's specification. For an ''[[#Attribute|attribute]]'' or a ''[[#Function|function]]'', includes the result type; for a ''[[#Routine|routine]]'', includes the number of arguments and the type of each. + +==Single inheritance== +:A restricted form of ''[[#Inheritance|inheritance]]'' whereby each class may have at most one ''[[#Parent (of a class)|parent]]''. Antonym: ''[[#Multiple inheritance|multiple inheritance]]''. + +==Software component== +:See ''[[#Reusable software component|reusable software component]]''. + +==Specification (of a class)== +:The ''[[#Short form (of a class)|short form]]'' of the class. + +==Specification (of a feature)== +:The properties of a feature that are relevant to a ''[[#Client|client]]''. Includes the name, ''[[#Signature (of a feature)|signature]]'', header comment and ''[[#Contract|contract]]'' of the feature. + +==Subcontract== +:The ability of a class to let some proper ''[[#Descendant (of a class)|descendant]]'' handle some of its feature calls, thanks to ''[[#Redeclaration|redeclaration]]'' and ''[[#Dynamic binding|dynamic binding]]''. + +==Supplier== +:A class that provides another, its ''[[#Client|client]]'', with features to be used through an interface specification (''[[#Contract|contract]]''). + +==Static== +:Applying to the text of a ''[[#System|system]]'', not to a particular execution. Antonym: ''[[#Dynamic|dynamic]]''. + +==Static binding== +:The premature choice of operation variant, resulting in possibly wrong results and (in favorable cases) run-time system crash. + +==Static typing== +:The ability to check, on the basis of the software text alone, that no execution of a system will ever try to apply to an ''[[#Object|object]]'' an operation that is not applicable to that object. + +==Synchronous call== +:A call which forces the caller to wait until it completes. Antonym: ''[[#Asynchronous call|asynchronous call]]''. + +==System== +:A set of classes that can be assembled to produce an executable result. + +==Template== +:C++ term for ''[[#Generic class|generic class]]'' (for ''[[#Unconstrained genericity|unconstrained genericity]]'' only). + +==Traitor== +:A ''[[#Reference|reference]]'' to a ''[[#Separate|separate]]'' ''[[#Object|object]]'', associated in the software text with an ''[[#Entity|entity]]'' that is declared as non-separate. + +==Transient object== +:An ''[[#Object|object]]'' that exists only during the execution of the system that creates it. Antonym: ''[[#Persistent object|persistent object]]''. + +==Type== +:The description of a set of objects equipped with certain operations. In the ''[[#Object-oriented|object-oriented]]'' approach every type is based on a class. + +==Type checking, typing== +:See ''[[#Static typing|static typing]]'', ''[[#Dynamic typing|dynamic typing]]''. + +==Unconstrained genericity== +:A form of ''[[#Genericity|genericity]]'' where a formal generic parameter represents an arbitrary type. See ''[[#Constrained genericity|constrained genericity]]''. + +==Variant== +:See ''[[#Loop variant|loop variant]]''. + + + diff --git a/documentation/18.11/index.wiki b/documentation/18.11/index.wiki new file mode 100644 index 00000000..7b2a8def --- /dev/null +++ b/documentation/18.11/index.wiki @@ -0,0 +1,27 @@ +[[Property:modification_date|Mon, 24 Sep 2018 13:20:40 GMT]] +[[Property:publication_date|Thu, 06 Sep 2018 15:10:13 GMT]] +[[Property:title|Documentation]] +[[Property:description|Central repository of information about Eiffel and the products and technologies of Eiffel Software]] +[[Property:weight|10]] +[[Property:uuid|E79DA6D4-70AD-4542-8E9B-EEFC813EC748]] + +This is the Eiffel documentation site, with a wealth of resources on how to unleash the power of Eiffel. It is organized as a set of '''books''': + +* [[Eiffel]]: the language and method. The Eiffel book includes: +** [[Eiffel Overview|Eiffel overview]]: to get a general idea of Eiffel, or refresh it if you haven't followed recent evolution. +** [[Eiffel Tutorials|Eiffel tutorials]]: step-by-step presentation of Eiffel concepts and constructs, including: +** [[Language reference|Language reference]]: Precise construct-by-construct descriptions. +** [[Technical papers about Eiffel|Eiffel technical papers]]: tutorial presentations of specific Eiffel highlights, such as void safety and SCOOP (the concurrency mechanism). +* [[EiffelStudio]]: the multi-platform development environment. The EiffelStudio book includes: +** [[Introducing EiffelStudio]]. +** [[Setup and installation]]. +** [[EiffelStudio tutorials]] +** [[Technical papers about EiffelStudio|Technical papers]] on specific concepts and tools +* [[Solutions]]. EiffelStudio comes with numerous libraries, packages, and tools. The Solutions book includes: +** Libraries: data structures, graphics, networking... +** Packages +** Tools +* [[Glossary]]: clear definitions of the concepts underlying Eiffel: feature, routine, attribute, contract... +* [[FAQ]]: everything you always wanted to ask about Eiffel. + +A number of sites outside of eiffel.org contain useful Eiffel resources. You can find a partial list [/contribute here]. diff --git a/documentation/18.11/solutions/_files/eth-46802-01.pdf b/documentation/18.11/solutions/_files/eth-46802-01.pdf new file mode 100644 index 00000000..6de5f6d5 Binary files /dev/null and b/documentation/18.11/solutions/_files/eth-46802-01.pdf differ diff --git a/documentation/18.11/solutions/_images/EiffelRibbon_Choosing_a_size_definition.png b/documentation/18.11/solutions/_images/EiffelRibbon_Choosing_a_size_definition.png new file mode 100644 index 00000000..5da14ca1 Binary files /dev/null and b/documentation/18.11/solutions/_images/EiffelRibbon_Choosing_a_size_definition.png differ diff --git a/documentation/18.11/solutions/_images/EiffelRibbon_Choosing_a_size_definition.png.data b/documentation/18.11/solutions/_images/EiffelRibbon_Choosing_a_size_definition.png.data new file mode 100644 index 00000000..f646fbe9 --- /dev/null +++ b/documentation/18.11/solutions/_images/EiffelRibbon_Choosing_a_size_definition.png.data @@ -0,0 +1,3 @@ +title=EiffelRibbon Choose Size Definition +author=halw +path=content/eiffelribbon-choose-size-definition diff --git a/documentation/18.11/solutions/_images/EiffelRibbon_application_01.png b/documentation/18.11/solutions/_images/EiffelRibbon_application_01.png new file mode 100644 index 00000000..e508ccfb Binary files /dev/null and b/documentation/18.11/solutions/_images/EiffelRibbon_application_01.png differ diff --git a/documentation/18.11/solutions/_images/EiffelRibbon_application_01.png.data b/documentation/18.11/solutions/_images/EiffelRibbon_application_01.png.data new file mode 100644 index 00000000..145d3688 --- /dev/null +++ b/documentation/18.11/solutions/_images/EiffelRibbon_application_01.png.data @@ -0,0 +1,3 @@ +title=EiffelRibbon application 01 +author=halw +path=content/eiffelribbon-application-01 diff --git a/documentation/18.11/solutions/_images/EiffelRibbon_design_tool_01.png b/documentation/18.11/solutions/_images/EiffelRibbon_design_tool_01.png new file mode 100644 index 00000000..1074ddcd Binary files /dev/null and b/documentation/18.11/solutions/_images/EiffelRibbon_design_tool_01.png differ diff --git a/documentation/18.11/solutions/_images/EiffelRibbon_design_tool_01.png.data b/documentation/18.11/solutions/_images/EiffelRibbon_design_tool_01.png.data new file mode 100644 index 00000000..e1d437cf --- /dev/null +++ b/documentation/18.11/solutions/_images/EiffelRibbon_design_tool_01.png.data @@ -0,0 +1,3 @@ +title=EiffelRibbon design tool 01 +author=halw +path=content/eiffelribbon-design-tool-01 diff --git a/documentation/18.11/solutions/_images/EiffelRibbon_design_tool_02_0.png b/documentation/18.11/solutions/_images/EiffelRibbon_design_tool_02_0.png new file mode 100644 index 00000000..a33aab57 Binary files /dev/null and b/documentation/18.11/solutions/_images/EiffelRibbon_design_tool_02_0.png differ diff --git a/documentation/18.11/solutions/_images/EiffelRibbon_design_tool_02_0.png.data b/documentation/18.11/solutions/_images/EiffelRibbon_design_tool_02_0.png.data new file mode 100644 index 00000000..8f06e3f9 --- /dev/null +++ b/documentation/18.11/solutions/_images/EiffelRibbon_design_tool_02_0.png.data @@ -0,0 +1,3 @@ +title=EiffelRibbon design tool 02 +author=halw +path=content/eiffelribbon-design-tool-02 diff --git a/documentation/18.11/solutions/_images/EiffelRibbon_scaling_policy_01.png b/documentation/18.11/solutions/_images/EiffelRibbon_scaling_policy_01.png new file mode 100644 index 00000000..7ac821d3 Binary files /dev/null and b/documentation/18.11/solutions/_images/EiffelRibbon_scaling_policy_01.png differ diff --git a/documentation/18.11/solutions/_images/EiffelRibbon_scaling_policy_01.png.data b/documentation/18.11/solutions/_images/EiffelRibbon_scaling_policy_01.png.data new file mode 100644 index 00000000..ccc3c9ff --- /dev/null +++ b/documentation/18.11/solutions/_images/EiffelRibbon_scaling_policy_01.png.data @@ -0,0 +1,3 @@ +title=EiffelRibbon scaling policy 01 +author=halw +path=content/eiffelribbon-scaling-policy-01 diff --git a/documentation/18.11/solutions/_images/EiffelRibbon_scaling_policy_01a.png b/documentation/18.11/solutions/_images/EiffelRibbon_scaling_policy_01a.png new file mode 100644 index 00000000..532bb76b Binary files /dev/null and b/documentation/18.11/solutions/_images/EiffelRibbon_scaling_policy_01a.png differ diff --git a/documentation/18.11/solutions/_images/EiffelRibbon_scaling_policy_01a.png.data b/documentation/18.11/solutions/_images/EiffelRibbon_scaling_policy_01a.png.data new file mode 100644 index 00000000..8fc24cd9 --- /dev/null +++ b/documentation/18.11/solutions/_images/EiffelRibbon_scaling_policy_01a.png.data @@ -0,0 +1,3 @@ +title=EiffelRibbon scaling policy 01a +author=halw +path=content/eiffelribbon-scaling-policy-01a diff --git a/documentation/18.11/solutions/_images/EiffelRibbon_scaling_policy_02.png b/documentation/18.11/solutions/_images/EiffelRibbon_scaling_policy_02.png new file mode 100644 index 00000000..3571ce41 Binary files /dev/null and b/documentation/18.11/solutions/_images/EiffelRibbon_scaling_policy_02.png differ diff --git a/documentation/18.11/solutions/_images/EiffelRibbon_scaling_policy_02.png.data b/documentation/18.11/solutions/_images/EiffelRibbon_scaling_policy_02.png.data new file mode 100644 index 00000000..ca2dcb96 --- /dev/null +++ b/documentation/18.11/solutions/_images/EiffelRibbon_scaling_policy_02.png.data @@ -0,0 +1,3 @@ +title=EiffelRibbon scaling policy 02 +author=halw +path=content/eiffelribbon-scaling-policy-02 diff --git a/documentation/18.11/solutions/_images/EiffelRibbon_scaling_policy_03.png b/documentation/18.11/solutions/_images/EiffelRibbon_scaling_policy_03.png new file mode 100644 index 00000000..895409f2 Binary files /dev/null and b/documentation/18.11/solutions/_images/EiffelRibbon_scaling_policy_03.png differ diff --git a/documentation/18.11/solutions/_images/EiffelRibbon_scaling_policy_03.png.data b/documentation/18.11/solutions/_images/EiffelRibbon_scaling_policy_03.png.data new file mode 100644 index 00000000..83b7abc1 --- /dev/null +++ b/documentation/18.11/solutions/_images/EiffelRibbon_scaling_policy_03.png.data @@ -0,0 +1,3 @@ +title=EiffelRibbon scaling policy 03 +author=halw +path=content/eiffelribbon-scaling-policy-03 diff --git a/documentation/18.11/solutions/_images/EiffelRibbon_scaling_policy_04.png b/documentation/18.11/solutions/_images/EiffelRibbon_scaling_policy_04.png new file mode 100644 index 00000000..2a4947db Binary files /dev/null and b/documentation/18.11/solutions/_images/EiffelRibbon_scaling_policy_04.png differ diff --git a/documentation/18.11/solutions/_images/EiffelRibbon_scaling_policy_04.png.data b/documentation/18.11/solutions/_images/EiffelRibbon_scaling_policy_04.png.data new file mode 100644 index 00000000..5c5ca859 --- /dev/null +++ b/documentation/18.11/solutions/_images/EiffelRibbon_scaling_policy_04.png.data @@ -0,0 +1,3 @@ +title=EiffelRibbon scaling policy 04 +author=halw +path=content/eiffelribbon-scaling-policy-04 diff --git a/documentation/18.11/solutions/_images/EiffelRibbon_scaling_policy_05.png b/documentation/18.11/solutions/_images/EiffelRibbon_scaling_policy_05.png new file mode 100644 index 00000000..9e429f57 Binary files /dev/null and b/documentation/18.11/solutions/_images/EiffelRibbon_scaling_policy_05.png differ diff --git a/documentation/18.11/solutions/_images/EiffelRibbon_scaling_policy_05.png.data b/documentation/18.11/solutions/_images/EiffelRibbon_scaling_policy_05.png.data new file mode 100644 index 00000000..8f6f6a95 --- /dev/null +++ b/documentation/18.11/solutions/_images/EiffelRibbon_scaling_policy_05.png.data @@ -0,0 +1,3 @@ +title=EiffelRibbon scaling policy 05 +author=halw +path=content/eiffelribbon-scaling-policy-05 diff --git a/documentation/18.11/solutions/_images/EiffelRibbon_size_definition_editor_01.png b/documentation/18.11/solutions/_images/EiffelRibbon_size_definition_editor_01.png new file mode 100644 index 00000000..a8bfab7f Binary files /dev/null and b/documentation/18.11/solutions/_images/EiffelRibbon_size_definition_editor_01.png differ diff --git a/documentation/18.11/solutions/_images/EiffelRibbon_size_definition_editor_01.png.data b/documentation/18.11/solutions/_images/EiffelRibbon_size_definition_editor_01.png.data new file mode 100644 index 00000000..c4378498 --- /dev/null +++ b/documentation/18.11/solutions/_images/EiffelRibbon_size_definition_editor_01.png.data @@ -0,0 +1,3 @@ +title=EiffelRibbon size definition editor +author=halw +path=content/eiffelribbon-size-definition-editor diff --git a/documentation/18.11/solutions/_images/EiffelRibbon_size_definition_editor_02.png b/documentation/18.11/solutions/_images/EiffelRibbon_size_definition_editor_02.png new file mode 100644 index 00000000..9986104f Binary files /dev/null and b/documentation/18.11/solutions/_images/EiffelRibbon_size_definition_editor_02.png differ diff --git a/documentation/18.11/solutions/_images/EiffelRibbon_size_definition_editor_02.png.data b/documentation/18.11/solutions/_images/EiffelRibbon_size_definition_editor_02.png.data new file mode 100644 index 00000000..283d4d3a --- /dev/null +++ b/documentation/18.11/solutions/_images/EiffelRibbon_size_definition_editor_02.png.data @@ -0,0 +1,3 @@ +title=Size Definition Editor 02 +author=halw +path=content/size-definition-editor-02 diff --git a/documentation/18.11/solutions/_images/EiffelRibbon_size_definition_editor_03.png b/documentation/18.11/solutions/_images/EiffelRibbon_size_definition_editor_03.png new file mode 100644 index 00000000..0f5157d9 Binary files /dev/null and b/documentation/18.11/solutions/_images/EiffelRibbon_size_definition_editor_03.png differ diff --git a/documentation/18.11/solutions/_images/EiffelRibbon_size_definition_editor_03.png.data b/documentation/18.11/solutions/_images/EiffelRibbon_size_definition_editor_03.png.data new file mode 100644 index 00000000..03327f28 --- /dev/null +++ b/documentation/18.11/solutions/_images/EiffelRibbon_size_definition_editor_03.png.data @@ -0,0 +1,3 @@ +title=Size Definition Editor 03 +author=halw +path=content/size-definition-editor-03 diff --git a/documentation/18.11/solutions/_images/EiffelRibbon_window_01.png b/documentation/18.11/solutions/_images/EiffelRibbon_window_01.png new file mode 100644 index 00000000..09e4d7ea Binary files /dev/null and b/documentation/18.11/solutions/_images/EiffelRibbon_window_01.png differ diff --git a/documentation/18.11/solutions/_images/EiffelRibbon_window_01.png.data b/documentation/18.11/solutions/_images/EiffelRibbon_window_01.png.data new file mode 100644 index 00000000..882a3639 --- /dev/null +++ b/documentation/18.11/solutions/_images/EiffelRibbon_window_01.png.data @@ -0,0 +1,3 @@ +title=EiffelRibbon window 01 +author=halw +path=content/eiffelribbon-window-01 diff --git a/documentation/18.11/solutions/_images/EiffelStudio_after_class_pick_and_drop2.png b/documentation/18.11/solutions/_images/EiffelStudio_after_class_pick_and_drop2.png new file mode 100644 index 00000000..3c7fda81 Binary files /dev/null and b/documentation/18.11/solutions/_images/EiffelStudio_after_class_pick_and_drop2.png differ diff --git a/documentation/18.11/solutions/_images/EiffelStudio_after_class_pick_and_drop2.png.data b/documentation/18.11/solutions/_images/EiffelStudio_after_class_pick_and_drop2.png.data new file mode 100644 index 00000000..ce31560f --- /dev/null +++ b/documentation/18.11/solutions/_images/EiffelStudio_after_class_pick_and_drop2.png.data @@ -0,0 +1,3 @@ +title=EiffelStudio after class pick and drop2 +author=vwheeler +path=content/eiffelstudio-after-class-pick-and-drop2 diff --git a/documentation/18.11/solutions/_images/EiffelStudio_during_class_pick_and_drop2.png b/documentation/18.11/solutions/_images/EiffelStudio_during_class_pick_and_drop2.png new file mode 100644 index 00000000..84121c9a Binary files /dev/null and b/documentation/18.11/solutions/_images/EiffelStudio_during_class_pick_and_drop2.png differ diff --git a/documentation/18.11/solutions/_images/EiffelStudio_during_class_pick_and_drop2.png.data b/documentation/18.11/solutions/_images/EiffelStudio_during_class_pick_and_drop2.png.data new file mode 100644 index 00000000..1049a16b --- /dev/null +++ b/documentation/18.11/solutions/_images/EiffelStudio_during_class_pick_and_drop2.png.data @@ -0,0 +1,3 @@ +title=EiffelStudio during class pick and drop2 +author=vwheeler +path=content/eiffelstudio-during-class-pick-and-drop2 diff --git a/documentation/18.11/solutions/_images/SCOOP_project_setting.png b/documentation/18.11/solutions/_images/SCOOP_project_setting.png new file mode 100644 index 00000000..ed910508 Binary files /dev/null and b/documentation/18.11/solutions/_images/SCOOP_project_setting.png differ diff --git a/documentation/18.11/solutions/_images/SCOOP_project_setting.png.data b/documentation/18.11/solutions/_images/SCOOP_project_setting.png.data new file mode 100644 index 00000000..67134d8c --- /dev/null +++ b/documentation/18.11/solutions/_images/SCOOP_project_setting.png.data @@ -0,0 +1,3 @@ +title=SCOOP project setting +author=halw +path=content/scoop-project-setting diff --git a/documentation/18.11/solutions/_images/WEL_cursors_example_01.png b/documentation/18.11/solutions/_images/WEL_cursors_example_01.png new file mode 100644 index 00000000..78132a01 Binary files /dev/null and b/documentation/18.11/solutions/_images/WEL_cursors_example_01.png differ diff --git a/documentation/18.11/solutions/_images/WEL_cursors_example_01.png.data b/documentation/18.11/solutions/_images/WEL_cursors_example_01.png.data new file mode 100644 index 00000000..6b5d6b8d --- /dev/null +++ b/documentation/18.11/solutions/_images/WEL_cursors_example_01.png.data @@ -0,0 +1,3 @@ +title=cursors +author=halw +path=content/cursors diff --git a/documentation/18.11/solutions/_images/accelerator.png b/documentation/18.11/solutions/_images/accelerator.png new file mode 100644 index 00000000..357ed96f Binary files /dev/null and b/documentation/18.11/solutions/_images/accelerator.png differ diff --git a/documentation/18.11/solutions/_images/accelerator.png.data b/documentation/18.11/solutions/_images/accelerator.png.data new file mode 100644 index 00000000..a67971d5 --- /dev/null +++ b/documentation/18.11/solutions/_images/accelerator.png.data @@ -0,0 +1,3 @@ +title=accelerator +author=admin +path=content/accelerator diff --git a/documentation/18.11/solutions/_images/analyz.png b/documentation/18.11/solutions/_images/analyz.png new file mode 100644 index 00000000..a995b8b1 Binary files /dev/null and b/documentation/18.11/solutions/_images/analyz.png differ diff --git a/documentation/18.11/solutions/_images/analyz.png.data b/documentation/18.11/solutions/_images/analyz.png.data new file mode 100644 index 00000000..d1e8e91e --- /dev/null +++ b/documentation/18.11/solutions/_images/analyz.png.data @@ -0,0 +1,3 @@ +title=analyz +author=admin +path=content/analyz diff --git a/documentation/18.11/solutions/_images/bilinear.png b/documentation/18.11/solutions/_images/bilinear.png new file mode 100644 index 00000000..10f14708 Binary files /dev/null and b/documentation/18.11/solutions/_images/bilinear.png differ diff --git a/documentation/18.11/solutions/_images/bilinear.png.data b/documentation/18.11/solutions/_images/bilinear.png.data new file mode 100644 index 00000000..c50aa0a1 --- /dev/null +++ b/documentation/18.11/solutions/_images/bilinear.png.data @@ -0,0 +1,3 @@ +title=bilinear +author=admin +path=content/bilinear diff --git a/documentation/18.11/solutions/_images/binary-tree.png b/documentation/18.11/solutions/_images/binary-tree.png new file mode 100644 index 00000000..34050b5f Binary files /dev/null and b/documentation/18.11/solutions/_images/binary-tree.png differ diff --git a/documentation/18.11/solutions/_images/binary-tree.png.data b/documentation/18.11/solutions/_images/binary-tree.png.data new file mode 100644 index 00000000..9b27d17e --- /dev/null +++ b/documentation/18.11/solutions/_images/binary-tree.png.data @@ -0,0 +1,3 @@ +title=binary-tree +author=admin +path=content/binary-tree diff --git a/documentation/18.11/solutions/_images/bmpview.png b/documentation/18.11/solutions/_images/bmpview.png new file mode 100644 index 00000000..04f5d01f Binary files /dev/null and b/documentation/18.11/solutions/_images/bmpview.png differ diff --git a/documentation/18.11/solutions/_images/bmpview.png.data b/documentation/18.11/solutions/_images/bmpview.png.data new file mode 100644 index 00000000..e03e1961 --- /dev/null +++ b/documentation/18.11/solutions/_images/bmpview.png.data @@ -0,0 +1,3 @@ +title=bmpview +author=admin +path=content/bmpview diff --git a/documentation/18.11/solutions/_images/browse.png b/documentation/18.11/solutions/_images/browse.png new file mode 100644 index 00000000..f0405763 Binary files /dev/null and b/documentation/18.11/solutions/_images/browse.png differ diff --git a/documentation/18.11/solutions/_images/browse.png.data b/documentation/18.11/solutions/_images/browse.png.data new file mode 100644 index 00000000..add2e3c0 --- /dev/null +++ b/documentation/18.11/solutions/_images/browse.png.data @@ -0,0 +1,3 @@ +title=browse +author=admin +path=content/browse diff --git a/documentation/18.11/solutions/_images/brushes.png b/documentation/18.11/solutions/_images/brushes.png new file mode 100644 index 00000000..1702d7c5 Binary files /dev/null and b/documentation/18.11/solutions/_images/brushes.png differ diff --git a/documentation/18.11/solutions/_images/brushes.png.data b/documentation/18.11/solutions/_images/brushes.png.data new file mode 100644 index 00000000..65744589 --- /dev/null +++ b/documentation/18.11/solutions/_images/brushes.png.data @@ -0,0 +1,3 @@ +title=brushes +author=admin +path=content/brushes diff --git a/documentation/18.11/solutions/_images/builder-window.png b/documentation/18.11/solutions/_images/builder-window.png new file mode 100644 index 00000000..d1f53c12 Binary files /dev/null and b/documentation/18.11/solutions/_images/builder-window.png differ diff --git a/documentation/18.11/solutions/_images/builder-window.png.data b/documentation/18.11/solutions/_images/builder-window.png.data new file mode 100644 index 00000000..ef6e9f37 --- /dev/null +++ b/documentation/18.11/solutions/_images/builder-window.png.data @@ -0,0 +1,3 @@ +title=builder-window +author=admin +path=content/builder-window diff --git a/documentation/18.11/solutions/_images/calculator.png b/documentation/18.11/solutions/_images/calculator.png new file mode 100644 index 00000000..92d3e4a1 Binary files /dev/null and b/documentation/18.11/solutions/_images/calculator.png differ diff --git a/documentation/18.11/solutions/_images/calculator.png.data b/documentation/18.11/solutions/_images/calculator.png.data new file mode 100644 index 00000000..443e5e55 --- /dev/null +++ b/documentation/18.11/solutions/_images/calculator.png.data @@ -0,0 +1,3 @@ +title=calculator +author=admin +path=content/calculator diff --git a/documentation/18.11/solutions/_images/change-font-dialog.png b/documentation/18.11/solutions/_images/change-font-dialog.png new file mode 100644 index 00000000..e7f12c08 Binary files /dev/null and b/documentation/18.11/solutions/_images/change-font-dialog.png differ diff --git a/documentation/18.11/solutions/_images/change-font-dialog.png.data b/documentation/18.11/solutions/_images/change-font-dialog.png.data new file mode 100644 index 00000000..6a884848 --- /dev/null +++ b/documentation/18.11/solutions/_images/change-font-dialog.png.data @@ -0,0 +1,3 @@ +title=change-font-dialog +author=admin +path=content/change-font-dialog diff --git a/documentation/18.11/solutions/_images/class-project-diagram-client.png b/documentation/18.11/solutions/_images/class-project-diagram-client.png new file mode 100644 index 00000000..cb9eb398 Binary files /dev/null and b/documentation/18.11/solutions/_images/class-project-diagram-client.png differ diff --git a/documentation/18.11/solutions/_images/class-project-diagram-client.png.data b/documentation/18.11/solutions/_images/class-project-diagram-client.png.data new file mode 100644 index 00000000..153e7801 --- /dev/null +++ b/documentation/18.11/solutions/_images/class-project-diagram-client.png.data @@ -0,0 +1,3 @@ +title=class-project-diagram-client +author=admin +path=content/class-project-diagram-client diff --git a/documentation/18.11/solutions/_images/class-project-diagram.png b/documentation/18.11/solutions/_images/class-project-diagram.png new file mode 100644 index 00000000..5a08decc Binary files /dev/null and b/documentation/18.11/solutions/_images/class-project-diagram.png differ diff --git a/documentation/18.11/solutions/_images/class-project-diagram.png.data b/documentation/18.11/solutions/_images/class-project-diagram.png.data new file mode 100644 index 00000000..fb50fa1e --- /dev/null +++ b/documentation/18.11/solutions/_images/class-project-diagram.png.data @@ -0,0 +1,3 @@ +title=class-project-diagram +author=admin +path=content/class-project-diagram diff --git a/documentation/18.11/solutions/_images/client-inheritance.png b/documentation/18.11/solutions/_images/client-inheritance.png new file mode 100644 index 00000000..2e7c7d47 Binary files /dev/null and b/documentation/18.11/solutions/_images/client-inheritance.png differ diff --git a/documentation/18.11/solutions/_images/client-inheritance.png.data b/documentation/18.11/solutions/_images/client-inheritance.png.data new file mode 100644 index 00000000..9c62d107 --- /dev/null +++ b/documentation/18.11/solutions/_images/client-inheritance.png.data @@ -0,0 +1,3 @@ +title=client-inheritance +author=admin +path=content/client-inheritance diff --git a/documentation/18.11/solutions/_images/collaps.png b/documentation/18.11/solutions/_images/collaps.png new file mode 100644 index 00000000..11d6328d Binary files /dev/null and b/documentation/18.11/solutions/_images/collaps.png differ diff --git a/documentation/18.11/solutions/_images/collaps.png.data b/documentation/18.11/solutions/_images/collaps.png.data new file mode 100644 index 00000000..e30d9b5c --- /dev/null +++ b/documentation/18.11/solutions/_images/collaps.png.data @@ -0,0 +1,3 @@ +title=collaps +author=admin +path=content/collaps diff --git a/documentation/18.11/solutions/_images/com-1.gif b/documentation/18.11/solutions/_images/com-1.gif new file mode 100644 index 00000000..3375032f Binary files /dev/null and b/documentation/18.11/solutions/_images/com-1.gif differ diff --git a/documentation/18.11/solutions/_images/com-1.gif.data b/documentation/18.11/solutions/_images/com-1.gif.data new file mode 100644 index 00000000..c02f4e4c --- /dev/null +++ b/documentation/18.11/solutions/_images/com-1.gif.data @@ -0,0 +1,3 @@ +title=com-1 +author=admin +path=content/com-1 diff --git a/documentation/18.11/solutions/_images/com-2.gif b/documentation/18.11/solutions/_images/com-2.gif new file mode 100644 index 00000000..799449c9 Binary files /dev/null and b/documentation/18.11/solutions/_images/com-2.gif differ diff --git a/documentation/18.11/solutions/_images/com-2.gif.data b/documentation/18.11/solutions/_images/com-2.gif.data new file mode 100644 index 00000000..88823968 --- /dev/null +++ b/documentation/18.11/solutions/_images/com-2.gif.data @@ -0,0 +1,3 @@ +title=com-2 +author=admin +path=content/com-2 diff --git a/documentation/18.11/solutions/_images/com-3.gif b/documentation/18.11/solutions/_images/com-3.gif new file mode 100644 index 00000000..51caff35 Binary files /dev/null and b/documentation/18.11/solutions/_images/com-3.gif differ diff --git a/documentation/18.11/solutions/_images/com-3.gif.data b/documentation/18.11/solutions/_images/com-3.gif.data new file mode 100644 index 00000000..72dadb05 --- /dev/null +++ b/documentation/18.11/solutions/_images/com-3.gif.data @@ -0,0 +1,3 @@ +title=com-3 +author=admin +path=content/com-3 diff --git a/documentation/18.11/solutions/_images/comctrls.png b/documentation/18.11/solutions/_images/comctrls.png new file mode 100644 index 00000000..d697d282 Binary files /dev/null and b/documentation/18.11/solutions/_images/comctrls.png differ diff --git a/documentation/18.11/solutions/_images/comctrls.png.data b/documentation/18.11/solutions/_images/comctrls.png.data new file mode 100644 index 00000000..d3d63ba3 --- /dev/null +++ b/documentation/18.11/solutions/_images/comctrls.png.data @@ -0,0 +1,3 @@ +title=comctrls +author=admin +path=content/comctrls diff --git a/documentation/18.11/solutions/_images/commands.png b/documentation/18.11/solutions/_images/commands.png new file mode 100644 index 00000000..7beb4495 Binary files /dev/null and b/documentation/18.11/solutions/_images/commands.png differ diff --git a/documentation/18.11/solutions/_images/commands.png.data b/documentation/18.11/solutions/_images/commands.png.data new file mode 100644 index 00000000..2a0fb1df --- /dev/null +++ b/documentation/18.11/solutions/_images/commands.png.data @@ -0,0 +1,3 @@ +title=commands +author=admin +path=content/commands diff --git a/documentation/18.11/solutions/_images/complete-project-diagram.png b/documentation/18.11/solutions/_images/complete-project-diagram.png new file mode 100644 index 00000000..0c5bf092 Binary files /dev/null and b/documentation/18.11/solutions/_images/complete-project-diagram.png differ diff --git a/documentation/18.11/solutions/_images/complete-project-diagram.png.data b/documentation/18.11/solutions/_images/complete-project-diagram.png.data new file mode 100644 index 00000000..836016cd --- /dev/null +++ b/documentation/18.11/solutions/_images/complete-project-diagram.png.data @@ -0,0 +1,3 @@ +title=complete-project-diagram +author=admin +path=content/complete-project-diagram diff --git a/documentation/18.11/solutions/_images/component-create-relation.png b/documentation/18.11/solutions/_images/component-create-relation.png new file mode 100644 index 00000000..5e1a0e0c Binary files /dev/null and b/documentation/18.11/solutions/_images/component-create-relation.png differ diff --git a/documentation/18.11/solutions/_images/component-create-relation.png.data b/documentation/18.11/solutions/_images/component-create-relation.png.data new file mode 100644 index 00000000..9ba7749c --- /dev/null +++ b/documentation/18.11/solutions/_images/component-create-relation.png.data @@ -0,0 +1,3 @@ +title=component-create-relation +author=admin +path=content/component-create-relation diff --git a/documentation/18.11/solutions/_images/component-fields-relation.png b/documentation/18.11/solutions/_images/component-fields-relation.png new file mode 100644 index 00000000..c7a254ab Binary files /dev/null and b/documentation/18.11/solutions/_images/component-fields-relation.png differ diff --git a/documentation/18.11/solutions/_images/component-fields-relation.png.data b/documentation/18.11/solutions/_images/component-fields-relation.png.data new file mode 100644 index 00000000..f2637321 --- /dev/null +++ b/documentation/18.11/solutions/_images/component-fields-relation.png.data @@ -0,0 +1,3 @@ +title=component-fields-relation +author=admin +path=content/component-fields-relation diff --git a/documentation/18.11/solutions/_images/component-namer.png b/documentation/18.11/solutions/_images/component-namer.png new file mode 100644 index 00000000..8f0730f3 Binary files /dev/null and b/documentation/18.11/solutions/_images/component-namer.png differ diff --git a/documentation/18.11/solutions/_images/component-namer.png.data b/documentation/18.11/solutions/_images/component-namer.png.data new file mode 100644 index 00000000..b63ecf01 --- /dev/null +++ b/documentation/18.11/solutions/_images/component-namer.png.data @@ -0,0 +1,3 @@ +title=component-namer +author=admin +path=content/component-namer diff --git a/documentation/18.11/solutions/_images/component-navigate-relation.png b/documentation/18.11/solutions/_images/component-navigate-relation.png new file mode 100644 index 00000000..11f0b9a0 Binary files /dev/null and b/documentation/18.11/solutions/_images/component-navigate-relation.png differ diff --git a/documentation/18.11/solutions/_images/component-navigate-relation.png.data b/documentation/18.11/solutions/_images/component-navigate-relation.png.data new file mode 100644 index 00000000..4da05873 --- /dev/null +++ b/documentation/18.11/solutions/_images/component-navigate-relation.png.data @@ -0,0 +1,3 @@ +title=component-navigate-relation +author=admin +path=content/component-navigate-relation diff --git a/documentation/18.11/solutions/_images/component-search-relation.png b/documentation/18.11/solutions/_images/component-search-relation.png new file mode 100644 index 00000000..14eeb1e4 Binary files /dev/null and b/documentation/18.11/solutions/_images/component-search-relation.png differ diff --git a/documentation/18.11/solutions/_images/component-search-relation.png.data b/documentation/18.11/solutions/_images/component-search-relation.png.data new file mode 100644 index 00000000..e6587c00 --- /dev/null +++ b/documentation/18.11/solutions/_images/component-search-relation.png.data @@ -0,0 +1,3 @@ +title=component-search-relation +author=admin +path=content/component-search-relation diff --git a/documentation/18.11/solutions/_images/component-selector.png b/documentation/18.11/solutions/_images/component-selector.png new file mode 100644 index 00000000..eceacf87 Binary files /dev/null and b/documentation/18.11/solutions/_images/component-selector.png differ diff --git a/documentation/18.11/solutions/_images/component-selector.png.data b/documentation/18.11/solutions/_images/component-selector.png.data new file mode 100644 index 00000000..b8a5de94 --- /dev/null +++ b/documentation/18.11/solutions/_images/component-selector.png.data @@ -0,0 +1,3 @@ +title=component-selector +author=admin +path=content/component-selector diff --git a/documentation/18.11/solutions/_images/component-viewer.png b/documentation/18.11/solutions/_images/component-viewer.png new file mode 100644 index 00000000..999f50d2 Binary files /dev/null and b/documentation/18.11/solutions/_images/component-viewer.png differ diff --git a/documentation/18.11/solutions/_images/component-viewer.png.data b/documentation/18.11/solutions/_images/component-viewer.png.data new file mode 100644 index 00000000..039deee8 --- /dev/null +++ b/documentation/18.11/solutions/_images/component-viewer.png.data @@ -0,0 +1,3 @@ +title=component-viewer +author=admin +path=content/component-viewer diff --git a/documentation/18.11/solutions/_images/constant-in-use.png b/documentation/18.11/solutions/_images/constant-in-use.png new file mode 100644 index 00000000..de7e2ee5 Binary files /dev/null and b/documentation/18.11/solutions/_images/constant-in-use.png differ diff --git a/documentation/18.11/solutions/_images/constant-in-use.png.data b/documentation/18.11/solutions/_images/constant-in-use.png.data new file mode 100644 index 00000000..2af3147b --- /dev/null +++ b/documentation/18.11/solutions/_images/constant-in-use.png.data @@ -0,0 +1,3 @@ +title=constant-in-use +author=admin +path=content/constant-use diff --git a/documentation/18.11/solutions/_images/constants-dialog.png b/documentation/18.11/solutions/_images/constants-dialog.png new file mode 100644 index 00000000..dba86c1c Binary files /dev/null and b/documentation/18.11/solutions/_images/constants-dialog.png differ diff --git a/documentation/18.11/solutions/_images/constants-dialog.png.data b/documentation/18.11/solutions/_images/constants-dialog.png.data new file mode 100644 index 00000000..edc8444a --- /dev/null +++ b/documentation/18.11/solutions/_images/constants-dialog.png.data @@ -0,0 +1,3 @@ +title=constants-dialog +author=admin +path=content/constants-dialog diff --git a/documentation/18.11/solutions/_images/controls.png b/documentation/18.11/solutions/_images/controls.png new file mode 100644 index 00000000..7620f411 Binary files /dev/null and b/documentation/18.11/solutions/_images/controls.png differ diff --git a/documentation/18.11/solutions/_images/controls.png.data b/documentation/18.11/solutions/_images/controls.png.data new file mode 100644 index 00000000..beed1437 --- /dev/null +++ b/documentation/18.11/solutions/_images/controls.png.data @@ -0,0 +1,3 @@ +title=controls +author=admin +path=content/controls diff --git a/documentation/18.11/solutions/_images/creator-provider-relation.png b/documentation/18.11/solutions/_images/creator-provider-relation.png new file mode 100644 index 00000000..915e8296 Binary files /dev/null and b/documentation/18.11/solutions/_images/creator-provider-relation.png differ diff --git a/documentation/18.11/solutions/_images/creator-provider-relation.png.data b/documentation/18.11/solutions/_images/creator-provider-relation.png.data new file mode 100644 index 00000000..34104a8e --- /dev/null +++ b/documentation/18.11/solutions/_images/creator-provider-relation.png.data @@ -0,0 +1,3 @@ +title=creator-provider-relation +author=admin +path=content/creator-provider-relation diff --git a/documentation/18.11/solutions/_images/ctlcolor.png b/documentation/18.11/solutions/_images/ctlcolor.png new file mode 100644 index 00000000..cb11de7d Binary files /dev/null and b/documentation/18.11/solutions/_images/ctlcolor.png differ diff --git a/documentation/18.11/solutions/_images/ctlcolor.png.data b/documentation/18.11/solutions/_images/ctlcolor.png.data new file mode 100644 index 00000000..fb2e7e11 --- /dev/null +++ b/documentation/18.11/solutions/_images/ctlcolor.png.data @@ -0,0 +1,3 @@ +title=ctlcolor +author=admin +path=content/ctlcolor diff --git a/documentation/18.11/solutions/_images/cursor-test.png b/documentation/18.11/solutions/_images/cursor-test.png new file mode 100644 index 00000000..5d3732ca Binary files /dev/null and b/documentation/18.11/solutions/_images/cursor-test.png differ diff --git a/documentation/18.11/solutions/_images/cursor-test.png.data b/documentation/18.11/solutions/_images/cursor-test.png.data new file mode 100644 index 00000000..aafaeb60 --- /dev/null +++ b/documentation/18.11/solutions/_images/cursor-test.png.data @@ -0,0 +1,3 @@ +title=cursor-test +author=admin +path=content/cursor-test diff --git a/documentation/18.11/solutions/_images/date-time-picker.png b/documentation/18.11/solutions/_images/date-time-picker.png new file mode 100644 index 00000000..b4457c74 Binary files /dev/null and b/documentation/18.11/solutions/_images/date-time-picker.png differ diff --git a/documentation/18.11/solutions/_images/date-time-picker.png.data b/documentation/18.11/solutions/_images/date-time-picker.png.data new file mode 100644 index 00000000..e62036cb --- /dev/null +++ b/documentation/18.11/solutions/_images/date-time-picker.png.data @@ -0,0 +1,3 @@ +title=date-time-picker +author=admin +path=content/date-time-picker diff --git a/documentation/18.11/solutions/_images/db-specific-tables-access-use.png b/documentation/18.11/solutions/_images/db-specific-tables-access-use.png new file mode 100644 index 00000000..0dc0b789 Binary files /dev/null and b/documentation/18.11/solutions/_images/db-specific-tables-access-use.png differ diff --git a/documentation/18.11/solutions/_images/db-specific-tables-access-use.png.data b/documentation/18.11/solutions/_images/db-specific-tables-access-use.png.data new file mode 100644 index 00000000..c56f705a --- /dev/null +++ b/documentation/18.11/solutions/_images/db-specific-tables-access-use.png.data @@ -0,0 +1,3 @@ +title=db-specific-tables-access-use +author=admin +path=content/db-specific-tables-access-use diff --git a/documentation/18.11/solutions/_images/directory-search-small.png b/documentation/18.11/solutions/_images/directory-search-small.png new file mode 100644 index 00000000..31284d40 Binary files /dev/null and b/documentation/18.11/solutions/_images/directory-search-small.png differ diff --git a/documentation/18.11/solutions/_images/directory-search-small.png.data b/documentation/18.11/solutions/_images/directory-search-small.png.data new file mode 100644 index 00000000..898da872 --- /dev/null +++ b/documentation/18.11/solutions/_images/directory-search-small.png.data @@ -0,0 +1,3 @@ +title=directory-search-small +author=admin +path=content/directory-search-small diff --git a/documentation/18.11/solutions/_images/diskspace.png b/documentation/18.11/solutions/_images/diskspace.png new file mode 100644 index 00000000..38cc5b0a Binary files /dev/null and b/documentation/18.11/solutions/_images/diskspace.png differ diff --git a/documentation/18.11/solutions/_images/diskspace.png.data b/documentation/18.11/solutions/_images/diskspace.png.data new file mode 100644 index 00000000..458541b7 --- /dev/null +++ b/documentation/18.11/solutions/_images/diskspace.png.data @@ -0,0 +1,3 @@ +title=diskspace +author=admin +path=content/diskspace diff --git a/documentation/18.11/solutions/_images/display-window.png b/documentation/18.11/solutions/_images/display-window.png new file mode 100644 index 00000000..51c80846 Binary files /dev/null and b/documentation/18.11/solutions/_images/display-window.png differ diff --git a/documentation/18.11/solutions/_images/display-window.png.data b/documentation/18.11/solutions/_images/display-window.png.data new file mode 100644 index 00000000..8ff7fa9d --- /dev/null +++ b/documentation/18.11/solutions/_images/display-window.png.data @@ -0,0 +1,3 @@ +title=display-window +author=admin +path=content/display-window diff --git a/documentation/18.11/solutions/_images/docked-external.png b/documentation/18.11/solutions/_images/docked-external.png new file mode 100644 index 00000000..f1d2633d Binary files /dev/null and b/documentation/18.11/solutions/_images/docked-external.png differ diff --git a/documentation/18.11/solutions/_images/docked-external.png.data b/documentation/18.11/solutions/_images/docked-external.png.data new file mode 100644 index 00000000..2c5167b5 --- /dev/null +++ b/documentation/18.11/solutions/_images/docked-external.png.data @@ -0,0 +1,3 @@ +title=docked-external +author=admin +path=content/docked-external diff --git a/documentation/18.11/solutions/_images/docking-insert.png b/documentation/18.11/solutions/_images/docking-insert.png new file mode 100644 index 00000000..549dbced Binary files /dev/null and b/documentation/18.11/solutions/_images/docking-insert.png differ diff --git a/documentation/18.11/solutions/_images/docking-insert.png.data b/documentation/18.11/solutions/_images/docking-insert.png.data new file mode 100644 index 00000000..f7a7b0ea --- /dev/null +++ b/documentation/18.11/solutions/_images/docking-insert.png.data @@ -0,0 +1,3 @@ +title=docking-insert +author=admin +path=content/docking-insert diff --git a/documentation/18.11/solutions/_images/dotnet-samples--date-time-picker-change-color-dlg.png b/documentation/18.11/solutions/_images/dotnet-samples--date-time-picker-change-color-dlg.png new file mode 100644 index 00000000..7ddc37e9 Binary files /dev/null and b/documentation/18.11/solutions/_images/dotnet-samples--date-time-picker-change-color-dlg.png differ diff --git a/documentation/18.11/solutions/_images/dotnet-samples--date-time-picker-change-color-dlg.png.data b/documentation/18.11/solutions/_images/dotnet-samples--date-time-picker-change-color-dlg.png.data new file mode 100644 index 00000000..fdee864c --- /dev/null +++ b/documentation/18.11/solutions/_images/dotnet-samples--date-time-picker-change-color-dlg.png.data @@ -0,0 +1,3 @@ +title=dotnet-samples--date-time-picker-change-color-dlg +author=admin +path=content/dotnet-samples-date-time-picker-change-color-dlg diff --git a/documentation/18.11/solutions/_images/dv-choice-creator-fkeys-selection.png b/documentation/18.11/solutions/_images/dv-choice-creator-fkeys-selection.png new file mode 100644 index 00000000..dc67c313 Binary files /dev/null and b/documentation/18.11/solutions/_images/dv-choice-creator-fkeys-selection.png differ diff --git a/documentation/18.11/solutions/_images/dv-choice-creator-fkeys-selection.png.data b/documentation/18.11/solutions/_images/dv-choice-creator-fkeys-selection.png.data new file mode 100644 index 00000000..27c899e4 --- /dev/null +++ b/documentation/18.11/solutions/_images/dv-choice-creator-fkeys-selection.png.data @@ -0,0 +1,3 @@ +title=dv-choice-creator-fkeys-selection +author=admin +path=content/dv-choice-creator-fkeys-selection diff --git a/documentation/18.11/solutions/_images/dv-table-component-strategy.png b/documentation/18.11/solutions/_images/dv-table-component-strategy.png new file mode 100644 index 00000000..297796f5 Binary files /dev/null and b/documentation/18.11/solutions/_images/dv-table-component-strategy.png differ diff --git a/documentation/18.11/solutions/_images/dv-table-component-strategy.png.data b/documentation/18.11/solutions/_images/dv-table-component-strategy.png.data new file mode 100644 index 00000000..25ab5022 --- /dev/null +++ b/documentation/18.11/solutions/_images/dv-table-component-strategy.png.data @@ -0,0 +1,3 @@ +title=dv-table-component-strategy +author=admin +path=content/dv-table-component-strategy diff --git a/documentation/18.11/solutions/_images/dv-tablerow-fields-design.png b/documentation/18.11/solutions/_images/dv-tablerow-fields-design.png new file mode 100644 index 00000000..7ad801ff Binary files /dev/null and b/documentation/18.11/solutions/_images/dv-tablerow-fields-design.png differ diff --git a/documentation/18.11/solutions/_images/dv-tablerow-fields-design.png.data b/documentation/18.11/solutions/_images/dv-tablerow-fields-design.png.data new file mode 100644 index 00000000..2e03a458 --- /dev/null +++ b/documentation/18.11/solutions/_images/dv-tablerow-fields-design.png.data @@ -0,0 +1,3 @@ +title=dv-tablerow-fields-design +author=admin +path=content/dv-tablerow-fields-design diff --git a/documentation/18.11/solutions/_images/dv-tablerows-navigator-clients.png b/documentation/18.11/solutions/_images/dv-tablerows-navigator-clients.png new file mode 100644 index 00000000..efa0608d Binary files /dev/null and b/documentation/18.11/solutions/_images/dv-tablerows-navigator-clients.png differ diff --git a/documentation/18.11/solutions/_images/dv-tablerows-navigator-clients.png.data b/documentation/18.11/solutions/_images/dv-tablerows-navigator-clients.png.data new file mode 100644 index 00000000..3aaf8ace --- /dev/null +++ b/documentation/18.11/solutions/_images/dv-tablerows-navigator-clients.png.data @@ -0,0 +1,3 @@ +title=dv-tablerows-navigator-clients +author=admin +path=content/dv-tablerows-navigator-clients diff --git a/documentation/18.11/solutions/_images/eb_type_selector.png b/documentation/18.11/solutions/_images/eb_type_selector.png new file mode 100644 index 00000000..b3d1d51c Binary files /dev/null and b/documentation/18.11/solutions/_images/eb_type_selector.png differ diff --git a/documentation/18.11/solutions/_images/eb_type_selector.png.data b/documentation/18.11/solutions/_images/eb_type_selector.png.data new file mode 100644 index 00000000..617a567c --- /dev/null +++ b/documentation/18.11/solutions/_images/eb_type_selector.png.data @@ -0,0 +1,3 @@ +title=type-selector +author=halw +path=content/type-selector diff --git a/documentation/18.11/solutions/_images/empty-radio-merge.png b/documentation/18.11/solutions/_images/empty-radio-merge.png new file mode 100644 index 00000000..1b8cabd7 Binary files /dev/null and b/documentation/18.11/solutions/_images/empty-radio-merge.png differ diff --git a/documentation/18.11/solutions/_images/empty-radio-merge.png.data b/documentation/18.11/solutions/_images/empty-radio-merge.png.data new file mode 100644 index 00000000..53eba3b7 --- /dev/null +++ b/documentation/18.11/solutions/_images/empty-radio-merge.png.data @@ -0,0 +1,3 @@ +title=empty-radio-merge +author=admin +path=content/empty-radio-merge diff --git a/documentation/18.11/solutions/_images/estore-generation.generator.png b/documentation/18.11/solutions/_images/estore-generation.generator.png new file mode 100644 index 00000000..3b7465b9 Binary files /dev/null and b/documentation/18.11/solutions/_images/estore-generation.generator.png differ diff --git a/documentation/18.11/solutions/_images/estore-generation.generator.png.data b/documentation/18.11/solutions/_images/estore-generation.generator.png.data new file mode 100644 index 00000000..c0e87aec --- /dev/null +++ b/documentation/18.11/solutions/_images/estore-generation.generator.png.data @@ -0,0 +1 @@ +title=estore-generation.generator diff --git a/documentation/18.11/solutions/_images/event-selection-dialog.png b/documentation/18.11/solutions/_images/event-selection-dialog.png new file mode 100644 index 00000000..bf49c8cb Binary files /dev/null and b/documentation/18.11/solutions/_images/event-selection-dialog.png differ diff --git a/documentation/18.11/solutions/_images/event-selection-dialog.png.data b/documentation/18.11/solutions/_images/event-selection-dialog.png.data new file mode 100644 index 00000000..29ac578f --- /dev/null +++ b/documentation/18.11/solutions/_images/event-selection-dialog.png.data @@ -0,0 +1,3 @@ +title=event-selection-dialog +author=admin +path=content/event-selection-dialog diff --git a/documentation/18.11/solutions/_images/ex_cust_pref_dialog.png b/documentation/18.11/solutions/_images/ex_cust_pref_dialog.png new file mode 100644 index 00000000..995d229a Binary files /dev/null and b/documentation/18.11/solutions/_images/ex_cust_pref_dialog.png differ diff --git a/documentation/18.11/solutions/_images/ex_cust_pref_dialog.png.data b/documentation/18.11/solutions/_images/ex_cust_pref_dialog.png.data new file mode 100644 index 00000000..05bb716b --- /dev/null +++ b/documentation/18.11/solutions/_images/ex_cust_pref_dialog.png.data @@ -0,0 +1,3 @@ +title=custom +author=jfiat +path=content/custom diff --git a/documentation/18.11/solutions/_images/ex_pref_dialog.png b/documentation/18.11/solutions/_images/ex_pref_dialog.png new file mode 100644 index 00000000..84bb9eeb Binary files /dev/null and b/documentation/18.11/solutions/_images/ex_pref_dialog.png differ diff --git a/documentation/18.11/solutions/_images/ex_pref_dialog.png.data b/documentation/18.11/solutions/_images/ex_pref_dialog.png.data new file mode 100644 index 00000000..a5135328 --- /dev/null +++ b/documentation/18.11/solutions/_images/ex_pref_dialog.png.data @@ -0,0 +1,3 @@ +title=normal +author=jfiat +path=content/normal diff --git a/documentation/18.11/solutions/_images/exception-raising.png b/documentation/18.11/solutions/_images/exception-raising.png new file mode 100644 index 00000000..937b5f8c Binary files /dev/null and b/documentation/18.11/solutions/_images/exception-raising.png differ diff --git a/documentation/18.11/solutions/_images/exception-raising.png.data b/documentation/18.11/solutions/_images/exception-raising.png.data new file mode 100644 index 00000000..e6b8c1db --- /dev/null +++ b/documentation/18.11/solutions/_images/exception-raising.png.data @@ -0,0 +1,3 @@ +title=exception-raising +author=admin +path=content/exception-raising diff --git a/documentation/18.11/solutions/_images/expand.png b/documentation/18.11/solutions/_images/expand.png new file mode 100644 index 00000000..169b32bd Binary files /dev/null and b/documentation/18.11/solutions/_images/expand.png differ diff --git a/documentation/18.11/solutions/_images/expand.png.data b/documentation/18.11/solutions/_images/expand.png.data new file mode 100644 index 00000000..fe304446 --- /dev/null +++ b/documentation/18.11/solutions/_images/expand.png.data @@ -0,0 +1,3 @@ +title=expand +author=admin +path=content/expand diff --git a/documentation/18.11/solutions/_images/fig-1.gif b/documentation/18.11/solutions/_images/fig-1.gif new file mode 100644 index 00000000..fee8d2b0 Binary files /dev/null and b/documentation/18.11/solutions/_images/fig-1.gif differ diff --git a/documentation/18.11/solutions/_images/fig-1.gif.data b/documentation/18.11/solutions/_images/fig-1.gif.data new file mode 100644 index 00000000..13ddd7ce --- /dev/null +++ b/documentation/18.11/solutions/_images/fig-1.gif.data @@ -0,0 +1,3 @@ +title=fig-1 +author=admin +path=content/fig-1 diff --git a/documentation/18.11/solutions/_images/fig-2.gif b/documentation/18.11/solutions/_images/fig-2.gif new file mode 100644 index 00000000..1a415e05 Binary files /dev/null and b/documentation/18.11/solutions/_images/fig-2.gif differ diff --git a/documentation/18.11/solutions/_images/fig-2.gif.data b/documentation/18.11/solutions/_images/fig-2.gif.data new file mode 100644 index 00000000..f17fd854 --- /dev/null +++ b/documentation/18.11/solutions/_images/fig-2.gif.data @@ -0,0 +1,3 @@ +title=fig-2 +author=admin +path=content/fig-2 diff --git a/documentation/18.11/solutions/_images/fig-3.gif b/documentation/18.11/solutions/_images/fig-3.gif new file mode 100644 index 00000000..7129ed5e Binary files /dev/null and b/documentation/18.11/solutions/_images/fig-3.gif differ diff --git a/documentation/18.11/solutions/_images/fig-3.gif.data b/documentation/18.11/solutions/_images/fig-3.gif.data new file mode 100644 index 00000000..6c3ab9df --- /dev/null +++ b/documentation/18.11/solutions/_images/fig-3.gif.data @@ -0,0 +1,3 @@ +title=fig-3 +author=admin +path=content/fig-3 diff --git a/documentation/18.11/solutions/_images/figure1.png b/documentation/18.11/solutions/_images/figure1.png new file mode 100644 index 00000000..6bc9af79 Binary files /dev/null and b/documentation/18.11/solutions/_images/figure1.png differ diff --git a/documentation/18.11/solutions/_images/figure1.png.data b/documentation/18.11/solutions/_images/figure1.png.data new file mode 100644 index 00000000..b6ad67ec --- /dev/null +++ b/documentation/18.11/solutions/_images/figure1.png.data @@ -0,0 +1,3 @@ +title=figure1 +author=admin +path=content/figure1 diff --git a/documentation/18.11/solutions/_images/fixed-child-positioner.png b/documentation/18.11/solutions/_images/fixed-child-positioner.png new file mode 100644 index 00000000..2f26e484 Binary files /dev/null and b/documentation/18.11/solutions/_images/fixed-child-positioner.png differ diff --git a/documentation/18.11/solutions/_images/fixed-child-positioner.png.data b/documentation/18.11/solutions/_images/fixed-child-positioner.png.data new file mode 100644 index 00000000..a52f1d55 --- /dev/null +++ b/documentation/18.11/solutions/_images/fixed-child-positioner.png.data @@ -0,0 +1,3 @@ +title=fixed-child-positioner +author=admin +path=content/fixed-child-positioner diff --git a/documentation/18.11/solutions/_images/folders.png b/documentation/18.11/solutions/_images/folders.png new file mode 100644 index 00000000..b8047c56 Binary files /dev/null and b/documentation/18.11/solutions/_images/folders.png differ diff --git a/documentation/18.11/solutions/_images/folders.png.data b/documentation/18.11/solutions/_images/folders.png.data new file mode 100644 index 00000000..a39a60e3 --- /dev/null +++ b/documentation/18.11/solutions/_images/folders.png.data @@ -0,0 +1,3 @@ +title=folders +author=admin +path=content/folders diff --git a/documentation/18.11/solutions/_images/fontenum.png b/documentation/18.11/solutions/_images/fontenum.png new file mode 100644 index 00000000..bbe63048 Binary files /dev/null and b/documentation/18.11/solutions/_images/fontenum.png differ diff --git a/documentation/18.11/solutions/_images/fontenum.png.data b/documentation/18.11/solutions/_images/fontenum.png.data new file mode 100644 index 00000000..b05531ce --- /dev/null +++ b/documentation/18.11/solutions/_images/fontenum.png.data @@ -0,0 +1,3 @@ +title=fontenum +author=admin +path=content/fontenum diff --git a/documentation/18.11/solutions/_images/fun.png b/documentation/18.11/solutions/_images/fun.png new file mode 100644 index 00000000..8b73e076 Binary files /dev/null and b/documentation/18.11/solutions/_images/fun.png differ diff --git a/documentation/18.11/solutions/_images/fun.png.data b/documentation/18.11/solutions/_images/fun.png.data new file mode 100644 index 00000000..d83a16d4 --- /dev/null +++ b/documentation/18.11/solutions/_images/fun.png.data @@ -0,0 +1,3 @@ +title=fun +author=admin +path=content/fun diff --git a/documentation/18.11/solutions/_images/gauges.png b/documentation/18.11/solutions/_images/gauges.png new file mode 100644 index 00000000..9315931d Binary files /dev/null and b/documentation/18.11/solutions/_images/gauges.png differ diff --git a/documentation/18.11/solutions/_images/gauges.png.data b/documentation/18.11/solutions/_images/gauges.png.data new file mode 100644 index 00000000..90f4ef89 --- /dev/null +++ b/documentation/18.11/solutions/_images/gauges.png.data @@ -0,0 +1,3 @@ +title=gauges +author=admin +path=content/gauges diff --git a/documentation/18.11/solutions/_images/header-ctrl.png b/documentation/18.11/solutions/_images/header-ctrl.png new file mode 100644 index 00000000..a3f9b07c Binary files /dev/null and b/documentation/18.11/solutions/_images/header-ctrl.png differ diff --git a/documentation/18.11/solutions/_images/header-ctrl.png.data b/documentation/18.11/solutions/_images/header-ctrl.png.data new file mode 100644 index 00000000..8f24e3ee --- /dev/null +++ b/documentation/18.11/solutions/_images/header-ctrl.png.data @@ -0,0 +1,3 @@ +title=header-ctrl +author=admin +path=content/header-ctrl diff --git a/documentation/18.11/solutions/_images/hello-world.png b/documentation/18.11/solutions/_images/hello-world.png new file mode 100644 index 00000000..50074f12 Binary files /dev/null and b/documentation/18.11/solutions/_images/hello-world.png differ diff --git a/documentation/18.11/solutions/_images/hello-world.png.data b/documentation/18.11/solutions/_images/hello-world.png.data new file mode 100644 index 00000000..7d916963 --- /dev/null +++ b/documentation/18.11/solutions/_images/hello-world.png.data @@ -0,0 +1,3 @@ +title=hello-world +author=admin +path=content/hello-world diff --git a/documentation/18.11/solutions/_images/hello.png b/documentation/18.11/solutions/_images/hello.png new file mode 100644 index 00000000..e91d76d6 Binary files /dev/null and b/documentation/18.11/solutions/_images/hello.png differ diff --git a/documentation/18.11/solutions/_images/hello.png.data b/documentation/18.11/solutions/_images/hello.png.data new file mode 100644 index 00000000..3e08c3e1 --- /dev/null +++ b/documentation/18.11/solutions/_images/hello.png.data @@ -0,0 +1,3 @@ +title=hello +author=admin +path=content/hello diff --git a/documentation/18.11/solutions/_images/history-window.png b/documentation/18.11/solutions/_images/history-window.png new file mode 100644 index 00000000..f1ba2fb1 Binary files /dev/null and b/documentation/18.11/solutions/_images/history-window.png differ diff --git a/documentation/18.11/solutions/_images/history-window.png.data b/documentation/18.11/solutions/_images/history-window.png.data new file mode 100644 index 00000000..41e4cc8a --- /dev/null +++ b/documentation/18.11/solutions/_images/history-window.png.data @@ -0,0 +1,3 @@ +title=history-window +author=admin +path=content/history-window diff --git a/documentation/18.11/solutions/_images/icon-builder-window-color.png b/documentation/18.11/solutions/_images/icon-builder-window-color.png new file mode 100644 index 00000000..3c8a1c93 Binary files /dev/null and b/documentation/18.11/solutions/_images/icon-builder-window-color.png differ diff --git a/documentation/18.11/solutions/_images/icon-builder-window-color.png.data b/documentation/18.11/solutions/_images/icon-builder-window-color.png.data new file mode 100644 index 00000000..d1f73d5d --- /dev/null +++ b/documentation/18.11/solutions/_images/icon-builder-window-color.png.data @@ -0,0 +1,3 @@ +title=icon-builder-window-color +author=admin +path=content/icon-builder-window-color diff --git a/documentation/18.11/solutions/_images/icon-clipboard-color.png b/documentation/18.11/solutions/_images/icon-clipboard-color.png new file mode 100644 index 00000000..58ec9a1e Binary files /dev/null and b/documentation/18.11/solutions/_images/icon-clipboard-color.png differ diff --git a/documentation/18.11/solutions/_images/icon-clipboard-color.png.data b/documentation/18.11/solutions/_images/icon-clipboard-color.png.data new file mode 100644 index 00000000..77c83ab2 --- /dev/null +++ b/documentation/18.11/solutions/_images/icon-clipboard-color.png.data @@ -0,0 +1,3 @@ +title=icon-clipboard-color +author=admin +path=content/icon-clipboard-color diff --git a/documentation/18.11/solutions/_images/icon-cmd-history-color.png b/documentation/18.11/solutions/_images/icon-cmd-history-color.png new file mode 100644 index 00000000..9ea3c510 Binary files /dev/null and b/documentation/18.11/solutions/_images/icon-cmd-history-color.png differ diff --git a/documentation/18.11/solutions/_images/icon-cmd-history-color.png.data b/documentation/18.11/solutions/_images/icon-cmd-history-color.png.data new file mode 100644 index 00000000..486395f3 --- /dev/null +++ b/documentation/18.11/solutions/_images/icon-cmd-history-color.png.data @@ -0,0 +1,3 @@ +title=icon-cmd-history-color +author=admin +path=content/icon-cmd-history-color diff --git a/documentation/18.11/solutions/_images/icon-code-generation-color.png b/documentation/18.11/solutions/_images/icon-code-generation-color.png new file mode 100644 index 00000000..2d37bbbb Binary files /dev/null and b/documentation/18.11/solutions/_images/icon-code-generation-color.png differ diff --git a/documentation/18.11/solutions/_images/icon-code-generation-color.png.data b/documentation/18.11/solutions/_images/icon-code-generation-color.png.data new file mode 100644 index 00000000..7bbe5723 --- /dev/null +++ b/documentation/18.11/solutions/_images/icon-code-generation-color.png.data @@ -0,0 +1,3 @@ +title=icon-code-generation-color +author=admin +path=content/icon-code-generation-color diff --git a/documentation/18.11/solutions/_images/icon-component-build-view-color.png b/documentation/18.11/solutions/_images/icon-component-build-view-color.png new file mode 100644 index 00000000..fd65bb72 Binary files /dev/null and b/documentation/18.11/solutions/_images/icon-component-build-view-color.png differ diff --git a/documentation/18.11/solutions/_images/icon-component-build-view-color.png.data b/documentation/18.11/solutions/_images/icon-component-build-view-color.png.data new file mode 100644 index 00000000..679565a2 --- /dev/null +++ b/documentation/18.11/solutions/_images/icon-component-build-view-color.png.data @@ -0,0 +1,3 @@ +title=icon-component-build-view-color +author=admin +path=content/icon-component-build-view-color diff --git a/documentation/18.11/solutions/_images/icon-component-display-view-color.png b/documentation/18.11/solutions/_images/icon-component-display-view-color.png new file mode 100644 index 00000000..15f4cd27 Binary files /dev/null and b/documentation/18.11/solutions/_images/icon-component-display-view-color.png differ diff --git a/documentation/18.11/solutions/_images/icon-component-display-view-color.png.data b/documentation/18.11/solutions/_images/icon-component-display-view-color.png.data new file mode 100644 index 00000000..3e3ae150 --- /dev/null +++ b/documentation/18.11/solutions/_images/icon-component-display-view-color.png.data @@ -0,0 +1,3 @@ +title=icon-component-display-view-color +author=admin +path=content/icon-component-display-view-color diff --git a/documentation/18.11/solutions/_images/icon-component-viewer-color.png b/documentation/18.11/solutions/_images/icon-component-viewer-color.png new file mode 100644 index 00000000..a56e41c4 Binary files /dev/null and b/documentation/18.11/solutions/_images/icon-component-viewer-color.png differ diff --git a/documentation/18.11/solutions/_images/icon-component-viewer-color.png.data b/documentation/18.11/solutions/_images/icon-component-viewer-color.png.data new file mode 100644 index 00000000..cb501ac8 --- /dev/null +++ b/documentation/18.11/solutions/_images/icon-component-viewer-color.png.data @@ -0,0 +1,3 @@ +title=icon-component-viewer-color +author=admin +path=content/icon-component-viewer-color diff --git a/documentation/18.11/solutions/_images/icon-copy-color.png b/documentation/18.11/solutions/_images/icon-copy-color.png new file mode 100644 index 00000000..c642c71d Binary files /dev/null and b/documentation/18.11/solutions/_images/icon-copy-color.png differ diff --git a/documentation/18.11/solutions/_images/icon-copy-color.png.data b/documentation/18.11/solutions/_images/icon-copy-color.png.data new file mode 100644 index 00000000..6475245d --- /dev/null +++ b/documentation/18.11/solutions/_images/icon-copy-color.png.data @@ -0,0 +1,3 @@ +title=icon-copy-color +author=admin +path=content/icon-copy-color diff --git a/documentation/18.11/solutions/_images/icon-cut-color.png b/documentation/18.11/solutions/_images/icon-cut-color.png new file mode 100644 index 00000000..f763a135 Binary files /dev/null and b/documentation/18.11/solutions/_images/icon-cut-color.png differ diff --git a/documentation/18.11/solutions/_images/icon-cut-color.png.data b/documentation/18.11/solutions/_images/icon-cut-color.png.data new file mode 100644 index 00000000..8b358260 --- /dev/null +++ b/documentation/18.11/solutions/_images/icon-cut-color.png.data @@ -0,0 +1,3 @@ +title=icon-cut-color +author=admin +path=content/icon-cut-color diff --git a/documentation/18.11/solutions/_images/icon-delete-small-color.png b/documentation/18.11/solutions/_images/icon-delete-small-color.png new file mode 100644 index 00000000..af0d82d7 Binary files /dev/null and b/documentation/18.11/solutions/_images/icon-delete-small-color.png differ diff --git a/documentation/18.11/solutions/_images/icon-delete-small-color.png.data b/documentation/18.11/solutions/_images/icon-delete-small-color.png.data new file mode 100644 index 00000000..3ea76549 --- /dev/null +++ b/documentation/18.11/solutions/_images/icon-delete-small-color.png.data @@ -0,0 +1,3 @@ +title=icon-delete-small-color +author=admin +path=content/icon-delete-small-color diff --git a/documentation/18.11/solutions/_images/icon-display-window-color.png b/documentation/18.11/solutions/_images/icon-display-window-color.png new file mode 100644 index 00000000..d61281f1 Binary files /dev/null and b/documentation/18.11/solutions/_images/icon-display-window-color.png differ diff --git a/documentation/18.11/solutions/_images/icon-display-window-color.png.data b/documentation/18.11/solutions/_images/icon-display-window-color.png.data new file mode 100644 index 00000000..7355ff9b --- /dev/null +++ b/documentation/18.11/solutions/_images/icon-display-window-color.png.data @@ -0,0 +1,3 @@ +title=icon-display-window-color +author=admin +path=content/icon-display-window-color diff --git a/documentation/18.11/solutions/_images/icon-expand-all-small-color.png b/documentation/18.11/solutions/_images/icon-expand-all-small-color.png new file mode 100644 index 00000000..8570c546 Binary files /dev/null and b/documentation/18.11/solutions/_images/icon-expand-all-small-color.png differ diff --git a/documentation/18.11/solutions/_images/icon-expand-all-small-color.png.data b/documentation/18.11/solutions/_images/icon-expand-all-small-color.png.data new file mode 100644 index 00000000..f7c1184a --- /dev/null +++ b/documentation/18.11/solutions/_images/icon-expand-all-small-color.png.data @@ -0,0 +1,3 @@ +title=icon-expand-all-small-color +author=admin +path=content/icon-expand-all-small-color diff --git a/documentation/18.11/solutions/_images/icon-format-onces-color.png b/documentation/18.11/solutions/_images/icon-format-onces-color.png new file mode 100644 index 00000000..b35948f3 Binary files /dev/null and b/documentation/18.11/solutions/_images/icon-format-onces-color.png differ diff --git a/documentation/18.11/solutions/_images/icon-format-onces-color.png.data b/documentation/18.11/solutions/_images/icon-format-onces-color.png.data new file mode 100644 index 00000000..f62c2ff1 --- /dev/null +++ b/documentation/18.11/solutions/_images/icon-format-onces-color.png.data @@ -0,0 +1,3 @@ +title=icon-format-onces-color +author=admin +path=content/icon-format-onces-color diff --git a/documentation/18.11/solutions/_images/icon-new-cluster-small-color.png b/documentation/18.11/solutions/_images/icon-new-cluster-small-color.png new file mode 100644 index 00000000..adc0acf5 Binary files /dev/null and b/documentation/18.11/solutions/_images/icon-new-cluster-small-color.png differ diff --git a/documentation/18.11/solutions/_images/icon-new-cluster-small-color.png.data b/documentation/18.11/solutions/_images/icon-new-cluster-small-color.png.data new file mode 100644 index 00000000..ceecdfb1 --- /dev/null +++ b/documentation/18.11/solutions/_images/icon-new-cluster-small-color.png.data @@ -0,0 +1,3 @@ +title=icon-new-cluster-small-color +author=admin +path=content/icon-new-cluster-small-color diff --git a/documentation/18.11/solutions/_images/icon-object-editor-color.png b/documentation/18.11/solutions/_images/icon-object-editor-color.png new file mode 100644 index 00000000..9af97b06 Binary files /dev/null and b/documentation/18.11/solutions/_images/icon-object-editor-color.png differ diff --git a/documentation/18.11/solutions/_images/icon-object-editor-color.png.data b/documentation/18.11/solutions/_images/icon-object-editor-color.png.data new file mode 100644 index 00000000..9e3d21e6 --- /dev/null +++ b/documentation/18.11/solutions/_images/icon-object-editor-color.png.data @@ -0,0 +1,3 @@ +title=icon-object-editor-color +author=admin +path=content/icon-object-editor-color diff --git a/documentation/18.11/solutions/_images/icon-past-color.png b/documentation/18.11/solutions/_images/icon-past-color.png new file mode 100644 index 00000000..7c7213fe Binary files /dev/null and b/documentation/18.11/solutions/_images/icon-past-color.png differ diff --git a/documentation/18.11/solutions/_images/icon-past-color.png.data b/documentation/18.11/solutions/_images/icon-past-color.png.data new file mode 100644 index 00000000..42ca6db1 --- /dev/null +++ b/documentation/18.11/solutions/_images/icon-past-color.png.data @@ -0,0 +1,3 @@ +title=icon-past-color +author=admin +path=content/icon-past-color diff --git a/documentation/18.11/solutions/_images/icon-redo-color.png b/documentation/18.11/solutions/_images/icon-redo-color.png new file mode 100644 index 00000000..51771a46 Binary files /dev/null and b/documentation/18.11/solutions/_images/icon-redo-color.png differ diff --git a/documentation/18.11/solutions/_images/icon-redo-color.png.data b/documentation/18.11/solutions/_images/icon-redo-color.png.data new file mode 100644 index 00000000..f17ce25a --- /dev/null +++ b/documentation/18.11/solutions/_images/icon-redo-color.png.data @@ -0,0 +1,3 @@ +title=icon-redo-color +author=admin +path=content/icon-redo-color diff --git a/documentation/18.11/solutions/_images/icon-save-color.png b/documentation/18.11/solutions/_images/icon-save-color.png new file mode 100644 index 00000000..f6970cfa Binary files /dev/null and b/documentation/18.11/solutions/_images/icon-save-color.png differ diff --git a/documentation/18.11/solutions/_images/icon-save-color.png.data b/documentation/18.11/solutions/_images/icon-save-color.png.data new file mode 100644 index 00000000..b5155761 --- /dev/null +++ b/documentation/18.11/solutions/_images/icon-save-color.png.data @@ -0,0 +1,3 @@ +title=icon-save-color +author=admin +path=content/icon-save-color diff --git a/documentation/18.11/solutions/_images/icon-show-hide-directory-color.png b/documentation/18.11/solutions/_images/icon-show-hide-directory-color.png new file mode 100644 index 00000000..7eb22ebc Binary files /dev/null and b/documentation/18.11/solutions/_images/icon-show-hide-directory-color.png differ diff --git a/documentation/18.11/solutions/_images/icon-show-hide-directory-color.png.data b/documentation/18.11/solutions/_images/icon-show-hide-directory-color.png.data new file mode 100644 index 00000000..fccb5e63 --- /dev/null +++ b/documentation/18.11/solutions/_images/icon-show-hide-directory-color.png.data @@ -0,0 +1,3 @@ +title=icon-show-hide-directory-color +author=admin +path=content/icon-show-hide-directory-color diff --git a/documentation/18.11/solutions/_images/icon-system-color.png b/documentation/18.11/solutions/_images/icon-system-color.png new file mode 100644 index 00000000..ca029ed4 Binary files /dev/null and b/documentation/18.11/solutions/_images/icon-system-color.png differ diff --git a/documentation/18.11/solutions/_images/icon-system-color.png.data b/documentation/18.11/solutions/_images/icon-system-color.png.data new file mode 100644 index 00000000..1dcb22b6 --- /dev/null +++ b/documentation/18.11/solutions/_images/icon-system-color.png.data @@ -0,0 +1,3 @@ +title=icon-system-color +author=admin +path=content/icon-system-color diff --git a/documentation/18.11/solutions/_images/icon-titled-window-main-small-color.png b/documentation/18.11/solutions/_images/icon-titled-window-main-small-color.png new file mode 100644 index 00000000..e8fa114f Binary files /dev/null and b/documentation/18.11/solutions/_images/icon-titled-window-main-small-color.png differ diff --git a/documentation/18.11/solutions/_images/icon-titled-window-main-small-color.png.data b/documentation/18.11/solutions/_images/icon-titled-window-main-small-color.png.data new file mode 100644 index 00000000..7ebf0819 --- /dev/null +++ b/documentation/18.11/solutions/_images/icon-titled-window-main-small-color.png.data @@ -0,0 +1,3 @@ +title=icon-titled-window-main-small-color +author=admin +path=content/icon-titled-window-main-small-color diff --git a/documentation/18.11/solutions/_images/icon-undo-color.png b/documentation/18.11/solutions/_images/icon-undo-color.png new file mode 100644 index 00000000..2c731285 Binary files /dev/null and b/documentation/18.11/solutions/_images/icon-undo-color.png differ diff --git a/documentation/18.11/solutions/_images/icon-undo-color.png.data b/documentation/18.11/solutions/_images/icon-undo-color.png.data new file mode 100644 index 00000000..f23cb87b --- /dev/null +++ b/documentation/18.11/solutions/_images/icon-undo-color.png.data @@ -0,0 +1,3 @@ +title=icon-undo-color +author=admin +path=content/icon-undo-color diff --git a/documentation/18.11/solutions/_images/implemented-interface-server.png b/documentation/18.11/solutions/_images/implemented-interface-server.png new file mode 100644 index 00000000..64884539 Binary files /dev/null and b/documentation/18.11/solutions/_images/implemented-interface-server.png differ diff --git a/documentation/18.11/solutions/_images/implemented-interface-server.png.data b/documentation/18.11/solutions/_images/implemented-interface-server.png.data new file mode 100644 index 00000000..f330453d --- /dev/null +++ b/documentation/18.11/solutions/_images/implemented-interface-server.png.data @@ -0,0 +1,3 @@ +title=implemented-interface-server +author=admin +path=content/implemented-interface-server diff --git a/documentation/18.11/solutions/_images/implemented-interface.png b/documentation/18.11/solutions/_images/implemented-interface.png new file mode 100644 index 00000000..9b76f0c6 Binary files /dev/null and b/documentation/18.11/solutions/_images/implemented-interface.png differ diff --git a/documentation/18.11/solutions/_images/implemented-interface.png.data b/documentation/18.11/solutions/_images/implemented-interface.png.data new file mode 100644 index 00000000..92ad6739 --- /dev/null +++ b/documentation/18.11/solutions/_images/implemented-interface.png.data @@ -0,0 +1,3 @@ +title=implemented-interface +author=admin +path=content/implemented-interface diff --git a/documentation/18.11/solutions/_images/import-project-clashes.png b/documentation/18.11/solutions/_images/import-project-clashes.png new file mode 100644 index 00000000..85af0ce2 Binary files /dev/null and b/documentation/18.11/solutions/_images/import-project-clashes.png differ diff --git a/documentation/18.11/solutions/_images/import-project-clashes.png.data b/documentation/18.11/solutions/_images/import-project-clashes.png.data new file mode 100644 index 00000000..353b6d7e --- /dev/null +++ b/documentation/18.11/solutions/_images/import-project-clashes.png.data @@ -0,0 +1,3 @@ +title=import-project-clashes +author=admin +path=content/import-project-clashes diff --git a/documentation/18.11/solutions/_images/import-project.png b/documentation/18.11/solutions/_images/import-project.png new file mode 100644 index 00000000..da582d7b Binary files /dev/null and b/documentation/18.11/solutions/_images/import-project.png differ diff --git a/documentation/18.11/solutions/_images/import-project.png.data b/documentation/18.11/solutions/_images/import-project.png.data new file mode 100644 index 00000000..27ce59e4 --- /dev/null +++ b/documentation/18.11/solutions/_images/import-project.png.data @@ -0,0 +1,3 @@ +title=import-project +author=admin +path=content/import-project diff --git a/documentation/18.11/solutions/_images/interface-inheritance-server.png b/documentation/18.11/solutions/_images/interface-inheritance-server.png new file mode 100644 index 00000000..5538d0da Binary files /dev/null and b/documentation/18.11/solutions/_images/interface-inheritance-server.png differ diff --git a/documentation/18.11/solutions/_images/interface-inheritance-server.png.data b/documentation/18.11/solutions/_images/interface-inheritance-server.png.data new file mode 100644 index 00000000..e38e78b9 --- /dev/null +++ b/documentation/18.11/solutions/_images/interface-inheritance-server.png.data @@ -0,0 +1,3 @@ +title=interface-inheritance-server +author=admin +path=content/interface-inheritance-server diff --git a/documentation/18.11/solutions/_images/interface-inheritance.png b/documentation/18.11/solutions/_images/interface-inheritance.png new file mode 100644 index 00000000..6694a7b5 Binary files /dev/null and b/documentation/18.11/solutions/_images/interface-inheritance.png differ diff --git a/documentation/18.11/solutions/_images/interface-inheritance.png.data b/documentation/18.11/solutions/_images/interface-inheritance.png.data new file mode 100644 index 00000000..54a9f1e7 --- /dev/null +++ b/documentation/18.11/solutions/_images/interface-inheritance.png.data @@ -0,0 +1,3 @@ +title=interface-inheritance +author=admin +path=content/interface-inheritance diff --git a/documentation/18.11/solutions/_images/introduction.png b/documentation/18.11/solutions/_images/introduction.png new file mode 100644 index 00000000..63c75341 Binary files /dev/null and b/documentation/18.11/solutions/_images/introduction.png differ diff --git a/documentation/18.11/solutions/_images/introduction.png.data b/documentation/18.11/solutions/_images/introduction.png.data new file mode 100644 index 00000000..8d221f19 --- /dev/null +++ b/documentation/18.11/solutions/_images/introduction.png.data @@ -0,0 +1,3 @@ +title=introduction +author=admin +path=content/introduction diff --git a/documentation/18.11/solutions/_images/layout-constructor-locked.png b/documentation/18.11/solutions/_images/layout-constructor-locked.png new file mode 100644 index 00000000..dafe1fd9 Binary files /dev/null and b/documentation/18.11/solutions/_images/layout-constructor-locked.png differ diff --git a/documentation/18.11/solutions/_images/layout-constructor-locked.png.data b/documentation/18.11/solutions/_images/layout-constructor-locked.png.data new file mode 100644 index 00000000..cc9c0342 --- /dev/null +++ b/documentation/18.11/solutions/_images/layout-constructor-locked.png.data @@ -0,0 +1,3 @@ +title=layout-constructor-locked +author=admin +path=content/layout-constructor-locked diff --git a/documentation/18.11/solutions/_images/layout-constructor.png b/documentation/18.11/solutions/_images/layout-constructor.png new file mode 100644 index 00000000..3d059143 Binary files /dev/null and b/documentation/18.11/solutions/_images/layout-constructor.png differ diff --git a/documentation/18.11/solutions/_images/layout-constructor.png.data b/documentation/18.11/solutions/_images/layout-constructor.png.data new file mode 100644 index 00000000..20c4c245 --- /dev/null +++ b/documentation/18.11/solutions/_images/layout-constructor.png.data @@ -0,0 +1,3 @@ +title=layout-constructor +author=admin +path=content/layout-constructor diff --git a/documentation/18.11/solutions/_images/linear.png b/documentation/18.11/solutions/_images/linear.png new file mode 100644 index 00000000..686b5a76 Binary files /dev/null and b/documentation/18.11/solutions/_images/linear.png differ diff --git a/documentation/18.11/solutions/_images/linear.png.data b/documentation/18.11/solutions/_images/linear.png.data new file mode 100644 index 00000000..65c26c53 --- /dev/null +++ b/documentation/18.11/solutions/_images/linear.png.data @@ -0,0 +1,3 @@ +title=linear +author=admin +path=content/linear diff --git a/documentation/18.11/solutions/_images/linked-list.png b/documentation/18.11/solutions/_images/linked-list.png new file mode 100644 index 00000000..b59efa38 Binary files /dev/null and b/documentation/18.11/solutions/_images/linked-list.png differ diff --git a/documentation/18.11/solutions/_images/linked-list.png.data b/documentation/18.11/solutions/_images/linked-list.png.data new file mode 100644 index 00000000..1a34fafd --- /dev/null +++ b/documentation/18.11/solutions/_images/linked-list.png.data @@ -0,0 +1,3 @@ +title=linked-list +author=admin +path=content/linked-list diff --git a/documentation/18.11/solutions/_images/list-view.png b/documentation/18.11/solutions/_images/list-view.png new file mode 100644 index 00000000..2fb59487 Binary files /dev/null and b/documentation/18.11/solutions/_images/list-view.png differ diff --git a/documentation/18.11/solutions/_images/list-view.png.data b/documentation/18.11/solutions/_images/list-view.png.data new file mode 100644 index 00000000..65ab23e2 --- /dev/null +++ b/documentation/18.11/solutions/_images/list-view.png.data @@ -0,0 +1,3 @@ +title=list-view +author=admin +path=content/list-view diff --git a/documentation/18.11/solutions/_images/magnify.png b/documentation/18.11/solutions/_images/magnify.png new file mode 100644 index 00000000..1a3f2e0a Binary files /dev/null and b/documentation/18.11/solutions/_images/magnify.png differ diff --git a/documentation/18.11/solutions/_images/magnify.png.data b/documentation/18.11/solutions/_images/magnify.png.data new file mode 100644 index 00000000..81e2406b --- /dev/null +++ b/documentation/18.11/solutions/_images/magnify.png.data @@ -0,0 +1,3 @@ +title=magnify +author=admin +path=content/magnify diff --git a/documentation/18.11/solutions/_images/main-window-with-docked-tools.png b/documentation/18.11/solutions/_images/main-window-with-docked-tools.png new file mode 100644 index 00000000..4d5c7abd Binary files /dev/null and b/documentation/18.11/solutions/_images/main-window-with-docked-tools.png differ diff --git a/documentation/18.11/solutions/_images/main-window-with-docked-tools.png.data b/documentation/18.11/solutions/_images/main-window-with-docked-tools.png.data new file mode 100644 index 00000000..d9d01722 --- /dev/null +++ b/documentation/18.11/solutions/_images/main-window-with-docked-tools.png.data @@ -0,0 +1,3 @@ +title=main-window-with-docked-tools +author=admin +path=content/main-window-docked-tools diff --git a/documentation/18.11/solutions/_images/main-window.png b/documentation/18.11/solutions/_images/main-window.png new file mode 100644 index 00000000..40fe5d97 Binary files /dev/null and b/documentation/18.11/solutions/_images/main-window.png differ diff --git a/documentation/18.11/solutions/_images/main-window.png.data b/documentation/18.11/solutions/_images/main-window.png.data new file mode 100644 index 00000000..fa8c5401 --- /dev/null +++ b/documentation/18.11/solutions/_images/main-window.png.data @@ -0,0 +1,3 @@ +title=main-window +author=admin +path=content/main-window diff --git a/documentation/18.11/solutions/_images/mdi--mdi.png b/documentation/18.11/solutions/_images/mdi--mdi.png new file mode 100644 index 00000000..72990721 Binary files /dev/null and b/documentation/18.11/solutions/_images/mdi--mdi.png differ diff --git a/documentation/18.11/solutions/_images/mdi--mdi.png.data b/documentation/18.11/solutions/_images/mdi--mdi.png.data new file mode 100644 index 00000000..a66ed60c --- /dev/null +++ b/documentation/18.11/solutions/_images/mdi--mdi.png.data @@ -0,0 +1,3 @@ +title=mdi--mdi +author=admin +path=content/mdi-mdi diff --git a/documentation/18.11/solutions/_images/mdi.png b/documentation/18.11/solutions/_images/mdi.png new file mode 100644 index 00000000..4b57a0b5 Binary files /dev/null and b/documentation/18.11/solutions/_images/mdi.png differ diff --git a/documentation/18.11/solutions/_images/mdi.png.data b/documentation/18.11/solutions/_images/mdi.png.data new file mode 100644 index 00000000..96c4efe1 --- /dev/null +++ b/documentation/18.11/solutions/_images/mdi.png.data @@ -0,0 +1,3 @@ +title=mdi +author=admin +path=content/mdi diff --git a/documentation/18.11/solutions/_images/menu-contextuel.png b/documentation/18.11/solutions/_images/menu-contextuel.png new file mode 100644 index 00000000..4211f3b9 Binary files /dev/null and b/documentation/18.11/solutions/_images/menu-contextuel.png differ diff --git a/documentation/18.11/solutions/_images/menu-contextuel.png.data b/documentation/18.11/solutions/_images/menu-contextuel.png.data new file mode 100644 index 00000000..183ab65c --- /dev/null +++ b/documentation/18.11/solutions/_images/menu-contextuel.png.data @@ -0,0 +1,3 @@ +title=menu-contextuel +author=admin +path=content/menu-contextuel diff --git a/documentation/18.11/solutions/_images/menu-principal.png b/documentation/18.11/solutions/_images/menu-principal.png new file mode 100644 index 00000000..c09b209d Binary files /dev/null and b/documentation/18.11/solutions/_images/menu-principal.png differ diff --git a/documentation/18.11/solutions/_images/menu-principal.png.data b/documentation/18.11/solutions/_images/menu-principal.png.data new file mode 100644 index 00000000..3b9cc3cd --- /dev/null +++ b/documentation/18.11/solutions/_images/menu-principal.png.data @@ -0,0 +1,3 @@ +title=menu-principal +author=admin +path=content/menu-principal diff --git a/documentation/18.11/solutions/_images/menus.png b/documentation/18.11/solutions/_images/menus.png new file mode 100644 index 00000000..c29b88de Binary files /dev/null and b/documentation/18.11/solutions/_images/menus.png differ diff --git a/documentation/18.11/solutions/_images/menus.png.data b/documentation/18.11/solutions/_images/menus.png.data new file mode 100644 index 00000000..a2273820 --- /dev/null +++ b/documentation/18.11/solutions/_images/menus.png.data @@ -0,0 +1,3 @@ +title=menus +author=admin +path=content/menus diff --git a/documentation/18.11/solutions/_images/message-box.png b/documentation/18.11/solutions/_images/message-box.png new file mode 100644 index 00000000..1fe9d13a Binary files /dev/null and b/documentation/18.11/solutions/_images/message-box.png differ diff --git a/documentation/18.11/solutions/_images/message-box.png.data b/documentation/18.11/solutions/_images/message-box.png.data new file mode 100644 index 00000000..fe44507d --- /dev/null +++ b/documentation/18.11/solutions/_images/message-box.png.data @@ -0,0 +1,3 @@ +title=message-box +author=admin +path=content/message-box diff --git a/documentation/18.11/solutions/_images/minimal.png b/documentation/18.11/solutions/_images/minimal.png new file mode 100644 index 00000000..3957f6a2 Binary files /dev/null and b/documentation/18.11/solutions/_images/minimal.png differ diff --git a/documentation/18.11/solutions/_images/minimal.png.data b/documentation/18.11/solutions/_images/minimal.png.data new file mode 100644 index 00000000..39874485 --- /dev/null +++ b/documentation/18.11/solutions/_images/minimal.png.data @@ -0,0 +1,3 @@ +title=minimal +author=admin +path=content/minimal diff --git a/documentation/18.11/solutions/_images/model-view-relationship.png b/documentation/18.11/solutions/_images/model-view-relationship.png new file mode 100644 index 00000000..27eae8cf Binary files /dev/null and b/documentation/18.11/solutions/_images/model-view-relationship.png differ diff --git a/documentation/18.11/solutions/_images/model-view-relationship.png.data b/documentation/18.11/solutions/_images/model-view-relationship.png.data new file mode 100644 index 00000000..84e8b02e --- /dev/null +++ b/documentation/18.11/solutions/_images/model-view-relationship.png.data @@ -0,0 +1,3 @@ +title=model-view-relationship +author=admin +path=content/model-view-relationship diff --git a/documentation/18.11/solutions/_images/new-directory-dialog.png b/documentation/18.11/solutions/_images/new-directory-dialog.png new file mode 100644 index 00000000..79faf8a5 Binary files /dev/null and b/documentation/18.11/solutions/_images/new-directory-dialog.png differ diff --git a/documentation/18.11/solutions/_images/new-directory-dialog.png.data b/documentation/18.11/solutions/_images/new-directory-dialog.png.data new file mode 100644 index 00000000..1c35e7b0 --- /dev/null +++ b/documentation/18.11/solutions/_images/new-directory-dialog.png.data @@ -0,0 +1,3 @@ +title=new-directory-dialog +author=admin +path=content/new-directory-dialog diff --git a/documentation/18.11/solutions/_images/new-project.png b/documentation/18.11/solutions/_images/new-project.png new file mode 100644 index 00000000..ef39da5b Binary files /dev/null and b/documentation/18.11/solutions/_images/new-project.png differ diff --git a/documentation/18.11/solutions/_images/new-project.png.data b/documentation/18.11/solutions/_images/new-project.png.data new file mode 100644 index 00000000..d4b0fcce --- /dev/null +++ b/documentation/18.11/solutions/_images/new-project.png.data @@ -0,0 +1,3 @@ +title=new-project +author=admin +path=content/new-project diff --git a/documentation/18.11/solutions/_images/object-editor.png b/documentation/18.11/solutions/_images/object-editor.png new file mode 100644 index 00000000..1795dd7a Binary files /dev/null and b/documentation/18.11/solutions/_images/object-editor.png differ diff --git a/documentation/18.11/solutions/_images/object-editor.png.data b/documentation/18.11/solutions/_images/object-editor.png.data new file mode 100644 index 00000000..31f4c07b --- /dev/null +++ b/documentation/18.11/solutions/_images/object-editor.png.data @@ -0,0 +1,3 @@ +title=object-editor +author=admin +path=content/object-editor diff --git a/documentation/18.11/solutions/_images/object_graph.png b/documentation/18.11/solutions/_images/object_graph.png new file mode 100644 index 00000000..f32608d0 Binary files /dev/null and b/documentation/18.11/solutions/_images/object_graph.png differ diff --git a/documentation/18.11/solutions/_images/object_graph.png.data b/documentation/18.11/solutions/_images/object_graph.png.data new file mode 100644 index 00000000..47d96df3 --- /dev/null +++ b/documentation/18.11/solutions/_images/object_graph.png.data @@ -0,0 +1,3 @@ +title=Child object graph +author=Roman +path=content/child-object-graph diff --git a/documentation/18.11/solutions/_images/open-project.png b/documentation/18.11/solutions/_images/open-project.png new file mode 100644 index 00000000..5851e5a6 Binary files /dev/null and b/documentation/18.11/solutions/_images/open-project.png differ diff --git a/documentation/18.11/solutions/_images/open-project.png.data b/documentation/18.11/solutions/_images/open-project.png.data new file mode 100644 index 00000000..88beba32 --- /dev/null +++ b/documentation/18.11/solutions/_images/open-project.png.data @@ -0,0 +1,3 @@ +title=open-project +author=admin +path=content/open-project diff --git a/documentation/18.11/solutions/_images/overwrite-project.png b/documentation/18.11/solutions/_images/overwrite-project.png new file mode 100644 index 00000000..f0f27c51 Binary files /dev/null and b/documentation/18.11/solutions/_images/overwrite-project.png differ diff --git a/documentation/18.11/solutions/_images/overwrite-project.png.data b/documentation/18.11/solutions/_images/overwrite-project.png.data new file mode 100644 index 00000000..78980593 --- /dev/null +++ b/documentation/18.11/solutions/_images/overwrite-project.png.data @@ -0,0 +1,3 @@ +title=overwrite-project +author=admin +path=content/overwrite-project diff --git a/documentation/18.11/solutions/_images/pixmap-selection-dialog.png b/documentation/18.11/solutions/_images/pixmap-selection-dialog.png new file mode 100644 index 00000000..76cd2b9d Binary files /dev/null and b/documentation/18.11/solutions/_images/pixmap-selection-dialog.png differ diff --git a/documentation/18.11/solutions/_images/pixmap-selection-dialog.png.data b/documentation/18.11/solutions/_images/pixmap-selection-dialog.png.data new file mode 100644 index 00000000..a41d3aae --- /dev/null +++ b/documentation/18.11/solutions/_images/pixmap-selection-dialog.png.data @@ -0,0 +1,3 @@ +title=pixmap-selection-dialog +author=admin +path=content/pixmap-selection-dialog diff --git a/documentation/18.11/solutions/_images/pizza.png b/documentation/18.11/solutions/_images/pizza.png new file mode 100644 index 00000000..2287892d Binary files /dev/null and b/documentation/18.11/solutions/_images/pizza.png differ diff --git a/documentation/18.11/solutions/_images/pizza.png.data b/documentation/18.11/solutions/_images/pizza.png.data new file mode 100644 index 00000000..d0ef274e --- /dev/null +++ b/documentation/18.11/solutions/_images/pizza.png.data @@ -0,0 +1,3 @@ +title=pizza +author=admin +path=content/pizza diff --git a/documentation/18.11/solutions/_images/pref_dialog.png b/documentation/18.11/solutions/_images/pref_dialog.png new file mode 100644 index 00000000..9b9c13ce Binary files /dev/null and b/documentation/18.11/solutions/_images/pref_dialog.png differ diff --git a/documentation/18.11/solutions/_images/pref_dialog.png.data b/documentation/18.11/solutions/_images/pref_dialog.png.data new file mode 100644 index 00000000..d109f9ea --- /dev/null +++ b/documentation/18.11/solutions/_images/pref_dialog.png.data @@ -0,0 +1,3 @@ +title=preference-window +author=admin +path=content/preference-window diff --git a/documentation/18.11/solutions/_images/preferences-dialog.png b/documentation/18.11/solutions/_images/preferences-dialog.png new file mode 100644 index 00000000..d6f0c799 Binary files /dev/null and b/documentation/18.11/solutions/_images/preferences-dialog.png differ diff --git a/documentation/18.11/solutions/_images/preferences-dialog.png.data b/documentation/18.11/solutions/_images/preferences-dialog.png.data new file mode 100644 index 00000000..258e4816 --- /dev/null +++ b/documentation/18.11/solutions/_images/preferences-dialog.png.data @@ -0,0 +1,3 @@ +title=preferences-dialog +author=admin +path=content/preferences-dialog diff --git a/documentation/18.11/solutions/_images/prepro.png b/documentation/18.11/solutions/_images/prepro.png new file mode 100644 index 00000000..0eb234c6 Binary files /dev/null and b/documentation/18.11/solutions/_images/prepro.png differ diff --git a/documentation/18.11/solutions/_images/prepro.png.data b/documentation/18.11/solutions/_images/prepro.png.data new file mode 100644 index 00000000..affb296a --- /dev/null +++ b/documentation/18.11/solutions/_images/prepro.png.data @@ -0,0 +1,3 @@ +title=prepro +author=admin +path=content/prepro diff --git a/documentation/18.11/solutions/_images/printer.png b/documentation/18.11/solutions/_images/printer.png new file mode 100644 index 00000000..6eaad697 Binary files /dev/null and b/documentation/18.11/solutions/_images/printer.png differ diff --git a/documentation/18.11/solutions/_images/printer.png.data b/documentation/18.11/solutions/_images/printer.png.data new file mode 100644 index 00000000..6d113831 --- /dev/null +++ b/documentation/18.11/solutions/_images/printer.png.data @@ -0,0 +1,3 @@ +title=printer +author=admin +path=content/printer diff --git a/documentation/18.11/solutions/_images/progress-bar.png b/documentation/18.11/solutions/_images/progress-bar.png new file mode 100644 index 00000000..88ed85b6 Binary files /dev/null and b/documentation/18.11/solutions/_images/progress-bar.png differ diff --git a/documentation/18.11/solutions/_images/progress-bar.png.data b/documentation/18.11/solutions/_images/progress-bar.png.data new file mode 100644 index 00000000..35621362 --- /dev/null +++ b/documentation/18.11/solutions/_images/progress-bar.png.data @@ -0,0 +1,3 @@ +title=progress-bar +author=admin +path=content/progress-bar diff --git a/documentation/18.11/solutions/_images/project-build-class.png b/documentation/18.11/solutions/_images/project-build-class.png new file mode 100644 index 00000000..10ac688d Binary files /dev/null and b/documentation/18.11/solutions/_images/project-build-class.png differ diff --git a/documentation/18.11/solutions/_images/project-build-class.png.data b/documentation/18.11/solutions/_images/project-build-class.png.data new file mode 100644 index 00000000..d3698981 --- /dev/null +++ b/documentation/18.11/solutions/_images/project-build-class.png.data @@ -0,0 +1,3 @@ +title=project-build-class +author=admin +path=content/project-build-class diff --git a/documentation/18.11/solutions/_images/project-build.png b/documentation/18.11/solutions/_images/project-build.png new file mode 100644 index 00000000..a90a56e3 Binary files /dev/null and b/documentation/18.11/solutions/_images/project-build.png differ diff --git a/documentation/18.11/solutions/_images/project-build.png.data b/documentation/18.11/solutions/_images/project-build.png.data new file mode 100644 index 00000000..81c6a35d --- /dev/null +++ b/documentation/18.11/solutions/_images/project-build.png.data @@ -0,0 +1,3 @@ +title=project-build +author=admin +path=content/project-build diff --git a/documentation/18.11/solutions/_images/project-generation.png b/documentation/18.11/solutions/_images/project-generation.png new file mode 100644 index 00000000..78d5c54a Binary files /dev/null and b/documentation/18.11/solutions/_images/project-generation.png differ diff --git a/documentation/18.11/solutions/_images/project-generation.png.data b/documentation/18.11/solutions/_images/project-generation.png.data new file mode 100644 index 00000000..6568bb65 --- /dev/null +++ b/documentation/18.11/solutions/_images/project-generation.png.data @@ -0,0 +1,3 @@ +title=project-generation +author=admin +path=content/project-generation diff --git a/documentation/18.11/solutions/_images/rb.png b/documentation/18.11/solutions/_images/rb.png new file mode 100644 index 00000000..05ad873a Binary files /dev/null and b/documentation/18.11/solutions/_images/rb.png differ diff --git a/documentation/18.11/solutions/_images/rb.png.data b/documentation/18.11/solutions/_images/rb.png.data new file mode 100644 index 00000000..07532eb8 --- /dev/null +++ b/documentation/18.11/solutions/_images/rb.png.data @@ -0,0 +1,3 @@ +title=rb +author=admin +path=content/rb diff --git a/documentation/18.11/solutions/_images/recent-projects.png b/documentation/18.11/solutions/_images/recent-projects.png new file mode 100644 index 00000000..e942b587 Binary files /dev/null and b/documentation/18.11/solutions/_images/recent-projects.png differ diff --git a/documentation/18.11/solutions/_images/recent-projects.png.data b/documentation/18.11/solutions/_images/recent-projects.png.data new file mode 100644 index 00000000..12e30749 --- /dev/null +++ b/documentation/18.11/solutions/_images/recent-projects.png.data @@ -0,0 +1,3 @@ +title=recent-projects +author=admin +path=content/recent-projects diff --git a/documentation/18.11/solutions/_images/retriev.png b/documentation/18.11/solutions/_images/retriev.png new file mode 100644 index 00000000..1713d73d Binary files /dev/null and b/documentation/18.11/solutions/_images/retriev.png differ diff --git a/documentation/18.11/solutions/_images/retriev.png.data b/documentation/18.11/solutions/_images/retriev.png.data new file mode 100644 index 00000000..f9bd82ff --- /dev/null +++ b/documentation/18.11/solutions/_images/retriev.png.data @@ -0,0 +1,3 @@ +title=retriev +author=admin +path=content/retriev diff --git a/documentation/18.11/solutions/_images/richedit.png b/documentation/18.11/solutions/_images/richedit.png new file mode 100644 index 00000000..bd9ddc59 Binary files /dev/null and b/documentation/18.11/solutions/_images/richedit.png differ diff --git a/documentation/18.11/solutions/_images/richedit.png.data b/documentation/18.11/solutions/_images/richedit.png.data new file mode 100644 index 00000000..0d3d1573 --- /dev/null +++ b/documentation/18.11/solutions/_images/richedit.png.data @@ -0,0 +1,3 @@ +title=richedit +author=admin +path=content/richedit diff --git a/documentation/18.11/solutions/_images/scoop-regions.png b/documentation/18.11/solutions/_images/scoop-regions.png new file mode 100644 index 00000000..25d233a0 Binary files /dev/null and b/documentation/18.11/solutions/_images/scoop-regions.png differ diff --git a/documentation/18.11/solutions/_images/scoop-regions.png.data b/documentation/18.11/solutions/_images/scoop-regions.png.data new file mode 100644 index 00000000..c4add29f --- /dev/null +++ b/documentation/18.11/solutions/_images/scoop-regions.png.data @@ -0,0 +1,3 @@ +title=SCOOP Regions +text=The memory of a SCOOP program, splitted into regions. +path=content/scoop-regions diff --git a/documentation/18.11/solutions/_images/simple-data-binding.png b/documentation/18.11/solutions/_images/simple-data-binding.png new file mode 100644 index 00000000..4a789806 Binary files /dev/null and b/documentation/18.11/solutions/_images/simple-data-binding.png differ diff --git a/documentation/18.11/solutions/_images/simple-data-binding.png.data b/documentation/18.11/solutions/_images/simple-data-binding.png.data new file mode 100644 index 00000000..89d6b3be --- /dev/null +++ b/documentation/18.11/solutions/_images/simple-data-binding.png.data @@ -0,0 +1,3 @@ +title=simple-data-binding +author=admin +path=content/simple-data-binding diff --git a/documentation/18.11/solutions/_images/simple-hello-world.png b/documentation/18.11/solutions/_images/simple-hello-world.png new file mode 100644 index 00000000..43a33ecd Binary files /dev/null and b/documentation/18.11/solutions/_images/simple-hello-world.png differ diff --git a/documentation/18.11/solutions/_images/simple-hello-world.png.data b/documentation/18.11/solutions/_images/simple-hello-world.png.data new file mode 100644 index 00000000..54d33a69 --- /dev/null +++ b/documentation/18.11/solutions/_images/simple-hello-world.png.data @@ -0,0 +1,3 @@ +title=simple-hello-world +author=admin +path=content/simple-hello-world diff --git a/documentation/18.11/solutions/_images/splitarea.png b/documentation/18.11/solutions/_images/splitarea.png new file mode 100644 index 00000000..6b35f0c0 Binary files /dev/null and b/documentation/18.11/solutions/_images/splitarea.png differ diff --git a/documentation/18.11/solutions/_images/splitarea.png.data b/documentation/18.11/solutions/_images/splitarea.png.data new file mode 100644 index 00000000..b8388fd9 --- /dev/null +++ b/documentation/18.11/solutions/_images/splitarea.png.data @@ -0,0 +1,3 @@ +title=splitarea +author=admin +path=content/splitarea diff --git a/documentation/18.11/solutions/_images/standard-dialogs.png b/documentation/18.11/solutions/_images/standard-dialogs.png new file mode 100644 index 00000000..4fe2a56b Binary files /dev/null and b/documentation/18.11/solutions/_images/standard-dialogs.png differ diff --git a/documentation/18.11/solutions/_images/standard-dialogs.png.data b/documentation/18.11/solutions/_images/standard-dialogs.png.data new file mode 100644 index 00000000..c0acd918 --- /dev/null +++ b/documentation/18.11/solutions/_images/standard-dialogs.png.data @@ -0,0 +1,3 @@ +title=standard-dialogs +author=admin +path=content/standard-dialogs diff --git a/documentation/18.11/solutions/_images/stddlgs.png b/documentation/18.11/solutions/_images/stddlgs.png new file mode 100644 index 00000000..e5e49c23 Binary files /dev/null and b/documentation/18.11/solutions/_images/stddlgs.png differ diff --git a/documentation/18.11/solutions/_images/stddlgs.png.data b/documentation/18.11/solutions/_images/stddlgs.png.data new file mode 100644 index 00000000..e7bdfd69 --- /dev/null +++ b/documentation/18.11/solutions/_images/stddlgs.png.data @@ -0,0 +1,3 @@ +title=stddlgs +author=admin +path=content/stddlgs diff --git a/documentation/18.11/solutions/_images/step1.png b/documentation/18.11/solutions/_images/step1.png new file mode 100644 index 00000000..d02b5444 Binary files /dev/null and b/documentation/18.11/solutions/_images/step1.png differ diff --git a/documentation/18.11/solutions/_images/step1.png.data b/documentation/18.11/solutions/_images/step1.png.data new file mode 100644 index 00000000..287a258a --- /dev/null +++ b/documentation/18.11/solutions/_images/step1.png.data @@ -0,0 +1,3 @@ +title=step1 +author=admin +path=content/step1 diff --git a/documentation/18.11/solutions/_images/step2.png b/documentation/18.11/solutions/_images/step2.png new file mode 100644 index 00000000..932183e9 Binary files /dev/null and b/documentation/18.11/solutions/_images/step2.png differ diff --git a/documentation/18.11/solutions/_images/step2.png.data b/documentation/18.11/solutions/_images/step2.png.data new file mode 100644 index 00000000..eca33337 --- /dev/null +++ b/documentation/18.11/solutions/_images/step2.png.data @@ -0,0 +1,3 @@ +title=step2 +author=admin +path=content/step2 diff --git a/documentation/18.11/solutions/_images/step3.png b/documentation/18.11/solutions/_images/step3.png new file mode 100644 index 00000000..222f0647 Binary files /dev/null and b/documentation/18.11/solutions/_images/step3.png differ diff --git a/documentation/18.11/solutions/_images/step3.png.data b/documentation/18.11/solutions/_images/step3.png.data new file mode 100644 index 00000000..b368f56d --- /dev/null +++ b/documentation/18.11/solutions/_images/step3.png.data @@ -0,0 +1,3 @@ +title=step3 +author=admin +path=content/step3 diff --git a/documentation/18.11/solutions/_images/step4.png b/documentation/18.11/solutions/_images/step4.png new file mode 100644 index 00000000..f86757cf Binary files /dev/null and b/documentation/18.11/solutions/_images/step4.png differ diff --git a/documentation/18.11/solutions/_images/step4.png.data b/documentation/18.11/solutions/_images/step4.png.data new file mode 100644 index 00000000..3d096e5c --- /dev/null +++ b/documentation/18.11/solutions/_images/step4.png.data @@ -0,0 +1,3 @@ +title=step4 +author=admin +path=content/step4 diff --git a/documentation/18.11/solutions/_images/step5.png b/documentation/18.11/solutions/_images/step5.png new file mode 100644 index 00000000..7c88ff1f Binary files /dev/null and b/documentation/18.11/solutions/_images/step5.png differ diff --git a/documentation/18.11/solutions/_images/step5.png.data b/documentation/18.11/solutions/_images/step5.png.data new file mode 100644 index 00000000..00048118 --- /dev/null +++ b/documentation/18.11/solutions/_images/step5.png.data @@ -0,0 +1,3 @@ +title=step5 +author=admin +path=content/step5 diff --git a/documentation/18.11/solutions/_images/step6.png b/documentation/18.11/solutions/_images/step6.png new file mode 100644 index 00000000..dea8c699 Binary files /dev/null and b/documentation/18.11/solutions/_images/step6.png differ diff --git a/documentation/18.11/solutions/_images/step6.png.data b/documentation/18.11/solutions/_images/step6.png.data new file mode 100644 index 00000000..53c08488 --- /dev/null +++ b/documentation/18.11/solutions/_images/step6.png.data @@ -0,0 +1,3 @@ +title=step6 +author=admin +path=content/step6 diff --git a/documentation/18.11/solutions/_images/step7.png b/documentation/18.11/solutions/_images/step7.png new file mode 100644 index 00000000..bc410f89 Binary files /dev/null and b/documentation/18.11/solutions/_images/step7.png differ diff --git a/documentation/18.11/solutions/_images/step7.png.data b/documentation/18.11/solutions/_images/step7.png.data new file mode 100644 index 00000000..ea7eb899 --- /dev/null +++ b/documentation/18.11/solutions/_images/step7.png.data @@ -0,0 +1,3 @@ +title=step7 +author=admin +path=content/step7 diff --git a/documentation/18.11/solutions/_images/step8.png b/documentation/18.11/solutions/_images/step8.png new file mode 100644 index 00000000..7737a6be Binary files /dev/null and b/documentation/18.11/solutions/_images/step8.png differ diff --git a/documentation/18.11/solutions/_images/step8.png.data b/documentation/18.11/solutions/_images/step8.png.data new file mode 100644 index 00000000..166ef5ed --- /dev/null +++ b/documentation/18.11/solutions/_images/step8.png.data @@ -0,0 +1,3 @@ +title=step8 +author=admin +path=content/step8 diff --git a/documentation/18.11/solutions/_images/strings.png b/documentation/18.11/solutions/_images/strings.png new file mode 100644 index 00000000..43a7c3ac Binary files /dev/null and b/documentation/18.11/solutions/_images/strings.png differ diff --git a/documentation/18.11/solutions/_images/strings.png.data b/documentation/18.11/solutions/_images/strings.png.data new file mode 100644 index 00000000..53a7ce2b --- /dev/null +++ b/documentation/18.11/solutions/_images/strings.png.data @@ -0,0 +1,3 @@ +title=strings +author=admin +path=content/strings diff --git a/documentation/18.11/solutions/_images/sub-component-objects.png b/documentation/18.11/solutions/_images/sub-component-objects.png new file mode 100644 index 00000000..271ee22d Binary files /dev/null and b/documentation/18.11/solutions/_images/sub-component-objects.png differ diff --git a/documentation/18.11/solutions/_images/sub-component-objects.png.data b/documentation/18.11/solutions/_images/sub-component-objects.png.data new file mode 100644 index 00000000..401e4f92 --- /dev/null +++ b/documentation/18.11/solutions/_images/sub-component-objects.png.data @@ -0,0 +1,3 @@ +title=sub-component-objects +author=admin +path=content/sub-component-objects diff --git a/documentation/18.11/solutions/_images/table-child-positioner.png b/documentation/18.11/solutions/_images/table-child-positioner.png new file mode 100644 index 00000000..c5a26ae5 Binary files /dev/null and b/documentation/18.11/solutions/_images/table-child-positioner.png differ diff --git a/documentation/18.11/solutions/_images/table-child-positioner.png.data b/documentation/18.11/solutions/_images/table-child-positioner.png.data new file mode 100644 index 00000000..5bf536e6 --- /dev/null +++ b/documentation/18.11/solutions/_images/table-child-positioner.png.data @@ -0,0 +1,3 @@ +title=table-child-positioner +author=admin +path=content/table-child-positioner diff --git a/documentation/18.11/solutions/_images/table-descr-access-objects.png b/documentation/18.11/solutions/_images/table-descr-access-objects.png new file mode 100644 index 00000000..ed4f5778 Binary files /dev/null and b/documentation/18.11/solutions/_images/table-descr-access-objects.png differ diff --git a/documentation/18.11/solutions/_images/table-descr-access-objects.png.data b/documentation/18.11/solutions/_images/table-descr-access-objects.png.data new file mode 100644 index 00000000..7d61015b --- /dev/null +++ b/documentation/18.11/solutions/_images/table-descr-access-objects.png.data @@ -0,0 +1,3 @@ +title=table-descr-access-objects +author=admin +path=content/table-descr-access-objects diff --git a/documentation/18.11/solutions/_images/table-descr-objects.png b/documentation/18.11/solutions/_images/table-descr-objects.png new file mode 100644 index 00000000..5a180331 Binary files /dev/null and b/documentation/18.11/solutions/_images/table-descr-objects.png differ diff --git a/documentation/18.11/solutions/_images/table-descr-objects.png.data b/documentation/18.11/solutions/_images/table-descr-objects.png.data new file mode 100644 index 00000000..0c1776dc --- /dev/null +++ b/documentation/18.11/solutions/_images/table-descr-objects.png.data @@ -0,0 +1,3 @@ +title=table-descr-objects +author=admin +path=content/table-descr-objects diff --git a/documentation/18.11/solutions/_images/table-objects-associations.png b/documentation/18.11/solutions/_images/table-objects-associations.png new file mode 100644 index 00000000..2d658448 Binary files /dev/null and b/documentation/18.11/solutions/_images/table-objects-associations.png differ diff --git a/documentation/18.11/solutions/_images/table-objects-associations.png.data b/documentation/18.11/solutions/_images/table-objects-associations.png.data new file mode 100644 index 00000000..9530e765 --- /dev/null +++ b/documentation/18.11/solutions/_images/table-objects-associations.png.data @@ -0,0 +1,3 @@ +title=table-objects-associations +author=admin +path=content/table-objects-associations diff --git a/documentation/18.11/solutions/_images/tables-access-inherit.png b/documentation/18.11/solutions/_images/tables-access-inherit.png new file mode 100644 index 00000000..a8b27008 Binary files /dev/null and b/documentation/18.11/solutions/_images/tables-access-inherit.png differ diff --git a/documentation/18.11/solutions/_images/tables-access-inherit.png.data b/documentation/18.11/solutions/_images/tables-access-inherit.png.data new file mode 100644 index 00000000..ccf516f8 --- /dev/null +++ b/documentation/18.11/solutions/_images/tables-access-inherit.png.data @@ -0,0 +1,3 @@ +title=tables-access-inherit +author=admin +path=content/tables-access-inherit diff --git a/documentation/18.11/solutions/_images/text.png b/documentation/18.11/solutions/_images/text.png new file mode 100644 index 00000000..3b25bc18 Binary files /dev/null and b/documentation/18.11/solutions/_images/text.png differ diff --git a/documentation/18.11/solutions/_images/text.png.data b/documentation/18.11/solutions/_images/text.png.data new file mode 100644 index 00000000..f1379c1e --- /dev/null +++ b/documentation/18.11/solutions/_images/text.png.data @@ -0,0 +1,3 @@ +title=text +author=admin +path=content/text diff --git a/documentation/18.11/solutions/_images/timer.png b/documentation/18.11/solutions/_images/timer.png new file mode 100644 index 00000000..1b9562f0 Binary files /dev/null and b/documentation/18.11/solutions/_images/timer.png differ diff --git a/documentation/18.11/solutions/_images/timer.png.data b/documentation/18.11/solutions/_images/timer.png.data new file mode 100644 index 00000000..209e04d7 --- /dev/null +++ b/documentation/18.11/solutions/_images/timer.png.data @@ -0,0 +1,3 @@ +title=timer +author=admin +path=content/timer diff --git a/documentation/18.11/solutions/_images/toolbar.png b/documentation/18.11/solutions/_images/toolbar.png new file mode 100644 index 00000000..1244d142 Binary files /dev/null and b/documentation/18.11/solutions/_images/toolbar.png differ diff --git a/documentation/18.11/solutions/_images/toolbar.png.data b/documentation/18.11/solutions/_images/toolbar.png.data new file mode 100644 index 00000000..184ecdd5 --- /dev/null +++ b/documentation/18.11/solutions/_images/toolbar.png.data @@ -0,0 +1,3 @@ +title=toolbar +author=admin +path=content/toolbar diff --git a/documentation/18.11/solutions/_images/tree-view--tree-view.png b/documentation/18.11/solutions/_images/tree-view--tree-view.png new file mode 100644 index 00000000..8c26ae48 Binary files /dev/null and b/documentation/18.11/solutions/_images/tree-view--tree-view.png differ diff --git a/documentation/18.11/solutions/_images/tree-view--tree-view.png.data b/documentation/18.11/solutions/_images/tree-view--tree-view.png.data new file mode 100644 index 00000000..00a7aeb6 --- /dev/null +++ b/documentation/18.11/solutions/_images/tree-view--tree-view.png.data @@ -0,0 +1,3 @@ +title=tree-view--tree-view +author=admin +path=content/tree-view-tree-view diff --git a/documentation/18.11/solutions/_images/tree-view.png b/documentation/18.11/solutions/_images/tree-view.png new file mode 100644 index 00000000..d0741f6b Binary files /dev/null and b/documentation/18.11/solutions/_images/tree-view.png differ diff --git a/documentation/18.11/solutions/_images/tree-view.png.data b/documentation/18.11/solutions/_images/tree-view.png.data new file mode 100644 index 00000000..2f9b455c --- /dev/null +++ b/documentation/18.11/solutions/_images/tree-view.png.data @@ -0,0 +1,3 @@ +title=tree-view +author=admin +path=content/tree-view diff --git a/documentation/18.11/solutions/_images/tree.png b/documentation/18.11/solutions/_images/tree.png new file mode 100644 index 00000000..d636454d Binary files /dev/null and b/documentation/18.11/solutions/_images/tree.png differ diff --git a/documentation/18.11/solutions/_images/tree.png.data b/documentation/18.11/solutions/_images/tree.png.data new file mode 100644 index 00000000..11dbe8c1 --- /dev/null +++ b/documentation/18.11/solutions/_images/tree.png.data @@ -0,0 +1,3 @@ +title=tree +author=admin +path=content/tree diff --git a/documentation/18.11/solutions/_images/two-way-list.png b/documentation/18.11/solutions/_images/two-way-list.png new file mode 100644 index 00000000..d230b31f Binary files /dev/null and b/documentation/18.11/solutions/_images/two-way-list.png differ diff --git a/documentation/18.11/solutions/_images/two-way-list.png.data b/documentation/18.11/solutions/_images/two-way-list.png.data new file mode 100644 index 00000000..7e5dc85d --- /dev/null +++ b/documentation/18.11/solutions/_images/two-way-list.png.data @@ -0,0 +1,3 @@ +title=two-way-list +author=admin +path=content/two-way-list diff --git a/documentation/18.11/solutions/_images/unicode.png b/documentation/18.11/solutions/_images/unicode.png new file mode 100644 index 00000000..0cb201e3 Binary files /dev/null and b/documentation/18.11/solutions/_images/unicode.png differ diff --git a/documentation/18.11/solutions/_images/unicode.png.data b/documentation/18.11/solutions/_images/unicode.png.data new file mode 100644 index 00000000..4881462c --- /dev/null +++ b/documentation/18.11/solutions/_images/unicode.png.data @@ -0,0 +1,3 @@ +title=unicode +author=admin +path=content/unicode diff --git a/documentation/18.11/solutions/_images/value-chart.PNG b/documentation/18.11/solutions/_images/value-chart.PNG new file mode 100644 index 00000000..eb62e5e6 Binary files /dev/null and b/documentation/18.11/solutions/_images/value-chart.PNG differ diff --git a/documentation/18.11/solutions/_images/value-chart.PNG.data b/documentation/18.11/solutions/_images/value-chart.PNG.data new file mode 100644 index 00000000..6aff6d9e --- /dev/null +++ b/documentation/18.11/solutions/_images/value-chart.PNG.data @@ -0,0 +1,3 @@ +title=value-chart +author=admin +path=content/value-chart diff --git a/documentation/18.11/solutions/_images/viewport.png b/documentation/18.11/solutions/_images/viewport.png new file mode 100644 index 00000000..df465eef Binary files /dev/null and b/documentation/18.11/solutions/_images/viewport.png differ diff --git a/documentation/18.11/solutions/_images/viewport.png.data b/documentation/18.11/solutions/_images/viewport.png.data new file mode 100644 index 00000000..a62a92b3 --- /dev/null +++ b/documentation/18.11/solutions/_images/viewport.png.data @@ -0,0 +1,3 @@ +title=viewport +author=admin +path=content/viewport diff --git a/documentation/18.11/solutions/_images/vision2--figure1.png b/documentation/18.11/solutions/_images/vision2--figure1.png new file mode 100644 index 00000000..68e989e4 Binary files /dev/null and b/documentation/18.11/solutions/_images/vision2--figure1.png differ diff --git a/documentation/18.11/solutions/_images/vision2--figure1.png.data b/documentation/18.11/solutions/_images/vision2--figure1.png.data new file mode 100644 index 00000000..dd507a95 --- /dev/null +++ b/documentation/18.11/solutions/_images/vision2--figure1.png.data @@ -0,0 +1,3 @@ +title=vision2--figure1 +author=admin +path=content/vision2-figure1 diff --git a/documentation/18.11/solutions/_images/wel-check-box-3-state-checked.png b/documentation/18.11/solutions/_images/wel-check-box-3-state-checked.png new file mode 100644 index 00000000..0ea35c05 Binary files /dev/null and b/documentation/18.11/solutions/_images/wel-check-box-3-state-checked.png differ diff --git a/documentation/18.11/solutions/_images/wel-check-box-3-state-checked.png.data b/documentation/18.11/solutions/_images/wel-check-box-3-state-checked.png.data new file mode 100644 index 00000000..d7cae8da --- /dev/null +++ b/documentation/18.11/solutions/_images/wel-check-box-3-state-checked.png.data @@ -0,0 +1,3 @@ +title=wel-check-box-3-state-checked +author=admin +path=content/wel-check-box-3-state-checked diff --git a/documentation/18.11/solutions/_images/wel-check-box-3-state-indeterminate.png b/documentation/18.11/solutions/_images/wel-check-box-3-state-indeterminate.png new file mode 100644 index 00000000..ddda7b01 Binary files /dev/null and b/documentation/18.11/solutions/_images/wel-check-box-3-state-indeterminate.png differ diff --git a/documentation/18.11/solutions/_images/wel-check-box-3-state-indeterminate.png.data b/documentation/18.11/solutions/_images/wel-check-box-3-state-indeterminate.png.data new file mode 100644 index 00000000..c4bb0020 --- /dev/null +++ b/documentation/18.11/solutions/_images/wel-check-box-3-state-indeterminate.png.data @@ -0,0 +1,3 @@ +title=wel-check-box-3-state-indeterminate +author=admin +path=content/wel-check-box-3-state-indeterminate diff --git a/documentation/18.11/solutions/_images/wel-check-box-3-state-unchecked.png b/documentation/18.11/solutions/_images/wel-check-box-3-state-unchecked.png new file mode 100644 index 00000000..adf9693a Binary files /dev/null and b/documentation/18.11/solutions/_images/wel-check-box-3-state-unchecked.png differ diff --git a/documentation/18.11/solutions/_images/wel-check-box-3-state-unchecked.png.data b/documentation/18.11/solutions/_images/wel-check-box-3-state-unchecked.png.data new file mode 100644 index 00000000..e64c2761 --- /dev/null +++ b/documentation/18.11/solutions/_images/wel-check-box-3-state-unchecked.png.data @@ -0,0 +1,3 @@ +title=wel-check-box-3-state-unchecked +author=admin +path=content/wel-check-box-3-state-unchecked diff --git a/documentation/18.11/solutions/_images/wel-check-box-checked.png b/documentation/18.11/solutions/_images/wel-check-box-checked.png new file mode 100644 index 00000000..6e2302ff Binary files /dev/null and b/documentation/18.11/solutions/_images/wel-check-box-checked.png differ diff --git a/documentation/18.11/solutions/_images/wel-check-box-checked.png.data b/documentation/18.11/solutions/_images/wel-check-box-checked.png.data new file mode 100644 index 00000000..d24aa1b8 --- /dev/null +++ b/documentation/18.11/solutions/_images/wel-check-box-checked.png.data @@ -0,0 +1,3 @@ +title=wel-check-box-checked +author=admin +path=content/wel-check-box-checked diff --git a/documentation/18.11/solutions/_images/wel-check-box-unchecked.png b/documentation/18.11/solutions/_images/wel-check-box-unchecked.png new file mode 100644 index 00000000..27ab1bb5 Binary files /dev/null and b/documentation/18.11/solutions/_images/wel-check-box-unchecked.png differ diff --git a/documentation/18.11/solutions/_images/wel-check-box-unchecked.png.data b/documentation/18.11/solutions/_images/wel-check-box-unchecked.png.data new file mode 100644 index 00000000..da525b27 --- /dev/null +++ b/documentation/18.11/solutions/_images/wel-check-box-unchecked.png.data @@ -0,0 +1,3 @@ +title=wel-check-box-unchecked +author=admin +path=content/wel-check-box-unchecked diff --git a/documentation/18.11/solutions/_images/wel-choose-color-dialog.png b/documentation/18.11/solutions/_images/wel-choose-color-dialog.png new file mode 100644 index 00000000..9d76fb7a Binary files /dev/null and b/documentation/18.11/solutions/_images/wel-choose-color-dialog.png differ diff --git a/documentation/18.11/solutions/_images/wel-choose-color-dialog.png.data b/documentation/18.11/solutions/_images/wel-choose-color-dialog.png.data new file mode 100644 index 00000000..9a2695f5 --- /dev/null +++ b/documentation/18.11/solutions/_images/wel-choose-color-dialog.png.data @@ -0,0 +1,3 @@ +title=wel-choose-color-dialog +author=admin +path=content/wel-choose-color-dialog diff --git a/documentation/18.11/solutions/_images/wel-choose-folder-dialog.png b/documentation/18.11/solutions/_images/wel-choose-folder-dialog.png new file mode 100644 index 00000000..27f9f565 Binary files /dev/null and b/documentation/18.11/solutions/_images/wel-choose-folder-dialog.png differ diff --git a/documentation/18.11/solutions/_images/wel-choose-folder-dialog.png.data b/documentation/18.11/solutions/_images/wel-choose-folder-dialog.png.data new file mode 100644 index 00000000..1dd67d8a --- /dev/null +++ b/documentation/18.11/solutions/_images/wel-choose-folder-dialog.png.data @@ -0,0 +1,3 @@ +title=wel-choose-folder-dialog +author=admin +path=content/wel-choose-folder-dialog diff --git a/documentation/18.11/solutions/_images/wel-choose-font-dialog.png b/documentation/18.11/solutions/_images/wel-choose-font-dialog.png new file mode 100644 index 00000000..7fa934fe Binary files /dev/null and b/documentation/18.11/solutions/_images/wel-choose-font-dialog.png differ diff --git a/documentation/18.11/solutions/_images/wel-choose-font-dialog.png.data b/documentation/18.11/solutions/_images/wel-choose-font-dialog.png.data new file mode 100644 index 00000000..279ae90e --- /dev/null +++ b/documentation/18.11/solutions/_images/wel-choose-font-dialog.png.data @@ -0,0 +1,3 @@ +title=wel-choose-font-dialog +author=admin +path=content/wel-choose-font-dialog diff --git a/documentation/18.11/solutions/_images/wel-group-box.png b/documentation/18.11/solutions/_images/wel-group-box.png new file mode 100644 index 00000000..94c8addf Binary files /dev/null and b/documentation/18.11/solutions/_images/wel-group-box.png differ diff --git a/documentation/18.11/solutions/_images/wel-group-box.png.data b/documentation/18.11/solutions/_images/wel-group-box.png.data new file mode 100644 index 00000000..72ca9ed9 --- /dev/null +++ b/documentation/18.11/solutions/_images/wel-group-box.png.data @@ -0,0 +1,3 @@ +title=wel-group-box +author=admin +path=content/wel-group-box diff --git a/documentation/18.11/solutions/_images/wel-list-view-style-lvs-icon.png b/documentation/18.11/solutions/_images/wel-list-view-style-lvs-icon.png new file mode 100644 index 00000000..4f2cb782 Binary files /dev/null and b/documentation/18.11/solutions/_images/wel-list-view-style-lvs-icon.png differ diff --git a/documentation/18.11/solutions/_images/wel-list-view-style-lvs-icon.png.data b/documentation/18.11/solutions/_images/wel-list-view-style-lvs-icon.png.data new file mode 100644 index 00000000..c4894dae --- /dev/null +++ b/documentation/18.11/solutions/_images/wel-list-view-style-lvs-icon.png.data @@ -0,0 +1,3 @@ +title=wel-list-view-style-lvs-icon +author=admin +path=content/wel-list-view-style-lvs-icon diff --git a/documentation/18.11/solutions/_images/wel-list-view-style-lvs-list.png b/documentation/18.11/solutions/_images/wel-list-view-style-lvs-list.png new file mode 100644 index 00000000..ab59354d Binary files /dev/null and b/documentation/18.11/solutions/_images/wel-list-view-style-lvs-list.png differ diff --git a/documentation/18.11/solutions/_images/wel-list-view-style-lvs-list.png.data b/documentation/18.11/solutions/_images/wel-list-view-style-lvs-list.png.data new file mode 100644 index 00000000..a44b3f72 --- /dev/null +++ b/documentation/18.11/solutions/_images/wel-list-view-style-lvs-list.png.data @@ -0,0 +1,3 @@ +title=wel-list-view-style-lvs-list +author=admin +path=content/wel-list-view-style-lvs-list diff --git a/documentation/18.11/solutions/_images/wel-list-view-style-lvs-report.png b/documentation/18.11/solutions/_images/wel-list-view-style-lvs-report.png new file mode 100644 index 00000000..a5721490 Binary files /dev/null and b/documentation/18.11/solutions/_images/wel-list-view-style-lvs-report.png differ diff --git a/documentation/18.11/solutions/_images/wel-list-view-style-lvs-report.png.data b/documentation/18.11/solutions/_images/wel-list-view-style-lvs-report.png.data new file mode 100644 index 00000000..1702b49b --- /dev/null +++ b/documentation/18.11/solutions/_images/wel-list-view-style-lvs-report.png.data @@ -0,0 +1,3 @@ +title=wel-list-view-style-lvs-report +author=admin +path=content/wel-list-view-style-lvs-report diff --git a/documentation/18.11/solutions/_images/wel-list-view-style-lvs-small-icon.png b/documentation/18.11/solutions/_images/wel-list-view-style-lvs-small-icon.png new file mode 100644 index 00000000..606170bc Binary files /dev/null and b/documentation/18.11/solutions/_images/wel-list-view-style-lvs-small-icon.png differ diff --git a/documentation/18.11/solutions/_images/wel-list-view-style-lvs-small-icon.png.data b/documentation/18.11/solutions/_images/wel-list-view-style-lvs-small-icon.png.data new file mode 100644 index 00000000..72a085a9 --- /dev/null +++ b/documentation/18.11/solutions/_images/wel-list-view-style-lvs-small-icon.png.data @@ -0,0 +1,3 @@ +title=wel-list-view-style-lvs-small-icon +author=admin +path=content/wel-list-view-style-lvs-small-icon diff --git a/documentation/18.11/solutions/_images/wel-multiple-line-edit.png b/documentation/18.11/solutions/_images/wel-multiple-line-edit.png new file mode 100644 index 00000000..0bdf7bc1 Binary files /dev/null and b/documentation/18.11/solutions/_images/wel-multiple-line-edit.png differ diff --git a/documentation/18.11/solutions/_images/wel-multiple-line-edit.png.data b/documentation/18.11/solutions/_images/wel-multiple-line-edit.png.data new file mode 100644 index 00000000..a048bcea --- /dev/null +++ b/documentation/18.11/solutions/_images/wel-multiple-line-edit.png.data @@ -0,0 +1,3 @@ +title=wel-multiple-line-edit +author=admin +path=content/wel-multiple-line-edit diff --git a/documentation/18.11/solutions/_images/wel-multiple-selection-list-box.png b/documentation/18.11/solutions/_images/wel-multiple-selection-list-box.png new file mode 100644 index 00000000..daed9014 Binary files /dev/null and b/documentation/18.11/solutions/_images/wel-multiple-selection-list-box.png differ diff --git a/documentation/18.11/solutions/_images/wel-multiple-selection-list-box.png.data b/documentation/18.11/solutions/_images/wel-multiple-selection-list-box.png.data new file mode 100644 index 00000000..26ab8d28 --- /dev/null +++ b/documentation/18.11/solutions/_images/wel-multiple-selection-list-box.png.data @@ -0,0 +1,3 @@ +title=wel-multiple-selection-list-box +author=admin +path=content/wel-multiple-selection-list-box diff --git a/documentation/18.11/solutions/_images/wel-open-file-dialog.png b/documentation/18.11/solutions/_images/wel-open-file-dialog.png new file mode 100644 index 00000000..b4600bd0 Binary files /dev/null and b/documentation/18.11/solutions/_images/wel-open-file-dialog.png differ diff --git a/documentation/18.11/solutions/_images/wel-open-file-dialog.png.data b/documentation/18.11/solutions/_images/wel-open-file-dialog.png.data new file mode 100644 index 00000000..5bcc883a --- /dev/null +++ b/documentation/18.11/solutions/_images/wel-open-file-dialog.png.data @@ -0,0 +1,3 @@ +title=wel-open-file-dialog +author=admin +path=content/wel-open-file-dialog diff --git a/documentation/18.11/solutions/_images/wel-print-dialog.png b/documentation/18.11/solutions/_images/wel-print-dialog.png new file mode 100644 index 00000000..3ee49956 Binary files /dev/null and b/documentation/18.11/solutions/_images/wel-print-dialog.png differ diff --git a/documentation/18.11/solutions/_images/wel-print-dialog.png.data b/documentation/18.11/solutions/_images/wel-print-dialog.png.data new file mode 100644 index 00000000..ec9eb492 --- /dev/null +++ b/documentation/18.11/solutions/_images/wel-print-dialog.png.data @@ -0,0 +1,3 @@ +title=wel-print-dialog +author=admin +path=content/wel-print-dialog diff --git a/documentation/18.11/solutions/_images/wel-progress-bar-half.png b/documentation/18.11/solutions/_images/wel-progress-bar-half.png new file mode 100644 index 00000000..e531de73 Binary files /dev/null and b/documentation/18.11/solutions/_images/wel-progress-bar-half.png differ diff --git a/documentation/18.11/solutions/_images/wel-progress-bar-half.png.data b/documentation/18.11/solutions/_images/wel-progress-bar-half.png.data new file mode 100644 index 00000000..258dd2a4 --- /dev/null +++ b/documentation/18.11/solutions/_images/wel-progress-bar-half.png.data @@ -0,0 +1,3 @@ +title=wel-progress-bar-half +author=admin +path=content/wel-progress-bar-half diff --git a/documentation/18.11/solutions/_images/wel-push-button.png b/documentation/18.11/solutions/_images/wel-push-button.png new file mode 100644 index 00000000..81bac431 Binary files /dev/null and b/documentation/18.11/solutions/_images/wel-push-button.png differ diff --git a/documentation/18.11/solutions/_images/wel-push-button.png.data b/documentation/18.11/solutions/_images/wel-push-button.png.data new file mode 100644 index 00000000..e32a50f9 --- /dev/null +++ b/documentation/18.11/solutions/_images/wel-push-button.png.data @@ -0,0 +1,3 @@ +title=wel-push-button +author=admin +path=content/wel-push-button diff --git a/documentation/18.11/solutions/_images/wel-radio-button-checked.png b/documentation/18.11/solutions/_images/wel-radio-button-checked.png new file mode 100644 index 00000000..a3f97f4c Binary files /dev/null and b/documentation/18.11/solutions/_images/wel-radio-button-checked.png differ diff --git a/documentation/18.11/solutions/_images/wel-radio-button-checked.png.data b/documentation/18.11/solutions/_images/wel-radio-button-checked.png.data new file mode 100644 index 00000000..0329dd89 --- /dev/null +++ b/documentation/18.11/solutions/_images/wel-radio-button-checked.png.data @@ -0,0 +1,3 @@ +title=wel-radio-button-checked +author=admin +path=content/wel-radio-button-checked diff --git a/documentation/18.11/solutions/_images/wel-radio-button-unchecked.png b/documentation/18.11/solutions/_images/wel-radio-button-unchecked.png new file mode 100644 index 00000000..8abadb5d Binary files /dev/null and b/documentation/18.11/solutions/_images/wel-radio-button-unchecked.png differ diff --git a/documentation/18.11/solutions/_images/wel-radio-button-unchecked.png.data b/documentation/18.11/solutions/_images/wel-radio-button-unchecked.png.data new file mode 100644 index 00000000..1d6a2c9b --- /dev/null +++ b/documentation/18.11/solutions/_images/wel-radio-button-unchecked.png.data @@ -0,0 +1,3 @@ +title=wel-radio-button-unchecked +author=admin +path=content/wel-radio-button-unchecked diff --git a/documentation/18.11/solutions/_images/wel-save-file-dialog.png b/documentation/18.11/solutions/_images/wel-save-file-dialog.png new file mode 100644 index 00000000..50e421f4 Binary files /dev/null and b/documentation/18.11/solutions/_images/wel-save-file-dialog.png differ diff --git a/documentation/18.11/solutions/_images/wel-save-file-dialog.png.data b/documentation/18.11/solutions/_images/wel-save-file-dialog.png.data new file mode 100644 index 00000000..d4380aaa --- /dev/null +++ b/documentation/18.11/solutions/_images/wel-save-file-dialog.png.data @@ -0,0 +1,3 @@ +title=wel-save-file-dialog +author=admin +path=content/wel-save-file-dialog diff --git a/documentation/18.11/solutions/_images/wel-scroll-bar-horizontal.png b/documentation/18.11/solutions/_images/wel-scroll-bar-horizontal.png new file mode 100644 index 00000000..a1c0f389 Binary files /dev/null and b/documentation/18.11/solutions/_images/wel-scroll-bar-horizontal.png differ diff --git a/documentation/18.11/solutions/_images/wel-scroll-bar-horizontal.png.data b/documentation/18.11/solutions/_images/wel-scroll-bar-horizontal.png.data new file mode 100644 index 00000000..7606df6e --- /dev/null +++ b/documentation/18.11/solutions/_images/wel-scroll-bar-horizontal.png.data @@ -0,0 +1,3 @@ +title=wel-scroll-bar-horizontal +author=admin +path=content/wel-scroll-bar-horizontal diff --git a/documentation/18.11/solutions/_images/wel-scroll-bar-vertical.png b/documentation/18.11/solutions/_images/wel-scroll-bar-vertical.png new file mode 100644 index 00000000..13ab3700 Binary files /dev/null and b/documentation/18.11/solutions/_images/wel-scroll-bar-vertical.png differ diff --git a/documentation/18.11/solutions/_images/wel-scroll-bar-vertical.png.data b/documentation/18.11/solutions/_images/wel-scroll-bar-vertical.png.data new file mode 100644 index 00000000..d57d0e5f --- /dev/null +++ b/documentation/18.11/solutions/_images/wel-scroll-bar-vertical.png.data @@ -0,0 +1,3 @@ +title=wel-scroll-bar-vertical +author=admin +path=content/wel-scroll-bar-vertical diff --git a/documentation/18.11/solutions/_images/wel-single-line-edit.png b/documentation/18.11/solutions/_images/wel-single-line-edit.png new file mode 100644 index 00000000..844f14a2 Binary files /dev/null and b/documentation/18.11/solutions/_images/wel-single-line-edit.png differ diff --git a/documentation/18.11/solutions/_images/wel-single-line-edit.png.data b/documentation/18.11/solutions/_images/wel-single-line-edit.png.data new file mode 100644 index 00000000..8d3bf85c --- /dev/null +++ b/documentation/18.11/solutions/_images/wel-single-line-edit.png.data @@ -0,0 +1,3 @@ +title=wel-single-line-edit +author=admin +path=content/wel-single-line-edit diff --git a/documentation/18.11/solutions/_images/wel-single-selection-list-box.png b/documentation/18.11/solutions/_images/wel-single-selection-list-box.png new file mode 100644 index 00000000..c312361e Binary files /dev/null and b/documentation/18.11/solutions/_images/wel-single-selection-list-box.png differ diff --git a/documentation/18.11/solutions/_images/wel-single-selection-list-box.png.data b/documentation/18.11/solutions/_images/wel-single-selection-list-box.png.data new file mode 100644 index 00000000..a1d4e297 --- /dev/null +++ b/documentation/18.11/solutions/_images/wel-single-selection-list-box.png.data @@ -0,0 +1,3 @@ +title=wel-single-selection-list-box +author=admin +path=content/wel-single-selection-list-box diff --git a/documentation/18.11/solutions/_images/wel-tooltip.png b/documentation/18.11/solutions/_images/wel-tooltip.png new file mode 100644 index 00000000..751e3f51 Binary files /dev/null and b/documentation/18.11/solutions/_images/wel-tooltip.png differ diff --git a/documentation/18.11/solutions/_images/wel-tooltip.png.data b/documentation/18.11/solutions/_images/wel-tooltip.png.data new file mode 100644 index 00000000..2bfe50ec --- /dev/null +++ b/documentation/18.11/solutions/_images/wel-tooltip.png.data @@ -0,0 +1,3 @@ +title=wel-tooltip +author=admin +path=content/wel-tooltip diff --git a/documentation/18.11/solutions/_images/wel-track-bar-horizontal.png b/documentation/18.11/solutions/_images/wel-track-bar-horizontal.png new file mode 100644 index 00000000..eec628bc Binary files /dev/null and b/documentation/18.11/solutions/_images/wel-track-bar-horizontal.png differ diff --git a/documentation/18.11/solutions/_images/wel-track-bar-horizontal.png.data b/documentation/18.11/solutions/_images/wel-track-bar-horizontal.png.data new file mode 100644 index 00000000..6b909eaa --- /dev/null +++ b/documentation/18.11/solutions/_images/wel-track-bar-horizontal.png.data @@ -0,0 +1,3 @@ +title=wel-track-bar-horizontal +author=admin +path=content/wel-track-bar-horizontal diff --git a/documentation/18.11/solutions/_images/wel-track-bar-vertical.png b/documentation/18.11/solutions/_images/wel-track-bar-vertical.png new file mode 100644 index 00000000..77d422b7 Binary files /dev/null and b/documentation/18.11/solutions/_images/wel-track-bar-vertical.png differ diff --git a/documentation/18.11/solutions/_images/wel-track-bar-vertical.png.data b/documentation/18.11/solutions/_images/wel-track-bar-vertical.png.data new file mode 100644 index 00000000..b08cc0a5 --- /dev/null +++ b/documentation/18.11/solutions/_images/wel-track-bar-vertical.png.data @@ -0,0 +1,3 @@ +title=wel-track-bar-vertical +author=admin +path=content/wel-track-bar-vertical diff --git a/documentation/18.11/solutions/_images/wel-up-down-control.png b/documentation/18.11/solutions/_images/wel-up-down-control.png new file mode 100644 index 00000000..678758d5 Binary files /dev/null and b/documentation/18.11/solutions/_images/wel-up-down-control.png differ diff --git a/documentation/18.11/solutions/_images/wel-up-down-control.png.data b/documentation/18.11/solutions/_images/wel-up-down-control.png.data new file mode 100644 index 00000000..19fd0dc7 --- /dev/null +++ b/documentation/18.11/solutions/_images/wel-up-down-control.png.data @@ -0,0 +1,3 @@ +title=wel-up-down-control +author=admin +path=content/wel-down-control diff --git a/documentation/18.11/solutions/_images/widget-selector-clients.PNG b/documentation/18.11/solutions/_images/widget-selector-clients.PNG new file mode 100644 index 00000000..69975400 Binary files /dev/null and b/documentation/18.11/solutions/_images/widget-selector-clients.PNG differ diff --git a/documentation/18.11/solutions/_images/widget-selector-clients.PNG.data b/documentation/18.11/solutions/_images/widget-selector-clients.PNG.data new file mode 100644 index 00000000..98a9001a --- /dev/null +++ b/documentation/18.11/solutions/_images/widget-selector-clients.PNG.data @@ -0,0 +1,3 @@ +title=widget-selector-clients +author=admin +path=content/widget-selector-clients diff --git a/documentation/18.11/solutions/_images/widget_sample.png b/documentation/18.11/solutions/_images/widget_sample.png new file mode 100644 index 00000000..432dd197 Binary files /dev/null and b/documentation/18.11/solutions/_images/widget_sample.png differ diff --git a/documentation/18.11/solutions/_images/widget_sample.png.data b/documentation/18.11/solutions/_images/widget_sample.png.data new file mode 100644 index 00000000..bcf443ff --- /dev/null +++ b/documentation/18.11/solutions/_images/widget_sample.png.data @@ -0,0 +1,3 @@ +title=widgets +author=admin +path=content/widgets diff --git a/documentation/18.11/solutions/_images/window-selector.png b/documentation/18.11/solutions/_images/window-selector.png new file mode 100644 index 00000000..6d668853 Binary files /dev/null and b/documentation/18.11/solutions/_images/window-selector.png differ diff --git a/documentation/18.11/solutions/_images/window-selector.png.data b/documentation/18.11/solutions/_images/window-selector.png.data new file mode 100644 index 00000000..eab88ae6 --- /dev/null +++ b/documentation/18.11/solutions/_images/window-selector.png.data @@ -0,0 +1,3 @@ +title=window-selector +author=admin +path=content/window-selector diff --git a/documentation/18.11/solutions/_images/windows.png b/documentation/18.11/solutions/_images/windows.png new file mode 100644 index 00000000..14dfd7b0 Binary files /dev/null and b/documentation/18.11/solutions/_images/windows.png differ diff --git a/documentation/18.11/solutions/_images/windows.png.data b/documentation/18.11/solutions/_images/windows.png.data new file mode 100644 index 00000000..670f905c --- /dev/null +++ b/documentation/18.11/solutions/_images/windows.png.data @@ -0,0 +1,3 @@ +title=windows +author=admin +path=content/windows diff --git a/documentation/18.11/solutions/_images/xcell.png b/documentation/18.11/solutions/_images/xcell.png new file mode 100644 index 00000000..e8411a21 Binary files /dev/null and b/documentation/18.11/solutions/_images/xcell.png differ diff --git a/documentation/18.11/solutions/_images/xcell.png.data b/documentation/18.11/solutions/_images/xcell.png.data new file mode 100644 index 00000000..e94389be --- /dev/null +++ b/documentation/18.11/solutions/_images/xcell.png.data @@ -0,0 +1,3 @@ +title=xcell +author=admin +path=content/xcell diff --git a/documentation/18.11/solutions/_images/xy.png b/documentation/18.11/solutions/_images/xy.png new file mode 100644 index 00000000..1482ebac Binary files /dev/null and b/documentation/18.11/solutions/_images/xy.png differ diff --git a/documentation/18.11/solutions/_images/xy.png.data b/documentation/18.11/solutions/_images/xy.png.data new file mode 100644 index 00000000..1470abef --- /dev/null +++ b/documentation/18.11/solutions/_images/xy.png.data @@ -0,0 +1,3 @@ +title=xy +author=admin +path=content/xy diff --git a/documentation/18.11/solutions/basic-computing/EiffelProcess-and-EiffelBaseProcess.wiki b/documentation/18.11/solutions/basic-computing/EiffelProcess-and-EiffelBaseProcess.wiki new file mode 100644 index 00000000..8aebb8c8 --- /dev/null +++ b/documentation/18.11/solutions/basic-computing/EiffelProcess-and-EiffelBaseProcess.wiki @@ -0,0 +1,93 @@ +[[Property:uuid|479D1DED-2E7B-4202-BE21-D2A1757398B9]] +[[Property:weight|0]] +[[Property:title|Process and BaseProcess]] +[[Property:link_title|External processes]] +The Process library provides solution to execute a command, to control its execution, to redirect its outputs and input. + +{{Note|Since version 17.01, there is a SCOOP-capable library BaseProcess that does not yet have all functionalities of the Process library.}} + += BaseProcess library = +{{Warning|This solution supports all kind of concurrency (none, thread, and SCOOP), but does not yet offer all the functionalities of the previous Process library. It is recommended to use BaseProcess, unless you badly need the missing features.}} + +== Creation of process handlers == +The main interfaces are `BASE_PROCESS_FACTORY` and `BASE_PROCESS`. The factory helps to instantiate a `BASE_PROCESS` object, which is the execution controller. The `BASE_PROCESS` object is used to configure the execution, to launch the execution, and check for the termination. It could also terminate the execution if wanted. + +The factory interface provides 2 useful functions creating a `BASE_PROCESS` object: +* `process_launcher` takes as parameters the file name of the executable, then the arguments as a list of strings, and an optional working directory. +* `process_launcher_with_command_line` is similar to `process_launcher`, but takes the full command line, instead of executable filename and arguments. +The advantage of `process_launcher` is that you do not have to care about quoting the argument values. + +== Output redirection == +On the `BASE_PROCESS` object, it is possible to configure the execution. +* It is possible to redirect the standard and error output, and also the input, for instance: +** `redirect_output_to_file` is used to record the execution output in a file +** `redirect_error_to_same_as_output` is used to redirect the error output with the standard output +** `redirect_input_to_file` is used to take the input from a file. +** check other `redirect_*` routines. + +== Platform-specific settings == + +{| class="wikitable" style="width: auto; margin: 0px auto;" +|- +! style="border-style: solid; text-align: center; font-weight: 500;" ! Feature +! style="border-style: solid; text-align: center; font-weight: 500;" ! Description +|- +| colspan="2" | {{Inline-Info|Only for Unix}} +|- +| `is_terminal_control_enabled` || If True, the launched process will have terminal control over standard input, output and error. {{Note|Has effect only when `is_launched_in_new_process_group` is True.}} +|- +| colspan="2" | {{Inline-Info|Only for Windows}} +|- +| `hidden` || If True, the process will be launched silently (no console window will prompt out). +|- +| `separate_console` || If True, the process will be launched with a new console instead of inheriting parent's console. +|- +| `detached_console` || If True, the process will be launched without any console. +|} + +== Execution control == +{| class="wikitable" style="width: auto; margin: 0px auto;" +|- +! style="border-style: solid; text-align: center; font-weight: 500;" ! Feature +! style="border-style: solid; text-align: center; font-weight: 500;" ! Description +|- +| `launch` || Launch the execution. +|- +| `terminate` || Terminate launched execution. Check `last_termination_successful` after to see if `terminate` succeeded. {{Note|`terminate` executes asynchronously. After calling `terminate`, call `wait_to_exit` to wait for process to exit.}} +|- +| `terminate_tree` || Terminate process tree starting from current launched process. Check `last_termination_successful` after to see if `terminate_tree` succeeded. `terminate_tree` executes asynchronously. After calling `terminate`, call `wait_to_exit` to wait for process to exit. {{Note|On Unix, this feature can terminate whole process tree only when `is_launched_in_new_process_group` is set to True before new process is launched.}} +|- +| `wait_for_exit` || Wait until process has exited. {{Note|Child processes of launched process are not guaranteed to have exited after `wait_for_exit` returns.}} +|- +| `wait_for_exit_with_timeout (timeout: INTEGER)` || Wait launched process to exit for at most `timeout` milliseconds. Check `has_exited` after to see if launched process has exited. {{Note|Child processes of launched process are not guaranteed to have exited even if `has_exited` is `True` after `wait_for_exit_with_timeout`.}} +|- +| `close` || Close handles associated with child process. The process may continue running. If there is any input/output redirection to/from current process, it will be closed. +|} + +== Execution status == +{| class="wikitable" style="width: auto; margin: 0px auto;" +|- +! style="border-style: solid; text-align: center; font-weight: 500;" ! Feature +! style="border-style: solid; text-align: center; font-weight: 500;" ! Description +|- +| `id` || Identifier of the last launched process. +|- +| `exit_code`|| Exit code of child process. It should be called after the process has exited. +|- +| `platform` || It is a facility to know which is the current platform. +|- +| `launched` || Has the process been launched? Check after a call to `launch`. +|- +| `is_running` || Is the process still running (i.e launched and not exited)? +|- +| `has_exited` || Has launched process exited and have allocated resources been cleaned up? +|} + += Process library = +{{Warning|This solution requires multi-threading. In other concurrency modes (none and SCOOP), your project will compile fine but at the execution, it can not be used since your system is not thread-capable.}} + +The Process library is an extension of the BaseProcess library, the main interfaces are +* `PROCESS_FACTORY` which inherits from `BASE_PROCESS_FACTORY` and creates `PROCESS` objects. +* `PROCESS` which inherits from `BASE_PROCESS` and add agent based redirection. +The agent based redirections can be useful to process the execution output as it comes, and also to send data to the input. + diff --git a/documentation/18.11/solutions/basic-computing/eiffelbase/eiffelbase-class-reference-0.wiki b/documentation/18.11/solutions/basic-computing/eiffelbase/eiffelbase-class-reference-0.wiki new file mode 100644 index 00000000..9d0c61cb --- /dev/null +++ b/documentation/18.11/solutions/basic-computing/eiffelbase/eiffelbase-class-reference-0.wiki @@ -0,0 +1,7 @@ +[[Property:title|EiffelBase Class Reference]] +[[Property:weight|2]] +[[Property:uuid|9308c4f5-43a5-c07f-2f66-a4597c4ee4ea]] +==View the [[ref:libraries/base/reference/index|EiffelBase Class Reference]]== + + + diff --git a/documentation/18.11/solutions/basic-computing/eiffelbase/eiffelbase-samples/eiffelbase-sample-calculator.wiki b/documentation/18.11/solutions/basic-computing/eiffelbase/eiffelbase-samples/eiffelbase-sample-calculator.wiki new file mode 100644 index 00000000..696ae47f --- /dev/null +++ b/documentation/18.11/solutions/basic-computing/eiffelbase/eiffelbase-samples/eiffelbase-sample-calculator.wiki @@ -0,0 +1,103 @@ +[[Property:title|EiffelBase Sample: Calculator]] +[[Property:weight|0]] +[[Property:uuid|12c3409d-165b-b1df-e26a-b05d49969661]] +This sample consists of a command line reverse Polish notation (RPN) calculator. + +{{note|A RPN calculator works slightly differently from standard calculators. It consists of a stack of numbers. Operations are applied to the two numbers on top of the stack. The result is then put on top of the stack so that it can be used in the next operation. This sample refers to the top of the stack as ''Accumulator''.This sample consists of a command line reverse Polish notation (RPN) calculator. }} + +==Compiling== + +To compile the example: +# Launch EiffelStudio. +# Click '''Add project''' +# Browse to ''$ISE_EIFFEL\examples\base\calculator\'' +# Choose ''calculator.ecf'' +# Choose the location where the project will be compiled, by default the same directory containing the configuration file. +# Click '''Open'''. + +==Running== + +After you launch the sample, the following text appears in a console: + +********************************* +Calculator in reverse Polish form +********************************* + +Allowable operations are: + '/': Divide top two numbers on the stack. + '0': Empty the stack. + 'a': Enter operand onto stack. + '?': Help. + '*': Multiply top two numbers on the stack. + '+': Add top two numbers on the stack + 'q': Quit. + '-': Subtract top two numbers on the stack. +Enter a number, followed by : + + +Enter the first number to be put onto the stack, for example 3. + +{{caution|Failing to enter a number at this stage will cause the sample to stop. This sample was designed to showcase the use of EiffelBase data structures and is not protected against unexpected entries. }} + +You may then add another number on the stack by entering the character a: + +********************************* +Calculator in reverse Polish form +********************************* +Allowable operations are: + '/': Divide top two numbers on the stack. + '0': Empty the stack. + 'a': Enter operand onto stack. + '?': Help. + '*': Multiply top two numbers on the stack. + '+': Add top two numbers on the stack + 'q': Quit. + '-': Subtract top two numbers on the stack. +Enter a number, followed by : 3 + +Accumulator = 3 + +Next operation? a +Enter a number, followed by : + + +Enter a second number, for example 2. You can then apply any operation to the two operands such as minus: + +... +Next operation? a +Enter a number, followed by : 2 + +Accumulator = 2 + +Next operation? - + +Accumulator = 1 + +Next operation? + + +You may use the operation 0 to clear the stack at any time. You may use q to quit the program. + +{{tip|You can use the command ? to display the list of available operations. }} + +==Under the Hood== + +This sample shows how to leverage EiffelBase data structures in a simple Eiffel system. The root class CALCULATOR first instantiates all ''state'' objects, each corresponding to one possible operation. The state classes all inherit from STATE. They are: +* PLUS: Add stack's two top numbers. +* MINUS: Substract stack's two top numbers. +* MULTIPLY: Multiply stack's two top numbers. +* DIVIDE: Divide stack's two top numbers. +* EMPTY: Empty stack. +* HELP: Prints available commands. +* QUESTION: Get number from user. +* QUIT: Close application. +Each of these classes implement the feature do_one_state from STATE which performs the operation associated with the state. The initial state is QUESTION which asks for the initial number to put in the ''accumulator''. Following states depend on the user input.
+Every descendant of STATE implement the feature operation which performs the corresponding stack transformation. + +See the reference for the class interfaces. + + + + + + diff --git a/documentation/18.11/solutions/basic-computing/eiffelbase/eiffelbase-samples/index.wiki b/documentation/18.11/solutions/basic-computing/eiffelbase/eiffelbase-samples/index.wiki new file mode 100644 index 00000000..c9c73cf7 --- /dev/null +++ b/documentation/18.11/solutions/basic-computing/eiffelbase/eiffelbase-samples/index.wiki @@ -0,0 +1,5 @@ +[[Property:title|EiffelBase Samples]] +[[Property:weight|3]] +[[Property:uuid|5095bbdf-0dd6-7d7b-68d4-59a8293950ee]] + + diff --git a/documentation/18.11/solutions/basic-computing/eiffelbase/eiffelbase-tutorial/eiffelbase-data-structures-overview/eiffelbase-abstract-container-structures-taxonomy.wiki b/documentation/18.11/solutions/basic-computing/eiffelbase/eiffelbase-tutorial/eiffelbase-data-structures-overview/eiffelbase-abstract-container-structures-taxonomy.wiki new file mode 100644 index 00000000..f108144f --- /dev/null +++ b/documentation/18.11/solutions/basic-computing/eiffelbase/eiffelbase-tutorial/eiffelbase-data-structures-overview/eiffelbase-abstract-container-structures-taxonomy.wiki @@ -0,0 +1,15 @@ +[[Property:title|EiffelBase, Abstract Container Structures: The Taxonomy]] +[[Property:weight|0]] +[[Property:uuid|15ec3e87-45c6-ab53-ddad-d1348a9d8d75]] +A container data structure (or container in the sequel) is an object which serves to store and access collections of objects, called the '''items''' of the container. All classes describing containers are descendants of the deferred class [[ref:libraries/base/reference/container_chart|CONTAINER]] . + +A container can be studied from three viewpoints: access, storage and traversal. +* The '''access''' criterion affects how the clients of a container can access its items. For example, in a stack or queue, only one item is accessible at any given time, and clients do not choose that item; in contrast, clients of an array or hash table must provide an index, or more generally a key, to access an item. +* The '''storage''' criterion affects how the items are put together. For example some containers are finite, others potentially infinite; among finite structures, some are bounded, others unbounded. +* The '''traversal''' criterion affects how, if in any way, the items of a container can be traversed. A traversal is a mechanism which makes it possible to examine each item of a container once, in a clearly specified order. For example some containers can be traversed sequentially, in one direction or two; tree structures lend themselves to preorder, postorder and breadth-first traversals. + +For each of these criteria the Base library offers a single-inheritance hierarchy of deferred classes. The top of the access hierarchy is class [[ref:libraries/base/reference/collection_chart|COLLECTION]] ; the top of the storage hierarchy is class [[ref:libraries/base/reference/box_chart|BOX]] ; the top of the traversal hierarchy is class [[ref:libraries/base/reference/traversable_chart|TRAVERSABLE]] . These three classes are heirs of the most general class [[ref:libraries/base/reference/container_chart|CONTAINER]] . + + + + diff --git a/documentation/18.11/solutions/basic-computing/eiffelbase/eiffelbase-tutorial/eiffelbase-data-structures-overview/eiffelbase-data-structures-lists.wiki b/documentation/18.11/solutions/basic-computing/eiffelbase/eiffelbase-tutorial/eiffelbase-data-structures-overview/eiffelbase-data-structures-lists.wiki new file mode 100644 index 00000000..f0ce8065 --- /dev/null +++ b/documentation/18.11/solutions/basic-computing/eiffelbase/eiffelbase-tutorial/eiffelbase-data-structures-overview/eiffelbase-data-structures-lists.wiki @@ -0,0 +1,385 @@ +[[Property:title|EiffelBase Data Structures, Lists]] +[[Property:weight|1]] +[[Property:uuid|23f540e0-16d5-807c-30af-74d3416a5709]] +Many applications need sequential structures, also called linear structures, in particular lists and circular chains. Apart from three classes describing individual list cells, all the classes involved are descendants of class [[ref:libraries/base/reference/linear_chart|LINEAR]] , one of the deferred classes describing general traversal properties and introduced in the chapter that described the general data structure taxonomy. More precisely, all but one of the classes of interest for the present discussion are descendants, direct or indirect, from a class called [[ref:libraries/base/reference/chain_chart|CHAIN]] which describes general sequential structures possessing a cursor as well as insertion properties. The exception is class [[ref:libraries/base/reference/countable_sequence_chart|COUNTABLE_SEQUENCE]] , which describes infinite structures; all the others describe finite structures.
+[[ref:libraries/base/reference/chain_chart|CHAIN]] is an heir of [[ref:libraries/base/reference/sequence_chart|SEQUENCE]] , which describes a more general notion of sequence. [[ref:libraries/base/reference/sequence_chart|SEQUENCE]] is a descendant of [[ref:libraries/base/reference/linear_chart|LINEAR]] . There are two main categories of sequential structures: some, called circular chains, are cyclic; others, called lists, are not. Another distinction exists between dynamic structures, which may be extended at will, and fixed ones, which have a bounded capacity.
+In all of the structures under review you may insert two or more occurrences of a given item in such a way that the occurrences are distinguishable. In other words, the structures are bags rather than just sets, although it is possible to use them to implement sets. + +=Higher Level Traversal Classes= + +The list and chain classes are characterized, for their traversal properties, as being linear and, more precisely, bilinear. In the traversal hierarchy, the relevant deferred classes are [[ref:libraries/base/reference/linear_chart|LINEAR]] and [[ref:libraries/base/reference/bilinear_chart|BILINEAR]] , introduced in the [[EiffelBase, Abstract Container Structures: The Taxonomy|discussion]] of the general taxonomy. + +==Linear structures== + +[[ref:libraries/base/reference/linear_chart|LINEAR]] describes sequential structures that may be traversed one way. It introduces in particular the following features, illustrated on the figure below: +* after, a boolean-valued query which determines whether you have moved past the last position (a more precise specification is given below). +* off, a boolean-valued query which is false if and only if there is no item at the current position; for [[ref:libraries/base/reference/linear_chart|LINEAR]] this is the same as: +is_empty and not after + +* item, a query which returns the item at the current position - provided of course there is one, as expressed by the precondition: + + not off + +* start, a command to move to the first position if any (if is_empty is true the command has no effect). +* forth, a command to advance by one position; the precondition is not after. +* finish, a command to move to the last position; the precondition is:
+ + not is_empty + + +[[Image:linear|fig.1: Linear Structure]] + + +There is also a procedure search with one argument, which determines whether the value of that argument appears in the structure at or after the current position, and if not makes after become true. This procedure is internally used by the default implementation of the has function (the general membership test) for linear structures. Like has for all containers, search uses object or reference equality depending on the value set for object_comparison. + +An invariant property of [[ref:libraries/base/reference/linear_chart|LINEAR]] structures is that the current position may go off one step past the last item if any, but no further. The precondition of forth - not after - helps ensure this. The first item (if any) being at position 1, the maximum allowable position is count + 1, where count is the number of items. + +==Bilinear structures== + +[[ref:libraries/base/reference/bilinear_chart|BILINEAR]] describes linear structures which may be traversed both ways. It inherits from [[ref:libraries/base/reference/linear_chart|LINEAR]] and extends it with two new features which ensure complete symmetry between the two directions of movement: +* before, a boolean-valued query which determines whether you have moved to the left of the first position (a more precise specification is given below). +* back, a command to move backward by one position; the precondition is not before. + +For bilinear structures the position can range between 0 (not just 1) and count + 1. Query off is accordingly redefined so as to yield the value of after or before. + + +[[Image:bilinear|fig.2: Bilinear Structure]] + + +==Invariant properties for after, before and off== + +The redefinition of off illustrates a general methodological advice about invariants: be careful about not over-constraining the invariant by including properties that may be made more general in descendants. It might have been tempting to include in [[ref:libraries/base/reference/linear_chart|LINEAR]] an invariant clause of the form + + off = is_empty or after + +This property, however, would be too constraining. More precisely, it is always true that the right-hand side implies the left-hand-side: if a linear structure is either empty or after, then it is off. But the converse is not true, since certain kinds of linear structure, for example bilinear ones, may be off but neither empty nor after.
+The actual invariant for class [[ref:libraries/base/reference/bilinear_chart|BILINEAR]] is obtained in three stages. In class [[ref:libraries/base/reference/traversable_chart|TRAVERSABLE]] the feature off is deferred and a basic property of that feature is expressed by the invariant clause + + empty_constraint:is_empty implies off + +In [[ref:libraries/base/reference/linear_chart|LINEAR]] , feature off is effected through an implementation which returns the value of the expression is_empty or after. The class adds an invariant clause which, however, says less than the implementation to leave some room for variation: + + after_constraint:after implies off + +Finally [[ref:libraries/base/reference/bilinear_chart|BILINEAR]] , an heir of [[ref:libraries/base/reference/linear_chart|LINEAR]] , redefines off to return the value of the expression + + before or after + +and adds the invariant clause + + before_constraint: before implies off + +The new implementation of off + + after or before + +would not guarantee the invariant clause inherited from [[ref:libraries/base/reference/traversable_chart|TRAVERSABLE]] were it not for another clause introduced in [[ref:libraries/base/reference/bilinear_chart|BILINEAR]] : + + empty_property: is_empty implies (after or before ) + +which indicates that an empty bilinear structure must always be after or before but not both, however, as stated by the last new clause, the reason for which is discussed in detail below: + + not_both: not(after and before) + +The flat-short form of [[ref:libraries/base/reference/bilinear_chart|BILINEAR]] shows the complete reconstructed invariant: + + not_both: not (after and before) + empty_property: is_empty implies (after or before) + before_constraint: before implies off + after_constraint: after implies off + empty_constraint: is_empty implies off + +==Iteration patterns== + +For a more general form of this scheme, applicable to circular chains as well as other linear structures, replace off by exhausted. With the features shown above, a typical iteration mechanism on a non-empty linear structure 'lin' is of the form: + + from + lin.start + some_optional_initializing_operation (lin) + until + lin.off + loop + lin.some_action (lin.item) + lin.forth + end + +The value of lin.off is always true for an empty structure, so in this case the loop will, correctly, execute only its initialization actions if present.
+This is a very common pattern, which you will find in the library classes themselves (for example has is implemented in this way) and many application clients. The iterator classes corresponding to linear structures ([[ref:libraries/base/reference/linear_iterator_chart|LINEAR_ITERATOR]] , [[ref:libraries/base/reference/two_way_chain_iterator_chart|TWO_WAY_CHAIN_ITERATOR]] ) turn this pattern and several related ones into actual reusable routines.
+For bilinear structures there is another traversal mechanism going backward rather than forward; it is the same as above except that finish replaces start and back replaces finish. The exit condition remains off since before, like after, implies off. + +==A precise view of after and before== + +Getting the specification of after and before right, so that it will handle all cases properly, requires some care.
+For every one of the structures under discussion there is a notion of current position, which we may call the cursor position even though for the moment the cursor is a virtual notion only. (Actual cursor objects will come later when we combine [[ref:libraries/base/reference/linear_chart|LINEAR]] , [[ref:libraries/base/reference/bilinear_chart|BILINEAR]] and other classes from the traversal hierarchy with [[ref:libraries/base/reference/cursor_structure_chart|CURSOR_STRUCTURE]] and other classes from the collection hierarchy.) The informal definition is that after is true if and only if the cursor - in this informal sense of a fictitious marker signaling the current position - is one position after the last item, if any, and that before is true if and only if the cursor is one position before the first item. When the cursor is on any of the items, after and before are false; after holds when the cursor is to the right of the last item, and before when it is to the left of the first item. This leaves open the question of what conventions to take for an empty structure. If iteration schemes of the above type are to work, then after must be true for an empty structure. For a bilinear structure, however, we should have total symmetry between the two pairs of features +* start, forth, after. +* finish, back, before. + +So for an empty list both before and after should be true. This scheme was used in early version of the Base libraries. It has some disadvantages, however; in particular it is not compatible with the simple, symmetric properties: + + after = (index = count + 1) + before = (index = 0) + +which express elementary definitions for after and before in terms of index, the current position, and count, the number of items (items being numbered from 1 to count). For an empty structure count is zero, so if we want after and before to be both true in this case we have to sacrifice one of the above properties, since the first would imply index to 1 and the second to 0. But again symmetry reigns supreme: we should either keep both properties or renounce both. The solution was to renounce both and replace them by slightly more complicated ones: + + after = (is_empty or (index = count + 1)) + before = (is_empty or (index = 0)) + +When a structure is created, some initializations will have to be made; the default initializations will usually lead to a value of 0 rather than 1 for index, although this dissymetry is not apparent in the assertions. Although acceptable, this solution leads to small but unpleasant complications, in particular frequent conditional instructions of the form + + if after and not is_empty then... + +The solution finally retained for the Base libraries uses a different technique, which has turned out to be preferable. The idea is to replace the conceptual picture by one in which there are always two fictitious sentinel items. The two sentinel items are only present conceptually. They are of course not taken into account for the computation of count and, although it is possible to conceive of an implementation which would actually reserve space for them (for example in an array representation), none of the implementations used in Base for the classes of this documentation and other descendants of [[ref:libraries/base/reference/linear_chart|LINEAR]] do. The only purpose of the sentinels is to provide two valid theoretical cursor positions, which exist regardless of the number of actual (non-sentinel) items in the structure.
+The sentinel items always appear at positions 0 and count + 1; this property is true even if the structure is empty of items, in which case count is zero. As a result, the following properties are part of the invariant: + + 0 <= index + index <= count + 1 + before = (index = 0) + after = (index = count + 1) + not (after and before) + +The last property given indicates that a structure can never be both after and before, since even in an empty structure the two sentinels are still present, with the cursor on one of them. For an empty structure, index will be zero by convention, so that before will be true and after false. But this property is not reflected in any of the invariant clauses. + +==Some lessons== + +This discussion has illustrated some of the important patterns of reasoning that are frequently involved in serious object-oriented design. Among the lessons are four ideas which you may find useful in many different cases. First, consistency is once again the central principle. Throughout the design of a class library we must constantly ask ourselves: +* How do I make my next design decision compatible with the previous ones? +* How do I take my next design decision so that it will be easy - or at least possible - to make future ones compatible with it? + +Another frequent concern, partly a consequence of consistency, is symmetry. To mathematicians and physicists, symmetry considerations are often important in guiding the search for a solution to a problem; if the problem exhibits a certain symmetry, a candidate solution will be rejected if it does not satisfy that symmetry. Such was the situation here: since the structure's specification is symmetric with respect to the two possible directions of traversal, so too should the feature design be.
+The third lesson is also well-known in mathematics and physics: the usefulness of looking at limit cases. To check that a design is sound it is often useful to examine what becomes of it when it is applied to extreme situations - in particular, as was done in this example, empty structures.
+Finally, the only way to make delicate design decisions is to express the issues clearly through assertions, most notably invariants. To analyze the properties under discussion, and weigh the various alternatives, we need the precision of mathematical logic. Once again note that without assertions it would be impossible to build a good library; we would have no way to know precisely what we are talking about. + +=Sequences And Chains= + +Still deferred, classes [[ref:libraries/base/reference/sequence_chart|SEQUENCE]] and[[ref:libraries/base/reference/chain_chart|CHAIN]] provide the basis for all list and chain classes, as well as for many trees and for dispensers.
+SEQUENCE is constructed with the full extent of the technique described in the discussion of the taxonomy: using multiple inheritance to combine one class each from the access, traversal and storage hierarchy. [[ref:libraries/base/reference/sequence_chart|SEQUENCE]] indeed has three parents: +* [[ref:libraries/base/reference/active_chart|ACTIVE]] gives the access properties. A sequence is an active structure with a notion of current item. Remember that active structures are a special case of bags. +* [[ref:libraries/base/reference/bilinear_chart|BILINEAR]] , as studied above, indicates that a sequence may be traversed both ways. +* FINITE, from the storage hierarchy, indicates that the class describes finite sequences. (A class [[ref:libraries/base/reference/countable_sequence_chart|COUNTABLE_SEQUENCE]] is also present, as described below.) + +To the features of [[ref:libraries/base/reference/bilinear_chart|BILINEAR]] , [[ref:libraries/base/reference/sequence_chart|SEQUENCE]] principally adds features for adding, changing and removing items. A few procedures in particular serve to insert items at the end: +* s .put ( v ) adds v at the end of a sequence s. +* extend and force, at the [[ref:libraries/base/reference/sequence_chart|SEQUENCE]] level, do the same as put. +* s .append ( s1 ) adds to the end of s the items of s1 (another sequence), preserving their s1 order. + +Other procedures work on the current position: +* s.remove removes the item at current position. +* s.replace ( v ) replaces by v the item at current position. + +SEQUENCE, however, does not provide a procedure to insert an item at the current position, since not all implementations of sequences support this possibility; you will find it in descendants of [[ref:libraries/base/reference/sequence_chart|SEQUENCE]] seen below.
+Yet another group of features are based on the first occurrence of a certain item, or on all occurrences: +* s.prune ( v ) removes the first occurrence of v in s, if any. +* s.prune_all ( v ) removes all occurrences of v. + +These procedures have various abstract preconditions: s .extendible for additions, s .writable for replacements, s .prunable for removals. Properties extendible and prunable characterize general categories of container structures rather than individual instances; for example extendible is always true for the 'dynamic' structures seen below. In contrast, writable depends on the current status of each instance. In general writable will be true if there is an item at the current position. + +==Chains== + +Chains are sequences with a few more properties: items may be accessed through their indices, and it is possible to define cursor objects attached to individual items.
+Class [[ref:libraries/base/reference/chain_chart|CHAIN]] is an heir of [[ref:libraries/base/reference/sequence_chart|SEQUENCE]] . It gets its access properties from [[ref:libraries/base/reference/cursor_structure_chart|CURSOR_STRUCTURE]] (which adds the notion of cursor to the features of [[ref:libraries/base/reference/active_chart|ACTIVE]] , already present in [[ref:libraries/base/reference/sequence_chart|SEQUENCE]] ) and is also an heir of [[ref:libraries/base/reference/indexable_chart|INDEXABLE]] . This ancestry implies in particular the presence of the following features: +* cursor, from [[ref:libraries/base/reference/cursor_structure_chart|CURSOR_STRUCTURE]] , which makes it possible to keep a reference to an item of the structure. +* i_th and put_i_th from [[ref:libraries/base/reference/table_chart|TABLE]] , via [[ref:libraries/base/reference/indexable_chart|INDEXABLE]] , which make it possible to access and replace the value of an item given by its integer index. + +These features were called item and put in [[ref:libraries/base/reference/table_chart|TABLE]] , but are renamed here to remove the conflict with homonymous features from [[ref:libraries/base/reference/sequence_chart|SEQUENCE]] .
+Procedure put for chains is the version obtained from [[ref:libraries/base/reference/cursor_structure_chart|CURSOR_STRUCTURE]] , which has the same effect as replace - replacing the value of the item at cursor position. The put procedure from [[ref:libraries/base/reference/sequence_chart|SEQUENCE]] is renamed sequence_ put. This feature is not exported by [[ref:libraries/base/reference/chain_chart|CHAIN]] , however, since its effect (adding an item at the end) may be obtained through the simpler name extend. + +==Dynamic chains== + +By default, chains can only be extended at the end, through extend and sequence_put. Of particular interest are those chains where clients can insert and remove items at any position. Such chains are said to be dynamic, and described by [[ref:libraries/base/reference/chain_chart|CHAIN]] 's heir [[ref:libraries/base/reference/dynamic_chain_chart|DYNAMIC_CHAIN]] . The new features are predictable: +* Procedure put_front adds an item before the first. (As noted, the procedures to add an item after the last are already available in chains.) +* Procedures put_left and put_right add an item at the left and right of the cursor position. +* Procedures remove_left and remove_right remove an item at the left and right or the cursor position. +* Procedures merge_left and merge_right are similar to put_left and put_right but insert another dynamic chain rather than a single item. As the word 'merge' suggests, the merged structure, passed as argument, does not survive the process; it is emptied of its items. To preserve it, perform a twin or copy before the merge operation. + +The class also provides implementations of prune, prune_all and wipe_out from [[ref:libraries/base/reference/collection_chart|COLLECTION]] . To make these implementations useful, it defines queries extendible and prunable so that they return the value true. + +=Lists And Circular Structures= + +A chain is a finite sequential structure. This property means that items are arranged in a linear order and may be traversed from the first to the last. To do this you may use a loop of the form shown above, based on procedures start and forth.
+This property leaves room for several variants. In particular chains may be straight or circular. +* A straight chain, which from now on will be called a list, has a beginning and an end. +* A circular chain, as represented by class [[ref:libraries/base/reference/circular_chart|CIRCULAR]] and its descendants, has a much more flexible notion of first item. It is organized so that every item has a successor. + +This representation is conceptual only; in fact the implementations of circular chains found in the Base libraries are based on lists, implemented in one of the ways described below (in particular linked and arrayed).
+The major originality of circular chains is that unless the structure is empty procedure forth is always applicable: it will cycle past the last item, coming back to the
+first. The symmetric property applies to back. The cyclic nature of forth and back for circular chains is expressed precisely by the assertions. The version of forth for class [[ref:libraries/base/reference/chain_chart|CHAIN]] , which comes from [[ref:libraries/base/reference/linear_chart|LINEAR]] , has precondition +not after + +Similarly, the precondition for back is +not before + +For lists, after becomes true when the cursor moves past the last item. For circular chains, however, after and before are never true except for an empty structure; this is expressed by the invariant clauses of class [[ref:libraries/base/reference/circular_chart|CIRCULAR]] : +not before + +For a non-empty circular chain, then, you can circle forever around the items, using forth or back. + +==Choosing the first item== + +For a list, the first and last items are fixed, and correspond to specific places in the physical representation.
+A circular chain also needs a notion of first item, if only to enable a client to initiate a traversal through procedure start. Similarly, there is a last item - the one just before the first in a cyclic traversal. (If the chain has just one item, it is both first and last.)
+For circular chains, however, there is no reason why the first item should always remain the same. One of the benefits that clients may expect from the use of a circular
+structure is the ability to choose any item as the logical first. Class [[ref:libraries/base/reference/circular_chart|CIRCULAR]] offers for that purpose the procedure set_start which designates the current cursor position as the first in the circular chain. Subsequent calls to start will move the cursor to this position; calls to finish will move the cursor to the cyclically preceding position. With most implementations, there will then be two notions of first position: the logical first, which clients may freely choose through calls to set_start; and the physical first, which results from the implementation. In a representation using an array with indices from 1 to capacity, for example, the physical first is position 1, and the logical first may be any index in the permitted range. In a linked representation, there will be a cell first element corresponding to the physical first, but the logical first is any cell in the chain.
+In such cases the circular chain classes have features called standard_first, standard_last, standard_start and so on, which are not exported (so that you will not see them in the flat-short forms) but serve to implement visible features such as first, last and forth. For example a possible implementation of forth for circular chains is +forth is + -- Move cursor to next item, cyclically. + do + standard_forth + if standard_after then + standard_start + end + if isfirst then + exhausted := True + end + end + +==Traversing a list or circular chain== + +The properties of forth for circular chains imply that a traversal loop written as +from + lin.start +until + lin.off +loop + ... + lin.forth +end + +would not work if lin is a non-empty circular structure: off would never become true, so that the loop would forever cycle over the structure's items. The same would apply to a loop using finish and back instead of start and forth. This behavior is the natural result of the semantics defined for off , forth and back for circular structures. But it prevents us from using these features to perform a single traversal which will visit every item once.
+Using exhausted in lieu of off solves this problem. In class [[ref:libraries/base/reference/circular_chart|CIRCULAR]] , exhausted is an attribute which is set to false by start and finish, and is set to true by forth when advancing from the last item to the first and by back when backing up from the first item to the last. So you should write the loop as +from + lin.start + + + + + some_optional_initializing_operation (lin) +until + lin.exhausted +loop + ... + lin.some_action (lin.item) + lin.forth +end + +This form is applicable to all linear structures, circular or not, since exhausted is introduced in class [[ref:libraries/base/reference/linear_chart|LINEAR]] as a function which returns the same value as off .Its redefinition into an attribute, modified by start, finish, forth and back, does not occur until class [[ref:libraries/base/reference/circular_chart|CIRCULAR]] .
+Because exhausted is more general than off , the iteration scheme just given (and its equivalent going backwards) is preferable to the earlier one using off , especially if there is any chance that the iteration might one day be applied to a lin structure that is circular. Classes of the Iteration library, in particular [[ref:libraries/base/reference/linear_iterator_chart|LINEAR_ITERATOR]] , rely on this scheme for iterating over linear structures. + +==Dynamic structures== + +For both lists and circular chains, the most flexible variants, said to be dynamic, allow insertions and deletions at any position.
+The corresponding classes are descendants of [[ref:libraries/base/reference/dynamic_list_chart|DYNAMIC_LIST]] and [[ref:libraries/base/reference/dynamic_circular_chart|DYNAMIC_CIRCULAR]] , themselves heirs of [[ref:libraries/base/reference/dynamic_chain_chart|DYNAMIC_CHAIN]] studied above.
+ + +==Infinite sequences== + +Class [[ref:libraries/base/reference/countable_sequence_chart|COUNTABLE_SEQUENCES]] , built by inheritance from [[ref:libraries/base/reference/countable_chart|COUNTABLE]] , [[ref:libraries/base/reference/linear_chart|LINEAR]] and [[ref:libraries/base/reference/active_chart|ACTIVE]] , is similar to [[ref:libraries/base/reference/sequence_chart|SEQUENCE]] but describes infinite rather than finite sequences. + +=Implementations= + +We have by now seen the concepts underlying the linear structures of the Base libraries, especially lists and circular chains. Let us look at the techniques used to implement them. + +==Linked and arrayed implementations== + +Most of the implementations belong to one of four general categories, better described
+as two categories with two subcategories each: +* Linked implementations, which may be one-way or two-way. +* Arrayed implementations, which may be resizable or fixed. + +A linked implementation uses linked cells, each containing an item and a reference to the next cell. One-way structures are described by classes whose names begin with LINKED_, for example [[ref:libraries/base/reference/linked_list_chart|LINKED_LIST]] . Two-way structures use cells which, in addition to the reference to the next cell, also include a reference to the previous one. Their names begin with TWO_WAY_.
+An arrayed implementation uses an array to represent a linear structure. If the array is resizable, the corresponding class name begins with ARRAYED_, for example
+[[ref:libraries/base/reference/arrayed_list_chart|ARRAYED_LIST]] ; if not, the prefix is FIXED_. + +==Linked structures== + +A linked structure requires two classes: one, such as [[ref:libraries/base/reference/linked_list_chart|LINKED_LIST]] , describes the list proper; the other, such as [[ref:libraries/base/reference/linkable_chart|LINKABLE]] , describes the individual list cells. The figure should help understand the difference; it describes a linked list, but the implementation of linked circular chains is similar. + + +[[Image:linked-list|fig.3: Linked list and linked cells]] + + +The instance of type [[ref:libraries/base/reference/linked_list_chart|LINKED_LIST]] shown at the top contains general information about the list, such as the number of items (count) and a reference to the first element (first). Because lists are active structures with a notion of current position, there is also a reference active to the cell at the current position. An entity declared as +my_list: LINKED_LIST [SOME_TYPE] + +will have as its run-time value (if not void) a reference to such an object, which is really a list header. The actual list content is given by the [[ref:libraries/base/reference/linkable_chart|LINKABLE]] instances, each of which contains a value of type SOME_TYPE and a reference to the next item, called right.
+Clearly, a header of type LINKED_LIST [SOME_TYPE] will be associated with cells of type LINKABLE [SOME_TYPE].
+Features such as active and first are used only for the implementation; they are not exported, and so you will not find them in the flat-short specifications, although the figures show them to illustrate the representation technique.
+A similar implementation is used for two-way-linked structures such as two-way lists and two-way circular chains. + + +[[Image:two-way-list|fig.4: Two way linked list]] + + +==Linked cells== + +The classes describing list cells are descendants of a deferred class called [[ref:libraries/base/reference/cell_chart|CELL]] , whose features are: +* item, the contents of the cell. +* put ( v : like item ), which replaces the contents of the cell by a new value. + +Class [[ref:libraries/base/reference/linkable_chart|LINKABLE]] is an effective descendant of [[ref:libraries/base/reference/cell_chart|CELL]] , used for one-way linked structures. It introduces features right, a reference to another cell to which the current
+cell will be linked. Two-way linked structures use [[ref:libraries/base/reference/bi_linkable_chart|BI_LINKABLE]] , an heir of [[ref:libraries/base/reference/linkable_chart|LINKABLE]] which to the above features adds left, a reference to the preceding cell in the structure. + +{{caution|Do not confuse the item feature of [[ref:libraries/base/reference/cell_chart|CELL]] and its descendants, such as [[ref:libraries/base/reference/linkable_chart|LINKABLE]] , with the item feature of the classes describing linear structures, such as [[ref:libraries/base/reference/linked_list_chart|LINKED_LIST]] . For a linked list, item returns the item at cursor position. }} + +It may be implemented as +item: G is + -- Current item + do + Result := active.item + end + +using the item feature of [[ref:libraries/base/reference/linkable_chart|LINKABLE]] , applied to active. + +==One-way and two-way linked chains== + +If you look at the interfaces of one-way and two-way linked structures, you will notice that they are almost identical. This is because it is possible to implement features such as back for one-way structures such as described by [[ref:libraries/base/reference/linked_list_chart|LINKED_LIST]] and [[ref:libraries/base/reference/linked_circular_chart|LINKED_CIRCULAR]] . A simple implementation of back stores away a reference to the current active item, executes start, and then performs forth until the item to the right of the cursor position is the previous active.
+Although correct, such an implementation is of course rather inefficient since it requires a traversal of the list. In terms of algorithmic complexity, it is in O (count), meaning that its execution time is on the average proportional to the number of items in the structure. In contrast, forth is O (1), that is to say, takes an execution time bounded by a constant. + +{{caution|As a consequence, you should not use one-way linked structures if you need to execute more than occasional back operations (and other operations requiring access to previous items, such as remove_left). }} + +Two-way linked structures, such as those described by [[ref:libraries/base/reference/two_way_list_chart|TWO_WAY_LIST]] and [[ref:libraries/base/reference/two_way_circular_chart|TWO_WAY_CIRCULAR]] , treat the two directions symmetrically, so that back will be just as efficient as forth. Hence the following important advice: If you need to traverse a linked structure both ways, not just left to right, use the TWO_WAY_ classes, not the LINKED_ versions. The TWO_WAY_ structures will take up more space, since they use [[ref:libraries/base/reference/bi_linkable_chart|BI_LINKABLE]] rather than [[ref:libraries/base/reference/linkable_chart|LINKABLE]] cells, but for most applications this space penalty is justified by the considerable gains in time that will result if right-to-left operations are frequently needed. + +==Arrayed chains== + +Arrayed structures as described by [[ref:libraries/base/reference/arrayed_list_chart|ARRAYED_LIST]] , [[ref:libraries/base/reference/fixed_list_chart|FIXED_LIST]] and [[ref:libraries/base/reference/arrayed_circular_chart|ARRAYED_CIRCULAR]] use arrays for their implementations. A list or circular chain of count items may be stored in positions 1 to count of an array of capacity items, where capacity >= count.
+An instance of [[ref:libraries/base/reference/fixed_list_chart|FIXED_LIST]] , as the name suggests, has a fixed number of items. In particular: +* Query extendible has value false for [[ref:libraries/base/reference/fixed_list_chart|FIXED_LIST]] : you may replace existing items, but not add any, even at the end. A [[ref:libraries/base/reference/fixed_list_chart|FIXED_LIST]] is created with a certain number of items and retains that number. +* As a result, [[ref:libraries/base/reference/fixed_list_chart|FIXED_LIST]] joins the deferred feature count of [[ref:libraries/base/reference/list_chart|LIST]] with the feature count of ARRAY, which satisfies the property count = capacity. +* Query prunable has value false too: it is not possible to remove an item from a fixed list. + +In contrast, [[ref:libraries/base/reference/arrayed_list_chart|ARRAYED_LIST]] has almost the same interface as [[ref:libraries/base/reference/linked_list_chart|LINKED_LIST]] . In particular, it is possible to add items at the end using procedure extend; if the call causes the list to grow beyond the current array's capacity, it will trigger a resizing. This is achieved by using the procedure force of class ARRAY to implement extend. [[ref:libraries/base/reference/arrayed_list_chart|ARRAYED_LIST]] even has the insertion procedures (put_front, put_left, put_right) and removal procedures (prune, remove, remove_left, remove_right) that apply to arbitrary positions and appear in the linked implementations. These procedures, however, are rather inefficient, since they usually require moving a whole set of array items, an O (count) operation. (Procedure extend does not suffer from this problem, since it is easy to add an item to the end of an array, especially if there is still room so that no resizing is necessary.) + +{{caution|The situation of these features in [[ref:libraries/base/reference/arrayed_list_chart|ARRAYED_LIST]] is similar to the situation of back in classes describing one-way linked structures: it is convenient to include them because they may be needed once in a while and an implementation exists; but using them more than occasionally may result in serious inefficiencies. If you do need to perform arbitrary insertions and removal, use linked structures, not arrayed ones. }} + +Arrayed structures, however, use up less space than linked representations. So they are appropriate for chains on which, except possibly for insertions at the end, few insertion and removal operations or none at all are expected after creation. [[ref:libraries/base/reference/fixed_list_chart|FIXED_LIST]] offers few advantages over [[ref:libraries/base/reference/arrayed_list_chart|ARRAYED_LIST]] . [[ref:libraries/base/reference/fixed_list_chart|FIXED_LIST]] may be useful, however, for cases in which the fixed number of items is part of the specification, and any attempt to add more items must be treated as an error. For circular chains only one variant is available, [[ref:libraries/base/reference/arrayed_circular_chart|ARRAYED_CIRCULAR]] , although writing a FIXED_ version would be a simple exercise. + +==Multi-arrayed lists== + +For lists one more variant is available, combining some of the advantages of arrayed and linked implementations: [[ref:libraries/base/reference/multi_array_list_chart|MULTI_ARRAY_LIST]] . With this implementation a list is
+divided into a number of blocks. Each block is an array, but the successive arrays are linked. + +=Sorted Linear Structures= + +The class [[ref:libraries/base/reference/comparable_struct_chart|COMPARABLE_STRUCT]] , an heir of [[ref:libraries/base/reference/bilinear_chart|BILINEAR]] , is declared as +deferred class + COMPARABLE_STRUCT [G -> COMPARABLE] + inherit + BILINEAR + feature + ... + +As indicated by the constrained generic parameter it describes bilinear structures whose items may be compared by a total order relation. + +{{caution|The class name COMPARABLE_STRUCT, chosen for brevity's sake, is slightly misleading: it is not the structures that are comparable but their items. }} + +COMPARABLE_STRUCT introduces the features min and max, giving access to the minimum and maximum elements of a structure; these are always present for a finite
+structure with a total order relation. [[ref:libraries/base/reference/sorted_struct_chart|SORTED_STRUCT]] , an heir of [[ref:libraries/base/reference/comparable_struct_chart|COMPARABLE_STRUCT]] , describes structures that can be sorted; it introduces the query sorted and the command sort.
+The deferred class [[ref:libraries/base/reference/part_sorted_list_chart|PART_SORTED_LIST]] describes lists whose items are kept ordered in a way that is compatible with a partial order relation defined on them. The class is declared as +deferred class + PART_SORTED_LIST [G -> COMPARABLE]... + +An implementation based on two-way linked lists is available through the effective heir [[ref:libraries/base/reference/sorted_two_way_list_chart|SORTED_TWO_WAY_LIST]] .
+The deferred class [[ref:libraries/base/reference/sorted_list_chart|SORTED_LIST]] , which inherits from [[ref:libraries/base/reference/part_sorted_list_chart|PART_SORTED_LIST]] , assumes that the order relation on G is a total order. As a result, the class is able to introduce features min, max and median. Here too a two-way linked list implementation is available, through the effective class [[ref:libraries/base/reference/sorted_two_way_list_chart|SORTED_TWO_WAY_LIST]] . + + + + diff --git a/documentation/18.11/solutions/basic-computing/eiffelbase/eiffelbase-tutorial/eiffelbase-data-structures-overview/eiffelbase-dispensers.wiki b/documentation/18.11/solutions/basic-computing/eiffelbase/eiffelbase-tutorial/eiffelbase-data-structures-overview/eiffelbase-dispensers.wiki new file mode 100644 index 00000000..c0f21139 --- /dev/null +++ b/documentation/18.11/solutions/basic-computing/eiffelbase/eiffelbase-tutorial/eiffelbase-data-structures-overview/eiffelbase-dispensers.wiki @@ -0,0 +1,38 @@ +[[Property:modification_date|Fri, 14 Sep 2018 22:39:40 GMT]] +[[Property:publication_date|Fri, 14 Sep 2018 22:39:40 GMT]] +[[Property:title|EiffelBase, Dispensers]] +[[Property:weight|2]] +[[Property:uuid|4f65d62b-940b-c3c2-557e-d709a2a1bcaf]] +A dispenser is called that way because of the image of a vending machine (a dispenser) of a rather primitive nature, in which there is only one button. If you press the button and the dispenser is not empty, you get one of its items in the exit tray at the bottom, but you do not choose that item: the machine does. There is also an input slot at the top, into which you may deposit new items; but you have no control over the order in which successive button press operations will retrieve these items. + +The deferred class [[ref:libraries/base/reference/dispenser_chart|DISPENSER]] provides the facilities which will be shared by all specialized classes. In fact, the interface of all dispenser classes is nearly identical, with the exception of a few extra possibilities offered by priority queues. Many kinds of dispenser are possible, each defined by the relation that the machine defines between the order in which items are inserted and the order in which they are returned. The Base libraries support three important categories - stacks, queues, and priority queues: +* A stack is a dispenser with a last-in, first-out (LIFO) internal policy: items come out in the reverse order of their insertion. Each button press returns the last deposited item. +* A queue is a dispenser with a first-in, first-out (FIFO) internal policy: items come out in the order of their insertion. Each button press returns the oldest item deposited and not yet removed. +* In a priority queue, items have an associated notion of order; the element that comes out at any given time is the largest of those which are in the dispenser. + +==Stacks== + +Stacks - dispensers with a LIFO retrieval policy - are a ubiquitous structure in software development. Their most famous application is to parsing (syntactic analysis), but many other types of systems use one or more stacks. Class STACK describes general stacks, without commitment to a representation. This is a deferred class which may not be directly instantiated. The fundamental operations are put (add an element to the top of the stack), item (retrieve the element from the top, non-destructively), remove (remove the element from the top), is_empty (test for an empty stack).
+Three effective heirs are provided: +* [[ref:libraries/base/reference/linked_stack_chart|LINKED_STACK]] : stacks implemented as linked lists, with no limit on the number of items (count). +* [[ref:libraries/base/reference/bounded_stack_chart|BOUNDED_STACK]] : stacks implemented as arrays. For such stacks, the maximum number of items (capacity) is set at creation time. +* [[ref:libraries/base/reference/arrayed_stack_chart|ARRAYED_STACK]] : also implemented as arrays, but in this case there is no limit on the number of items; the interface is the same as [[ref:libraries/base/reference/linked_stack_chart|LINKED_STACK]] except for the creation procedure. If the number of elements exceeds the initially allocated capacity, the array will simply be resized. + +==Queues== + +Class [[ref:libraries/base/reference/queue_chart|QUEUE]] describes general queues, without commitment to a representation. This is a deferred class which may not be directly instantiated. Three non-deferred heirs are also provided, distinguished by the same properties as their stack counterparts: +* [[ref:libraries/base/reference/linked_queue_chart|LINKED_QUEUE]] +* [[ref:libraries/base/reference/bounded_queue_chart|BOUNDED_QUEUE]] +* [[ref:libraries/base/reference/arrayed_queue_chart|ARRAYED_QUEUE]] + +==Priority Queues== + +In a priority queue, each item has an associated priority value, and there is an order relation on these values. The item returned by item or removed by remove is the element with the highest priority.The most general class is [[ref:libraries/base/reference/priority_queue_chart|PRIORITY_QUEUE]] , which is deferred. Two effective variants are provided: +* [[ref:libraries/base/reference/linked_priority_queue_chart|LINKED_PRIORITY_QUEUE]] , a linked list implementation. +* [[ref:libraries/base/reference/heap_priority_queue_chart|HEAP_PRIORITY_QUEUE]] which is more efficient and is to be preferred in most cases. A heap is organized like a binary tree, although physically stored in an array; elements with a high priority percolate towards the root. + +Because it must be possible to compare priorities, the type of the items must conform to [[ref:libraries/base/reference/part_comparable_chart|PART_COMPARABLE]] . Constrained genericity ensures this; all the priority queue classes have a formal generic parameter constrained by [[ref:libraries/base/reference/part_comparable_chart|PART_COMPARABLE]] . + + + + diff --git a/documentation/18.11/solutions/basic-computing/eiffelbase/eiffelbase-tutorial/eiffelbase-data-structures-overview/eiffelbase-iteration.wiki b/documentation/18.11/solutions/basic-computing/eiffelbase/eiffelbase-tutorial/eiffelbase-data-structures-overview/eiffelbase-iteration.wiki new file mode 100644 index 00000000..34f32743 --- /dev/null +++ b/documentation/18.11/solutions/basic-computing/eiffelbase/eiffelbase-tutorial/eiffelbase-data-structures-overview/eiffelbase-iteration.wiki @@ -0,0 +1,535 @@ +[[Property:modification_date|Wed, 12 Sep 2018 17:55:43 GMT]] +[[Property:publication_date|Wed, 12 Sep 2018 13:40:39 GMT]] +[[Property:title|EiffelBase, Iteration]] +[[Property:weight|6]] +[[Property:uuid|9c0313bf-571d-0c8d-5c49-8bd99f86bed5]] +The classes of the Iteration cluster encapsulate control structures representing common traversal operations. + +=Iterators and Agents= + +Eiffel's agent mechanism offers an attractive alternative to the Iterator cluster of EiffelBase. + +=The Notion of iterator= + +Let us first explore the role of iterators in the architecture of a system. + +==Iterating over data structures== + +Client software that uses data structures of a certain type, for example lists or trees, often needs to traverse a data structure of that type in a predetermined order so as to apply a certain action to all the items of the structure, or to all items that satisfy a certain criterion. Such a systematic traversal is called an iteration.
+Cases of iteration can be found in almost any system. Here are a few typical examples: +* A text processing system may maintain a list of paragraphs. In response to a user command, such as a request to resize the column width, the system will iterate over the entire list so as to update all paragraphs. +* A business system may maintain a list of customers. If the company decides that a special promotion will target all customers satisfying a certain criterion (for example all customers that have bought at least one product over the past six months), the system will iterate over the list, generating a mailing for every list item that satisfies the criterion. +* An interactive development environment for a programming language may maintain a syntax tree. In response to a program change, the system will traverse the tree to determine what nodes are affected by the change and update them. + +These examples illustrate the general properties of iteration. An iteration involves a data structure of a known general type and a particular ordering of the structure's items. For some structures, more than one ordering will be available; for example a tree iteration may use preorder, postorder or breadth-first (as defined below). The iteration involves an operation, say item_action, to be applied to the selected items. It may also involve a boolean-valued query, say item_test, applicable to candidate items. Finally, it involves a certain policy, usually based on item_test, as to which items should be subjected to item_action. Typical example policies are: +* Apply item_action to all the items in the structure. (In this case item_test is not relevant). +* Apply item_action to all items that satisfy item_test. +* Apply item_action to all items up to the first one that satisfies item_test. + +The Iteration library provides many more, covering in particular all the standard control structures. + +==Iterations and control structures== + +You can perform iterations without any special iteration classes. For example if customers is declared as +customers: LIST [CUSTOMER] + +then a class SPECIAL_PROMOTION of a text processing system may include in one of its routines a loop of the form + + from + customers.start + until + customers.exhausted + loop + if recent_purchases.has (customers.item) then + target_list.put (customers.item) + end + customers.forth + end + +Such schemes are quite common. But it is precisely because they occur frequently that it is useful to rely on library classes to handle them. One of the principal tasks of object-oriented software development is to identify recurring patterns and build reusable classes that encapsulate them, so that future developers will be able to rely on ready-made solutions.
+The classes of the Iteration library address this need. Using them offers two benefits: +* You avoid writing loops, in which the definition of sub-components such as exit conditions, variants and invariants is often delicate or error-prone. +* You can more easily adapt the resulting features in descendant classes. The rest of this chapter shows how to obtain these benefits. + +=Simple Examples= + +To get a first grasp of how one can work with the Iteration library, let us look at a typical iteration class and a typical iteration client. + +==An example iterator routine== + +Here, given with its full implementation, is a typical Iteration library routine: the procedure until_do from [[ref:libraries/base/reference/linear_iterator_chart|LINEAR_ITERATOR]] , the class defining iteration mechanisms on linear (sequential) structures. + + until_do (action: PROCEDURE [G]; test: FUNCTION [G, BOOLEAN]) + -- Apply `action' to every item of `target' up to + -- but excluding first one satisfying `test'. + -- (Apply to full list if no item satisfies `test'.) + do + start + until_continue (action, test) + ensure then + achieved: not exhausted implies test.item ([target.item]) + end + + until_continue (action: PROCEDURE [G]; test: FUNCTION [G, BOOLEAN]) + -- Apply `action' to every item of `target' from current + -- position, up to but excluding first one satisfying `test'. + require + invariant_satisfied: invariant_value + do + from + invariant + invariant_value + until + exhausted or else test.item ([target.item]) + loop + action.call ([item]) + forth + end + ensure + achieved: exhausted or else test.item ([target.item]) + invariant_satisfied: invariant_value + end + + +The precise form of the procedure in the class relies on a call to another procedure, until_continue, and on inherited assertions. Here the routines are shown as they are found in the current implementation of the class [[ref:libraries/base/reference/linear_iterator_chart|LINEAR_ITERATOR]].
+This procedure will traverse the linear structure identified by [[ref:libraries/base/linear_iterator_flatshort.html#f_target|target]] and apply the procedure called action on every item up to but excluding the first one satisfying test.
+The class similarly offers do_all, do_while, do_for, do_if and other procedures representing the common control structures. It also includes functions such as exists and forall, corresponding to the usual quantifiers.
+These iteration schemes depend on the procedure action, defining the action to be applied to successive elements, and on the function test, defining the boolean query to be applied to these elements. Both routines are used trough the Eiffel's agent mechanism; here is an example of a test +function intended to be used with iteration over a data structure whose elements are STRINGs. + + test (a_item: STRING): BOOLEAN + -- Test to be applied to a_item + do + Result := a_item.count > 0 + end + + +This indicates that the value of the boolean function test will be obtained by verifying that a_item is an empty string or not. + +==An example use of iteration== + +Here now is an example illustrating the use of these mechanisms. The result will enable us to resize all the paragraphs of a text up to the first one that has been modified - as we might need to do, in a text processing system, to process an interactive user request. Assume a class TEXT that describes lists of paragraphs with certain additional features. The example will also assume a class PARAGRAPH with a procedure resize, and a boolean-valued attribute modified which indicates whether a paragraph has been modified. Class TEXT inherits from [[ref:libraries/base/reference/linked_list_chart|LINKED_LIST]] and so is a descendant of [[ref:libraries/base/reference/linear_chart|LINEAR]] : + +class + TEXT + +inherit + LINKED_LIST [PARAGRAPH] + ... +feature + ... +end + +In a class TEXT_PROCESSOR, you can use an iteration procedure to write a very simple procedure resize_ paragraphs that will resize all paragraphs up to but excluding the first one that has been modified: + +class + TEXT_PROCESSOR + +inherit + LINEAR_ITERATOR [PARAGRAPH] + +feature + + resize_paragraphs (t: TEXT) + -- Resize all the paragraphs of t up to but excluding + -- the first one that has been modified. + do + set (t) + until_do (agent item_action, agent item_test) + end + +feature {NONE} + + item_test (p: PARAGRAPH): BOOLEAN + -- Has p been modified? + do + Result := p.modified + end + + item_action (p: PARAGRAPH) + -- Resize p. + do + p.resize + end + ... +end + +Thanks to the iteration mechanism, the procedure resize_paragraphs simply needs two procedure calls: +* To set its argument t as the iteration target, it uses procedure set. (This procedure is from class [[ref:libraries/base/reference/iterator_chart|ITERATOR]] which passes it on to all iterator classes.) +* Then it simply calls until_do as defined above. + +Procedure item_action is defined to describe the operation to be performed on each successive element. Function item_test is defined to describe the exit test.
+As presented so far, the mechanism seems to limit every descendant of an iteration class to just one form of iteration. As shown later in this chapter, it is in fact easy to generalize the technique to allow a class to use an arbitrary number of iteration schemes.
+What is interesting here is that the definitions of item_test and item_action take care of all the details. There is no need to write any loop or other control structure. We are at the very heart of the object-oriented method, enjoying the ability to encapsulate useful and common software schemes so that client developers will only need to fill in what is specific to their application. + +=Using the Iteration Library= + +Let us now explore the classes of the Iteration library and the different ways of using them. + +==Overview of the classes== + +There are only four Iteration classes, whose simple inheritance structure appeared at the beginning of this chapter. +* [[ref:libraries/base/reference/iterator_chart|ITERATOR]] , a deferred class which describes the most general notion. +* [[ref:libraries/base/reference/linear_iterator_chart|LINEAR_ITERATOR]] , for iterating over linear structures and chains. +* [[ref:libraries/base/reference/two_way_chain_iterator_chart|TWO_WAY_CHAIN_ITERATOR]] , a repeated heir of [[ref:libraries/base/reference/linear_iterator_chart|LINEAR_ITERATOR]] , for iterating in either direction over a bilinear structure. +* [[ref:libraries/base/reference/cursor_tree_iterator_chart|CURSOR_TREE_ITERATOR]] , for iterating over trees. + +As you will remember from the [[EiffelBase, Abstract Container Structures: The Taxonomy|presentation]] of the abstract overall taxonomy, the traversal hierarchy describes how data structures can be traversed; its most general class is [[ref:libraries/base/reference/two_way_list_chart|TRAVERSABLE]] .
+Each one of the iterator classes is paired with a traversal class (or two in one case): + + +{| border="1" +|- +| [[ref:libraries/base/reference/iterator_chart|ITERATOR]] +| [[ref:libraries/base/reference/two_way_list_chart|TRAVERSABLE]] +|- +| [[ref:libraries/base/reference/linear_iterator_chart|LINEAR_ITERATOR]] +| [[ref:libraries/base/reference/linear_chart|LINEAR]] +|- +| [[ref:libraries/base/reference/two_way_chain_iterator_chart|TWO_WAY_CHAIN_ITERATOR]] +| [[ref:libraries/base/reference/two_way_list_chart|TWO_WAY_LIST]] +|- +| [[ref:libraries/base/reference/two_way_chain_iterator_chart|TWO_WAY_CHAIN_ITERATOR]] +| [[ref:libraries/base/reference/two_way_list_chart|TWO_WAY_LIST]] , [[ref:libraries/base/reference/two_way_circular_chart|TWO_WAY_CIRCULAR]] +|- +| [[ref:libraries/base/reference/cursor_tree_iterator_chart|CURSOR_TREE_ITERATOR]] +| [[ref:libraries/base/reference/cursor_tree_chart|CURSOR_TREE]] +|} + + +Each iterator class relies on the corresponding traversal class to provide the features for traversing the corresponding data structures, such as start, forth, and exhausted for linear structures.
+Of course the data structure class used in connection with a given iterator class does not need to be the iterator's exact correspondent as given by the above table; it may be any one of its descendants. For example you may use [[ref:libraries/base/reference/linear_iterator_chart|LINEAR_ITERATOR]] to iterate over data structures described not just by [[ref:libraries/base/reference/linear_chart|LINEAR]] but also by such descendants as [[ref:libraries/base/reference/list_chart|LIST]] , [[ref:libraries/base/reference/linked_list_chart|LINKED_LIST]] , [[ref:libraries/base/reference/arrayed_list_chart|ARRAYED_LIST]] , or even [[ref:libraries/base/reference/two_way_list_chart|TWO_WAY_LIST]] if you do not need the backward iteration features (for which you will have to use [[ref:libraries/base/reference/two_way_chain_iterator_chart|TWO_WAY_CHAIN_ITERATOR]] ). + +==General iteration facilities== + +Class [[ref:libraries/base/reference/iterator_chart|ITERATOR]] defines the features that apply to all forms of iterator.
+An iterator will always apply to a certain target structure. The target is introduced in [[ref:libraries/base/reference/iterator_chart|ITERATOR]] by the feature target: [[ref:libraries/base/reference/traversable_chart|TRAVERSABLE]] [G]
+Both the iterator classes and the traversal classes are generic, with a formal generic parameter G. The actual generic parameters will be matched through the choice of iteration target: for a generic derivation of the form SOME_ITERATOR [ ACTUAL_TYPE] the target can only be of type SOME_TRAVERSABLE [ACTUAL_TYPE] for the same ACTUAL_TYPE, where SOME_TRAVERSABLE is the traversal class matching SOME_ITERATOR according to the preceding table ([[ref:libraries/base/reference/linear_chart|LINEAR]] for [[ref:libraries/base/reference/linear_iterator_chart|LINEAR_ITERATOR]] and so on), or one of its proper descendants.
+Each of the proper descendants of [[ref:libraries/base/reference/iterator_chart|ITERATOR]] redefines the type of target to the matching proper descendant of [[ref:libraries/base/reference/traversable_chart|TRAVERSABLE]] , to cover more specific variants of the iteration target. For example in [[ref:libraries/base/reference/linear_iterator_chart|LINEAR_ITERATOR]] the feature is redefined to be of type [[ref:libraries/base/reference/linear_chart|LINEAR]]. [[ref:libraries/base/reference/iterator_chart|ITERATOR]] also introduces the procedure for selecting a target: + + set (s: like target) + -- Make s the new target of iterations. + require + s /= Void + do + target := s + ensure + target = s + target /= Void + end + +Another feature introduced in [[ref:libraries/base/reference/iterator_chart|ITERATOR]] is the query invariant_value, describing invariant properties that must be ensured at the beginning of any iteration and preserved by every iteration step. As declared in [[ref:libraries/base/reference/iterator_chart|ITERATOR]] this query always returns true, but proper descendants can redefine it to describe more interesting invariant properties.
+Finally, [[ref:libraries/base/reference/iterator_chart|ITERATOR]] introduces in deferred form the general iteration routines applicable to all iteration variants. They include two queries corresponding to the quantifiers of first-order predicate calculus: +* for_all will return true if all items of the target structure satisfy test. +* there_exists will return true if at least one item satisfies test. + +The other routines are commands which will traverse the target structure and apply action to items selected through test: +* do_all applies action to all items. +* do_if, to those items which satisfy test. +* until_do, to all items up to but excluding the first one that satisfies test. +* do_until, to all items up to and including the first one that satisfies test. +* while_do and do_while, to all items up to the first one that does not satisfy test. (This can also be achieved with until_do or do_until by choosing the opposite test.) + +Some of these features and most of the other iteration features introduced in proper descendants of [[ref:libraries/base/reference/iterator_chart|ITERATOR]] and described next, have either an action argument that must be of type PROCEDURE [G] or an argument test of type FUNCTION [G, BOOLEAN]. Some have both. Information about the target of the iterations comes from feature target, set by procedure set; information about what needs to be done for each item of the target structure comes from the argument action passed to the routines referenced above. + +==Linear and chain iteration== + +[[ref:libraries/base/reference/linear_iterator_chart|LINEAR_ITERATOR]] , an effective class, refines the iteration mechanisms for cases in which the target is a linear structure, such as a list in any implementation or a circular chain.
+The class effects all the deferred features inherited from [[ref:libraries/base/reference/iterator_chart|ITERATOR]] , taking advantage of the linear traversal mechanisms present in the corresponding traversal class, [[ref:libraries/base/reference/linear_chart|LINEAR]] . [[#An example iterator routine|Here]] for example is the effecting of until_do.
+This routine text relies on features start, forth and exhausted which, together with off, have for convenience been carried over to [[ref:libraries/base/reference/linear_iterator_chart|LINEAR_ITERATOR]] from their counterparts in [[ref:libraries/base/reference/linear_chart|LINEAR]] , with feature declarations such as + + off: BOOLEAN + -- Is position of target off? + require + traversable_exists: target /= Void + do + Result := target.off + end + +and similarly for the others.
+In addition to effecting the general iteration features from [[ref:libraries/base/reference/iterator_chart|ITERATOR]] , class [[ref:libraries/base/reference/linear_iterator_chart|LINEAR_ITERATOR]] introduces iteration features that apply to the specific case of linear structures: +* search (test: FUNCTION [G, BOOLEAN]; b: BOOLEAN) moves the iteration to the first position satisfying test if both test and b have the same value (both True or both False). +* With a linear structure we can implement an iteration corresponding to the 'for' loop of traditional programming languages, defined by three integers: the starting position, the number of items to be traversed, and the step between consecutive items. This is provided by procedure do_for (action: PROCEDURE [G]; starting , number , step: INTEGER). +* Since with a linear target the iterator can advance the cursor step by step, the basic iteration operations are complemented by variants which pick up from the position reached by the last call: continue_until, until_continue, continue_while, while_continue, continue_search, continue_for. + +==Two-way iteration== + +Class [[ref:libraries/base/reference/two_way_chain_iterator_chart|TWO_WAY_CHAIN_ITERATOR]] has all the features of [[ref:libraries/base/reference/linear_iterator_chart|LINEAR_ITERATOR]] , to which it adds features for iterating backward as well as forward.
+The class introduces commands finish and back, applying the corresponding operations to the two-way target. It also has a backward variant for every iteration feature. The name of each such variant is the name of the forward feature followed by ''_back'': do_all_back, until_do_back and so on.
+An alternative design would have kept just one set of features and added two features: a command reverse to reverse the direction of future iteration operations, and a query backward to find out the direction currently in force.
+Contrary to what one might at first imagine, class [[ref:libraries/base/reference/two_way_chain_iterator_chart|TWO_WAY_CHAIN_ITERATOR]] is extremely short and simple; its Feature clause only contains the declarations of two features, finish and back.
+The trick is to use repeated inheritance. [[ref:libraries/base/reference/two_way_chain_iterator_chart|TWO_WAY_CHAIN_ITERATOR]] inherits twice from [[ref:libraries/base/reference/linear_iterator_chart|LINEAR_ITERATOR]] ; the first inheritance branch yields the forward iteration features, the second yields those for backward iteration. There is no need for any explicit declaration or redeclaration of iteration features. Here is the entire class text that yields this result: + +class TWO_WAY_CHAIN_ITERATOR [G] inherit + + LINEAR_ITERATOR [G] + redefine + target + select + start, + forth, + do_all, + until_do, + do_until, + while_do, + do_while, + do_if, + do_for, + search, + for_all, + there_exists, + until_continue, + continue_until, + while_continue, + continue_while, + continue_for, + continue_search + end + + LINEAR_ITERATOR [G] + rename + start as finish, + forth as back, + do_all as do_all_back, + until_do as until_do_back, + do_until as do_until_back, + do_while as do_while_back, + while_do as while_do_back, + do_if as do_if_back, + do_for as do_for_back, + search as search_back, + for_all as for_all_back, + there_exists as there_exists_back, + until_continue as until_continue_back, + continue_until as continue_until_back, + while_continue as while_continue_back, + continue_while as continue_while_back, + continue_for as continue_for_back, + continue_search as continue_search_back + redefine + back, finish, target + end + +create + set + +feature -- Access + + target: CHAIN [G] + +feature -- Cursor movement + + finish + -- Move cursor of `target' to last position. + do + target.finish + end + + back + -- Move cursor of `target' backward one position. + do + target.back + end + +end + + +This class provides a good example of the economy of expression that the full inheritance mechanism affords through the combination of renaming, redefinition, repeated inheritance rules and selection, without sacrificing clarity and maintainability. + +==Tree iteration== + +Tree iterations, provided by class [[ref:libraries/base/reference/cursor_tree_iterator_chart|CURSOR_TREE_ITERATOR]] , work on trees of the cursor tree form; only with this form of tree are traversal operations possible. Three forms of iteration are provided: preorder, postorder and breadth-first. They correspond to the three traversal policies described in the discussion of trees. Here too it would seem that a rather lengthy class is needed, but repeated inheritance works wonders.
+[[ref:libraries/base/reference/cursor_tree_iterator_chart|CURSOR_TREE_ITERATOR]] simply inherits three times from [[ref:libraries/base/reference/linear_iterator_chart|LINEAR_ITERATOR]] , renaming the features appropriately in each case: +* pre_do_all, pre_until, and so on. +* post_do_all, post_until, and so on. +* breadth_do_all, breadth_until, and so on. + +All it needs to do then is to redefine the type of target to be [[ref:libraries/base/reference/cursor_tree_chart|CURSOR_TREE [G]]] , and to redefine six features: the three renamed start (pre_start, etc.) and the three forth ( pre_ forth, and so on). These seven redefinitions give us a full-fledged battery of tree iteration mechanisms. + +=Building and Using Iterators= + +To conclude this discussion, let us now put together the various mechanisms studied so far, to see how authors of client software can use the Iteration library to perform possibly complex iterations on various data structures without ever writing a single loop or test. The basic ideas were sketched above but now we have all the elements for the full view.
+An application class may use one of the iteration classes in either of two ways: as a descendant (single or repeated) or as a client. The descendant technique is extremely simple but less versatile. + +==The single descendant technique== + +Assume an application class PROCESSOR that is a proper descendant of one of the effective iteration classes studied in this chapter. Then a routine of PROCESSOR, say iterate, may iterate a certain action over a data structure, subject to a certain test. First, class PROCESSOR must specify the action by redefining item_action and item_test (or, in the most general case, action and test). Then routine iterate must specify the target data structure through a call of the form set (t) where t represents the selected target data structure. The type of t must correspond to the iteration class selected as ancestor of PROCESSOR: for [[ref:libraries/base/reference/linear_iterator_chart|LINEAR_ITERATOR]] it must be a descendant of [[ref:libraries/base/reference/linear_chart|LINEAR]] (such as [[ref:libraries/base/reference/linked_list_chart|LINKED_LIST]] , [[ref:libraries/base/reference/arrayed_list_chart|ARRAYED_LIST]] , LINKED_CIRCULAR or any other list or circular chain classes); for [[ref:libraries/base/reference/two_way_chain_iterator_chart|TWO_WAY_CHAIN_ITERATOR]] it must be a descendant of [[ref:libraries/base/reference/linear_chart|BILINEAR]] such as [[ref:libraries/base/reference/two_way_list_chart|TWO_WAY_LIST]] or [[ref:libraries/base/reference/two_way_circular_chart|TWO_WAY_CIRCULAR]] ; for [[ref:libraries/base/reference/cursor_tree_iterator_chart|CURSOR_TREE_ITERATOR]] it must be a descendant of [[ref:libraries/base/reference/cursor_tree_chart|CURSOR_TREE]] . In all cases the actual generic parameters of the iterator class and ofthe data structure class must be compatible. Then the iteration proper is obtained simply by calling the appropriate procedure, without any qualification or arguments, for example: do_ if
+It is hard to imagine a simpler scheme: no loops, no initialization, no arguments. Feature item_action may need to rely on some variable values. Because it does not take any argument, such values will have to be treated as attributes, with the corresponding set_... procedures to set and change their values. This also applies to the two schemes set next.
+The single descendant technique has one drawback: it provides the iterating class, PROCESSOR, with only one set of iteration particulars. This limitation does not affect the number of targets: you may use as many targets as you wish, as long as they are of compatible types, by calling a routine such as iterate several times, or calling several such routines, each call being preceded by a call to set to define a new target. The limitation also does not affect the iterating scheme: one iteration could use do_if, the next do_all and so on. But it does require the action and test to be the same in all cases.
+The next two techniques will remove this limitation. + +==Using repeated inheritance== + +One way to obtain several iteration schemes is a simple extension to the single descendant technique. You can use repeated inheritance to provide two or more variants. We have in fact already encountered the technique when studying how to derive [[ref:libraries/base/reference/two_way_chain_iterator_chart|TWO_WAY_CHAIN_ITERATOR]] and [[ref:libraries/base/reference/cursor_tree_iterator_chart|CURSOR_TREE_ITERATOR]] from [[ref:libraries/base/reference/linear_iterator_chart|LINEAR_ITERATOR]] . The general pattern, applied here to just two iteration schemes but easily generalized to more, is straightforward: + +class + DUAL_PROCESSOR + +inherit + LINEAR_ITERATOR [SOME_TYPE] + rename + item_action as action1, + item_test as test1, + do_if as do_if1, + redefine + action1, test1 + select + action1, test1 + end + + LINEAR_ITERATOR [SOME_TYPE] + rename + item_action as action2, + item_test as test2, + do_if as do_if2, + redefine + action2, test2 + end + +feature + + action1 + -- Action for the first scheme + do + ... + end + + test1: BOOLEAN + -- Test for the first scheme + do + ... + end + + action2 + -- Action for the second scheme + do + ... + end + + test2: BOOLEAN + -- Test for the second scheme + do + ... + end + + iterate1 + -- Execute iteration of first kind. + do + set (...) + do_if1 + end + + iterate2 + -- Execute iteration of second kind. + do + set (...) + do_if2 + end + + ... +end + + +The repeated inheritance machinery takes care of the rest. + +==Using explicit iterator objects== + +To obtain maximum flexibility, classes that need iteration facilities should be clients rather than descendants of the iteration classes. The resulting scheme is completely dynamic: to perform iterations you use iterator objects as discussed earlier.
+The following example illustrates the technique. Consider a deferred class FIGURE describing the notion of graphical figure, with many effective descendants ( POLYGON, CIRCLE and so on). It is useful to define COMPLEX_FIGURE, describing figures that are recursively composed of sub-figures. This is a remarkable example of multiple inheritance: + +class + COMPLEX_FIGURE + +inherit + FIGURE, + LINKED_LIST [FIGURE] + +feature + ... +end + + +In the feature clause we want to provide the appropriate effectings for the deferred features of class FIGURE: display, hide, translate and all other basic figure operations.
+We can use loops for that purpose, for example + + display + -- Recursively display all components of the complex + -- figure + do + from + start + until + exhausted + loop + item.display + forth + end + end + + +Although acceptable and even elegant, this scheme will cause significant duplication: all the FIGURE features - not just display but also hide, rotate, move and others - will have the same structure, with a loop. We can use iterators to avoid this duplication. The repeated inheritance technique would work, but given the large number of FIGURE features the amount of repeated inheritance that would be needed seems unwieldy. It is also not very desirable to have to change the inheritance structure of the system just to add a new feature to FIGURE. The more dynamic approach using iterator objects seems preferable.
+To implement this approach, define a class for iterating on complex figures: + +class + COMPLEX_FIGURE_ITERATOR + +inherit + LINEAR_ITERATOR + redefine + target + end + +create + set + +feature + + target: COMPLEX_FIGURE + +end + + +Then for each operation to be iterated define a small class. For example: + +class + FIGURE_DISPLAYER + +inherit + COMPLEX_FIGURE_ITERATOR + redefine + item_action + end + +create + set + +feature + + item_action (f: FIGURE) + -- Action to be applied to each figure: display + -- it. + do + f.display + end +end + + +Similarly, you may define FIGURE_HIDER, FIGURE_MOVER and others. Then the features of COMPLEX_FIGURE are written almost trivially, without any explicit loops; for example: + + display + -- Recursively display all components of the complex + -- figure + local + disp: FIGURE_DISPLAYER + do + create disp.set (Current) + disp.do_all + end + + +and similarly for all the others.
+Note the use of set as creation procedure, which is more convenient than requiring the clients first to create an iterator object and then to call set. This is also safer, since with set as a creation procedure the client cannot forget to initialize the target. (If a class C has a creation clause, the creation instruction create C.) + + + + diff --git a/documentation/18.11/solutions/basic-computing/eiffelbase/eiffelbase-tutorial/eiffelbase-data-structures-overview/eiffelbase-sets.wiki b/documentation/18.11/solutions/basic-computing/eiffelbase/eiffelbase-tutorial/eiffelbase-data-structures-overview/eiffelbase-sets.wiki new file mode 100644 index 00000000..c9a0b3b9 --- /dev/null +++ b/documentation/18.11/solutions/basic-computing/eiffelbase/eiffelbase-tutorial/eiffelbase-data-structures-overview/eiffelbase-sets.wiki @@ -0,0 +1,33 @@ +[[Property:title|EiffelBase, Sets]] +[[Property:weight|4]] +[[Property:uuid|44d33f46-cfa9-2aca-6b4f-2d9d91723d85]] +Sets are containers where successive occurrences of the same item are not distinguished: inserting the same item twice has the same observable effect as inserting it once. + +==Deferred classes== + +The most general class describing sets is [[ref:libraries/base/reference/set_chart|SET]] . The usual operations of set theory such as union and intersection have been relegated to [[ref:libraries/base/reference/subset_chart|SUBSET]] , an heir of [[ref:libraries/base/reference/set_chart|SET]] . This enables a class to inherit from [[ref:libraries/base/reference/set_chart|SET]] without having to effect these operations if it satisfies the basic set property but has no convenient implementation of the subset operations. + +==Sets without a notion of order== + +[[ref:libraries/base/reference/linked_set_chart|LINKED_SET]] provides a basic implementation of [[ref:libraries/base/reference/set_chart|SET]] by linked lists. + +==Sets of comparable elements and sorted sets== + +The deferred class [[ref:libraries/base/reference/comparable_set_chart|COMPARABLE_SET]] , declared as + +deferred class + COMPARABLE_SET [G -> COMPARABLE] + + inherit + SUBSET [G] + COMPARABLE_STRUCT [G] + ... + + +describes sets whose items may be compared by a total order relation. The class has the features [[ref:libraries/base/reference/comparable_set_chart|min]] and [[ref:libraries/base/reference/comparable_set_chart|max]] .
+Two implementations of [[ref:libraries/base/reference/comparable_set_chart|COMPARABLE_SET]] are provided. One, [[ref:libraries/base/reference/two_way_sorted_set_chart|TWO_WAY_SORTED_SET]] , uses sorted two-way lists. The other, [[ref:libraries/base/reference/binary_search_tree_set_chart|BINARY_SEARCH_TREE_SET]] , uses binary search trees.
+If the items are partially rather than totally ordered, you may use the class PART_SORTED_SET [G -> PART_COMPARABLE]], which uses a two-way sorted list implementation. + + + + diff --git a/documentation/18.11/solutions/basic-computing/eiffelbase/eiffelbase-tutorial/eiffelbase-data-structures-overview/eiffelbase-tables.wiki b/documentation/18.11/solutions/basic-computing/eiffelbase/eiffelbase-tutorial/eiffelbase-data-structures-overview/eiffelbase-tables.wiki new file mode 100644 index 00000000..56ce576d --- /dev/null +++ b/documentation/18.11/solutions/basic-computing/eiffelbase/eiffelbase-tutorial/eiffelbase-data-structures-overview/eiffelbase-tables.wiki @@ -0,0 +1,60 @@ +[[Property:title|EiffelBase, Tables]] +[[Property:weight|5]] +[[Property:uuid|194a63a2-e440-18dc-c9d5-6959dbe169fb]] +Hash tables are a convenient mechanism tostore and retrieve objects identified by unique keys. +==Why use hash tables?== +The main advantage of hash tables is the efficiency of the basic operations: store ( [[ref:libraries/base/reference/hash_table_chart|put]] ) and retrieve ( [[ref:libraries/base/reference/hash_table_chart|item]] , [[ref:libraries/base/reference/hash_table_chart|remove]] ).
+The idea behind hash tables is to try to emulate the data structure that provides the ultimate in efficiency: the array. On an array a, for some integer i whose value lies within the bounds of a, the basic operations are + + a.put (x, i) + x := a.item (i) + x := a @ i + +The first causes the value of a at index i to be x; the second (and the third, which is simply a syntactical variant) access the value at index i and assign it to x. With the usual computer architectures, these operations are very fast: because arrays items are stored contiguously in memory, a computer will need just one addition (base address plus index) and one memory access to perform a put or item.
+Not only are the operation times small; they are constant (or more precisely bounded by a constant). This is a great advantage over structures such as lists or trees which you must traverse at least in part to retrieve an item, so that access and modification times grow with the number of items. With an array, disregarding the influence of other factors such as memory paging, the time for a put or item is for all practical purposes the same whether the array has five items or five hundred thousand. These properties make arrays excellent data structures for keeping objects. Unfortunately, they are only applicable if the objects satisfy three requirements: +* '''A1'''. For each object there must be an associated integer, which for the purpose of this discussion we may call the object's index (since it will serve as index for the object in the array.) +* '''A2'''. No two objects may have the same index. +* '''A3'''. If we want to avoid wasting huge amount of storage, all the indices must lie in a contiguous or almost contiguous range. + +Hash tables may be viewed as a rehabilitation mechanism for objects that do not naturally possess these three properties. If we are unable to find a natural index, we can sometimes devise an artificial one. To do so we must be able to find a key. Each key must uniquely identify the corresponding object; this is the same as property '''A2''', making keys similar to indices. But keys are not necessarily integers (violating property '''A1'''), although it must be possible to associate an integer with each key. The mechanism that maps keys to integers is called the hashing function.
+Thanks to the hashing mechanism we will indeed be able to store suitable objects into arrays, approaching the optimal efficiency of this data structure. The efficiency will not be quite as good, however, for two reasons: +* We must pay the price of computing the hash function whenever we store or retrieve an object. +* Different keys may hash into the same integer value, requiring extra processing to find an acceptable index. + +With good implementations, however, it is possible to use hash tables with a performance that is not much worse than that of arrays and, most importantly, may be treated as if the time for a put, an item or a remove were constant. This will mean that you can consider operations such as + + h.put (x, k) + x := h.item (k) + +where h is a hash-table and k is a key (for example a string) as conceptually equivalent to the array operations mentioned above.
+The quality of a hashed implementation will depend both on the data structure that will store the objects, and on the choice of hashing function. Class [[ref:libraries/base/reference/hash_table_chart|HASH_TABLE]] attempts to address the first concern; for the second, client developers will be responsible for choosing the proper hashing function, although Base provides a few predefined functions, in particular for class [[ref:libraries/base/reference/string_8_chart|STRING]] . + +==When hash tables are appropriate== + +You may keep objects in a hash table if for each one of these objects you can find a key that uniquely identifies it. The objects and their keys may be of many possible kinds: +* '''H1'''. In a simple example, the objects are integers; each integer serves as its own key. (More precisely we will use its absolute value, since it is convenient to have non-negative keys only.) This case is of more than theoretical interest, since it makes hash tables appropriate for storing a set of integers with widely scattered values, for which simple array storage would be a waste of space (see requirement '''A3''' above). +* '''H2'''. Frequently, the objects will be composite, that is to say, instances of a developer-defined class, and one of the attributes of that class, of type [[ref:libraries/base/reference/string_8_chart|STRING]] , can serve as the key. For example if you were writing an Eiffel compiler you would probably need to keep a data structure that includes information about classes of the system. Each class is represented by an object with several fields describing the properties of the class; one of these fields, the class name, corresponding to an attribute of type [[ref:libraries/base/reference/string_8_chart|STRING]] , will serve as key. +* '''H3'''. Instead of being the full object (as in case '''H1''') or one of the object's fields (as in case '''H2'''), the key may have to be computed through a function of the generating class, which will take into account several attributes of the class (that is to say, for each object, several fields). + +What this practically means is that in all cases you will need, in the generating class of the objects to be stored, a query (attribute or function) that gives the key. The type of the key is highly variable but must in all cases be a descendant of [[ref:libraries/base/reference/hashable_chart|HASHABLE]] . This is true of both [[ref:libraries/base/reference/integer_32_chart|INTEGER]] (case '''H1''') and [[ref:libraries/base/reference/string_8_chart|STRING]] (case '''H2'''). The requirements for being a [[ref:libraries/base/reference/hashable_chart|HASHABLE]] are not harsh: all you need is a function hash_code that returns a non-negative integer.> + +==Using hash tables== + +Class [[ref:libraries/base/reference/hash_table_chart|HASH_TABLE]] takes two generic parameters: + +class HASH_TABLE [G, H -> HASHABLE] ... + +G represents the type of the objects to be stored in the hash table, H the type of their keys.
+When viewed as an implementation of containers, [[ref:libraries/base/reference/hash_table_chart|HASH_TABLE]] , in a strict sense, represents bags rather than sets: unlike the other classes in this chapter, it allows an object to have two or more distinct occurrences in a single container. But this is only true if we consider a hash table as a repository of objects of type G. In reality each item of the table is identified by a pair of values, one from G and one from H. Because the keys must uniquely identify objects, the hash table viewed as a container of such pairs is indeed a set. The creation procedure make takes an integer argument, as in + + create my_table.make (n) + +The value of n indicates how many items the hash table is expected to have to accommodate. This number of items is not a hardwired size, just information passed to the class. In particular: +* The actual size of the underlying array representation will be higher than n since efficient operation of hash table algorithms require the presence of enough breathing space - unoccupied positions. +* If the number of items in the table grows beyond the initial allocation, the table will automatically be resized. + +It is useful, however, to use a reasonable upon creation: not too large to avoid wasting space, but not too small to avoid frequent applications of resizing, an expensive operation. + + + + diff --git a/documentation/18.11/solutions/basic-computing/eiffelbase/eiffelbase-tutorial/eiffelbase-data-structures-overview/eiffelbase-trees.wiki b/documentation/18.11/solutions/basic-computing/eiffelbase/eiffelbase-tutorial/eiffelbase-data-structures-overview/eiffelbase-trees.wiki new file mode 100644 index 00000000..c3026832 --- /dev/null +++ b/documentation/18.11/solutions/basic-computing/eiffelbase/eiffelbase-tutorial/eiffelbase-data-structures-overview/eiffelbase-trees.wiki @@ -0,0 +1,128 @@ +[[Property:title|EiffelBase, Trees]] +[[Property:weight|3]] +[[Property:uuid|8357fc1a-a089-c846-aee8-18b8fb26c288]] +Trees and their immediate generalization, forests, are useful for any system that manipulates hierarchically organized information. The range of applications is broad, from abstract syntax trees in compilers through document structures in text processing systems to company organization charts in business software.
+Trees, in particular binary trees and their variants, also provide convenient implementations of container data structures. + +==Basic Terminology== + +A tree consists of a set of nodes. Each node may have zero or more children, other nodes of which it is the parent. Each node has at most one parent, although it may have an arbitrary number of children. + + +[[Image:tree|tree]] + + +A node with no parent, such as the node marked ''A'' on the figure, is called a root; a node with no children, such as ''E'', ''F'', ''G'', ''H'' and ''I'', is called a leaf. The length of a path from the root to a leaf (that is to say, the number of nodes on the path minus one) is the height of the tree; the average length of all such paths is the average height. On the figure the height is 2 and the average height is 11/6 since of the six paths five have length 2 and one has length 1. + +The children of a common node are called siblings. For example ''G'', ''H'' and ''I'' are siblings on the figure. The siblings of a node are usually considered to be ordered; the order corresponds to the direction from left to right on conventional figures such as this one. + +The descendants of a node are the node itself and, recursively, the descendants of its children. The ancestors of a node are the node itself and, recursively, the ancestors of its parent. For example the descendants of ''A'' are all the tree's nodes; and the ancestors of ''I'' are ''A'', ''D'' and ''I''. + +To obtain a tree rather than a more general kind of graph, there is an extra requirement: in we start from an arbitrary node, go to the parent, to the parent's parent and so on (for as long as there is a parent), we will never find the starting node again. In more precise terms the condition is that the 'parent' relation must not have any cycles. (That relation is in fact a partial function, since every node has zero or one parent.) If we consider infinite as well as finite trees the above condition must be restated to express that if we start from an arbitrary node and repeatedly go to the parent we will eventually hit a root. This discussion, however, will only consider finite trees (those with a finite number of nodes), for which the two statements are equivalent. + +The definition given so far properly defines forests rather than trees. ''A'' tree is a forest with at most one root (that is to say, with exactly one root unless it is empty), such as the example on the last figure. The discussion and the library classes will handle trees rather than forest, but this is not a very important difference since by using an obvious device you can treat any forest as a tree: simply add an extra node, and make it the parent of all the forest's roots. + +Another important observation is that there is a one-to-one correspondence between trees and nodes. To any node N of a tree T we can associate a tree: take T, remove all nodes that are not descendants of N, and use N as the new root. Conversely, to any tree we can associate a node - its root. This correspondence enables us to treat the two concepts of tree and node as essentially the same. + +==Recursive Trees== + +The closeness of the notions of tree and node yields an elegant definition of trees in terms of lists. If we look at trees or, equivalently, at tree nodes, we can consider each node as being both: +* A list: the list of its children. +* A list cell (similar to a [[ref:libraries/base/reference/linkable_chart|LINKABLE ]] or [[ref:libraries/base/reference/bi_linkable_chart|BI_LINKABLE]] for one-way and two-way linked lists), paired with the node's siblings. + +This yields a simple definition of trees by multiple inheritance from [[ref:libraries/base/reference/list_chart|LIST]] and [[ref:libraries/base/reference/cell_chart|CELL]] . + +===Dynamic recursive trees=== + +An example of dynamic tree structure is provided by class [[ref:libraries/base/reference/two_way_tree_chart|TWO_WAY_TREE]] , an heir of both [[ref:libraries/base/reference/two_way_list_chart|TWO_WAY_LIST]] and [[ref:libraries/base/reference/bi_linkable_chart|BI_LINKABLE]] . There is also [[ref:libraries/base/reference/linked_tree_chart|LINKED_TREE]] , which inherits from [[ref:libraries/base/reference/linked_list_chart|LINKED_LIST]] and [[ref:libraries/base/reference/linkable_chart|LINKABLE]] , but [[ref:libraries/base/reference/two_way_tree_chart|TWO_WA Y_TREE]] is generally preferable since children of a node often needs to be traversed both ways; the notion of order is usually less significant here than for lists. Such a form of definition is a particularly effective way of conveying the profoundly recursive nature of trees. The corresponding classes are useful in many different areas such as graphics, text processing and compilation. To create a one-way or two-way linked tree, use +create my_tree.make (root_value) + +This will attach my_tree to a new one-node tree, with root_value at the root node. Here my_tree must be declared of type [[ref:libraries/base/reference/two_way_tree_chart|TWO_WAY_TREE]] [MY_TYPE] for some type MY_TYPE, and root_value must be of type MY_TYPE.
+A class with a similar interface but using arrays rather than lists to represent nodes is also available: [[ref:libraries/base/reference/arrayed_tree_chart|ARRAYED_TREE ]] . This class is more efficient in both time and space for trees whose nodes have many children that are accessed randomly, if relatively few child insertions occur after node creation. Here the creation procedure indicates the initial number of children: +create my_tree.make (max_estimated_children, root_value) + +The integer argument max_estimated_children only serves for the initial allocation; the array will be resized if the number of children grows beyond the initial size. As with the previous kinds of tree, the newly created node initially has no children. + +===Fixed trees=== + +[[ref:libraries/base/reference/two_way_tree_chart|TWO_WAY_TREE]] is useful for fully dynamic trees, in which a node may get new children at any time. For some applications, the number of children of a tree, although still arbitrary, is set for each node when the node is created, and will not change after that. Of course, some children may be absent; the corresponding entries will be void references. Class [[ref:libraries/base/reference/fixed_tree_chart|FIXED_TREE]] provides the basic mechanism; as you may have guessed, the implementation associates with each node an array of its children, arrays usually being the right structure when a collection of objects is known not to change size after creation. To create a fixed tree, use +create my_tree.make (how_many_children, root_value) + +The root will have the associated value root value and will have how_many_ children children, all initially void. Unlike the argument max_estimated_children for the creation procedure of [[ref:libraries/base/reference/arrayed_tree_chart|ARRAYED_TREE]] , the value of how_many_children is the final arity of the newly created node; since it set separately for each node on creation, the various nodes of a tree can have different arities, as illustrated on the above figure. + +===Properties of recursive trees=== + +Whether fixed or dynamic, recursive trees fully enjoy their dual origin. This means in particular that each node is viewed as a list of its children, and can apply to this list the features inherited from [[ref:libraries/base/reference/list_chart|LIST]] , appropriately renamed; for example:
+[[ref:libraries/base/reference/dynamic_tree_chart|child_put_left]]
+[[ref:libraries/base/reference/dynamic_tree_chart|child_forth]]
+[[ref:libraries/base/reference/dynamic_tree_chart|child_put]]
+and so on. Feature [[ref:libraries/base/reference/dynamic_tree_chart|count]] , inherited from [[ref:libraries/base/reference/list_chart|LIST]] , indicates the number of children; it is renamed arity to conform to accepted tree terminology. (The word is a substantived form of the 'ary' adjective ending, as in 'ternary', 'quaternary' and so on, which yielded the expression 'n-ary'.) + +==Binary Trees== + +Binary trees are a special case of fixed trees in which nodes always have two children, although either or both of these children may be void. + +===Basic binary trees=== + +Class [[ref:libraries/base/reference/binary_tree_chart|BINARY_TREE]] describes binary trees. + + +[[Image:binary-tree|binary_tree]] + + +The children are represented by features [[ref:libraries/base/reference/binary_tree_chart|left_child]] and [[ref:libraries/base/reference/binary_tree_chart|right_child]] . Queries [[ref:libraries/base/reference/binary_tree_chart|has_left]] and [[ref:libraries/base/reference/binary_tree_chart|has_right]] indicate whether any of these is non-void; arity is redefined to yield the number of non-void children (0, 1 or 2). + +===Binary representations of trees=== + +For any ordinary tree, there exists a standard representation as a binary tree, which is useful in some applications. The correspondence is one-to-one, so that the original tree may be reconstructed without ambiguity. It actually applies to forests rather than trees and works as follows, ''fr'' being the first root in a forest: the binary tree's root corresponds to ''fr''; its left subtree is obtained recursively from the forest made by the subtrees of ''fr''; and its right subtree is obtained recursively from the original forest deprived of the tree rooted at ''fr''. If you start from a tree rather than a forest the binary tree's root will have no right child.
+Function [[ref:libraries/base/reference/tree_chart|binary_representation]] , in [[ref:libraries/base/reference/tree_chart|TREE]] , creates a binary tree representation (the function's result) obtained from the current tree.
+Procedure [[ref:libraries/base/reference/dynamic_tree_chart|fill_ from_binary]] , in [[ref:libraries/base/reference/dynamic_tree_chart|DYNAMIC_TREE]] , reconstructs a tree from a binary tree representation passed as argument. + +===Binary search trees=== + +Class [[ref:libraries/base/reference/binary_search_tree_chart|BINARY_SEARCH_TREE]] describes binary search trees, an implementation ofbags which is appropriate for comparable items.
+Binary search trees rely for insertion on a policy whereby any item less than the root is inserted (recursively) into the left subtree, and any item greater than the root into the right subtree. So if the insertion order is reasonably random the items will distribute evenly among the various branches, This means that the average height of the tree will be not much more than the optimal: [log2 n] where n is the number of nodes and [x], for any x, is the integer part of x.
+Since search operations will follow the same principle (search left if smaller than the root, and so on), the time to find an item or ascertain that it is not there is proportional to the average height. In normal cases this means about [log2 n] basic operations, rather than n with a linear structure such as a list, and hence much better performance for large n. + +==Cursor Trees== + +Recursive trees, as described so far, are not active data structures: even though each node has its own cursor to traverse the list of its children, there is no global cursor on the tree as a whole. It is not hard to see that the notion of recursive tree is in fact incompatible with the presence of a global cursor. In situations where you need such a cursor, enabling you to move freely from a node to its children, siblings and parents, you may use class [[ref:libraries/base/reference/cursor_tree_chart|CURSOR_TREE]] and its descendants. + +===The conceptual model=== + +With cursor trees the model is different from what we have seen earlier in this chapter: there is a clear distinction between the nodes and the tree itself. The manipulated object is a tree, and the notion of node is merely implicit. In the various operations presented below and illustrated on the following figure, 'up' means towards the root and 'down' towards the leaves. This, of course, is the reverse of the properties of trees of the other kind - those which grow towards the sun and serve to print books about software. + +===Operations on cursor trees=== + +The cursor supported by instances of [[ref:libraries/base/reference/cursor_tree_chart|CURSOR_TREE]] has a position referring to a node of the tree, which is then considered to be the active node, or is off the tree. The different off positions are: [[ref:libraries/base/reference/cursor_tree_chart|above]] (above the root), [[ref:libraries/base/reference/cursor_tree_chart|below]] (below a leaf), [[ref:libraries/base/reference/cursor_tree_chart|before]] (before a leftmost sibling), [[ref:libraries/base/reference/cursor_tree_chart|after]] (after a rightmost sibling.) As with linear structures, fictitious sentinel elements are assumed to be present to the left, right, top and bottom.
+Various procedures are available to move the cursor in all directions: +* [[ref:libraries/base/reference/cursor_tree_chart|down (i)]] moves the cursor down to the i -th child of the active node. If i is equal to 0 the cursor ends up before; if i is equal to the arity of the current parent plus 1, the cursor ends up [[ref:libraries/base/reference/cursor_tree_chart|after]] . Calling [[ref:libraries/base/reference/cursor_tree_chart|down (i)]] when the cursor is on a leaf node results in setting [[ref:libraries/base/reference/cursor_tree_chart|below]] and [[ref:libraries/base/reference/cursor_tree_chart|before]] to true if i is equal to 0, or [[ref:libraries/base/reference/cursor_tree_chart|below]] and [[ref:libraries/base/reference/cursor_tree_chart|after]] to true if is equal to arity+1. +* [[ref:libraries/base/reference/cursor_tree_chart|forth]] and [[ref:libraries/base/reference/cursor_tree_chart|back]] move the cursor forward and backward between siblings and can cause the cursor to end up [[ref:libraries/base/reference/cursor_tree_chart|after]] or [[ref:libraries/base/reference/cursor_tree_chart|before]] . +* [[ref:libraries/base/reference/cursor_tree_chart|up]] moves the cursor up one level. The call may be made even when the cursor is [[ref:libraries/base/reference/cursor_tree_chart|after]] or [[ref:libraries/base/reference/cursor_tree_chart|before]] . If the cursor is on the root of the tree or below in an empty tree, the cursor ends up [[ref:libraries/base/reference/cursor_tree_chart|above]] . + +You can move the cursor in any one direction ( [[ref:libraries/base/reference/cursor_tree_chart|up]] , [[ref:libraries/base/reference/cursor_tree_chart|down]] , [[ref:libraries/base/reference/cursor_tree_chart|forth]] , [[ref:libraries/base/reference/cursor_tree_chart|back]] ), repeatedly, until it is [[ref:libraries/base/reference/cursor_tree_chart|off]] ( [[ref:libraries/base/reference/cursor_tree_chart|above]] , [[ref:libraries/base/reference/cursor_tree_chart|below,]] [[ref:libraries/base/reference/cursor_tree_chart|after]] , [[ref:libraries/base/reference/cursor_tree_chart|before]] respectively), but once it is [[ref:libraries/base/reference/cursor_tree_chart|off]] , further movement in the same direction is prohibited. For example the precondition of [[ref:libraries/base/reference/cursor_tree_chart|put_left]] requires [[ref:libraries/base/reference/cursor_tree_chart|before]] to be false, and the precondition of [[ref:libraries/base/reference/cursor_tree_chart|put_right]] requires [[ref:libraries/base/reference/cursor_tree_chart|after]] to be false.
+It is possible to move down from an [[ref:libraries/base/reference/cursor_tree_chart|above]] position; in an empty tree this brings the cursor [[ref:libraries/base/reference/cursor_tree_chart|below]] . Similarly, it is possible to move up from [[ref:libraries/base/reference/cursor_tree_chart|below]] , left from [[ref:libraries/base/reference/cursor_tree_chart|after]] , right from [[ref:libraries/base/reference/cursor_tree_chart|before]] .
+The sentinel element above the tree's root is considered to be the root of a forest containing just one tree. This view justifies the convention for the result of arity when the cursor is above: 0 if the tree [[ref:libraries/base/reference/cursor_tree_chart|is_empty]] , 1 if it has a root (viewed as the child of the fictitious sentinel element). + +===Manipulating the cursor explicitly=== + +The cursor attached to a cursor tree is not just a conceptual notion but an actual object, of type [[ref:libraries/base/reference/cursor_chart|CURSOR]] . You may use the query cursor to obtain a reference to the current cursor. Procedure [[ref:libraries/base/reference/cursor_tree_chart|go_to]] takes a cursor as argument and brings the tree's cursor to the node identified by the value of that argument. + +===Traversals=== + +A useful notion associated with trees and particularly applicable to cursor trees is that of traversal.
+A traversal is a certain policy for ordering all the nodes in a tree - usually to apply an operation to all these nodes in the resulting order. [[ref:libraries/base/reference/cursor_tree_chart|CURSOR_TREE]] and its descendants support three forms of traversal: preorder, postorder and breadth-first. They correspond to the most commonly used traversal policies on trees, illustrated on the figure (where the children of each node are assumed to be ordered from left to right): + + +[[Image:tree|tree]] + + +* Preorder is the traversal that visits the root first, then (recursively) traverses each subtree in order. On the figure we will visit node ''A'' first then, recursively, the subtrees rooted at ''B'' (which implies visiting ''E'' and ''F''), ''C'' and ''D''. The resulting order is: ''A B E F C D G H I''. +* Postorder first traverses (recursively) the subtrees, then visits the root. On the example this gives: '' E F B C G H I D A''. +* Breadth-first visits the nodes level by level, starting with the root: first the root, then all its children, then all their children and so on. Here the resulting order is: ''A B C D E F G H I''. + +For each of the traversals, procedures are available to move the cursor accordingly, for example [[ref:libraries/base/reference/cursor_tree_chart|breadth_start]] and [[ref:libraries/base/reference/cursor_tree_chart|breadth_ forth]] for breadth-first, and similar names for the others. + + + + diff --git a/documentation/18.11/solutions/basic-computing/eiffelbase/eiffelbase-tutorial/eiffelbase-data-structures-overview/index.wiki b/documentation/18.11/solutions/basic-computing/eiffelbase/eiffelbase-tutorial/eiffelbase-data-structures-overview/index.wiki new file mode 100644 index 00000000..94ae3b62 --- /dev/null +++ b/documentation/18.11/solutions/basic-computing/eiffelbase/eiffelbase-tutorial/eiffelbase-data-structures-overview/index.wiki @@ -0,0 +1,12 @@ +[[Property:title|EiffelBase Data Structures Overview]] +[[Property:weight|1]] +[[Property:uuid|195085fd-0b2f-8211-3d70-81c32cc13566]] +The data structures cluster of EiffelBase includes classes that cover a wide range of data structures classes for you to reuse in your systems. The cluster is divided into a number of subclusters. Each subcluster contains one or more '''deferred''' classes, which provide the general high-level abstractions; other classes in the cluster inherit from the deferred ones. + +The highest-level class is [[ref:libraries/base/reference/container_chart| CONTAINER]] , with the following heirs: +* [[ref:libraries/base/reference/collection_chart|COLLECTION]] , which describes containers through their access properties (defining how to access a container's items, forexample through an index or according to a last-in, first-out policy). +* [[ref:libraries/base/reference/traversable_chart|TRAVERSABLE]] , which considers their traversal properties, such as sequential or hierarchical. +* [[ref:libraries/base/reference/box_chart|BOX]] , which describes their storage properties, such as being bounded or unbounded. + +The documentation further discusses: + diff --git a/documentation/18.11/solutions/basic-computing/eiffelbase/eiffelbase-tutorial/eiffelbase-kernel/Access-to-internal-properties.wiki b/documentation/18.11/solutions/basic-computing/eiffelbase/eiffelbase-tutorial/eiffelbase-kernel/Access-to-internal-properties.wiki new file mode 100644 index 00000000..b2310e6c --- /dev/null +++ b/documentation/18.11/solutions/basic-computing/eiffelbase/eiffelbase-tutorial/eiffelbase-kernel/Access-to-internal-properties.wiki @@ -0,0 +1,62 @@ +[[Property:uuid|3E1CF220-F2C6-458D-8ED9-92FA7FD4CBAF]] +[[Property:weight|4]] +[[Property:title|Access to internal properties]] +In some applications, you may need to fine-tune the exception handling and memory management mechanisms. You may also need a simple way to access command-line arguments. In less common cases, you may require low-level access to internal properties of objects. + +==Exception handling== + +Class [[ref:libraries/base/reference/exceptions_chart|EXCEPTIONS]] enables you to control the handling of exceptions. [[ref:libraries/base/reference/unix_signals_chart|UNIX_SIGNALS]] , discussed next, complements it for the special case of fine-grain signal handling on Unix or Unix-like platforms. Both are meant to be inherited by any class that needs their facilities. + +The basic exception mechanism treats all exceptions in the same way. In some cases, it may be useful to discriminate in a Rescue clause between the various possible causes. + +Class [[ref:libraries/base/reference/exceptions_chart|EXCEPTIONS]] provides the features to do this. Each kind of exception has an integer code, which you can use through several features: +* The integer-valued query exception which gives the code of the latest exception. +* Queries which determine the general nature of the latest exception: is_signal which determines whether the exception was an operating system signal; is_developer_exception which determines whether it was explicitly caused by a raise, as explained next; assertion_violation. +* Query recipient_name which gives the name of the exception's recipient - the routine that was interrupted by the exception. + +The class also provides a set of constant integer-valued attributes which denote the various possible codes, such as No_more_memory, Routine_ failure and Precondition_violation. So you can test the value of exception against these codes if you need to ascertain the precise nature of an exception. To keep [[ref:libraries/base/reference/exceptions_chart|EXCEPTIONS]] simple these constant attributes are declared in a class EXCEP_CONST, of which [[ref:libraries/base/reference/exceptions_chart|EXCEPTIONS]] is an heir. + +Another occasional requirement is for a mechanism to trigger an exception explicitly. Procedure raise answers this needs; the argument, a string, is the tag chosen for the exception. The code in this case is Developer_exception; the query is_developer_exception will return true; and the tag is accessible through feature tag_name. + +You will notice in the interface specification for [[ref:libraries/base/reference/exceptions_chart|EXCEPTIONS]] that for some properties of the latest exception there are two features, one with a name such as exception or recipient_name as seen above and the other with a name prefixed by original_: original_exception, original_recipient_name. + +{{caution|The reason for the presence of these pairs is that the immediately visible cause of a routine interruption may not be the real one. Assume that routine r from class C, which has a Rescue clause, calls s from D with no Rescue clause, and that some call executed by s causes a precondition violation. Because s has no Rescue clause of its own, s will fail. Up the call chain, the first routine that has a Rescue clause - r itself, or one of its own direct or indirect callers - may process the exception; but if it examines the exception code through attribute exception it will get the value of Routine_failure. This may be what you want; but to handle the situation in a finer way you will usually need to examine the code for the original exception, the one that interrupted s. This code will be accessible through the attribute original_exception, which in this case will have the value of Precondition, the exception code for precondition violations. So you have the choice between exploring the properties of the original exception, or those of the resulting routine failures. Just make sure you know what you are looking for. }} + +As you will see from the header comments in the flat-short form of class [[ref:libraries/base/reference/exceptions_chart|EXCEPTIONS]] , the queries that return detailed information about an exception, such as assertion_violation, all give an answer determined by original_exception rather than exception, since when the two are different (that is to say, when you handle the exception in a routine other than the original recipient) the value of exception is always Routine_failure and there is nothing more to say about it. + +==Signal handling== + +The features of class [[ref:libraries/base/reference/exceptions_chart|EXCEPTIONS]] enable you to determine whether a certain exception is a signal - an operating system event such as may result from a child process that disappears, a window that is resized, a user that hits the Break key and many others. But they do not give you more details because the exact set of possible signals is highly platform-dependent. + +Class [[ref:libraries/base/reference/unix_signals_chart|UNIX_SIGNALS]] complements EXCEP_CONST by providing codes for the signals of Unix and similar systems, such as Sigkill for the 'kill' signal and Sigbus for bus error. + +Query is_defined (some_signal), where some_signal is an integer code, will determine whether some_signal is supported on the platform. + +A class whose routines need to perform specific processing depending on the nature of signals received should inherit from [[ref:libraries/base/reference/unix_signals_chart|UNIX_SIGNALS]] , or a similar class for another platform. + +Because signal codes are platform-dependent, the features of [[ref:libraries/base/reference/unix_signals_chart|UNIX_SIGNALS]] are implemented as once functions - computed on the first call - rather than constants, although this makes no difference to clients. + +==Memory management== + +Class [[ref:libraries/base/reference/memory_chart|MEMORY]] , like [[ref:libraries/base/reference/exceptions_chart|EXCEPTIONS]] , is meant to be used as an ancestor by classes that need its facilities. It offers a number of features for controlling memory management and fine-tuning the garbage collection mechanism, a key component of the Eiffel Software environment. + +One of the most useful features in this class is dispose. This procedure describes actions to be applied to an unreachable object just before the garbage collector reclaims it. By default, as declared in [[ref:libraries/base/reference/memory_chart|MEMORY]] , the procedure does nothing; but you may redefine it in a proper descendant of [[ref:libraries/base/reference/memory_chart|MEMORY]] to describe dispose actions. Normally such actions will involve freeing external resources: for example a class describing file descriptors may redefine dispose so that whenever a descriptor object is garbage-collected the corresponding file will be closed. + +{{caution|This example is typical of proper uses of dispose. In a dispose procedure, you should not include any instruction that could modify the Eiffel object structure, especially if some objects in that structure may themselves have become unreachable: these instructions could conflict with the garbage collector's operations and cause catastrophic behavior. The legitimate use of dispose redefinition is for disposing of non-Eiffel resources. }} + +Other features of [[ref:libraries/base/reference/memory_chart|MEMORY]] provide direct control over the operation of the garbage collector. You can in particular stop garbage collection through a call to collection_off, and restart it through a call to collection_on. By default, garbage collection is always on (a testimony to its authors' trust in its efficiency). Garbage collection is normally incremental, so as not to disrupt the application in a perceptible way. To start a complete garbage collection mechanism - reclaiming all unused objects - call procedure full_collect. The remaining features of [[ref:libraries/base/reference/memory_chart|MEMORY]] enable finer control of the collection mechanism and are useful in special cases only. You will even find a free procedure providing brave (and competent) developers with a mechanism for reclaiming individual objects manually. + +MEM_INFO, the result type for query memory_statistics in [[ref:libraries/base/reference/memory_chart|MEMORY]] , describes objects containing information collected about memory usage. The features of [[ref:libraries/base/reference/gc_info_chart|GC_INFO]] provide statistics about the garbage collector's operation. + +==Command-line arguments== + +Writing, assembling and compiling a system yields an executable command. The system's users will call that command with arguments. These are normally provided in textual form on the command line, as in +your_system arg1 arg2 arg3 + +although one may conceive of other ways of entering the command arguments, such as tabular or graphical form-filling. In any case, the software must be able to access the values passed as command arguments. + +A language mechanism is available for that purpose: the Root Class rule indicates that the creation procedure of the root class may have a single argument (in the Eiffel sense of argument to a routine) of type ARRAY [STRING]. The corresponding array of strings will be initialized at the beginning of the system's execution with the values entered as arguments to that execution of the command. + +Although this facility suffices in many cases, it is not always convenient if you suddenly need to access the command arguments in a class that is far away from the root. An alternative mechanism, class ARGUMENTS, is available. Once again, this is a class from which you should inherit if you need its facilities. It has just two exported features: +* argument_count, a non-negative integer, is the number of command arguments. +* argument (i), a string, is the i-th command argument. Here i must be between 0 and argument_count; the convention is that for i = 0 the result is the name of the command itself. diff --git a/documentation/18.11/solutions/basic-computing/eiffelbase/eiffelbase-tutorial/eiffelbase-kernel/Files--input--output.wiki b/documentation/18.11/solutions/basic-computing/eiffelbase/eiffelbase-tutorial/eiffelbase-kernel/Files--input--output.wiki new file mode 100644 index 00000000..dedad538 --- /dev/null +++ b/documentation/18.11/solutions/basic-computing/eiffelbase/eiffelbase-tutorial/eiffelbase-kernel/Files--input--output.wiki @@ -0,0 +1,35 @@ +[[Property:uuid|37099E33-657D-44CF-923C-1F10BE09AAFB]] +[[Property:weight|2]] +[[Property:title|Files, input, output]] +A few classes of the Kernel Library support file manipulation, input and output: [[ref:libraries/base/reference/std_files_chart|STD_FILES]] , FILE, [[ref:libraries/base/reference/directory_chart|DIRECTORY]] and [[ref:libraries/base/reference/unix_file_info_chart|UNIX_FILE_INFO]] . For simple applications it suffices to use [[ref:libraries/base/reference/std_files_chart|STD_FILES]] , but to understand the concepts better it is preferable to look first at the other two. + +==General files== + +FILE describes the notion of sequential file viewed as a data structure which fits in the general taxonomy of EiffelBase. + +The class declaration defines files as unbounded sequences of characters. This means that you will find in FILE all the operations on sequential data structures that you have come to know and love by reading this documentation - at least, all that apply. Just as stacks and linked lists, files have put, extend, has, item and so on. More specific to files are the typed input and output operations. For output, you will find put_character, put_integer, put_real, put_double and put_string, as well as new_line. For input you will find read_integer and its co-conspirators. + +{{caution|Note the application to input features of the command-query separation principle.
+The input features such as read_integer do not by themselves return a result; they set the values of queries such as last_integer. So the normal way to read is through two operations:
+     my_file.read_integer
+     new_value := my_file.last_integer}} + +Queries are available to determine the status of a file, in particular exists, is_readable, is_executable, is_writable, is_creatable, is_closed, is_open_read and so on. + +{{caution|You will notice in the flat-short form that all these queries except the first have exists as a precondition. This precondition is good for efficiency since it saves an existence test - a relatively expensive operation - when you know that a certain file exists. But it also means that if you have any doubt about the file's existence you must use the queries in the style
+if my_file.exists and then my_file.is_readable then ...}} + +FILE is a deferred class. Various implementations are possible. A quite detailed one is PLAIN_TEXT_FILE, which adds many features for accessing reading and writing data from/to a file. + +[[ref:libraries/base/reference/unix_file_info_chart|UNIX_FILE_INFO]] describes objects that contain internal information, such as protection mode and size, about a file. + +The class [[ref:libraries/base/reference/directory_chart|DIRECTORY]] describes those files which are directories - nodes in the tree describing the file structure. + +==Basic input and output== + +Regardless of the operating system that you use, for simple input and output [[ref:libraries/base/reference/std_files_chart|STD_FILES]] is sufficient. You may inherit from that class to gain direct access to its features; or you may declare an entity of type [[ref:libraries/base/reference/std_files_chart|STD_FILES]] . But remember that a feature of this type is always available: io, from class [[ref:libraries/base/reference/any_chart|ANY]] . Thanks to this feature you may include simple input and output in any class, with instructions such as +io.put_string ("My message") + +[[ref:libraries/base/reference/std_files_chart|STD_FILES]] defines three default files through features input, output and error. These features are Once functions, so that the first reference to any one of them will automatically create the corresponding file descriptor and open the associated file. + +To simplify the writing of common input and output operations, the most frequently used features of class FILE - for reading and writing integers, reals and so on, as discussed next - have been repeated in [[ref:libraries/base/reference/std_files_chart|STD_FILES]] so as to apply to the default input and output. Procedure put_string in the example at the beginning of this section is typical: it writes its output on the standard output. More generally, [[ref:libraries/base/reference/std_files_chart|STD_FILES]] has all the put_xxx, read_xxx and last_xxx features of FILE. diff --git a/documentation/18.11/solutions/basic-computing/eiffelbase/eiffelbase-tutorial/eiffelbase-kernel/Language-related-facilities.wiki b/documentation/18.11/solutions/basic-computing/eiffelbase/eiffelbase-tutorial/eiffelbase-kernel/Language-related-facilities.wiki new file mode 100644 index 00000000..1cc3f77b --- /dev/null +++ b/documentation/18.11/solutions/basic-computing/eiffelbase/eiffelbase-tutorial/eiffelbase-kernel/Language-related-facilities.wiki @@ -0,0 +1,186 @@ +[[Property:uuid|9BEE6EE3-5652-4C2E-BD2E-E6A50787508E]] +[[Property:weight|1]] +[[Property:title|Language-related facilities]] +A number of classes offer facilities which are very close to the language level. Here too the book ''[[Eiffel: The Language]]'' covers the classes in detail, so we can satisfy ourselves with a quick summary; the flat-short forms appear in part C. + +==Basic types== + +The basic types [[ref:libraries/base/reference/boolean_chart|BOOLEAN]] , [[ref:libraries/base/reference/character_8_chart|CHARACTER]] , [[ref:libraries/base/reference/integer_32_chart|INTEGER]] , [[ref:libraries/base/reference/real_32_chart|REAL]] and [[ref:libraries/base/reference/real_64_chart|DOUBLE]] are defined by classes of the Kernel library. + +In reading the class specifications for the numeric types [[ref:libraries/base/reference/integer_32_chart|INTEGER]] , [[ref:libraries/base/reference/real_32_chart|REAL]] and [[ref:libraries/base/reference/real_64_chart|DOUBLE]] , you might think that the type declarations are too restrictive. For example the addition operation in class [[ref:libraries/base/reference/real_32_chart|REAL]] reads + + infix "+" (other: REAL): REAL + + +but there is actually no problem here. A language convention applicable to all arithmetic expressions, the Balancing rule, states that in any such expression all operands are considered to be converted to the heaviest type, where [[ref:libraries/base/reference/real_64_chart|DOUBLE]] is heavier than [[ref:libraries/base/reference/real_32_chart|REAL]] and [[ref:libraries/base/reference/real_32_chart|REAL]] is heavier than [[ref:libraries/base/reference/integer_32_chart|INTEGER]] . So mixed-type arithmetic, consistent with common practice, is possible and indeed frequent. + +==Arrays== + +To create and manipulate one-dimensional arrays, use class [[ref:libraries/base/reference/array_chart|ARRAY]] of the Kernel Library. Arrays are not primitive language elements; instead, they are handled through class [[ref:libraries/base/reference/array_chart|ARRAY]] . This class is 'normal' in the sense that it may be used just as any other class by client and descendant classes. It is also somewhat special, however, in that the Eiffel compiler knows about it and uses this knowledge to generate efficient code for array operations. + +To create an instance of [[ref:libraries/base/reference/array_chart|ARRAY]] , use the creation instruction + + create my_array.make (1, u) + + +where the arguments indicate the lower and upper bounds. These bounds will then be accessible as my_array .lower and my_array .upper. The number of items is my_array .count; feature capacity is a synonym for count. The class invariant expresses the relation between count, lower and upper. + +To access and change the item at index ''i'' in array a, you may use features item and put, as in + + x := my_array.item (i) + my_array.put (new_value, i) + + +Function item has a bracket alias, so that you may also write the first assignment above more concisely as + + x := my_array [i] + + +Features item and put have preconditions requiring the index ( iin the above calls) to be within the bounds of the array. This means that you can detect bounds violations (which correspond to bugs in the client software) by using a version of class [[ref:libraries/base/reference/array_chart|ARRAY]] compiled with precondition checking on. The bounds of an array may be changed dynamically through procedure resize. Previously entered elements are retained. Rather than an explicit resize, you may use calls to procedure force which has the same signature as put but no precondition; if the index is not within the current bounds force will perform a resize as necessary. +==Optimizing array computations== + +''' CAUTION''': Although [[ref:libraries/base/reference/array_chart|ARRAY]] benefits from an efficient implementation, its more advanced facilities such as resizing do not come for free. For extensive computations on large arrays, an optimization may be desirable, bypassing these facilities. The technique yields loops that run at about the same speed as the corresponding loops written in C or Fortran (the usual references for array computations). It is of interest for advanced uses only, so that you may safely skip this section on first reading unless your domain of application is numerical computation or some other area requiring high-performance array manipulations. + +The optimization relies on the class SPECIAL, used internally by [[ref:libraries/base/reference/array_chart|ARRAY]] but of no direct interest to client developers in most common uses. With the declarations + + my_array: ARRAY [SOME_TYPE] + direct_access: SPECIAL [SOME_TYPE] + + +you may use direct_access in lieu of 'my_array' within a critical loop, provided none of the operations may resize the array. Typically, the operations should only include put and item. In such a case you can use the following scheme: + + direct_access:= my_array.area + -- The critical loop: + from + some_initialization + index := some_initial_index + until + index = some_final_index + loop + ... + x := direct_access.item (index) + ... + direct_access.put (some_value, index) + ... + end + + +This replaces an original loop where the operations were on my_array. Feature area of [[ref:libraries/base/reference/array_chart|ARRAY]] gives direct access to the special object, an instance of SPECIAL, containing the array values. Features put and item are available in SPECIAL as in [[ref:libraries/base/reference/array_chart|ARRAY]] , but without the preconditions; in other words, you will not get any bounds checking. Instances of SPECIAL are always indexed from zero, in contrast with arrays, whose lower bound is arbitrary, 1 being the most common value. But rather than performing index translations (that is to say, subtracting my_array .lower from index throughout the loop) it is preferable to use the following simple technique: if the lower bound 'lb' of my_array is 1 or another small integer, use 0 as lower bound instead when creating my_array, but only use the positions starting at 'lb'. You will waste a few memory positions (0 to lb-1), but will not have to change anything in your algorithm and will avoid costly subtractions. + +It is important to note that this optimization, if at all necessary, should at most affect a few loops in a large system. You should always begin by writing your software using the normal [[ref:libraries/base/reference/array_chart|ARRAY]] facilities; then once you have the certainty that the software is correct, if you detect that a large array computation is hampering the efficiency of the system, you may apply the above technique to get the fastest performance out of that computation. The change to the software will be minimal - a few lines - and will be easy to undo if necessary. + +==Tuples== + +A new Kernel Library class is introduced: [[ref:libraries/base/reference/tuple_chart|TUPLE]] . + +Alone among all classes, class TUPLE has a variable number of generic parameters. TUPLE, TUPLE [X], TUPLE [X, Y], TUPLE [X, Y, Z] and so on are all valid types, assuming valid types X, Y, Z and so on. + +Conformance rules: +[CONF1] + For n >= 0 + TUPLE [U1, U2, ..., Un, Un+1] conforms to + TUPLE [U1, U2, ..., Un] + +(and hence to TUPLE [T1, T2, ..., Tn] if each of the Ui conforms to each of the Ti for 1 <= i <= n.) + +In particular all tuple types conform to [[ref:libraries/base/reference/tuple_chart|TUPLE]] , with no parameter. +[CONF2] + For n >= 0 If *every* one of the types T1, T2, ..., Tn conforms + to a type T, then TUPLE [T1, T2, ..., Tn] conforms + to ARRAY [T] + + +{{Definition|Tuple Type|A "tuple type" is any type based on class [[ref:libraries/base/reference/tuple_chart|TUPLE]] , i.e. any type of the form TUPLE [T1, T2, ..., Tn] for any n (including 0, for which there is no generic parameter). }} + + +{{note|CONF1 should be understood in terms of the underlying mathematical model.
Mathematically, TUPLE [T1, T2, ..., Tn] is the set TUPLE n of all partial functions f from N+ (the set of non-negative integers) to T1 U T2 U ... Tn, such that:
The domain of f contains the interval 1..n (in other words, f is defined for any i such that 1 <= i <= n).
For 1 <= i <= n, f (i) is a member of Ti. }} + +With this definition, TUPLE n is indeed a subset of TUPLE n+1, and in particular TUPLE 0, the empty set, is a subset of TUPLE n for any n.) + +Semantics: an instance of TUPLE [T1, T2, ..., Tn] is a tuple whose first element is an instance of T1, the second element being an instance of T2 etc. (The precise definition is the mathematical one given in note 1.) Note that there can be more than n elements to the tuple: for example a tuple with first element 5 and second element "FOO" is an instance of all of the following tuple types: TUPLE; TUPLE [INTEGER]; TUPLE [INTEGER, STRING]. + +It may seem restrictive at first to permit only one class, [[ref:libraries/base/reference/tuple_chart|TUPLE]] , to have an arbitrary number of actual generic parameters. Why not have a general mechanism for declaring any class C so that all of C [X], C [X, Y] etc. are valid? But in fact this is not really a restriction. To obtain this effect without any complicated language convention, just declare C as +C [G -> TUPLE] and then use the generic derivations +C [TUPLE [X]] +C [TUPLE [X, Y]] + +and so on. This also makes it possible to have the effect of some fixed parameters and some variable ones, as in C [G, H, I -> TUPLE] so we have all the necessary flexibility.) + +==Tuple expressions== + +Let e1, e2, ..., en be expressions of respective types T1, T2, ..., Tn. Then the expression [e1, e2, ..., en] denotes an instance of TUPLE [T1, T2, ..., Tn], whose first element is e1, the second element being e2, etc. + +Tuple expressions can be nested: whereas [1, 2, 3] is a tuple with three elements (representing an instance of TUPLE [INTEGER, INTEGER, INTEGER]), [1, [2, 3]] is a tuple with two elements, the second one itself a tuple; the overall expression represents an instance of TUPLE [INTEGER, TUPLE [INTEGER, INTEGER]]. + +As a special case of tuple expression syntax, the delimiters [ and ] are replaced by parentheses for the tuple representing the actual argument list of a routine call (see section 4). + +==Tuple features== + +The exact specification of class [[ref:libraries/base/reference/tuple_chart|TUPLE]] will be described in an addition to ELKS. The principal features are: +* [[ref:libraries/base/reference/tuple_chart|count]] (number of significant elements) +* [[ref:libraries/base/reference/tuple_chart|item]] (i), with the obvious precondition: the i-th element, of type [[ref:libraries/base/reference/any_chart|ANY]] (since the value of i is not known at compile time); also first, second, third, fourth and fifth, of the appropriate types. +* [[ref:libraries/base/reference/tuple_chart|put]] (x, i), with the obvious precondition: replace i-th element with x. If argument x is not of the appropriate type T i there is no effect. +* [[ref:libraries/base/reference/tuple_chart|is_equal]] : redefined to consider only the first n elements, where n is the smaller length. + +Other features under consideration include: +* stripped (i): a tuple of type TUPLE [T1, T2, Ti-1, Ti+1, ..., Tn], derived from the current one by removing the i-th component, again with the obvious precondition. +* wedged (x, i): a tuple with one more element, inserted at position i. +* '''infix''' "+": tuple concatenation +* '''infix''' "++": element concatenation; t ++ x is the same thing as t.wedged (x, t.count + 1). + +==What have we gained?== + +First we have solved the only case in the Eiffel programming language in which an expression has no precisely defined type: polymorphic manifest arrays. We don't have manifest arrays any more, but manifest tuples, with a precisely defined type. No incompatibility is introduced thanks to rule CONF2. The original syntax for manifest arrays, Result := <>, will continue to be supported. +Second, we can define functions that return multiple results. This is a quite significant increase in expressive power. No common language has that. (You have to go to Lisp and functional languages.) Just define TUPLE [...] as the result type; in the function, you will write things like + +Result := [e1, e2, ..., en] + +Also, from a theoretical viewpoint, feature calls are simpler and more homogeneous: every feature takes exactly one tuple as argument and returns exactly one tuple as a result. (Either of these tuples may be empty: the first for a feature with no argument, the second for a procedure.) The syntax for a call becomes +Feature Arguments + +with Arguments defined as +Tuple_expression + +where the Tuple_expression uses the form given in section 2 but with the outermost [ and ] delimiters replaced by parentheses to conform to usual practice. So the call +f (a, b, c) + +which we continue to think of as having three arguments a, b and c, formally has only one tuple argument [a, b, c]. This is of course not to be confused with a call of the form +g ([a, b, c]) + +which has one argument (a tuple with three elements) in both the ordinary and the formal sense. + +==Active, iterators, numerical applications, introspection== + +For a set of important applications of tuples see the book chapter on [[EiffelBase, Iteration|agents and iterators]] which also covers aspects of numerical software and related topics following from the tuple mechanism. + +==Temporary limitations== + +The implementation of tuples has the following limitations: +* Conformance of [[ref:libraries/base/reference/array_chart|ARRAY]] types to [[ref:libraries/base/reference/tuple_chart|TUPLE]] types is not yet fully supported. +* Class [[ref:libraries/base/reference/tuple_chart|TUPLE]] does not have features such as first and second. You must use item and, in most cases, an object test. + +==Strings== + +Strings are handled by class [[ref:libraries/base/reference/string_8_chart|STRING]] , similar in many respects to [[ref:libraries/base/reference/array_chart|ARRAY]] . Strings are of arbitrary size. The make creation procedure takes an integer argument, as in: + + s, s1, s2, s3: STRING + ... + create s.make (30) + +The argument indicates the number of characters for the initial allocation. This is not an absolute limit: the string will automatically grow or shrink as a result of future operations. You may always request a resizing explicitly by calling procedure resize. + +==String descriptor== + +The object attached at run-time to an entity such declared of type [[ref:libraries/base/reference/string_8_chart|STRING]] is not the actual sequence of characters but a string descriptor, which contains a reference to the actual string contents. + +As a result, four assignment or assignment-like operations are possible: +* '''A1''' s1 := s +* '''A2''' s2.share (s) +* '''A3''' s3 := s.twin +* '''A4''' s4.copy (s) + +As illustrated below, ''' A1''' is a reference assignment: s1 will be attached to the same descriptor as s. ''' A2''' keeps the descriptors distinct, but make them refer to the same sequence of characters. In ''' A3''', s3 will be attached to a new string, completely distinct from the string attached to s1 although made of identical characters. ''' A4''' has almost the same effect as '''A3''', but is only applicable if s4 was not void, and will override the existing descriptor rather than creating a new one. + [[Image:strings]] +fig. 1: Effect of string assignment and copy operations + +[[ref:libraries/base/reference/basic_routines_chart|BASIC_ROUTINES]] provides a number of conversion functions, such as charconv. diff --git a/documentation/18.11/solutions/basic-computing/eiffelbase/eiffelbase-tutorial/eiffelbase-kernel/Persistence--storage--and-retrieval.wiki b/documentation/18.11/solutions/basic-computing/eiffelbase/eiffelbase-tutorial/eiffelbase-kernel/Persistence--storage--and-retrieval.wiki new file mode 100644 index 00000000..2d00826b --- /dev/null +++ b/documentation/18.11/solutions/basic-computing/eiffelbase/eiffelbase-tutorial/eiffelbase-kernel/Persistence--storage--and-retrieval.wiki @@ -0,0 +1,173 @@ +[[Property:uuid|EA781CE6-3452-4EEF-BF05-47D94FC88A3D]] +[[Property:weight|3]] +[[Property:title|Persistence, storage, and retrieval]] +Most object-oriented applications need the ability to store object structures on persistent storage for later retrieval, and to transfer such object structures to other applications. Eiffel offers a full persistence mechanisms serving these needs. + +=Persistence completeness= + +A fundamental requirement on object persistence mechanisms is the ''Persistence Completeness'' rule, stated as follows in ''[[Eiffel: The Language]]'': + +
Whenever an object is stored into an external file, the stored content contains all the dependents of that object. Conversely, retrieving a previously stored object also retrieves all its dependents. +
+
+Storing an object just by itself would usually result in wrong semantics: most objects contain references to other objects, which must also be stored and retrieved with it. The persistence completeness rule ensures that this is always the case. It also means, of course, that features used for storing and retrieving objects must do much more than simple input and output; they must perform complete traversals of object structures. +
+ +The Eiffel persistence mechanism applies Persistence Completeness. + +=Varieties of store operations= + +Different variants of the store operation are available: '''session''', '''basic''' and '''independent''' store + +* '''Session''' store produces the most compact structure in the resulting files; but the resulting structure is dependent on the current execution of the system which executes the store operation (''System'' is taken here, as elsewhere in this documentation, in its Eiffel sense of an executable assembly of classes, compiled together with the help of a configuration file.) + +* '''Basic''' store is like session store with the difference that the resulting structure is dependent on the system which executes the store operation (i.e. only the system creating the persistent version can retrieve it.) + +* On the other hand, '''independent''' store allows a system running on a computer with a certain architecture to retrieve, without any explicit conversion operation, object structures stored by a system running on a machine of a completely different architecture. In addition, independent store lets you retrieve an old version of the object that was saved (see more details in the recoverable section below.) + +=Using the storage and retrieval facilities= + +Historically, the persistence mechanism was offered via the helper class [[ref:libraries/base/reference/storable_chart|STORABLE]] which you could use as an ancestor whenever you wanted to store and retrieve objects. Via this class you would have access to basic_store and independent_store to store an object, and retrieved to retrieve one. However this was not necessary and the persistence mechanism could be used directly from any descendants of the [[ref:libraries/base/reference/io_medium_chart|IO_MEDIUM]] using routines with the same names. This manner of storing and retrieving objects is called the '''C''' persistence mechanism since it was completely written in C and is included as part of the Eiffel runtime. + +Today, we recommend using the '''SED''' ('''SE'''rialization '''D'''eserialization) persistence mechanism, entirely written in Eiffel. It is very flexible, since it lets you control the format of the stored structure, but in most cases it suffices to rely on the simple helper class [[ref:libraries/base/reference/sed_storable_facilities_chart|SED_STORABLE_FACILITIES]]. This class offers session_store, basic_store, and store (the de-facto independent store), as well as retrieved. + +In both cases, you only need to be aware of the difference between the various storing mechanism (session, basic and independent) at storage time. The stored structure will always be available through feature retrieved; this feature will figure out, from the format of the stored structure how it was stored and will decode it accordingly. + +{{Caution|This is only true when using just the '''C''' or '''SED''' persistence format. If the structure was stored using the '''C''' format, you need to use the '''C''' retrieved feature. Conversely, if it was stored using '''SED''', you need to use the '''SED''' retrieval mechanism.}} + +Regardless of the mechanism used, the feature retrieved returns a result of type [[ref:libraries/base/reference/any_chart|detachable ANY]] and is typically used through an object test. + +==With the C persistence format== + +The example below will show you how to store an object using the C persistence format. It uses independent_store but you could also use in-place basic_store instead: + + +store_object (o: ANY; p: PATH) + -- Store object `o` into file located in `p`. + local + f: RAW_FILE + do + create f.make_with_path (p) + f.open_write + f.independent_store (o) + f.close + end + + +Then to retrieve the object you would write the following: + + +retrieve (p: PATH) + -- Retrieve object stored in file located in `p`. + local + f: RAW_FILE + do + create f.make_with_path (p) + f.open_read + if attached {MY_TYPE} io_medium.retrieved as data then + -- Retrieved result is of expected type. + -- Proceed with processing of result, + -- typically with calls of the form `data.some_feature'. + else + -- Result was not of expected type MY_TYPE. + end + f.close + end + + +If the structure in the file has been corrupted and retrieved is unable to do its job, it will trigger an exception (the code for that exception in class [[ref:libraries/base/reference/exceptions_chart|EXCEPTIONS]] (which inherits it from EXCEP_CONST and is discussed in the next section, together with the notion of exception code) is Retrieve_exception.) + +==With the SED persistence format== + +The example below will show you how to store an object using the SED mechanism assuming the current class is a descendant of [[ref:libraries/base/reference/sed_storable_facilities_chart|SED_STORABLE_FACILITIES]]. It uses the store feature but you could also use session_store or basic_store too. + + +store_object (o: ANY; p: PATH) + -- Store object `o` into file located in `p`. + local + f: RAW_FILE + writer: SED_MEDIUM_READER_WRITER + do + create f.make_with_path (p) + f.open_write + create writer.make_for_writing (l_file) + store (o, writer) + f.close + end + + +Then to retrieve the object you would write the following: + + +retrieve (p: PATH) + -- Retrieve object stored in file located in `p`. + local + f: RAW_FILE + reader: SED_MEDIUM_READER_WRITER + do + create f.make_with_path (p) + f.open_read + create reader.make_for_reading (f) + if attached {MY_TYPE} retrieved (reader, False) as data then + -- Retrieved result is of expected type. + -- Proceed with processing of result, + -- typically with calls of the form `data.some_feature'. + else + -- Result was not of expected type MY_TYPE. + end + f.close + end + + +In case of an error during retrieval, no objects will be returned and instead the query retrieved_errors will list all the errors it encountered. + +=Recoverable format= + +Sometimes you will be in a position where the definition of a class (its "schema") will have changed between the time you stored your object and the time you are trying to retrieve it. Such schema changes include: + +* Renaming the class. +* Adding attributes. +* Removing attributes. +* Renaming attributes. +* Changing the types of attributes. + +The persistence mechanism allows you to retrieve the old version of the object only if it was saved using the independent_store facility. + +The mechanism lets you define precisely what will happen in the case of a scheme change, or "mismatch". Each time you retrieve an object of a certain base class whose schema has changed, the feature correct_mismatch will be called. This feature is defined in [[ref:libraries/base/reference/any_chart|ANY]] and has the following effect: +* Its default version causes an exception. This is the proper behavior since the old object might not make sense with the new schema (for example, it might violate the invariant), and you do not want to continue the computation, without warning, with wrong objects. +* To specify otherwise, and avoid the exception, just redefine correct_mismatch in the class whose schema has been changed. +For example, the important EiffelBase library class [[ref:libraries/base/reference/hash_table_chart|HASH_TABLE]] changed between version 5.1 and version 5.2 to use SPECIAL rather than [[ref:libraries/base/reference/array_chart|ARRAY]] for its internal data storage. To retrieve a 5.1 version of [[ref:libraries/base/reference/hash_table_chart|HASH_TABLE]], you can redefine correct_mismatch as follows: + +correct_mismatch + -- Attempt to correct object mismatch during retrieve using `mismatch_information'. + do + -- In version 5.1 and earlier, `content', `keys' and `deleted_marks' + -- were of base class ARRAY. In 5.2 we changed it to be a SPECIAL for + -- efficiency reasons. In order to retrieve an old HASH_TABLE we + -- need to convert those ARRAY instances into SPECIAL instances. + + -- Convert `content' from ARRAY to SPECIAL. + if attached {ARRAY [G]} mismatch_information.item ("content") as l_temp then + content := l_temp.area + end + + -- Convert `keys' from ARRAY to SPECIAL. + if attached {ARRAY [H]} mismatch_information.item ("keys") as l_temp then + keys := l_temp.area + end + + -- Convert `deleted_marks' from ARRAY to SPECIAL. + if attached {ARRAY [BOOLEAN]} mismatch_information.item ("deleted_marks") as l_temp then + deleted_marks := l_temp.area + end + + if content = Void or keys = Void or deleted_marks = Void then + -- Could not retrieve old version of HASH_TABLE. We throw an exception. + Precursor {TABLE} + end + end + + +Note the use of mismatch_information. This is a once query of [[ref:libraries/base/reference/any_chart|ANY]] of type MISMATCH_INFORMATION which behaves like a [[ref:libraries/base/reference/hash_table_chart|HASH_TABLE]]. The keys of the table are the names of the attributes on which a mismatch occurred, and the values are the corresponding object fields as they were originally stored. In this particular case of [[ref:libraries/base/reference/hash_table_chart|HASH_TABLE]] we know that the previous version was an [[ref:libraries/base/reference/array_chart|ARRAY]], so we do an object test and if it succeeds we assign its area to the corresponding attribute of [[ref:libraries/base/reference/hash_table_chart|HASH_TABLE]]. + +If a class name changed, you should create an instance of CLASS_NAME_TRANSLATIONS, it behaves like a [[ref:libraries/base/reference/hash_table_chart|HASH_TABLE]] where the keys represent the old name, and the value the new name. This instance needs to be created before the call to retrieved. diff --git a/documentation/18.11/solutions/basic-computing/eiffelbase/eiffelbase-tutorial/eiffelbase-kernel/Universal-Class-and-its-Features.wiki b/documentation/18.11/solutions/basic-computing/eiffelbase/eiffelbase-tutorial/eiffelbase-kernel/Universal-Class-and-its-Features.wiki new file mode 100644 index 00000000..20b0a214 --- /dev/null +++ b/documentation/18.11/solutions/basic-computing/eiffelbase/eiffelbase-tutorial/eiffelbase-kernel/Universal-Class-and-its-Features.wiki @@ -0,0 +1,93 @@ +[[Property:uuid|419E822A-646B-4817-810C-B30F973A2D70]] +[[Property:weight|0]] +[[Property:title|Universal class and its features]] +The Eiffel inheritance mechanism is set up in such a way that every class is a descendant of a Kernel Library class called [[ref:libraries/base/reference/any_chart|ANY]] . The features of this class provide a number of generally applicable facilities covering such needs as comparison, copying and rudimentary input and output. + +=The structure of universal classes= + +Every class which has no inheritance clause is understood to have an inheritance clause of the form + +inherit + ANY + + +As a result, every developer-defined class is a descendant of [[ref:libraries/base/reference/any_chart|ANY]] . You may introduce your own project specific features in [[ref:libraries/base/reference/any_chart|ANY]] so that all the classes of your system will be able to use these features. + +=Using the universal classes= + +If you need to rename or redefine a feature inherited from one of the universal classes, you should include an explicit inheritance clause, as in + +class + C +inherit + ANY + rename + out as basic_out + redefine + print + end + ... +feature + ... +end + + + + + +The features of [[ref:libraries/base/reference/any_chart|ANY]] are usable in both qualified and unqualified form. For example, the argumentless function out, which produces a printable representation of any object, may be called under either of the forms + + x := out + x := a.out + + +The first call yields a printable representation of the current object; the second, which assumes that a is not void, yields a printable representation of the object attached to a. + +=Input and output features= + +Some of the features of [[ref:libraries/base/reference/any_chart|ANY]] cover common input and output needs. + +Feature io, of type [[ref:libraries/base/reference/std_files_chart|STD_FILES]] , gives access to standard input and output facilities. For example, io.input is the standard input file and io.new_line will print a line feed on the standard output. Feature io is declared as a once function which, when first called, returns the value of an instance of [[ref:libraries/base/reference/std_files_chart|STD_FILES]] that provides access to the standard input, the standard output and the error output. As a result, io is never void, so that operations such as io.new_line are always possible. + +Function out, of type [[ref:libraries/base/reference/string_8_chart|STRING]] , is a universal mechanism for obtaining a simple external representation of any object. For non-void x of any type, the string x.out is a printable representation of x. This works for x of all types, reference or expanded. For example, if x is an integer expression, x.out is its string representation, such as -897; if n is a non-void reference, x.out is (recursively) the concatenation of the result of applying out to the successive fields of the attached object, each labeled by the name of the corresponding attribute. You may redefine out in any class to specify any suitable format for displaying instances of the class. To obtain the default representation regardless of any redefinition of out, use tagged_out, declared as a frozen synonym of the original out. + +The call print (x) will output the value of x.out on the default output if x is not void, and do nothing otherwise. + +=Copy and comparison routines= + +Procedure copy copies the fields of an object onto those of another. It is used under the form + + target.copy (source) + + +Here both target and source must be non-void; this means that copy is only good for copying onto an object that already exists. If you need both to allocate a new object and to initialize it as a copy of another, use the function twin. For non-void source, the assignment + + target := source.twin + +starts by creating a new object, then populates its fields to be identical to source. + +The boolean function equal compares two objects for field-by-field equality. This is different from the equality operators = and /= which, in the case of reference types, compare references, not objects. + +The function deep_twin produces a duplicate of an entire object structure. The boolean function deep_equal determines whether two object structures are recursively identical. These routines are the ''deep'' counterparts of the shallow copy and equality tests provided by twin and equal. + +A class that needs a specific notion of equality and the corresponding copy semantics may redefine copy and is_equal (from which equal follows, since equal (a, b) is defined as a.is_equal (b) for non-void a). You will find such redefinitions in a number of classes of the Base libraries. For example an instance of [[ref:libraries/base/reference/string_8_chart|STRING]] is a string descriptor containing a reference to the actual character sequence, not that sequence itself, so that what the default equal compares and the default copy copies is the descriptor, not the string. Class [[ref:libraries/base/reference/string_8_chart|STRING]] redefines these routines to yield the semantics normally expected by string clients; the frozen variants standard_copy and standard_equal, originally declared as synonyms to equal and copy, remain available with the default semantics. + +The function twin is defined in terms of copy, and so will follow any redefinition of copy. This makes it impossible to change the semantics of one but not of the other, which would be a mistake. The variant standard_twin is defined in terms of standard_copy. + + +{{note|In some existing Eiffel code you may encounter the use of a function clone which is used to do the job of twin, but has a form like copy, as in target.clone (source). clone is an obsolete function. Use twin instead. +}} + +=Type information= + +The string-valued query generator, applied to any object, returns the name of the object's generating class: the class of which it is an instance. The boolean function conforms_to makes it possible to test dynamically whether the type of an object conforms to that of another - that is to say whether the first one's generator is a descendant of the second one's. + +These two features enable clients to ascertain the dynamic type of an entity at runtime. They are only useful for low-level components; the normal mechanism for type-dependent operations is dynamic binding. + +=Miscellaneous= + +The query Void, of type NONE, denotes a reference that is always void - not attached to any object. + +Procedure do_nothing does what its name implies. + +Function default also has an empty body; its result type is like Current, so what it returns is the default value of the current type. This is mostly interesting for expanded types, since for reference types the default value is simply a void reference. diff --git a/documentation/18.11/solutions/basic-computing/eiffelbase/eiffelbase-tutorial/eiffelbase-kernel/index.wiki b/documentation/18.11/solutions/basic-computing/eiffelbase/eiffelbase-tutorial/eiffelbase-kernel/index.wiki new file mode 100644 index 00000000..835403e0 --- /dev/null +++ b/documentation/18.11/solutions/basic-computing/eiffelbase/eiffelbase-tutorial/eiffelbase-kernel/index.wiki @@ -0,0 +1,20 @@ +[[Property:title|EiffelBase, The Kernel]] +[[Property:weight|0]] +[[Property:uuid|A26C5BCA-20A5-4EE6-9710-F4E8B72DBA10]] +In addition to basic concepts close to the language level, the Kernel covers such common needs as '''input''' and '''output''', '''storage''' and '''retrieval''' of objects on persistent storage, fine control over '''exception handling''' and '''memory management''', and access to '''operating system facilities'''. The kernel can be divided into 5 logical clusters of classes: +# [[Universal class and its features|The first cluster]] contains the universal class defining facilities accessible to all other classes: [[ref:libraries/base/reference/any_chart|ANY]] . Every developer-defined class is a descendant of this class. +# [[Language-related facilities|The second cluster]] includes classes whose facilities are directly related to language concepts: +** Classes describing the basic types: [[ref:libraries/base/reference/boolean_chart|BOOLEAN]] , [[ref:libraries/base/reference/character_8_chart|CHARACTER]] , [[ref:libraries/base/reference/integer_32_chart|INTEGER]] , [[ref:libraries/base/reference/real_32_chart|REAL]] and [[ref:libraries/base/reference/real_64_chart|DOUBLE]] +** Arrays: class [[ref:libraries/base/reference/array_chart|ARRAY]] +** Tuples: class [[ref:libraries/base/reference/tuple_chart|TUPLE]] +** Strings: class [[ref:libraries/base/reference/string_8_chart|STRING]] +** Basic facilities: class [[ref:libraries/base/reference/basic_routines_chart|BASIC_ROUTINES]] +# [[Files, input, output|The third cluster]] provides input and output facilities: +** [[ref:libraries/base/reference/std_files_chart|STD_FILES]] offers basic mechanisms, sufficient for simple input and output. +** [[ref:libraries/base/reference/file_chart|FILE]] describes the notion of sequential file, viewed as a sequence of characters and fully integrated in the data structure library. +** [[ref:libraries/base/reference/directory_chart|DIRECTORY]] gives properties of directories (files serving as collections of other files). +# [[Persistence, storage, and retrieval|The fourth cluster]] makes it possible to store object structures on persistent storage and retrieve them later. This facility can also be used to transmit object structures through pipes or over a network. +# [[Access to internal properties|The last cluster]] provides access to internal properties of the compiler and environment, useful for applications that need some fine-tuning of the basic mechanisms: +** Class [[ref:libraries/base/reference/exceptions_chart|EXCEPTIONS]] (complemented by [[ref:libraries/base/reference/unix_signals_chart|UNIX_SIGNALS]] for Unix-type platforms) provides control over the exception handling mechanism, in particular for applications that need to handle different types of exception in different ways. +** Similarly, classes [[ref:libraries/base/reference/memory_chart|MEMORY]] and [[ref:libraries/base/reference/gc_info_chart|GC_INFO]] provide ways to control the garbage collector and tailor it to specific needs. +** Class ARGUMENTS gives access to the command-line arguments. diff --git a/documentation/18.11/solutions/basic-computing/eiffelbase/eiffelbase-tutorial/eiffelbase-support-cluster.wiki b/documentation/18.11/solutions/basic-computing/eiffelbase/eiffelbase-tutorial/eiffelbase-support-cluster.wiki new file mode 100644 index 00000000..ce401540 --- /dev/null +++ b/documentation/18.11/solutions/basic-computing/eiffelbase/eiffelbase-tutorial/eiffelbase-support-cluster.wiki @@ -0,0 +1,31 @@ +[[Property:title|EiffelBase Support Cluster]] +[[Property:weight|2]] +[[Property:uuid|f9c2a003-9836-6688-db1f-5aa31313b317]] +The support cluster offers some commonly needed functionality that do not belong to the kernel. + +==Conversions, mathematical properties and ASCII characters== + +A few utility classes complement the [[EiffelBase, The Kernel|kernel]] facilities. [[ref:libraries/base/reference/primes_chart|PRIMES]] , [[ref:libraries/base/reference/random_chart|RANDOM]] and [[ref:libraries/base/reference/fibonacci_chart|FIBONACCI]] are part of the data structure taxonomy; the others are meant to be used as ancestors by classes needing their features. + +Two classes provide basic mathematical functions such as logarithms and trigonometric functions: [[ref:libraries/base/reference/single_math_chart|SINGLE_MATH]] for single precision and [[ref:libraries/base/reference/double_math_chart|DOUBLE_MATH]] for the double-precision variants. [[ref:libraries/base/reference/math_const_chart|MATH_CONST]] contains mathematical constants: p , the square root of two, Euler's constant e . + +[[ref:libraries/base/reference/primes_chart|PRIMES]] , [[ref:libraries/base/reference/random_chart|RANDOM]] and [[ref:libraries/base/reference/fibonacci_chart|FIBONACCI]] are data structure classes - heirs of [[ref:libraries/base/reference/countable_sequence_chart|COUNTABLE_SEQUENCE]] . In all of these classes function i_th takes an integer argument i and will return the i-th element of the sequence under consideration - prime numbers, pseudo-random numbers or Fibonacci numbers. These sequences are active structures, on which forth will advance the current position and item will return the value at the current position. A few other features are specific to each case: for example [[ref:libraries/base/reference/random_flatshort|higher_prime]] will yield the smallest prime greater than or equal to a certain value, and [[ref:libraries/base/reference/random_flatshort|set_seed]] will define the seed to be used for starting the pseudo-random sequence. + +==Internal object structures== + +Class [[ref:libraries/base/reference/internal_chart|INTERNAL]] provides low-level access to internal object structures. It, too, is meant to be used as ancestor by classes needing its features.
+Here are some of the most useful calls and what they yield, obj being an entity attached to an object O and i an integer: +* class_name (obj) : the name of the generator class for O. +* dynamic_type (obj) : the integer code for the type of O, where each type in a system is identified by a unique code. +* field_count (obj) : the number of fields in O. +* physical_size (obj) : the space occupied by O, in bytes. +* field_xx (i, obj) where xx is name or offset: name or offset of the i-th field of O. +* field (i, obj) : the value of the i-th field of , if a reference; declared of type ANY in the class. +* yy_field (i, obj) where yy is boolean, character, integer, real or double: the value of the i-th field of O, if of the corresponding type; each declared of the appropriate type in the class. +* is_special (obj) : a boolean query which indicates whether O is a special object (the sequence of values representing the elements of an array or the characters of a string). + +{{warning|Only very special cases justify the use of the class [[ref:libraries/base/reference/internal_chart|INTERNAL]]. Unless you are writing the lowest level of an interface between an Eiffel application and external tools (such as a database management system), and this requires passing to those tools information about the internals of Eiffel objects, you almost certainly should not use [[ref:libraries/base/reference/internal_chart|INTERNAL]] . }} + + + + diff --git a/documentation/18.11/solutions/basic-computing/eiffelbase/eiffelbase-tutorial/index.wiki b/documentation/18.11/solutions/basic-computing/eiffelbase/eiffelbase-tutorial/index.wiki new file mode 100644 index 00000000..e76063cf --- /dev/null +++ b/documentation/18.11/solutions/basic-computing/eiffelbase/eiffelbase-tutorial/index.wiki @@ -0,0 +1,6 @@ +[[Property:title|EiffelBase Tutorial]] +[[Property:weight|-2]] +[[Property:uuid|d540615d-802b-8e12-af74-4d01d1fc4760]] + +Learn about the EiffelBase library. + diff --git a/documentation/18.11/solutions/basic-computing/eiffelbase/ifell.wiki b/documentation/18.11/solutions/basic-computing/eiffelbase/ifell.wiki new file mode 100644 index 00000000..03a8a584 --- /dev/null +++ b/documentation/18.11/solutions/basic-computing/eiffelbase/ifell.wiki @@ -0,0 +1,108 @@ +[[Property:title|IFELL]] +[[Property:weight|4]] +[[Property:uuid|34079f13-741d-a937-e492-9ccfe235efeb]] +This license describes the terms applicable to the open-source EiffelBase libraries. For the EiffelStudio and other libraries license terms, please refer to the Eiffel Software end-user license. + +On August 4, 1998 -- as part of the Eiffel Summit at TOOLS USA '98 -- Interactive Software Engineering (Eiffel Software) officially made its flagship [[EiffelBase|EiffelBase library ]] available for free to any organization that wants to use it, for either commercial or non-profit purposes. + +The terms of the new EiffelBase license are given below. Changes since the original version are recorded in the [[#changes|changes section]] . + +We hope that others will be inspired by this example to release their own reusable Eiffel components to the public. +==Preamble== +(This Preamble is not part of the license.) + +EiffelBase is one of the principal contributions of Eiffel: a library of fundamental structures and algorithms covering the basics of computing, and resulting from a "Linnaean" effort at a general-purpose taxonomy of computing structures. We believe that EiffelBase is one of the most carefully designed and extensively used libraries in the object-oriented industry. The library and its design principles are described in detail in the book [http://www.eiffel.com/services/training/books.html ''Reusable Software: The Base Object-Oriented Component Libraries'' ] . + +EiffelBase is at the center of Eiffel Software's Eiffel and has been among the major factors attracting users to the technology. In spite of this competitive advantage, Eiffel Software officially announced in June of 1998 that it would release the library to the public in source form, under the terms of the license below. There are two main reasons for this initiative: +* As the software industry seems poised to adopt the idea of reusable components, we feel that EiffelBase provides an ideal basis and are happy to contribute it to the community. +* We are impressed by the quality of some public-domain software and the effectiveness of the "open source" movement. We hope that the public availability of EiffelBase in source form will encourage many people to take a close look at the classes of EiffelBase, criticize its weaker points, provide improvements, and add their own high-quality contributions. + +===About the license=== + +After considering existing license contracts for publicly available software, we felt that the GPL (Gnu Public License) as well as LGPL, its variant for libraries, while useful and interesting, were not adequate since they are too restrictive. + +In particular a crucial requirement was that the license should allow commercial companies to use EiffelBase (and other libraries that may use this license in the future) in for-profit developments without any fear (justified or not) that GPL-like requirements could cause proprietary elements of their products to come under the open source umbrella themselves. + +The closest model was that of the Perl Artistic License, which significantly influenced the terms of the agreement as shown below. It too, however, was not applicable verbatim. EiffelBase was initially designed as a commercial product and then released as free software, a different situation from that of software that was never commercial. + +You will note that there are few restrictions on the use of EiffelBase in the license given below. You can use EiffelBase in your academic work and re-publish the source; you can produce a commercial software product using EiffelBase and not owe a cent to Eiffel Software. + +===Ownership=== + +EiffelBase remains an Eiffel Software product and will continue to be distributed as such to Eiffel Software customers. This means in particular that there is no o lessening of our maintenance and support responsibility to our customers under maintenance. In fact, the increased scrutiny and outside contributions will mean an increase of our commitment to develop EiffelBase and of the quality of the product. + +==The License Text== + +This is the official license text. + +===Definitions=== +"Eiffel Software" refers to Interactive Software Engineering Inc. +"The Library" refers to the collection of software texts in the Eiffel programming language, originally written by Eiffel Software, and constituting the EiffelBase library of fundamental computing science structures, as well as any derivatives of these texts as may be created through textual modification (by people) or through translation to lower-level languages (by programs such as compilers). + +"Standard Version" refers to the version of the Library maintained by Eiffel Software and distributed by Eiffel Software to its customers under maintenance. + +"You" means any person interested in using, modifying or distributing the Library. + +"Source form" means the text of the Library's classes, in the Eiffel programming language. + +"Object form" means the translation, as performed by a compiler or other program, of the Library or part of the Library into another, usually lower-level code (such as C, assembly language or machine language) intended for execution by a machine. + +"Reference implementation" means the latest officially released version of Eiffel Software's implementation of the Eiffel programming language. + +===Statement of copyright and ownership=== + +'''1.''' The Library is the property of Eiffel Software and bears Eiffel Software's copyright. Any use you make of the Library must respect Eiffel Software's proprietary rights. + +===Right of use=== +'''2.''' Eiffel Software hereby grants you permission to do any of the following without payment to Eiffel Software, under the conditions of sections 3 to 7 of this Agreement: +* '''2.1.''' Use the Library, in source form or object form, as part of any software you develop and distribute to other parties. +* '''2.2.''' Distribute the source of the Library to other parties. + +===Conditions=== + +'''3.''' If you use (2.1) or distribute (2.2) the Library, you are encouraged, but not required,to provide to Eiffel Software and the rest of the Library's user community any bug fixes or other improvements that you make to the existing classes of the Library. + +'''4.'''If you produce new classes based on the Library or extending the Library, you are encouraged, but not required, to make them available in the same way. + +'''5.''' If you use the Library (2.1) in source or object form for producing software that you distribute, you are encouraged, but not required, to include the following mention (or its translation into the language of the rest of the distribution, if other than English) in the documentation of your software, including textual documentation as well as online documentation such as "About..." entries: +* ''This product includes EiffelBase software from Interactive Software Engineering, used according to the terms of the Eiffel Software Free Eiffel Library License (IFELL). ''See [http://eiffel.com/ http://eiffel.com] and, for the license terms, [http://eiffel.com/products/base/license.html http://eiffel.com/products/base/license.html] . + + +'''6.''' If you distribute the source code of part or all of the Library (2.2) you must: +* Distribute entire classes, not just extracts. +* Retain, in the distributed version, the entire copyright notice of these classes. +* If you need to make any modification to the classes, mark those modifications clearly in the class texts. +* Ensure that the text remains valid Eiffel. Note that this license does not authorize you to distribute versions of the Library restated in other programming, analysis or design languages, except if mechanically translated from the source form by an Eiffel compiler, in which case they fall under "object form". For any non-mechanical adaptation to other languages you must obtain authorization from Eiffel Software. "Valid Eiffel" includes the language described in the latest edition or printing of the book ''[[Eiffel: The Language]]'' (Prentice Hall), plus any changes or extensions that have been approved by the Nonprofit International Consortium for Eiffel (NICE) or have been accepted for discussion by the Language Committee of NICE, provided they are accepted by the reference implementation. +* If Eiffel Software releases a new version of the Library, you must, no later than six months after the release of that version, either: (A) update your distribution to the new version; (B) add the following notice to all files in your distribution:" ''This is an obsolete version of EiffelBase. The latest version is available from http://eiffel.com''"; or (C) cease distributing your version. + + +You may not charge any fee for the distribution of the Library (source or binary), although you may charge for software that includes the Library in whole or in part as per the other provisions of this Agreement. + +'''7.''' You may not use the name of Eiffel Software to endorse or promote products derived from the Library without specific prior written permission. + +'''8.''' THIS PACKAGE IS PROVIDED "AS IS" AND WITHOUT ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, WITHOUT LIMITATION, THE IMPLIED WARRANTIES OF MERCHANTIBILITY AND FITNESS FOR A PARTICULAR PURPOSE. + +==Changes== +(This list of changes is not part of the license.) +'''General note on changes''': as usage of free EiffelBase grows and more people contribute to it, some terms of the license text may occasionally have to be changed in light of this accumulated experience and of comments received from users and contributors. It is our intention to ensure that +* (1) Any such changes will be minor, affecting the details of the licensing rather than the spirit of IFELL. +* (2) If they affect the substance of the license in any way, they go in the general direction of extending, not restricting, the rights of users of EiffelBase. + + +Should a question arise regarding use of EiffelBase, the terms to be applied are those in effect at the time of use, disregarding any later change. + +'''28 June 2000''': in response to comments by Joachim Durchholz through Patrick Schoenbach, replacement of most occurrences of the word "EiffelBase" by"the Library" to facilitate application to other libraries. + +'''7 May 1999''': in response to comments by David Broadfoot on the Eiffel Software user list, rewording of the [[#contamination|explanation]] of why we are applying more liberal terms than GPL-style licenses. regarding fears of [[#contamination|contamination]] with the Gnu Public License. + +'''6 May 1999''': following comments by Ed Avis and Alexander Kjeldaas, we now permit distribution maintainers to continue distributing an old version as long as they [[#obsolete_version|mention clearly that it's obsolete ]] . + +'''7 April 1999''': following comments by Loryn Jenkins and Ed Avis, removal of the requirement that bug fixes and improvements be provided back to the maintainers of the library. This requirement has been changed to a mere [[#encourage_bug_reports|encouragement ]] , facilitating use of the library. Of course it is in everyone's interest to report bugs and improvements. + +'''7 April 1999''': following comments by Loryn Jenkins, loosening of the [[#valid_eiffel|definition of "valid Eiffel"]] . This change also caused addition of the notion of [[#reference_implementation|reference implementation]] . The purpose is to avoid crippling EiffelBase by preventing it from utilizing innovative language constructs and corrections in the language contributions. Such language extensions are OK as long as they have been accepted for discussion by NICE and are supported by the reference implementation. + +'''1 April 1999''': following some comments by Richard Stallman,addition of a qualification (" ''justified or not''") to the notes regarding fears of [[#contamination|contamination ]] with the Gnu Public License. Our intention is not to criticize the GPL but simply to note that the GPL does cause some fears, "justified or not", among commercial developers. + + + + diff --git a/documentation/18.11/solutions/basic-computing/eiffelbase/index.wiki b/documentation/18.11/solutions/basic-computing/eiffelbase/index.wiki new file mode 100644 index 00000000..cd4c87b5 --- /dev/null +++ b/documentation/18.11/solutions/basic-computing/eiffelbase/index.wiki @@ -0,0 +1,11 @@ +[[Property:title|EiffelBase]] +[[Property:weight|1]] +[[Property:uuid|0153c1de-bf88-fa0d-52a5-e50ffcc4e8c8]] +==The EiffelBase Library== + +Type: Library
+Platform: Any
+Availability: Open Source, Eiffel Forum License version 2 (EFLv2) + +The EiffelBase class library, covered by the open-source Eiffel Forum License version 2 (EFLv2), is one of the principal contributions of Eiffel: a library of fundamental structures and algorithms covering the basics of computing, and resulting from a "Linnaean" effort at a general-purpose taxonomy of computing structures. EiffelBase is one of the most carefully designed and extensively used libraries in the object-oriented industry. + diff --git a/documentation/18.11/solutions/basic-computing/index.wiki b/documentation/18.11/solutions/basic-computing/index.wiki new file mode 100644 index 00000000..683a60a7 --- /dev/null +++ b/documentation/18.11/solutions/basic-computing/index.wiki @@ -0,0 +1,7 @@ +[[Property:title|Basic computing]] +[[Property:weight|-15]] +[[Property:uuid|be2b9c40-f2ff-d6dc-738d-b240deb69407]] +==Fundamental computing and data structures== + +Eiffel solutions for everyday computing needs. + diff --git a/documentation/18.11/solutions/concurrent-computing/SCOOP_tutorial.wiki b/documentation/18.11/solutions/concurrent-computing/SCOOP_tutorial.wiki new file mode 100644 index 00000000..2e6a0464 --- /dev/null +++ b/documentation/18.11/solutions/concurrent-computing/SCOOP_tutorial.wiki @@ -0,0 +1,7 @@ +[[Property:modification_date|Fri, 30 Nov 2018 20:17:44 GMT]] +[[Property:publication_date|Mon, 26 Nov 2018 12:09:44 GMT]] +[[Property:uuid|FF51774B-2EB9-4EDF-8A0C-0F71A96D391F]] +[[Property:weight|0]] +[[Property:title|SCOOP_tutorial]] +[[Property:link_title|SCOOP Tutorial: a small concurrent email system]] +The text of this tutorial will be available on 2 December 2018 (sorry for the delay but please come back!). \ No newline at end of file diff --git a/documentation/18.11/solutions/concurrent-computing/concurrent-eiffel-scoop/SCOOP-papers.wiki b/documentation/18.11/solutions/concurrent-computing/concurrent-eiffel-scoop/SCOOP-papers.wiki new file mode 100644 index 00000000..36840529 --- /dev/null +++ b/documentation/18.11/solutions/concurrent-computing/concurrent-eiffel-scoop/SCOOP-papers.wiki @@ -0,0 +1,9 @@ +[[Property:uuid|7A9673B8-2FFC-4C9B-A055-29EB1CDD653F]] +[[Property:weight|10]] +[[Property:title|SCOOP papers]] +[[Property:link_title|papers]] += Papers related to SCOOP and Concurrency = + +== Concurrency patterns in SCOOP (Master Thesis by Romans Schmocker) == +* Permanent link: [https://doi.org/10.3929/ethz-a-010255889] +* Local file: [[file:eth-46802-01.pdf|document as pdf]]. diff --git a/documentation/18.11/solutions/concurrent-computing/concurrent-eiffel-scoop/index.wiki b/documentation/18.11/solutions/concurrent-computing/concurrent-eiffel-scoop/index.wiki new file mode 100644 index 00000000..58af1827 --- /dev/null +++ b/documentation/18.11/solutions/concurrent-computing/concurrent-eiffel-scoop/index.wiki @@ -0,0 +1,32 @@ +[[Property:link_title|SCOOP]] +[[Property:title|Concurrent programming with SCOOP]] +[[Property:weight|1]] +[[Property:uuid|5FE312E0-0AC6-465C-AD3B-D5D73AAE566F]] +==Overview== + +SCOOP is ''Simple Concurrent Object-Oriented Programming''. SCOOP allows developers to create object-oriented software systems which will take advantage of multiple, concurrently active execution engines while providing strong guarantees that allow programmers to reason like in sequential programs. Read further to get a better idea of what all this means, but for now, the primary message should be: SCOOP is concurrent software development made easy. The basic SCOOP ideas were first published as early as 1993. Since that time, considerable research and development has refined the SCOOP into the model that is implemented in EiffelStudio today. + + +{{Note|As you begin to use SCOOP you should make sure that you correctly set up your project. Information on how to do this can be found at [[Getting Started with SCOOP]]. Also consider compiling and working with some of the many [[SCOOP examples]].}} + + +==Concurrency== + +Concurrency in computation is a situation in which we can expect that a running computer system will have multiple computations executing simultaneously in a controlled fashion to achieve the goals of the system. The simultaneous executions can be handled by widely diverse computational engines: separate networked computer systems, separate processors in the same CPU, separate processor cores on a single chip, separate processor threads within a process, separate processes on the same CPU, etc... + +Concurrent systems would not cause much trouble if the portions of the systems on different processors, processes, or threads were completely independent, that is, they shared no resources. But that would be a rare case indeed. In a concurrent system, simultaneously executing software elements can and do share resources and communicate with each other. This is where the problems can arise; problems in the form of various synchronization issues such as [http://en.wikipedia.org/wiki/Race_condition#Computing race conditions], [http://en.wikipedia.org/wiki/Atomicity_(programming) atomicity] violations, and [http://en.wikipedia.org/wiki/Deadlock deadlocks]. The issues boil down to two essential problems in allowing access to shared resources: + +:# '''Provide Safety''': Make certain that nothing bad ever happens, like two threads that access the same memory in no defined order, or an invalid interleaving of operations that causes the program to crash. +:# '''Ensure Progress''': Make certain that every participating thread eventually gets the opportunity to execute. Possible problems in this category are deadlocks, starvation (a thread keeps a lock forever, causing another one to wait), fairness etc... + +Concurrency control is a rich research area in computer science. Consequently, many schemes have been designed to control concurrent computation. + +SCOOP is such a model for concurrent computation which differs in some areas from other research efforts. + +First, it is a goal of SCOOP to abstract the notion of concurrency to a level above the tools and techniques that are currently available. What this means is that if you were writing a system with multiple process threads, you could do that without SCOOP, using the tools that are currently used in multi-threaded programming, like semaphores and mutexes. Or you could write it in SCOOP using only the SCOOP mechanisms. Likewise with SCOOP, a system intended to run on multiple processors or multiple processor cores also could be written using only those same SCOOP mechanisms that you used for the multi-threaded system. + +Second, the SCOOP model depends primarily upon Design by Contract with slightly changed contract semantics, and a single new keyword separate added to the Eiffel programming language. As you will see, the semantics of preconditions differ with concurrent execution versus sequential. Also, there are other underlying concepts and rules that need to be understood, but the point is that concurrent Eiffel using SCOOP will look a lot like sequential Eiffel. + +Third, SCOOP uses the common act of argument passing to identify the necessity for guaranteeing exclusive access. + +We will examine the details of how all this fits together and what it means to you as you begin to build concurrent software in Eiffel using SCOOP. diff --git a/documentation/18.11/solutions/concurrent-computing/concurrent-eiffel-scoop/scoop-asynchronous-calls.wiki b/documentation/18.11/solutions/concurrent-computing/concurrent-eiffel-scoop/scoop-asynchronous-calls.wiki new file mode 100644 index 00000000..fd3bc333 --- /dev/null +++ b/documentation/18.11/solutions/concurrent-computing/concurrent-eiffel-scoop/scoop-asynchronous-calls.wiki @@ -0,0 +1,136 @@ +[[Property:title|Asynchronous Calls]] +[[Property:weight|6]] +[[Property:uuid|d3d3873c-5c84-7566-547e-1ede38544081]] +==Overview== + +As we've seen in [[Separate Calls]], feature calls to a non-separate target are always synchronous. +Furthermore, queries are always synchronous as well, because the caller has to wait for the result. + +{| border="1" +|- +! Target +! Query +! Command +|- +| non-separate +| synchronous +| synchronous +|- +| separate +| synchronous +| potentially asynchronous +|} + +Asynchronous calls can therefore only happen on commands with a separate target. +Indeed, such calls are by default executed asynchronously, but there are some important exceptions to this rule. +A command to a separate target is executed synchronously if any of the following applies: +* The client (caller) and supplier (target) region are the same. +* The target region is passive. +* The callee needs a lock currently held by the caller (lock passing). +* The caller holds the locks of the callee (separate callbacks). + +== Triggers for Synchronization == + +=== Same Regions === + +The first case happens when a reference is declared separate, but happens to be non-separate. This case follows directly from the type system: A non-separate type A always conforms to its variation separate A. At run-time such cases can be detected with an object test: + + +sep_object: separate A +--... +if attached {A} sep_object as non_sep_object then + -- ... +end + + +=== Passive Regions === + +In the SCOOP model, a passive region does not have a processor attached to it. +This means that clients of the passive region need to apply features logged against a passive region themselves. +The logical consequence of this is that all call to a passive region, including commands, are executed synchronously. + +=== Lock Passing === + +Lock passing is another source of synchronization. It is one of the trickiest issues to detect, and to fully understand it we must first introduce a few more definitions. + +In [[Exclusive Access]] we have learned that an object is ''controlled'' if it appears as a formal argument of the enclosing routine. SCOOP however always grants exclusive access over a whole region. We therefore introduce the new term ''Lock'': + +{{definition|Lock|Exclusive access to a SCOOP region and all objects therein.}} + +Note the difference between ''controlled'' and ''locked'': +* ''Controlled'' applies to a single object, whereas ''locked'' applies to a region. +* The ''controlled'' property can be determined statically at compile-time, whereas ''locked'' is determined at runtime. +* The set of ''controlled'' objects of a processor is always a subset of the set of objects in ''locked'' regions. + +{{note|In terms of implementation, a ''lock'' corresponds to an open call queue to a region.}} + +Now consider a small classes HASH_STORAGE and EXAMPLE: + +class HASH_STORAGE feature + + hash_code: INTEGER + + set_hash_code (a_string: separate STRING) + do + hash_code := a_string.hash_code + end +end + +class EXAMPLE feature + + run (a_hash_storage: separate HASH_STORAGE; a_string: separate STRING) + do + a_hash_storage.set_hash_code (a_string) + io.put_integer (a_hash_storage.hash_code) + end +end + + +You might notice a problem here: +In the feature {EXAMPLE}.run, exclusive access to 'a_hash_storage' and 'a_string' is guaranteed by the SCOOP semantics. +Or in other words, the corresponding regions are ''locked''. The feature {HASH_STORAGE}.set_hash_code however needs access to ''a_string'' as well. +In the SCOOP model, as seen so far, this would result in a deadlock. The handler of the HASH_STORAGE object waits for exclusive access on the string object, and the EXAMPLE object waits for the query {HASH_STORAGE}.hash_code to return. + +To resolve this problem, SCOOP implements a technique called ''Lock Passing''. +Locks on regions can be passed to the handler of the target of a separate call. +Lock passing happens whenever the client processor (the handler of the EXAMPLE object) has locked a region that holds an object which is passed as an actual argument to a separate call. Note that this also includes non-separate reference objects, because a processor always holds a lock over its own region. + +When a client has passed its locks to the supplier processor, it cannot continue execution until the called feature has been applied by the supplier processor, and the supplier processor has given back the locks to the client. Therefore, this type of call must be synchronous. + +{{note|During lock passing, a processor gives away all the locks that it currently holds, including the lock on itself.}} + +{{note| Lock passing happens for every synchronous call, in particular also for queries and passive processors.}} + +The advantage of lock passing is that it enables some very common programming patterns without triggering a deadlock. The disadvantage, however, is that it's hard to tell '''when''' it happens. However, there are a few cases when lock passing is guaranteed to happen, namely when the actual argument passed to a separate call is +* a formal argument of the enclosing routine, +* of a non-separate reference type or +* Current. + +There are, however, some cases where it's not immediately obvious that lock passing happens. +For example, a region might be locked because of a controlled argument somewhere further up in the call stack (i.e. not the enclosing routine, but the caller of that routine), or because an object is passed as an argument which happens to be on the same region as one of the controlled objects. + +There is a workaround to disable lock passing for a specific call: + +async_call (a_procedure: separate PROCEDURE [TUPLE]) + do + a_procedure.call (Void) + end + +example (a_object: separate ANY) + do + async_call (agent a_object.some_feature (Current)) + end + + +The feature async_call can be defined somewhere in the project and can be reused. The downside is that an agent needs to be created, but there's no lock passing happening, because all arguments to the agent are closed and only Void is passed to the separate call which cannot trigger lock passing. +However, this mechanism should be used with some care, because it's easy to run into one of the above mentioned deadlocks. + +=== Separate Callbacks === + +The last occurrence of synchronous calls is closely related to lock passing. If a processor '''A''' has passed a non-separate reference argument to another processor '''B''', and thus has passed its locks away, it cannot proceed its execution. Sometimes however processor '''B''' has to log some calls back to '''A''', which is called a ''separate callback''. + +{{definition|Separate Callback | A separate call where the caller holds the locks of the callee. }} + +During a separate callback processor '''B''' has to give back the locks it has previously received from '''A'''. +This in turn means '''B''' has to wait until '''A''' has finished its execution of the separate callback and returned the locks, which effectively makes the call synchronous. + diff --git a/documentation/18.11/solutions/concurrent-computing/concurrent-eiffel-scoop/scoop-design-by-contract.wiki b/documentation/18.11/solutions/concurrent-computing/concurrent-eiffel-scoop/scoop-design-by-contract.wiki new file mode 100644 index 00000000..62b16d6f --- /dev/null +++ b/documentation/18.11/solutions/concurrent-computing/concurrent-eiffel-scoop/scoop-design-by-contract.wiki @@ -0,0 +1,57 @@ +[[Property:title|Design by Contract in SCOOP]] +[[Property:link_title|Design by Contract]] +[[Property:weight|5]] +[[Property:uuid|f8df5904-d1ee-31d7-f618-fb8bf1ddc876]] + +The backbone of the Eiffel Method is design by contract. Preconditions, postconditions, and class invariants are used in Eiffel for extending software interfaces into software specification. This is essentially the same in concurrent Eiffel with SCOOP as it is in traditional, sequential Eiffel. However, because of the concurrent nature of processing under SCOOP, the runtime semantics of the elements of Design by Contract are different for concurrent systems. + + +==Preconditions== + +The role of the precondition is somewhat different in SCOOP than in sequential Eiffel. In non-concurrent Eiffel we view the precondition of a routine as defining a set of obligations on potential callers of the routine. That is, the set of conditions that must be true before correct execution of the routine can be expected. So, we could look at the precondition clauses in sequential Eiffel as '''correctness conditions'''. A typical example might be a square root routine that returns the square root of a passed argument value. A precondition clause, i. e., a correctness condition, for this routine will be that the argument must be non-negative. It is the responsibility of the caller to ensure that this property of the argument holds at the time of the feature call. + +In concurrent Eiffel, the same correctness conditions are still valid, but there are cases in which we must view the clients role here a little differently. +In the case of a precondition clause that depends on a separate object, even if the client tests the condition ahead of the call, there is no assurance that action by some other concurrent processor may have invalidated the precondition clause between the time that the check was made and the time that the feature application takes place. + +In SCOOP preconditions can therefore additionally take the role of a '''wait condition'''. +Wait conditions are useful for cases where the caller can't guarantee that a property on an object is true at the time of the call, but it knows that it will eventually become true. +If a wait condition fails, the current processor will stall its execution, release the locks on its arguments, and wait until the precondition is fulfilled. + +A typical example is a CONSUMER object trying to dequeue an item from a shared BUFFER. +In the following example, the precondition in {CONSUMER}.consume is treated as a wait condition: + +class CONSUMER feature + consume (a_buffer: separate BUFFER): INTEGER + require + not_empty: not a_buffer.is_empty + do + Result := a_buffer.item + a_buffer.remove + end +end + + +A precondition clause is only treated as a wait condition when there's a separate call. +However, the opposite is not true - not all precondition clauses with a separate call are treated as wait conditions. +The rule is a bit tricky to understand, but as a general rule of thumb, a precondition violation is raised when the SCOOP runtime detects that there's no possibility that a precondition clause may become true in the future if the routine releases its exclusive access. + +{{Info| Alright, here are the exact rules: The decision depends on the context of the '''caller''' of the routine. +If one of the separate objects used as a target in a precondition clause is ''locked'' (see definition in [[Asynchronous Calls]]) in the context of the caller, the precondition is treated as a correctness condition. Otherwise, it is a wait condition.}} + +{{SeeAlso|The {PRODUCER}.store feature in the [[Producer-consumer|producer-consumer]] example. When called by {PRODUCER}.produce it becomes a '''wait condition'''.}} + +==Postconditions== + +As with preconditions the effect of concurrent execution can make a difference in how postconditions are viewed. + +If a routine has executed correctly, then the postcondition of the routine will hold at the time that it terminates. This is true whether or not concurrency is involved. However, when a postcondition involves separate calls, clients must be cautious about how they depend upon the state guaranteed by postconditions. + + +==Class invariants== + +The '''separate argument''' rule in [[Separate Calls]] tells us that a separate call is valid only on a target which is a formal arguments of the enclosing routine. Because class invariants are not routines and therefore have no arguments, separate calls are not allowed in class invariants. + +{{Info|Technically, it should be possible in a class invariant to code an inline agent that gets passed arguments of separate types, then execute separate calls within the inline agent. But generally, it can be assumed that class invariants contain no separate calls. }} + +The semantics of class invariants will be the same as in sequential Eiffel, precisely because invariants must include only non-spearate calls. To put it the terms of SCOOP, the class invariant ensuring the validity of any particular object will be evaluated entirely by the processor handling that object. + diff --git a/documentation/18.11/solutions/concurrent-computing/concurrent-eiffel-scoop/scoop-examples/baboon-crossing.wiki b/documentation/18.11/solutions/concurrent-computing/concurrent-eiffel-scoop/scoop-examples/baboon-crossing.wiki new file mode 100644 index 00000000..b3e0e0ba --- /dev/null +++ b/documentation/18.11/solutions/concurrent-computing/concurrent-eiffel-scoop/scoop-examples/baboon-crossing.wiki @@ -0,0 +1,46 @@ +[[Property:title|Baboon crossing]] +[[Property:weight|-10]] +[[Property:uuid|8b48b7bb-baa8-41a2-2d93-1d9667b05323]] + + +=Description= + +In the baboon crossing problem, a number of baboons are located on the edges of a deep canyon. There are baboons on both sides and, as you have probably guessed, some of the baboons on the left side want to get to the right side, and vice versa. Fortunately, a large rope has been stretched across the abyss allowing baboons to cross by brachiation: hanging from the rope and swinging hand-over-hand to the other side. + +The baboon crossing policy must be compatible with the constraints of the situation: + +# If two baboons meet in the middle of the rope, then all activity stops, and no other baboons can cross (deadlock). So, at any given time, all the baboons on the rope must be going the same direction. +# The rope can hold only a certain number of baboons at a time. A baboon cannot be allowed on the rope if the rope is already at full capacity. +# A continuous stream of baboons from one direction could prevent baboons wanting to go the opposite direction from ever being able to cross (unfairness, starvation). + + +=Highlights= + +The rope is modeled in this example by class ROPE, and is the primary shared resource. The fact that, at any given moment, the rope is considered unavailable to baboons wanting to cross the canyon in the direction opposite the current flow of baboons adds an interesting twist ... as does the maximum limit of baboon flesh that the rope can support. The ROPE class has features to manage its state: + +: capacity is an integer representing the maximum number of baboons that can be supported at one time. +: baboons is an integer which is the number of baboons currently traversing the rope. +: direction is the current direction of baboon flow, represented as a boolean. +: changing is an indicator of whether the direction of the rope is currently in the process of changing. +: is_secure is a boolean indicating whether the rope is in such a state that a baboon may be allowed to mount the rope. + +ROPE also includes procedures mount and dismount which a baboon uses to get on and off the rope. + +There are two more interesting features of ROPE, directions and announce which will be discussed below. + +The baboons (modeled by class BABOON), as they are created, are determined at random to want to go either left or right. As each baboon is created by the root class of the example, it is launched into life. For the purposes of this example, the baboon life is short and consists of four steps: + +: 1) Announcing one's desired direction to the rope. Doing this involves the feature {ROPE}.announce that was mentioned above. The rope keeps a queue of these desired directions as announced by the baboons in its directions feature. It is by keeping this queue that the rope can make its decisions to change the direction of the flow of baboons. + +: 2) Mounting the rope. The baboon calls its own mount feature (which in turn calls {ROPE}.mount. The baboon's mount procedure includes two wait conditions. One makes sure the rope is safe ({ROPE}.is_secure), and the second make sure that the direction of the baboons is the same as that of the baboon wanting to mount. Whenever these conditions are met, the baboon is able to grab a spot on the rope and start to cross the canyon. + +: 3) Traversing the canyon. Once on the rope, the baboon takes a short time to make it to the other side. + +: 4) Dismounting the rope. After crossing the canyon, the baboon gets off the rope ... and dies immediately after attaining what was apparently its only goal in life. + +Although it was mentioned above, it bears repeating that the rope is not just a shared resource, but an active and important player in this example. Indeed, it is the rope that controls the direction of the flow of baboons across the canyon, and ensures fairness. + +When a baboon announces himself as a candidate for crossing the canyon in a particular direction, the rope queues this information. When the rope allows a baboon to mount and cross, the desired direction of the next baboon in the directions queue is queried. If the next baboon wants to go in a different direction, then the state of the rope is set to "changing", and no more baboons are allowed on the rope until the current stream finishes crossing. When the last baboon if that stream dismounts the rope, the direction of flow is changed and the "changing" state is repealed, allowing baboons wanting to cross in the opposite direction to have a go. + + + diff --git a/documentation/18.11/solutions/concurrent-computing/concurrent-eiffel-scoop/scoop-examples/barbershop.wiki b/documentation/18.11/solutions/concurrent-computing/concurrent-eiffel-scoop/scoop-examples/barbershop.wiki new file mode 100644 index 00000000..b6dc28c1 --- /dev/null +++ b/documentation/18.11/solutions/concurrent-computing/concurrent-eiffel-scoop/scoop-examples/barbershop.wiki @@ -0,0 +1,27 @@ +[[Property:title|Barbershop]] +[[Property:weight|-11]] +[[Property:uuid|3a6f929f-17a2-c9d8-1b88-0aad83db4160]] + +=Description= + +The [http://en.wikipedia.org/wiki/Sleeping_barber_problem barbershop], sometimes called ''the sleeping barber'', models a barbershop with one barber, one barber's chair, and a waiting room with several chairs. The alternative name of the problem comes from the fact that if there is no one waiting for a haircut, the barber flops in his chair and falls asleep. + +Also involved are a number of shaggy-haired customers. A customer entering the barbershop looks around and assesses the situation. If all the waiting room chairs are occupied, the customer leaves the shop to return again at a time when hopefully the queue will be shorter. If there is an open chair the customer sits down and waits for the barber. + +Once the barber has finished cutting a customer's hair, the customer leaves the shop which allows another customer to enter the shop (if all the chairs had been occupied) and the the next customer (if there is one) in the queue to get a haircut. + +In this example, even after getting their hair cut, the customers come back to the shop until they have had their hair cut some prescribed number of times. + + +=Highlights= + +The example contains classes that model the barber (BARBER), the customers (CUSTOMER), and the shop with its waiting area (SHOP). The root class creates as separate objects the barber, the shop, and the set of customers. As each customer is created, it is launched on its lifecycle of getting haircut after haircut until haircuts are no longer needed. + +The SHOP includes features enter and leave. Customers call the enter feature to find out if there is a chair available in the shop. Customers call leave, after their hair has been cut. Both of these calls are "wrapped" as separate calls in the class CUSTOMER. + +A typical customer lives in this way: As long as he still needs haircuts, he repeatedly does the following steps: He tries to enter the shop. If he's unsuccessful because all the chairs are occupied, he goes off for a while (in the implementation, his processor sleeps and then comes to the end of this step). If he is able to enter the shop, then he puts himself in the queue for a haircut. Once his haircut is complete, he reduces his number of haircuts needed by one, and leaves the shop. + + + + + diff --git a/documentation/18.11/solutions/concurrent-computing/concurrent-eiffel-scoop/scoop-examples/counter.wiki b/documentation/18.11/solutions/concurrent-computing/concurrent-eiffel-scoop/scoop-examples/counter.wiki new file mode 100644 index 00000000..bb732888 --- /dev/null +++ b/documentation/18.11/solutions/concurrent-computing/concurrent-eiffel-scoop/scoop-examples/counter.wiki @@ -0,0 +1,36 @@ +[[Property:title|Counter]] +[[Property:weight|-14]] +[[Property:uuid|ef5e7a86-3c2d-6a55-07b5-395f30bf8f96]] + +=Description= + +Unlike many of the other examples, this one is not really a problem to be solved. Rather, the Counter example uses multiple instances of the simple class COUNTER to explore various concurrent scenarios. Each instance of COUNTER has a unique identifier, a current value, and a speed. A counter's speed is that time that it takes to perform a single increment. You will see that some of the tests start multiple counters at different speeds. Class COUNTER has a procedure run which takes an integer as an argument, and increments the counter that many times. The example's root class contains the code to create counter instances and run the various tests. + +=Highlights= + +There are six tests that can be called from the root procedure: + + + make + -- Test counters. + do + print ("Counter application%N") + -- Leave one of the following lines uncommented to perform testing. + + test_1 -- start just one counter +-- test_2 -- start two counters +-- test_3 -- start many counters +-- test_4 -- start counter_1 twice +-- test_5 -- start counter_1 with precondition +-- test_6 -- start counter_1 separately and counter_2 non-separately + end + + +You can uncomment the test that you want to run and leave the rest commented. When you run the test, you can see you can watch the output in the console window as the test progresses. + +Have a look at the source code for each test before you run it, so that you can reconcile the output you see with your expectation of the execution. + + + + + diff --git a/documentation/18.11/solutions/concurrent-computing/concurrent-eiffel-scoop/scoop-examples/dining-philosophers.wiki b/documentation/18.11/solutions/concurrent-computing/concurrent-eiffel-scoop/scoop-examples/dining-philosophers.wiki new file mode 100644 index 00000000..caca96b4 --- /dev/null +++ b/documentation/18.11/solutions/concurrent-computing/concurrent-eiffel-scoop/scoop-examples/dining-philosophers.wiki @@ -0,0 +1,53 @@ +[[Property:title|Dining philosophers]] +[[Property:weight|-12]] +[[Property:uuid|569f012e-7913-fbdf-7ad7-cd17d82e64aa]] + +=Description= + +In the [http://en.wikipedia.org/wiki/Dining_philosophers_problem dining philosophers] a number of philosophers (five, in our example) are seated at a round table. On the table are five plates of food, one in front of each philosopher, and five forks, one between each adjacent pair of plates. So each philosopher has a plate in front of him and a fork to his left and a fork to his right. + +The philosophers spend all their time in either of only two states: they are thinking or they are eating. The philosophers may be mental giants, but apparently manual dexterity is not their strong suit. This is evidenced by the fact that in order to eat, any philosopher must be able to pick up both of the forks positioned next to his plate (which he can do, so long as neither of the philosophers next to him is currently eating). So, while eating he must have possession of both forks, and while thinking, he has put down any forks that he had previously used. Therefore, any particular philosopher has the opportunity to eat only when the two philosophers on either side of him are thinking and have made their forks available. + +Apart from any negative consequences from the questionable sanitary practices described above, the dining philosophers can, in improperly designed solutions, encounter problems related to concurrency. For example, if all philosophers were to pick up the fork to their right and then wait for the fork to their left to become available (or vice versa), the philosophers would be caught in a [http://en.wikipedia.org/wiki/Deadlock deadlock]. If, because of a lack of fairness in the solution, some of the philosophers get stuck in thinking mode because they can never secure the two forks necessary to eat, then those philosophers so affected would suffer a condition known as [http://en.wikipedia.org/wiki/Resource_starvation resource starvation]. + + +=Highlights= + +This example includes three classes relevant to the problem: DINING_PHILOSOPHERS, PHILOSOPHER, and FORK. Class DINING_PHILOSOPHERS sets the problem in motion by creating the forks and philosophers all typed as separate, and then applying the feature live to each philosopher after creation. + +Class PHILOSOPHER models the philosophers. The totality of a philosopher's exciting activities is modeled by the feature step: + + + step + -- Perform tasks. + do + think + eat (left_fork, right_fork) + end + + +This feature is called by {PHILOSOPHER}.live repeatedly until the philosopher has eaten a prescribed number of times. + +The feature think requires no access to shared objects, but the feature eat depends upon the philosopher's ability to secure access to both of the forks adjacent to his plate. Because all forks are separate objects, each call to eat waits until the processors for both the left and right forks are available (in accordance with the [[Concurrent programming with SCOOP#Access to shared resources|Wait rule]]). + +Another interesting feature of this example is the feature {PHILOSOPHER}.eat. If you look at the text of this feature + + + eat (l, r: separate FORK) + -- Eat, having grabbed l and r. + do + io.put_string ("Philosopher " + id.out + ": taking forks%N") + times_eaten := times_eaten + 1 + io.put_string ("Philosopher " + id.out + ": eating%N") + io.put_string ("Philosopher " + id.out + ": putting forks back%N") + end + + +and you're not wearing your SCOOP glasses, this could look a little odd to you. Here is a routine that takes two arguments l and r representing the left and right forks. But then, l and r are never used in body of the routine! + +However, with SCOOP in mind, we realize that the fork objects are shared resources to which exclusive access must be secured before a philosopher can eat. In this example, the fork object themselves don't really do anything except serve that purpose. (Take a look at the FORK class, and you'll see that it has no features.) + +In real world concurrency problems, it is likely that shared resources would play a more active role than the forks of the dining philosophers, but here it's just not necessary. + + + diff --git a/documentation/18.11/solutions/concurrent-computing/concurrent-eiffel-scoop/scoop-examples/dining-savages.wiki b/documentation/18.11/solutions/concurrent-computing/concurrent-eiffel-scoop/scoop-examples/dining-savages.wiki new file mode 100644 index 00000000..611e9d56 --- /dev/null +++ b/documentation/18.11/solutions/concurrent-computing/concurrent-eiffel-scoop/scoop-examples/dining-savages.wiki @@ -0,0 +1,24 @@ +[[Property:title|Dining savages]] +[[Property:weight|-6]] +[[Property:uuid|ecd618f3-14f4-1a06-7f9c-be57623a9889]] + +=Description= + +The problem of the dining savages (an allusion to the classic dining philosophers) is based on the arguably tasteless analogy of a number of members of a primitive culture, hereinafter called the "savages", sharing a meal from a single pot. The primary abstractions are the savages themselves, a cook, and the pot. The pot contains a certain number of servings of savage sustenance (the nature of which will be left to your imagination). Each of the savages can freely remove a serving from the pot so long as the pot is not empty. So before taking a serving, a savage must check to make sure the pot is not empty. In the case in which the pot is empty, the savage must wake up the cook to refill the pot, after which the feast continue. The savages, then, can eat only when the pot is not empty, and the cook can fill the pot only when the pot is empty. + + +=Highlights= + +The primary shared resource here is the pot, represented by class POT, which is accessed for different purposes by both the savages and by the cook. POT has queries is_empty and is_full that can be used by savages (modeled by class SAVAGE) and the cook (class COOK). POT also has a feature to allow refilling of the pot. This feature is exported only to COOK. Another feature, this one exported only to SAVAGE allows the removal of a serving from the pot. + +The cook can also be viewed as a resource shared among all the savages. Whenever a savage executes the feature that checks the pot, he must have exclusive access to both the pot and the cook. If the pot is empty then the savage uses his access to the cook to request a refill. If the pot is not empty, then the savage exits the routine, and goes on to execute the routine that removes a serving from the pot. + +In the root class, you can adjust the number of savages, the size (in servings) of the pot, and how hungry the savages are. The hunger index indicates how many times a savage will take a serving from the pot and eat it before becoming sated. So if the pot holds 20 servings and there are 5 savages with hunger index of 4, then the pot will become empty just as the last savage takes his last serving, meaning that the pot will not require refilling. In the same scenario, if the hunger index were 10, then 50 servings total would be required, resulting in the need for the cook to be notified to refill the pot 2 times ... and 10 servings leftover ... presumably for tomorrow's breakfast. + +The root class creates the pot, then the cook, then some number of savages. As the savages are created, their lives are launched. To occupy themselves, they repeatedly check the pot, take a serving, and eat. They give this all up once they have eaten the number of servings prescribed by their hunger index. During the check of the pot, if the pot is empty, a separate call is made to the cook requesting that the pot be refilled, and the savage goes on about the business of removing a serving from the pot. It is possible that when the savage then tries to get a serving from the pot, the pot will still be empty. In this case the precondition on get_serving_from_pot will cause the savage to wait until such time as the pot is no longer empty. + +Whenever the cook is requested to refill the pot, the {COOK}.cook procedure is called. The procedure takes as an argument the pot which is declared of course as separate. So access to the pot must be guaranteed before cook can execute. The cook procedure has a precondition that causes it to wait if the pot is not currently empty. + + + + diff --git a/documentation/18.11/solutions/concurrent-computing/concurrent-eiffel-scoop/scoop-examples/faneuil-hall.wiki b/documentation/18.11/solutions/concurrent-computing/concurrent-eiffel-scoop/scoop-examples/faneuil-hall.wiki new file mode 100644 index 00000000..abf27f97 --- /dev/null +++ b/documentation/18.11/solutions/concurrent-computing/concurrent-eiffel-scoop/scoop-examples/faneuil-hall.wiki @@ -0,0 +1,43 @@ +[[Property:title|Faneuil Hall]] +[[Property:weight|-5]] +[[Property:uuid|93132084-5eb9-c7d9-d58c-7b5c3f7508f8]] +=Description= + +The Faneuil Hall example is one of several examples that comes to us from Allen Downey's book ''[http://greenteapress.com/semaphores/ The Little Book of Semaphores]''. Downey credits Grant Hutchins as the originator of the example. [http://en.wikipedia.org/wiki/Faneuil_Hall Faneuil Hall] itself is an historic building in Boston which dates from 1742 an has served as a public meeting and market place. + +The scenario in the Faneuil Hall example involves a number of immigrants waiting to have their naturalizations confirmed by a judge and receive their certificates of citizenship. Immigrants entering the Hall wait in line to check in, then they wait to take their oaths and receive their certificates of citizenship. Meanwhile, a number of spectators can also enter the building. Once the judge enters the Hall, no one else may enter the hall. Spectators may leave, but immigrants may not. Once the immigrants in the Hall have checked in, their naturalization can be confirmed by the judge. Once confirmed, the immigrants can pick up their certificates. At some point after the confirmation, the judge leaves the Hall. At that point, spectators can enter again, and immigrants can leave as soon as they have picked up their certificates. The judge will make successive trips into the hall until all the immigrants expect during the day have been confirmed. + + +=Highlights= + +The primary actors here are the immigrants, the judge, and the spectators, model by classes IMMIGRANT, JUDGE, and SPECTATOR, respectively. In addition to the actor classes, there is a class HALL that represents Faneuil Hall itself, and a root class that sets everything up and starts the processing. There is only one judge. But there can be many immigrants and spectators. Their numbers are limited to certain maximums specified by constants in the root class. The specific number of immigrants and spectators varies at random from one execution to the next. You can experiment with larger or smaller maximum numbers for immigrants and spectators by changing the values for the constants {FANEUIL_HALL}.Max_immigrants and {FANEUIL_HALL}.Max_spectators. + +Although not really considered an actor here, the class HALL plays a critical role in synchronizing the concurrent actions of the immigrants, spectators, and the judge. HALL includes many status queries which, when used in preconditions in features of the other actors, constitute [[Concurrent programming with SCOOP#Preconditions|uncontrolled precondition clauses]] which when false will cause the calling processor to wait until the condition becomes true. For example, consider the following status query from class HALL: + + + immigrants_ready: BOOLEAN + -- Are immigrants ready? + do + Result := present_immigrant_count = ready_immigrant_count + end + + +This query is used by the JUDGE when preparing to sit and administer oaths to the immigrants: + + + take_place (a_hall: separate HALL) + -- Prepare to confirm. + require + immigrants_ready: a_hall.immigrants_ready + do + print (out + " taking place%N") + a_hall.sit_judge + end + + +The judge will take his place only when all the immigrants present have checked in and are ready to take the oath. + +Another thing to note about this example is that immigrants and spectators obey slightly different rules when coming and going in the hall. Neither immigrants nor spectators may enter the hall if the judge is in the hall. Immigrants may not leave until the judge has left, but spectators may leave at anytime. So when you compare the leave features of the two classes you'll see a precondition that serves as a wait condition on {IMMIGRANT}.leave that is not present on {SPECTATOR}.leave. + + + diff --git a/documentation/18.11/solutions/concurrent-computing/concurrent-eiffel-scoop/scoop-examples/index.wiki b/documentation/18.11/solutions/concurrent-computing/concurrent-eiffel-scoop/scoop-examples/index.wiki new file mode 100644 index 00000000..4337e405 --- /dev/null +++ b/documentation/18.11/solutions/concurrent-computing/concurrent-eiffel-scoop/scoop-examples/index.wiki @@ -0,0 +1,5 @@ +[[Property:title|SCOOP examples]] +[[Property:weight|8]] +[[Property:uuid|75ddd9e0-3baf-655a-748f-ea8765a1d06d]] +The examples for SCOOP that are distributed with EiffelStudio are solutions to classic and not-so-classic concurrency problems. + diff --git a/documentation/18.11/solutions/concurrent-computing/concurrent-eiffel-scoop/scoop-examples/observer-pattern.wiki b/documentation/18.11/solutions/concurrent-computing/concurrent-eiffel-scoop/scoop-examples/observer-pattern.wiki new file mode 100644 index 00000000..44994774 --- /dev/null +++ b/documentation/18.11/solutions/concurrent-computing/concurrent-eiffel-scoop/scoop-examples/observer-pattern.wiki @@ -0,0 +1,31 @@ +[[Property:title|Observer pattern]] +[[Property:weight|-4]] +[[Property:uuid|72c53c25-6fa5-6787-0762-cfa3d1c814c5]] + +=Description= + +The Observer pattern example should be considered a work in progress. During the development of SCOOP for EiffelStudio, Eiffel Software engineers began to think in terms of the impact that SCOOP might have on our own software. One area that emerged was the parsing of Eiffel software text during compilation. You know that Eiffel systems are composed of modules called classes. In a non-concurrent compilation process, the classes are parsed one after another. However, there is no reason why parsing could not take place on multiple, concurrently executing SCOOP processors. + +You may remember seeing as you compile an Eiffel system, the different degrees of compilation counting down. Degree 5 is a phase of compilation that deals with parsing classes and creating an abstract syntax tree. The Observer pattern example tries to imagine concurrent Degree 5 parsing in the presence of SCOOP. + + +{{note|You should understand that the example doesn't really parse any Eiffel code or, for that matter, involve any real code files. Rather, it just tries to show what the structure of such a concurrent parser might look like, and the parsing step just involves a short wait to simulate the time that parsing would take.}} + + +=Highlights= + +The name of this example is Observer pattern, but it's not a classic example of the [http://en.wikipedia.org/wiki/Observer_pattern Observer design pattern] as commonly known. But it does have elements of the observer pattern, as you will see below. + +The important classes here are DEGREE_5, EIFFEL_PARSER_POOL, and EIFFEL_PARSER. DEGREE_5 represents Eiffel compilation degree five, parsing of classes. In the example, DEGREE_5 uses an instance of EIFFEL_PARSER_POOL to manage a pool of instances of EIFFEL_PARSER which actually do the (simulated) parsing. The EIFFEL_PARSERs are declared separate so that they can work concurrently, parsing different files. + +When DEGREE_5 creates the EIFFEL_PARSER_POOL, it provides a maximum number of parsers to be held in the pool and a function agent which the pool can use to create a new parser instance. Then when DEGREE_5 asks the pool to parse a file, it provides references to the file itself and two procedure agents: one for pre-parse processing and one for post-parse processing. + +The pre-parse processing agent is associated with a routine that is used to set up a parser before asking it to parse a file. + +When an EIFFEL_PARSER finishes with a file, it calls the agent for post-parse processing. In this way, it notifies the instance of DEGREE_5 that it is done with that file. + +So, it is here that elements of the observer pattern become evident, just in a slightly non-typical way. In more typical observer pattern examples, there is one observed object and a set of one or more observers. But here, there is one observer, the instance of DEGREE_5, and many observable objects, the parsers. When parsers complete their work, they notify their observer (the DEGREE_5), that they are done by executing the routine associated with the post-parse agent. So there's another difference, too. Instead of making calls directly to the observer, the observed objects apply the agents that have been provided by the observer. + + + + diff --git a/documentation/18.11/solutions/concurrent-computing/concurrent-eiffel-scoop/scoop-examples/producer-consumer.wiki b/documentation/18.11/solutions/concurrent-computing/concurrent-eiffel-scoop/scoop-examples/producer-consumer.wiki new file mode 100644 index 00000000..b47f803b --- /dev/null +++ b/documentation/18.11/solutions/concurrent-computing/concurrent-eiffel-scoop/scoop-examples/producer-consumer.wiki @@ -0,0 +1,69 @@ +[[Property:title|Producer-consumer]] +[[Property:weight|-13]] +[[Property:uuid|03739be2-e0d5-f5f0-b405-0bb75c8fee0f]] + +=Description= + +The [http://en.wikipedia.org/wiki/Producer-consumer_problem producer-consumer] problem is a classic software concurrency problem. The problem features one or more "producers" and one or more "consumers". All producers and consumers must share access to a "buffer" into which producers insert the products they produce, and from which consumers take the products they consume. The shared buffer is "bounded", that is, it has a maximum capacity. + +So at any time, the buffer could be empty, precluding any consumer from withdrawing a product. Or the buffer could be full, which would mean that no producer could produce a new product until a consumer had first consumed a product, making space in the buffer. To avoid concurrency related problems, producers and consumers can access the buffer only at times when no other producer or consumer is accessing it, and only when it is in the proper state for the particular type requesting access (i. e., not empty for consumers and not full for producers). + +=Highlights= + +The root class of the example creates the bounded product buffer and a number of producers and consumers, all given separate types. It requests the producers to create a number of products, and the consumers, in the aggregate, to consume that same number of products. + +==Separate argument rule== + +Notice that the root class uses a feature launch_producer (and a corresponding feature launch_consumer) for instructing the producers and consumers on how many products to handle. launch_producer looks like this: + + + launch_producer (a_producer: separate PRODUCER) + -- Launch `a_producer'. + do + a_producer.produce (900) + end + + +It might occur to you that it would be easier, simpler, and clearer just to include this feature's single procedural line: + + + a_producer.produce (900) + + +in place of the call to launch_producer, and dispense with the launch_producer feature entirely. But that is not possible in this case. + +The reason is that a_producer.produce (900) is a [[Concurrent programming with SCOOP#Separate types and separate calls|separate call]] (i. e., the object attached to a_producer is declared of a separate type), and according to the [[Concurrent programming with SCOOP#Access to shared resources|separate argument rule]], calls on a separate object are valid only when applied to an argument of the enclosing routine. + +==Wait condition== + +This example also shows an [[Concurrent programming with SCOOP#Preconditions|uncontrolled precondition]] serving as a "wait condition". In the class PRODUCER we see the buffer declared as a class attribute with a separate type: + + + buffer: separate BOUNDED_BUFFER [INTEGER] + -- Shared product buffer. + + +The feature store contains a precondition which ensures that the shared buffer is not full when store gets applied: + + + store (a_buffer: separate BOUNDED_BUFFER [INTEGER]; an_element: INTEGER) + -- Store `an_element' into `a_buffer'. + require + not a_buffer.is_full + do + a_buffer.put (an_element) + ensure + not a_buffer.is_empty + a_buffer.count = old a_buffer.count + 1 + end + + +The store routine is called by the routine produce, passing a reference to the separate attribute buffer like this: + + + store (buffer, l_element) + + +Because buffer is considered uncontrolled in the context of produce, then the precondition for store becomes a wait condition, rather than a correctness condition. This means that if the buffer is full, then the application of the feature store will wait until some consumer removes an product from the buffer. The removal of a product makes the precondition hold again, and the application of store can proceed. + + diff --git a/documentation/18.11/solutions/concurrent-computing/concurrent-eiffel-scoop/scoop-examples/quicksort.wiki b/documentation/18.11/solutions/concurrent-computing/concurrent-eiffel-scoop/scoop-examples/quicksort.wiki new file mode 100644 index 00000000..e64b4837 --- /dev/null +++ b/documentation/18.11/solutions/concurrent-computing/concurrent-eiffel-scoop/scoop-examples/quicksort.wiki @@ -0,0 +1,22 @@ +[[Property:title|Quicksort]] +[[Property:weight|-7]] +[[Property:uuid|61632685-20ad-293b-44b6-907b15d0447a]] + +=Description= + +The quicksort example is a concurrent implementation of the well-known [http://en.wikipedia.org/wiki/Quicksort quicksort] sorting algorithm developed by computer scientist [http://en.wikipedia.org/wiki/C._A._R._Hoare C. A. R. Hoare]. Quicksort uses a "divide and conquer" strategy to sort a structure. It applies a basic algorithm to the structure which leads to a division of the elements into to two substructures. Then it applies the same algorithm to each of the substructures, and so on, until the whole structure is sorted. Because of the repetitive application of the same algorithm to evolving parts of the structure, the quicksort is often used in computer science classes to provide students with experience in [http://en.wikipedia.org/wiki/Recursion_(computer_science) recursive] computation. + +In the SCOOP example, instead of recursive calls, substructures are handled (within limits) by separate [[Concurrent programming with SCOOP|SCOOP processors]] running concurrently. + + +=Highlights= + +The quicksort example sorts a randomly generated container of integers. The set-up for this example is done in the root class. It is interactive in the sense that when you run the example, you get to to choose how many elements will be sorted (within certain limits) and you get to provide a seed for the random number generator which will be used to produce the unsorted structure. + +The quicksort algorithm is embodied in the class QUICKSORTER, primarily in its routine sort. Instances of QUICKSORTER declared as separate are spawned to sort substructures as the algorithm progresses. + +The structures acted upon by QUICKSORTER are managed in instances of class DATA. DATA is a class designed specifically to support the quicksort example. + +When the example runs, separate QUICKSORTER processes are used for the recursive sorts up until a certain depth of recursion is reached. The limit is defined by the NATURAL constant {QUICKSORTER}.max_recursion_depth. + + diff --git a/documentation/18.11/solutions/concurrent-computing/concurrent-eiffel-scoop/scoop-examples/search-insert-delete.wiki b/documentation/18.11/solutions/concurrent-computing/concurrent-eiffel-scoop/scoop-examples/search-insert-delete.wiki new file mode 100644 index 00000000..f81dc6ba --- /dev/null +++ b/documentation/18.11/solutions/concurrent-computing/concurrent-eiffel-scoop/scoop-examples/search-insert-delete.wiki @@ -0,0 +1,44 @@ +[[Property:title|Search-insert-delete]] +[[Property:weight|-9]] +[[Property:uuid|2c09ce66-f3be-1e31-eac8-f06ad3d6fc3a]] + +=Description= + +The Search-insert-delete example involves a shared data structure that is being accessed concurrently by three types of independent actors. ''Searchers'' access the list without changing it. So, any number of concurrent searchers can be accessing the structure safely. ''Inserters'' have the ability to add new elements to the end of the structure. Only one inserter can access the structure at any given time, but can work concurrently with any number of searchers. Lastly, ''Deleters'' can remove items from any position in the structure. As such, any deleter demands exclusive access to the structure. So, while a deleter has access to the structure neither any other deleter, any inserter, nor any searcher is allowed access. + + +=Highlights= + +The primary actors are modeled by classes SEARCHER, INSERTER, and DELETER. Additionally, some common features are abstracted into a class ACTOR from which the effective actor classes inherit. Each actor lives only to access the data structure one time. The access looks similar in the different actor classes, and consists of executing a procedure to start the action, then waiting a random time interval, then executing a procedure to end the action. + +The shared data structure is modeled by the class SHARED_LIST. Because the point of this example is to demonstrate the different allowable types of concurrent access by the different types of actors, it should be said that features that support that goal are all that you will find in this class. In other words, SHARED_LIST doesn't really maintain a data structure, it only provides the features necessary to coordinate safe concurrent access by searchers, inserters, and deleters. + +SHARED_LIST provides features in three feature clauses, each explicitly exported one of the types of accessors. For example, the feature clause exported to clients of type SEARCHER includes the query can_search and the procedures start_search and end_search. The features available to inserters and deleters are nearly identical. Because of the different concurrency requirements of each type of actor though, the implementation for can_search and can_delete are different. Also different are the implementations for starting and ending actions for the various actor types. + +SHARED_LIST keeps certain state attributes: + + + searchers: INTEGER_32 + -- How many searchers are there? + + inserting: BOOLEAN + -- Is someone inserting? + + deleting: BOOLEAN + -- Is someone deleting? + + +These are used in the can_search, can_insert, and can_delete queries, which are in turn used in the preconditions for the corresponding start_xxxx features. For example, start_delete is constrained by a precondition can_delete, which is implemented like this: + + + can_delete: BOOLEAN + -- Can delete? + do + Result := not deleting and not inserting and searchers = 0 + end + + +For the deleter calling {SHARED_LIST}.start_delete, the precondition clause can_delete is an [[Concurrent programming with SCOOP#Preconditions|uncontrolled precondition]]. This means that the deleter will wait until the can_delete becomes true before feature application of start_delete occurs. + + + diff --git a/documentation/18.11/solutions/concurrent-computing/concurrent-eiffel-scoop/scoop-examples/senate-bus.wiki b/documentation/18.11/solutions/concurrent-computing/concurrent-eiffel-scoop/scoop-examples/senate-bus.wiki new file mode 100644 index 00000000..cd3604e2 --- /dev/null +++ b/documentation/18.11/solutions/concurrent-computing/concurrent-eiffel-scoop/scoop-examples/senate-bus.wiki @@ -0,0 +1,25 @@ +[[Property:title|Senate bus]] +[[Property:weight|-8]] +[[Property:uuid|cfce3b31-bb8d-8259-a02b-73fd1495fce9]] + +=Description= + +According to Allen Downey in his text ''[http://greenteapress.com/semaphores/ The Little Book of Semaphores],'' the Senate bus example was inspired by the [http://www.wellesley.edu/Transportation/senate.html Senate Bus at Wellesley College]. Passengers come to a bus stop to catch the Senate bus. The bus can hold 50 passengers. When the bus stops at the bus stop, the waiting passengers board. If the bus fills up, then any passengers who cannot board, must wait until the bus shows up again. Likewise, any passenger who arrives at the stop during the time the bus is boarding also must wait until the next cycle. + + +=Highlights= + +The root class for this example creates the bus stop, the bus, and the passengers all typed as separate. + +The bus stop, modeled by class STATION has features that can be used by the bus and by passengers. Access to these +features is restricted to the appropriate client classes through the clients part of the feature clause. Clients of type PASSENGER can access {STATION}.pass_enter. A client of type BUS can access {STATION}.bus_enter, {STATION}.pick_up, and {STATION}.leave, as well as a status feature {STATION}.bus_is_waiting and two passenger queues {STATION}.waiting_list and {STATION}.checked_in_list. + +The lifecycle of a passenger is simple: enter the bus stop. This is accomplished by making a [[Concurrent programming with SCOOP#Separate types and separate calls|separate call]] to {STATION}.enter and passing Current (the passenger object itself) as an argument. + +The lifecycle of the bus is slightly more complex: enter the bus stop, pick up passengers, leave the bus stop, wait for a short time. The bus repeats this sequence forever. The routines in class BUS for entering the bus stop, picking up passengers, and leaving the bus stop all accept as an argument the separate bus stop object (a_station: separate STATION) and make a [[Concurrent programming with SCOOP#Separate types and separate calls|separate call]] to the corresponding routine in STATION. + +Features of the bus stop (class STATION) manage the queues for waiting and checked-in passengers and whether a bus is at the bus stop. Passengers are added to the waiting queue when they arrive at the station. When the bus leaves the station, any waiting passengers are transferred to the checked-in queue. When the bus arrives at the station, the passengers on the checked-in queue are allowed to board the bus (up to the first 50 passengers, that is), and the boarding passengers are then removed from the checked-in queue. + + + + diff --git a/documentation/18.11/solutions/concurrent-computing/concurrent-eiffel-scoop/scoop-examples/single-element-producer-consumer.wiki b/documentation/18.11/solutions/concurrent-computing/concurrent-eiffel-scoop/scoop-examples/single-element-producer-consumer.wiki new file mode 100644 index 00000000..81d1e6a0 --- /dev/null +++ b/documentation/18.11/solutions/concurrent-computing/concurrent-eiffel-scoop/scoop-examples/single-element-producer-consumer.wiki @@ -0,0 +1,21 @@ +[[Property:title|Single-element producer-consumer]] +[[Property:weight|-15]] +[[Property:uuid|25d3e585-0eb6-efa8-ada9-8ee596df5ada]] +=Description= + +The single-element producer-consumer is a simpler variant of the classic [http://en.wikipedia.org/wiki/Producer-consumer_problem producer-consumer] problem. A producer produces products, in this case integers, into a single-element inventory. The products are then consumed from inventory by a consumer. The producer, consumer, and inventory are managed by separate [[Concurrent programming with SCOOP#Processors|processors]], so any access they have to one another must be synchronized through scoop mechanisms. + +=Highlights= + +In the single-element producer-consumer only a single producer and single consumer are created, and there is only storage allowing for a single instance of the product. So, effectively in this example, the bounded buffer of the classic producer-consumer problem has a size of one. + +The classes modeling the different actors have obvious names: PRODUCER, CONSUMER, and INVENTORY. The root class of the example creates one separate instance of each of these, and then brings the producer and consumer to life. + +The PRODUCER class supports a procedure produce in which a product is produced and stored in the single-element INVENTORY. The producer can only produce an element if the inventory is currently empty. Class INVENTORY exports a boolean query has_item which is the indicator of whether a product has been produced and is available for consumption. So {PRODUCER}.produce has a precondition that depends upon {INVENTORY}.has_item being false. Because the inventory is handled by a separate processor, this precondition is [[Concurrent programming with SCOOP#Preconditions|uncontrolled]] and will cause the producer to wait until the condition is true to proceed. + +The CONSUMER class works in a way that is largely the symmetrical opposite of PRODUCER. The consumer tries to consume the item from the INVENTORY. But this only possible if an item has been produced and is available. So {CONSUMER}.consume has a "wait" precondition based on the query {INVENTORY}.has_item. + +So the heart of the problem is the synchronization between producer and consumer sharing a single inventory. If there's already a product in inventory, the producer cannot produce more and must wait. Only when the consumer consumes the current product can the producer produce again. For the consumer's part, if there's a product currently in inventory, then the consumer can consume that product. Otherwise, the consumer must wait until the producer produces a new product. The synchronization is handled by the SCOOP mechanism of uncontrolled (wait) preconditions on the inventory. + + + diff --git a/documentation/18.11/solutions/concurrent-computing/concurrent-eiffel-scoop/scoop-exceptions.wiki b/documentation/18.11/solutions/concurrent-computing/concurrent-eiffel-scoop/scoop-exceptions.wiki new file mode 100644 index 00000000..a5b75c37 --- /dev/null +++ b/documentation/18.11/solutions/concurrent-computing/concurrent-eiffel-scoop/scoop-exceptions.wiki @@ -0,0 +1,107 @@ +[[Property:title|Exceptions in SCOOP]] +[[Property:link_title|Exceptions]] +[[Property:weight|7]] +[[Property:uuid|4f760d0c-ff3b-5f8a-7d43-9be855cef17a]] +== Introduction == + +Exceptions are a rather nasty issue in concurrency. +In a shared memory system, an exception can leave a system in an inconsistent state, for example because they jump over an unlock operation. +In message passing systems on the other hand they can introduce unnecessary synchronization just to make sure that no exception happened, or they can create havoc because the recipient of an exception message is no longer in a state where it can handle it. + +For SCOOP, the exception mechanism was carefully designed with the following goals in mind: +* Comprehensibility: It should be easy to understand +* Compatibility with exceptions in sequential programs +* Consistency: An exception should not leave objects in a tainted state. +* Asynchrony: Exceptions should not restrict the level of concurrency. + +== Exception Propagation == + +Within a single processor, exceptions propagate just like in a sequential program. +When a routine encounters an exception, the rescue clause is entered, and if no retry statement is present, the exception is propagated to the caller. +This ensures backwards compatibility with sequential programs, because when there's only the root processor, the semantics are exactly the same. +Furthermore, this mechanism has proven itself useful for restoring invariants after an exception in order to bring objects to a consistent state. + +The interesting case is when an exception propagates between regions, which happens during a separate call. +In that case there are two possibilities: +* The call is synchronous: The exception is propagated to the client region. +* The call is asynchronous: The exception is not propagated, because the client is busy executing something else. Instead, the supplier region is marked as ''dirty''. + +This decision was mostly made to ensure comprehensibility. +Propagating an exception to the client in an asynchonous call would be really hard to handle. +The client would have to be ready to handle an exception at any point in time, and there would have been a need for an additional language mechanism to protect critical sections. +Because of these reasons SCOOP restricts exception propagation to synchronous calls only. + +== Dirty Regions == + +A region marked as dirty has suffered an exception in an asynchronous call, which could not be propagated to its client. +The dirty mark has a big impact for future separate calls. + +{{rule|name=Semantics of Dirty Regions|text=
+1) All calls logged to a dirty region, whether synchronous or asynchronous, are ignored.
+2) A synchronous separate feature call to a dirty region immediately triggers an exception in the client. Afterwards, the region is clean again.}} + +The reason for these rules is that a series of commands and a subsequent query often depend on each other. +For example, a first call may instruct the target region to open a file, the next call to append a string to it, followed by a query to get the new size of the file. +If the first call already fails, there's no point in executing subsequent calls. +Even worse, it can make recovery from exceptions very hard to do in the client if it has no idea which calls have been successfully executed after the first exception. + +The dirty mark will also vanish when an region is unlocked. +{{rule|name=Unlocking Dirty Regions|text=After releasing a lock on a dirty region, the region is clean again.}} + +This is probably the most controversial design decision, because '''it allows for exceptions to be lost'''. +During the design of the exception mechanism, there was a choice of two other solutions. +One would have been to add an automatic "safeguard" synchronization whenever an unlock operation happens, during which exceptions could be propagated. The obvious downside is that it severely limits the uses of asynchrony. +Another solution would have been to preserve the exception, and raise it in the client that next logs a call. +The last solution only partially solves the problem (there might be no next client logging a query at all), but introduces a new problem that processors can get an exception completely out of context. +However, the main reason to choose the "forget-upon-unlock" solution over the other two is that it's easy to simulate the behaviour manually (as you'll see in the next section), while it's impossible to have a "forget-upon-unlock" semantics if one of the other models is used. + +{{info|Upon lock passing, the dirtyness of a region is preserved.}} + +== Preventing Exception Loss == + +One way to prevent exceptions from being lost is to add a synchronous query at the end of a routine: + + +put_character (c: CHARACTER; a_file: separate MY_FILE) + local + l_sync: POINTER + do + a_file.open + a_file.put_character (c) + a_file.close + -- This ensures that exceptions are propagated: + l_sync := a_file.default_pointer + end + + +Another possibility is to store the failure in the separate object: + + +class MY_FILE feature + + is_tainted: BOOLEAN + + open + do + -- Open a file. + rescue + is_tainted := True + end + + -- other features +end + +class CLIENT feature + + put_character (c: CHARACTER; a_file: separate MY_FILE) + do + if a_file.is_tainted then + -- Handle exception in `a_file'. + end + a_file.open + a_file.put_character (c) + a_file.close + end +end + + diff --git a/documentation/18.11/solutions/concurrent-computing/concurrent-eiffel-scoop/scoop-exclusive-access.wiki b/documentation/18.11/solutions/concurrent-computing/concurrent-eiffel-scoop/scoop-exclusive-access.wiki new file mode 100644 index 00000000..b7c29ec0 --- /dev/null +++ b/documentation/18.11/solutions/concurrent-computing/concurrent-eiffel-scoop/scoop-exclusive-access.wiki @@ -0,0 +1,145 @@ +[[Property:title|Exclusive Access]] +[[Property:weight|4]] +[[Property:uuid|7f5adf71-7169-c54e-9bed-079c84aee8d3]] + +The topic of exclusive access was already briefly touched in [[Separate Calls]]. +In this chapter, we'll have a deeper look at the exclusive access guarantees given in SCOOP, and what it means in practice. + +== Reasoning Guarantees == + +In the SCOOP model, there are two very important guarantees - ''Order Preservation'' and ''Exclusive Access''. + +{{definition|Order Preservation | The guarantee that, between any two regions, the order of separate feature calls logged by one region is the same as the order of feature applications by the other region.}} +{{definition|Exclusive Access (to a region) | The guarantee that no intervening features logged by other processors are executed.}} + +The first guarantee is always valid. +A SCOOP processor is never allowed to reorder two feature calls when both have been logged by the same region. +However, the order preservation guarantee only holds between two processors - it is not valid in a global context. +For example, when a region A first logs a command to C, and then another region B logs a command to C, you generally don't know which feature will be applied first. +And also the other way around: You have no guarantee on the order of feature application when A logs both an (asynchronous) separate call to B and C. + +Exclusive access on the other hand is only valid in certain contexts. +When an object is ''controlled'', SCOOP guarantees exclusive access to the region that contains the object. +We'll define the term ''controlled'' a bit later, but you've already seen an example in [[Separate Calls]]: +A separate object which is passed as an argument. + +These two basic guarantees in the SCOOP model are important to reach one of the main goals: +The ability to reason about a program should be preserved in a concurrent program. +SCOOP guarantees that a ''controlled'' object behaves just like in a sequential program, +meaning that Pre- and Postconditions will remain valid in between feature calls because no other processor can interfere. + +== Inline Separate == + +Passing a separate object as an argument is not the only way to gain exclusive access in SCOOP. +While in theory the mechanism would be sufficient, experience has shown that it's often bulky and not very elegant to write a new routine whenever one wants to call a feature on a separate target. + +Therefore SCOOP introduces the ''Inline Separate'' block to make things a bit easier. + +person: separate PERSON + +show_separate_block + do + separate person as l_person do + print (l_person.age) + end + end + + +The separate block evaluates the expression on the left hand side of the as keyword, assigns it to the new read-only local variable l_person on the right hand side, +and does whatever is necessary to provide ''exclusive access'' to the region that handles l_person. + +You can think of the inline separate block as syntactic sugar that creates a new wrapper routine (although inline separate still lets you access local variables of the enclosing routine): + +person: separate PERSON + +show_separate_block + do + anonymous_wrapper (person) + end + +anonymous_wrapper (l_person: separate PERSON) + do + print (l_person.age) + end + + +== Controlled Objects == + +The Eiffel compiler introduces the concept of a ''controlled'' object to support the exclusive access guarantee. + +{{definition|Controlled/uncontrolled object|An object is '''controlled''' if it is attached to a reference that has one of the following properties:
+1) It is of a non-separate type.
+2) It is of a separate type and it appears as a formal argument of the enclosing routine.
+3) It is a local variable of an inline separate block. +

Otherwise it is '''uncontrolled'''.}} + +An object is always ''controlled'' with respect to the processor handling Current, and the meaning is that the current processor has ''Exclusive Access'' to the region that holds the object. In particular, this means that no other processor can access or modify a controlled object. + +In chapter [[Separate Calls]] we've already mentioned that SCOOP places a restriction on separate calls. +A separate call is allowed if the target appears as a formal argument of the enclosing routine. +While this rule is correct, it does not cover all of the cases. +With the above definition however, we can both simplify and extend the previous ''Separate Argument'' rule: + +{{rule|name=Controlled Target|text=A separate call is valid if its target is controlled.}} + +The compiler checks this property at compile-time and throws an error if a separate call happens on an uncontrolled target. + +{{note| Query results with a non-separate return type are placed on the same processor as the target. This means that, if a processor controls the target, it is also safe to use these query results. The compiler tries to exploit this fact a little by treating such query results as controlled as well within a single expression. This allows to have multi-dot calls on separate target, such as sep_person.spouse.name.out.
+Note that this does not yet cover all cases where ''controlled'' can be inferred, and the compiler may become smarter in the future.}} + +== Exclusive Access to multiple regions == + +It is possible to gain exclusive access to multiple regions simultaneously. +This can either be done by passing multiple arguments to a region, or with an ''inline separate'' block. + + +balance_with_arguments (incr: separate INCREMENTER; decr: separate DECREMENTER): INTEGER + do + Result := incr.value + decr.value + end + +balance_with_inline_separate: INTEGER + do + separate incrementer as incr, decrementer as decr do + Result := incr.value + decr.value + end + end + +incrementer: separate INCREMENTER +decrementer: separate DECREMENTER + + +Exclusive access to the arguments is granted '''atomically''' in this case. +This ensures that no deadlock can occur when two regions want to gain access to the same regions, provided that they both use the "multiple-arguments-mechanism" of SCOOP and don't lock regions one after the other by hand. + +{{SeeAlso|The dining philosopher example makes use of this fact. The feature {PHILOSOPHER}.eat has two separate arguments, which are guaranteed to be locked in one atomic step by the SCOOP runtime. If this were not the case, a deadlock may occur.}} + +== Waiting for regions == + +You may wonder how the exclusive access guarantee is implemented in SCOOP. +A simple solution would be to have a lock for every region, and to gain exclusive access, one has to acquire the lock. +Before the 15.01 release, this was indeed how it was implemented. +However, the implementation proved to be flawed because it caused a lot of synchronization and waiting. + +In EiffelStudio 15.01 this has changed. +When a processor needs exclusive access to another one, it opens a new ''queue'' to log calls. +There can be multiple open queues to a processor, but the processor will always work on only one queue. + +This has an important effect in practice: '''Gaining exclusive access to a region is always non-blocking.''' +Note that this is also true for exclusive access to multiple regions. +Previously it may have been necessary to wait for another processor to relinquish the lock, but now a processor can just proceed with logging calls, which will eventually be executed by the supplier processor. + +You may start to wonder now where waiting happens, as it isn't possible to both have a guarantee for exclusive access and fully non-blocking behaviour. +Well, it happens during synchronous calls. +When a client gains exclusive access and starts logging calls, the supplier may not care about it yet because it is busy with something else. +However, as soon as a synchronous call is logged, the client needs to wait for the result. +During that time, the supplier will finish its other tasks and eventually start to execute the calls logged by the suspended client, at which point it will wake up again. + +{{note|Due to this, the only way to experience a deadlock in SCOOP is when a processor is stuck in a separate query.}} + +To summarize: +* Gaining exclusive access, also to multiple regions, is always non-blocking. +* An asynchronous call is also non-blocking. +* Only a call to a query may be blocking, and thus a place where a processor can be stuck (e.g. in case of deadlock or starvation). + + diff --git a/documentation/18.11/solutions/concurrent-computing/concurrent-eiffel-scoop/scoop-getting-started.wiki b/documentation/18.11/solutions/concurrent-computing/concurrent-eiffel-scoop/scoop-getting-started.wiki new file mode 100644 index 00000000..3c79e814 --- /dev/null +++ b/documentation/18.11/solutions/concurrent-computing/concurrent-eiffel-scoop/scoop-getting-started.wiki @@ -0,0 +1,74 @@ +[[Property:title|Getting Started with SCOOP]] +[[Property:link_title|Getting Started]] +[[Property:weight|-1]] +[[Property:uuid|87f78898-2bbb-b134-0128-e55401a61a05]] +=Introduction= + +SCOOP adds only a single keyword to the Eiffel programming language: separate. In any case in which SCOOP is not enabled, the separate keyword is ignored, and the SCOOP-specific validity rules are not applied. + +In order to enable SCOOP processing in your project, you use the project settings. There are two mandatory settings. One of them is the option ''Concurrency'', and the value you need is ''SCOOP'', as shown in the section of the Project Settings dialog below. + +[[Image:SCOOP project setting]] + +The second setting is the precompiled library. This should either be '''base-scoop-safe''', or nothing at all. A precompiled library which is not built with SCOOP support will not work. + +{{caution | When you use a precompiled library, the ''Concurrency'' setting for that library trumps whatever ''Concurrency'' value you have set for the project. So, if you use the "base-safe.ecf" precompiled library, your project will not be SCOOP-enabled regardless of the setting of ''Concurrency'' in the Target. Likewise, using the "base-scoop-safe.ecf" precompiled library always produces a SCOOP-enabled project, even if the Target ''Concurrency'' setting is ''None''.}} + + +=Creating a new SCOOP project= + +== Step 1: Create a new project == + +Create a new project with the EiffelStudio new project wizard by selecting ''Basic application'' from the choices under ''Create project'' when EiffelStudio opens. +The created project will not have SCOOP enabled however (this is true in all EiffelStudio releases so far, but may change in the future). +Do not compile the newly created project or precompile a library if asked - it will just be a waste of time. + +== Step 2: Convert the project == + +To enable SCOOP, you'll have to do some work on the project settings. Follow the steps in the next section. + += Convert an existing project to SCOOP = + +== Step 1: Adjust Concurrency setting == + +Open the project settings dialogue (Project -> Project settings...). +Select your favorite target (usually there's only one) and extend the section ''Advanced''. + +In there you'll find the setting ''Concurrency'', which should have a value ''None'' for sequential projects. Change it to ''SCOOP''. + +In addition to the ''Concurrency'' project setting, it is recommended that for new projects you use [[Creating a new void-safe project#Project settings for void-safe projects|the settings that guarantee void-safety]]. + +== Step 2: Remove the precompiled library == + +Expand the node ''Groups'' in the project settings on the left. +If your project uses a precompiled library, you should be able to see and expand the node ''Precompile'' as well. +Right click on the item (usually something like "base-safe_precompile") in the category ''Precompile'', then select ''Remove''. + +== Step 3: (Optional) Add precompiled base-scoop-safe to the project == + +Select the node ''Groups'' on the left, and then press Ctrl + P on the keyboard (or select ''Add Precompile'' from the toolbox). +Note that this only works when there's no existing precompiled library and when the node ''Groups'' is highlighted. + +In the dialog that opens, select "precomp_base-scoop-safe", then close the dialog by clicking ''OK''. + +== Step 4: Clean compile == + +Changing the ''Concurrency'' setting and precompiled libraries each would cause you to have to do a [[Clean compile|clean compile]] of your system in order to become effective. To do so, close EiffelStudio and reopen it. +In the dialog that appears, select the previously modified project and then select the ''Compile'' action and add a tick to ''Clean''. +At this point, your project should be void-safe and SCOOP enabled. + +== Step 5: Double-check == + +Before doing anything after the clean compile, check the warnings section. If EiffelStudio is complaining that some settings could not be applied, something might be wrong with the precompiled library. + +To make sure that SCOOP is really enabled, you can insert the following code snippet somewhere in your code: + +check_scoop (a_string: separate STRING) + local + str: STRING + do + str := a_string + end + +This should trigger a compiler error. If it doesn't, then SCOOP is not correctly set up in your project. + diff --git a/documentation/18.11/solutions/concurrent-computing/concurrent-eiffel-scoop/scoop-implementation.wiki b/documentation/18.11/solutions/concurrent-computing/concurrent-eiffel-scoop/scoop-implementation.wiki new file mode 100644 index 00000000..7b2cd4a6 --- /dev/null +++ b/documentation/18.11/solutions/concurrent-computing/concurrent-eiffel-scoop/scoop-implementation.wiki @@ -0,0 +1,109 @@ +[[Property:title|SCOOP implementation]] +[[Property:weight|9]] +[[Property:uuid|eeb07907-e036-f3d6-5297-a7c44cfd1900]] + + +The implementation of SCOOP is the result of many years of design and refinement of the model. This page describes specific properties of its current state, in particular ways in which it differs from some of the earlier publications about the model. + + +=Known limitations= + + +==Supported concurrency mechanisms== + +At the core of the SCOOP model lies the notion of [[Concurrent programming with SCOOP#Processors|processor]]: a mechanism that can execute instructions sequentially. As a general model covering many forms of concurrency, SCOOP allows many possible implementations of this concept. In the EiffelStudio implementation, processors are implemented as threads of the operating system. + + +==Maximum number of SCOOP processors== + +The maximum number of SCOOP processors per system is currently 1024. + + + +==Agents targeted to objects of separate types== + +Agents targeted on separate objects are currently not supported. + + +=Workarounds= + +The first implementation of SCOOP, some things that we do commonly in sequential Eiffel become less fluid in the presence of SCOOP. Although not strictly limitations in the implementation of SCOOP principles, in order to make SCOOP programming easier, these are areas that should be improved in future releases. In the meantime, there are workarounds for some of these situations. + + +==Printing a separate STRING == + +Suppose you have declared a class attribute of type separate STRING: + + + my_separate_string: separate STRING = "Hello Eiffel World!" + + +and you want to output that string using io.put_string. The solution you might use from sequential Eiffel would be: + + + io.put_string (my_separate_string) + + +But the statement above results in a compile error because the argument type (separate STRING) is not compatible with the type (STRING) that put_string is expecting. + +In order to make printing of the content of separate instances of STRING, a creation procedure, make_from_separate, is available in the string classes which allows initialization of a non-separate instance of STRING from a separate STRING. + +So, to print my_separate_string, you could create a non-separate instance of STRING, then print the non-separate instance, as shown below. + + + local + l_temp: STRING + ... + create l_temp.make_from_separate (my_separate_string) + io.put_string (l_temp) + + +Or use a creation expression and avoid declaring the local variable: + + + io.put_string (create {STRING}.make_from_separate (my_separate_string)) + + +== Calling a separate agent == + +Calling a separate agent is a bit tricky, especially if it's a PROCEDURE which should be executed asynchronously. +If the agent does not take any arguments, you must pass Void, otherwise the compiler will generate an empty TUPLE which +is on the same processor as the caller and thus triggers lock passing (see [[Asynchronous Calls]]): + + +do_call (proc: separate PROCEDURE [TUPLE]) + do + proc.call (Void) + end + + +If the agent does take arguments, things get a bit more tricky. If the call must be asynchronous, you have to do a workaround with the feature {ROUTINE}.empty_operands like this: + + +do_call (a_procedure: separate PROCEDURE [TUPLE[separate STRING]]; a_string: separate STRING) + local + l_tuple: separate TUPLE [separate STRING] + do + l_tuple := a_procedure.empty_operands + set_tuple_string (l_tuple, a_string) + a_procedure.call (l_tuple) + end + +set_tuple_string (a_tuple: separate TUPLE [str: separate STRING]; a_string: separate STRING) + do + a_tuple.str := a_string + end + + + +=Implementation dependent behavior= + + +==The Wait Rule== + +{{note | This only applies to EiffelStudio releases prior to 15.01}} + +The [[Concurrent programming with SCOOP#Access to shared resources|Wait Rule]] says: ''A routine call with separate arguments will execute when all corresponding processors are available and hold them exclusively for the duration of the routine.'' + +In the EiffelStudio implementation prior to 15.01, a routine will not necessarily wait for all processors associated with its separate arguments to be available before it ''begins'' execution. The waiting on processors occurs in a "lazy" manner. Execution will only wait on the availability of one of the processors when it actually needs to use the argument associated with that processor. This means that if there are several instructions ahead of the first instruction that references a separate argument, then those several instructions will be executed immediately. Only at the point at which the separate argument's processor is needed will the routine pause and wait for the availability of the processor. + diff --git a/documentation/18.11/solutions/concurrent-computing/concurrent-eiffel-scoop/scoop-regions-processors.wiki b/documentation/18.11/solutions/concurrent-computing/concurrent-eiffel-scoop/scoop-regions-processors.wiki new file mode 100644 index 00000000..a2240ecb --- /dev/null +++ b/documentation/18.11/solutions/concurrent-computing/concurrent-eiffel-scoop/scoop-regions-processors.wiki @@ -0,0 +1,115 @@ +[[Property:title|Regions and Processors]] +[[Property:weight|2]] +[[Property:uuid|974a41dd-0e36-4d75-edd1-ead6ea4b372d]] +== Regions == + +One of the key ideas in SCOOP is to prohibit simultaneous access to shared memory. +In order to reach this goal, the SCOOP model partitions the heap memory into ''regions''. + +{{definition|Region|A set of objects in the heap. The set of all regions in a program is a partition of the heap.}} + +Every object in an Eiffel program belongs to exactly one ''region''. +A ''region'' is by itself sequential, meaning that there can only be one routine executed in one object. +There can be multiple regions in a SCOOP program however. + +[[Image:SCOOP regions]] + +{{info|SCOOP is classified as a message passing concurrency model, because there is no shared memory.}} +{{note|A sequential program is a special case for a SCOOP program that has only one region.}} + +A direct access from one region into another is not allowed. +If one wishes to perform a command or a query in an object of a different region, a message has to be sent. +You'll see how this can be done in chapter [[Separate Calls]]. + +The simple trick of splitting the heap into several regions, where each region by itself is sequential, +prevents one of the trickiest problems in concurrency: Data Races. +In SCOOP you are guaranteed that a data race, meaning a read and write access to the same memory with nondeterministic ordering, can never happen. + +== Processors == + +In the SCOOP model, a ''processor'' is used as the engine for execution. + +{{definition|Processor| An autonomous thread of control capable of sequential execution of instructions.}} + +A ''processor'' is always attached to exactly one region, and is responsible to perform operations on all its objects. +The term ''handler of an object'' is used to denote the processor attached to the region on which the object is placed. + +As already mentioned earlier, a ''processor'' cannot access or perform operations on an object in a different ''region'' +and has to send a message to the other handler instead. + +{{info|''Processor'' is an abstract notion and does not mean the physical silicon chip which is present in every computer. +In SCOOP we think of it as a thread of control capable of applying features to objects. +In theory processors are not restricted to any particular type of hardware or software, for example they could correspond to threads, processes, hardware processors, or machines in a network. +Currently however a SCOOP processor is implemented as a thread.}} + +== Separate Types== + +To support the concept of regions in a program text, SCOOP extends the type system by introducing a single new keyword: separate. + +The separate keyword is used to annotate a reference and means that the object attached to it may be in a different region. + +{{definition|Separate type|A type which has been declared including the keyword separate.}} + +If an entity uses the keyword separate in its declaration, such as: + + + my_x: separate X + + +it indicates that the handler of my_x may be different than the handler of Current. +This in turn means that it is forbidden to access and modify my_x directly. +To perform any operation on my_x, a message should be sent to the other handler. + +Note that the SCOOP type system allows to attach an object to a separate reference, even if it is actually in the same region as Current. +But it is not possible the other way around: An object in a different region must always be of a separate type. +This is reflected in the type checker, which treats a regular type A as a subtype of the separate type separate A. + +In the image above, the three references that cross a processor boundary must be declared separate. +The single reference in Region 2, which stays in the same region, can be of a non-separate type. + +== Creating regions and processors == + +In order to turn a sequential program into a concurrent program, one has to create new regions and put objects into them. +The means to achieve this is the creation instruction on an entity whose type is separate. + + + my_x: separate X + -- ... + create my_x.make + + +The instruction create my_x.make does a lot of things at the same time: +* It creates a new region. +* It creates a new processor for the new region. +* It creates a new object of type X which is placed into the newly created region. + +With this new knowledge we can create a small program that generates the object and region graph shown above: + + +class APPLICATION create make feature + + person: separate PERSON + + thing: separate ANY + + make + do + create person.make + create thing + end +end + +class PERSON create make feature + + name: STRING + + thing: separate ANY + + make + do + create name.make_from_string ("John Doe") + create thing + end +end + + diff --git a/documentation/18.11/solutions/concurrent-computing/concurrent-eiffel-scoop/scoop-separate-calls.wiki b/documentation/18.11/solutions/concurrent-computing/concurrent-eiffel-scoop/scoop-separate-calls.wiki new file mode 100644 index 00000000..a3e9b049 --- /dev/null +++ b/documentation/18.11/solutions/concurrent-computing/concurrent-eiffel-scoop/scoop-separate-calls.wiki @@ -0,0 +1,126 @@ +[[Property:title|Separate Calls]] +[[Property:weight|3]] +[[Property:uuid|c030d521-1420-1570-b63e-9035332a3e26]] +==Separate Calls== + +In the [[Regions and Processors | previous chapter]] we've learned that a concurrent SCOOP program consists of several ''regions'' that communicate via message passing. +You may wonder how it is possible to pass a message to another processor, and the answer is simple: +With the good old feature call. + +{{definition|Separate call|A feature call whose target is of a separate type.}} + +The ''separate call'' is the SCOOP way to pass messages from one region to another. +A call such as this + + + do_call (my_x: separate X) + do + my_x.f (42) + end + + +roughly corresponds to a message to the handler of my_x with the content: +"Execute feature f on target my_x with argument 42." + +Note that there can be a difference between the time a message is sent and the time the feature is executed. +In SCOOP we therefore distinguish between a ''feature call'' and a ''feature application''. + +{{definition|Feature call|Register a feature to be executed.}} +{{definition|Feature application|Execute a feature.}} + + +==Access to shared resources== + +The main issue with concurrent systems is the proper control of access to resources that can be shared among simultaneously executing processors. + +Traditional solutions to the problem involve the use of “critical sections” of code. +These are sections of code in which the shared resource is accessed. +Only one thread is allowed to be executing the critical section at a time. +So if one thread wants to execute the critical section and another is already doing so, then the first must wait. +Thread synchronization schemes ensure this “mutual exclusion” of access to the critical section. + +Rather than using critical sections, SCOOP relies on the mechanism of argument passing to assure exclusive access. +As a result, there is a restriction placed on separate calls. + +{{Rule|name=Separate argument|text=A separate call a_x.f (a) is valid if a_x is an argument of the enclosing routine.}} + +So, according to this rule, for a separate call to be valid, the target of the call must be a formal argument of the routine in which the call occurs. +The code below contains both an invalid separate call and a valid one. + + + + my_separate_attribute: separate SOME_TYPE + + ... + calling_routine + -- One routine + do + my_separate_attribute.some_feature -- Invalid call: Feature call on separate attribute + enclosing_routine (my_separate_attribute) -- Separate attribute passed as argument + end + + enclosing_routine (a_arg: separate SOME_TYPE) + -- Another routine + do + a_arg.some_feature -- Valid call: Feature call on separate argument + end + + + +In the code above, my_separate_attribute is a class attribute declared as a separate type. In the first line in calling_routine a direct feature call is made to apply some_feature to my_separate_attribute. This is an invalid separate call. The second line calls feature enclosing_routine and passes my_separate_attribute as an argument. enclosing_routine takes an argument of type separate SOME_TYPE. Within enclosing_routine it is valid to call some_feature on a_arg. + +{{info|Congratulations! You've just gained enough knowledge to write a small SCOOP program. +You may want to have a look at the [[Dining Philosophers]] example, which does not use any of the advanced concepts.}} + +{{SeeAlso|The launch_producer feature of the [[Producer-consumer|producer-consumer]] example, a feature which exists for the purpose of compliance with the separate argument rule.}} + + +==Synchronous and asynchronous feature calls== + +When we think of the execution of sequential Eiffel, we tend to equate feature call and feature application. That is, it is expected that for a sequence of two feature calls: + + + + x.f + y.g + + + +that the feature application of x.f will complete before y.g begins. + +In concurrent Eiffel with SCOOP things are different. This is because a particular feature call, x.f, may occur on one processor, and the consequent feature application (of feature f to x) may occur on a different processor. + + +{{definition|Synchronous feature call|A feature call in which the execution of the calling client does not proceed until the feature application has completed. }} + + +{{definition|Asynchronous feature call|A feature call which causes the “logging” of a request by a client for the associated feature application to be executed by the supplier’s processor. }} + + +After an asynchronous feature call, the execution of the client proceeds immediately, possibly in parallel with the application of the feature on some other processor. + + +===What makes a call synchronous or asynchronous?=== + +First, every feature call is either a synchronous feature call or an asynchronous feature call. For a particular call, the following rules determine which it is: + +A feature call is always '''synchronous''' in the following cases: + +:S1 It is a non-separate call. +:S2 It is a separate call to a query. + +A feature call may be '''asynchronous''' in the following case: +:A1 It is a separate call to a command. + +Let’s look a little closer at those cases determining synchronous calls. + +Case S1 is the case of typical sequential Eiffel, where all calls are non-separate, and therefore synchronous. Of course, even in concurrent Eiffel with SCOOP, plenty of non-separate calls will occur, and these will be synchronous. + +Case S2 says that if a separate call is a query it must be synchronous. This is because even though the feature application will probably occur on a different processor, the instructions following the query will likely depend up on the result of the query, so they must wait until the feature application completes. This situation is known as ''wait by necessity''. + +The case A1 is the only case where asynchrony is involved. But be careful with the wording - it says the call '''may be asynchronous''', because there are some exceptions. The exact rules are a bit complex and are described in [[Asynchronous Calls]]. As a general rule of thumb, a separate call is executed asynchronously when the client does not have exclusive access over an object which is needed by the target region. + +Asynchronous execution means that when a client processes the call to the command, it “logs” the need for its associated feature application. But then, rather than waiting for the feature application to complete, the client continues execution of instructions beyond the asynchronous call. + +It is in this case that concurrent computation is achieved. The processor of the client object is free to continue processing while the processor handling the target of the asynchronous feature call applies that feature. + diff --git a/documentation/18.11/solutions/concurrent-computing/eiffelthread/eiffelthread-class-reference.wiki b/documentation/18.11/solutions/concurrent-computing/eiffelthread/eiffelthread-class-reference.wiki new file mode 100644 index 00000000..a2228d25 --- /dev/null +++ b/documentation/18.11/solutions/concurrent-computing/eiffelthread/eiffelthread-class-reference.wiki @@ -0,0 +1,7 @@ +[[Property:title|EiffelThread Class Reference]] +[[Property:weight|0]] +[[Property:uuid|e1d3e50a-e67a-a375-7165-8a7856b7b969]] +==View the [[ref:libraries/thread/reference/index|EiffelThread Class Reference]]== + + + diff --git a/documentation/18.11/solutions/concurrent-computing/eiffelthread/eiffelthread-tutorial/compilation-multithreaded-systems.wiki b/documentation/18.11/solutions/concurrent-computing/eiffelthread/eiffelthread-tutorial/compilation-multithreaded-systems.wiki new file mode 100644 index 00000000..1b38b0d2 --- /dev/null +++ b/documentation/18.11/solutions/concurrent-computing/eiffelthread/eiffelthread-tutorial/compilation-multithreaded-systems.wiki @@ -0,0 +1,49 @@ +[[Property:title|Compilation of multithreaded systems]] +[[Property:weight|3]] +[[Property:uuid|24e474b5-3cb7-16ff-365f-73be8e73bd56]] +{{UpdateNeeded}} + + +{{ReviewRequested}} + + +==Settings== +* Set the Concurrency option to EiffelThread in the project settings under Advanced. +* Do not use a non-multi-threaded precompiled library. The corresponding multi-threaded libraries of base, WEL and Vision2 should be located in $ISE_EIFFEL/precomp/spec/$PLATFORM/ with the mt prefix. +* You may want to include the thread library (located at "$ISE_EIFFEL/library/thread") in your project. This setting can be done in [[Group Options| the groups section of the project settings window]] . +* When using external C libraries, be sure that they are MT-safe on the platforms where the Eiffel Threads are available. For example [[WEL]] and [[EiffelNet]] multi-threaded libraries can be recognized by the `mt` prefix. + +==Compilation== + +Just launch the compilation: the Eiffel compiler will generate and link the multi-threaded executable. If the project was already compiled, [[Clean compile|clean the project and recompile it from scratch]]. + +==External C files== + +The C files that you link with a multi-threaded Eiffel application must be compiled in multi-threaded mode. In addition, you should follow some basic guidelines, which you can find in any documentation on threads. Here are the main requirements: +* Check that what you are importing is safe: you cannot arbitrarily enter non-threaded code in a multi-threaded program. Check your include files and the libraries that you use for linking to decide if they can be used in multi-threaded mode. +* If you are using CECIL in multi-threaded mode, you must compile your C files with the same defined symbols as those used to compile the generated C-code in multi-threaded mode. +* Threaded code can safely refer to unsafe code ONLY from the initial thread. + +{{note|If you use the libraries EiffelNet and MEL in multi-threaded mode, you should use libmtnet. a and libmtmel. a. When using MEL, you have to be aware that Motif 1. 2 is not threaded-safe (i.e not reentrant). Motif 2. x is threaded-safe.}} + +==Thread Safe Eiffel libraries== + +Most libraries are not thread safe. This means that even though you can use them in a multi-threaded environment, you will need to add the necessary protection to ensure that objects are accessed only by one thread at a time. + +Most of the issues are related to the use of EiffelBase containers which were designed at a time when threads were not present. In the future we will certainly provide a version of EiffelBase which will be designed to be thread safe, in the meantime, you have to use basic protection mechanisms such as mutexes to guarantee the safe execution of your programs. + +Here is a summary of what you need to include in your project settings when using our libraries: + +- EiffelBase: not thread safe, no externals required + +- WEL: partly thread safe regarding creation of graphical objects that belong to two different threads, but since it relies on EiffelBase, be aware of what has been said. Other libraries have the same dependency on EiffelBase and this warning will not be repeated. + +- MEL: you have to be aware that Motif 1. 2 is not thread safe and that Motif 2.x is. Therefore you can use MEL in a multi-threaded program only if you have Motif 2.x. In this case, you need to include libmtmel.a instead of libmel.a + +- EiffelNet: thread safe with above limitation on EiffelBase. + +- COM: not thread safe. + + + + diff --git a/documentation/18.11/solutions/concurrent-computing/eiffelthread/eiffelthread-tutorial/index.wiki b/documentation/18.11/solutions/concurrent-computing/eiffelthread/eiffelthread-tutorial/index.wiki new file mode 100644 index 00000000..4fccb2fb --- /dev/null +++ b/documentation/18.11/solutions/concurrent-computing/eiffelthread/eiffelthread-tutorial/index.wiki @@ -0,0 +1,17 @@ +[[Property:title|EiffelThread Tutorial]] +[[Property:weight|-1]] +[[Property:uuid|c1965bc3-23cf-25d6-02c1-717b7035d41c]] +Multithreaded applications provide a flexible, exciting way of utilizing the power of modern computer systems. EiffelThread supports a powerful multithreaded model, fast and easy to use. + +The EiffelThread library is mapped to the native thread library of your platform such as Windows, POSIX, Solaris and Unix International Threads. + +This document will explain how to use the EiffelThread library. To fully take advantage of this documentation you should know some basics about multithreaded systems + +To enable multithreading in the EiffelStudio environment, you will need to do some changes in your project settings. + +There are special considerations for using "once" features in an Eiffel multithreaded environment. + +If you encounter problems, take a look at the FAQ list. + + + diff --git a/documentation/18.11/solutions/concurrent-computing/eiffelthread/eiffelthread-tutorial/multithread-faq.wiki b/documentation/18.11/solutions/concurrent-computing/eiffelthread/eiffelthread-tutorial/multithread-faq.wiki new file mode 100644 index 00000000..9c5f58ec --- /dev/null +++ b/documentation/18.11/solutions/concurrent-computing/eiffelthread/eiffelthread-tutorial/multithread-faq.wiki @@ -0,0 +1,24 @@ +[[Property:title|Multithread FAQ]] +[[Property:weight|6]] +[[Property:uuid|a0e1ddf6-cc19-b6f8-0e05-075908ddd347]] +===I've launched several threads and they do not seem to be executed:=== + +The thread that launched the several threads may be dead before its children. + +===Two threads can lock the same mutex, however none of them unlocks it:=== + +Same problem as above. Maybe the first thread that locked the shared mutex died before the second tried to lock it: thus, the first one automatically unlocked it when it died. You should put a join_all or an infinite loop in the parent thread. + +===I've added the option multithreaded in the project settings and it crashes:=== + +If you have already compiled your system in non-MT mode, you cannot change the mode of compilation and simply relaunch your compilation (the generated C-code would be incompatible). Delete all your object files in your W_code or F_code directory and freeze or finalize the system again. + +===My once function changed during my MT-Eiffel-program:=== + +The once functions are once per thread in Multithreaded mode. Hence, each once function is thread-specific and is initialized the first time it is called in a thread. + +You can create a once per process by following [[Once features in multithreaded mode|these instructions]] . + + + + diff --git a/documentation/18.11/solutions/concurrent-computing/eiffelthread/eiffelthread-tutorial/once-features-multithreaded-mode.wiki b/documentation/18.11/solutions/concurrent-computing/eiffelthread/eiffelthread-tutorial/once-features-multithreaded-mode.wiki new file mode 100644 index 00000000..55f695c8 --- /dev/null +++ b/documentation/18.11/solutions/concurrent-computing/eiffelthread/eiffelthread-tutorial/once-features-multithreaded-mode.wiki @@ -0,0 +1,87 @@ +[[Property:title|Once features in multithreaded mode]] +[[Property:weight|4]] +[[Property:uuid|5578da29-7603-b501-1a7d-305d20fd6485]] +==Manipulating Once features in multithreaded mode== + +Eiffel introduced the powerful mechanism of once routines. A once routine has a body that will be executed only once, at the first call. Subsequent calls will have no further effect and, in the case of a function, will return the same result as the first. This provides a simple way of sharing objects in an object-oriented context. + +For multithreaded applications, the appropriate semantics is that once routines must be called once per thread (rather than once per process). This is the semantics supported by EiffelThread. + +Then the once feature is not initialized once per process but once per thread. Your once feature will be called again in any new thread execution. + +==Once per Process/Thread== + +By default, once features are once per thread. This means that when a once feature is called in a thread, the Eiffel run-time will check whether it has been already computed in this thread. If not, the once feature will be initialized and computed. This corresponds to the most commonly desired behavior for once features in multithreaded mode: most of the time, a once called in a thread is not likely to share its result with other threads. + +This is only the default, however: you may at times need to use "once per process" versus "once per thread". Objects created "once per process" in multithreading mode can be shared among threads. You can use a [[ET: Once routines and shared objects#Adjusting once semantics with "once keys"|'''once key''']] to indicate the mode you wish to use. + +==Specifying once per thread or once per process == + +As mentioned above, in multithreaded mode, the default once syntax will ensure "once per thread", as in this example: + + + object_per_thread: OBJECT + -- Once per thread. + once + create Result.make + end + + +You could obtain the same effect by explicitly coding the "THREAD" once key: + + + object_per_thread: OBJECT + -- Once per thread. + once ("THREAD") + create Result.make + end + + +To ensure that a once function is executed only once per process, you would use the "PROCESS" once key: + + + object_per_process: OBJECT + -- New 'object' (once per process) + -- that could be shared between threads + -- without reinitializing it. + once ("PROCESS") + create Result.make + end + + + +The same concepts apply to once procedures. + + +{{note|Remember the effect of exceptions on the execution of once routines. If an exception occurs during the execution of a once routine, then '''that same exception will be raised again on each subsequent call''' to the once routine.}} + +===Obsolete syntax=== + +The syntax shown above is the current standard syntax. However in Eiffel code written for previous versions, you may run across once keys for multithreaded systems which are expressed in a different syntax. Specifically, the obsolete syntax used a feature's note clause to specify a once key, as in the following example. + + + object_per_process: OBJECT + -- Obsolete syntax + -- New 'object' (once per process) + -- that could be shared between threads + -- without reinitializing it. + note + once_status: global + once + create Result.make + end + + + +==Using once per object in a multithreaded system== + +It is possible to use a once key to specify a once function that is executed [[ET: Once routines and shared objects#Adjusting once semantics with "once keys"|once per object]]. However, in a multithreaded system, it is important to understand that no automatic synchronization of access occurs in this case. So the following caution is given. + + +{{caution|You should understand that in a multithreaded system, you must synchronize access to the result of a function executed once per object in the same way that you would synchronize access to class attributes. }} + + + +{{SeeAlso|The Eiffel Tutorial section on [[ET: Once routines and shared objects]] .}} + + diff --git a/documentation/18.11/solutions/concurrent-computing/eiffelthread/eiffelthread-tutorial/thread-library-overview.wiki b/documentation/18.11/solutions/concurrent-computing/eiffelthread/eiffelthread-tutorial/thread-library-overview.wiki new file mode 100644 index 00000000..6b5e0ae7 --- /dev/null +++ b/documentation/18.11/solutions/concurrent-computing/eiffelthread/eiffelthread-tutorial/thread-library-overview.wiki @@ -0,0 +1,199 @@ +[[Property:title|Thread library overview]] +[[Property:weight|1]] +[[Property:uuid|2bdeeb91-1917-f443-ebfc-4f877107edd7]] +This is only a quick overview of the EiffelThread Library. The class reference for this library should give its complete interface. + +==Creating and launching threads: the class THREAD (deferred)== + +The class of the thread object you want to create should inherit the THREAD class.
+Your thread is represented by a class which inherits from THREAD (deferred class).
+ + +class + MY_THREAD + +inherit + THREAD + ... + +feature + + execute + -- define the deferred feature from THREAD. + do + ... + end + + ... + +end -- class MY_THREAD + + + +Creating a thread is like creating an Eiffel object: + + + + my_thread: MY_THREAD + -- MY_THREAD inherits from THREAD and defines + -- the deferred procedure `execute' + + ... + + create my_thread + + + +{{note|You have created a thread object but have not started the thread itself yet.
+To run the thread, use the feature launch from THREAD. }} + + + + my_thread.launch + + +On the Eiffel side, the procedure execute will be launched. This procedures deferred in class THREAD, you have to define it in MY_THREAD. + + +On the C side, a C thread will be created and launched. + + +{{caution|You may call join_all and the end of the execution of the parent thread if you do not want it to die before its child, otherwise they may prematurely terminate. }} + + +==The class MUTEX== + +The implementation of the class MUTEX is mapped on the C standard thread library. An instance of class MUTEX can be shared between different thread. + + +my_mutex.pointer is the pointer to the nested C mutex of my_mutex. + + +* Declaration of the mutex: + + my_mutex: MUTEX + +* Creation of mutex: + + create my_mutex.make + +* Locking the mutex: + + my_mutex.lock + +* Unlocking the mutex: + + my_mutex.unlock + +* try_lock: if it is not locked yet, lock the mutex and return True, otherwise it returns False. + + my_mutex.try_lock + +* Is my mutex initialized? + + my_mutex.is_set + + +{{note|on Windows: The MUTEX objects on Windows are recursive while they are not on Unix. A recursive mutex can be locked twice by the same thread. }} + + +{{caution|Be sure that a mutex is unlocked when it is disposed. }} + + +==The class SEMAPHORE== + +Like MUTEX, the features of this class are mapped on the C thread library. An instance of class SEMAPHORE can be shared between thread. + + +* Declaration of the semaphore : + + my_sem: SEMAPHORE + +Creation of semaphore: initialize semaphore with nb_tokens, it requires nb_tokens > = 0 + + create my_sem.make (nb_tokens) + +* Wait for a token: + + my_sem.wait + +* Give back a token: + + my_sem.post + +* try_wait, similar to try_lock from MUTEX, if a token is available, take it and return True , otherwise return False . + + my_sem.try_wait + + +{{caution|Be sure that a semaphore does not wait for a token when it is disposed }} + +==The class CONDITION_VARIABLE== + +This class allows to use condition variables in Eiffel. An instance of class CONDITION_VARIABLE can be shared between threads. + + +* Declaration of the condition variable + + my_cond: CONDITION_VARIABLE + +* Creation: + + create my_cond.make + +* Wait for a signal (send by signal). You need to use a mutex. + + my_mutex: MUTEX + + ... + + create my_mutex.make + + + +my_mutex must be locked by the calling thread so as wait can be called. wait atomically unlocks my_mutex and waits for the condition variable my_mutex to receive a signal. As soon as it received a signal, ''my_cond '' locks ''my_mutex '' + + + my_mutex.lock + -- You must lock `my_mutex' before calling wait. + + my_cond.wait (my_mutex) + -- Here the critical code to execute when `my_cond' received a signal. + + my_mutex.unlock + -- Unlock the mutex at the end of the critical section. + + + +* Send a signal one thread blocked on the condition variable `my_cond'. + + my_cond.signal + +* Send a signal to all the threads blocked on the condition variable `my_cond'. + + my_cond.broadcast + + +{{caution|Be sure that a condition variable is unblocked when it is disposed. }} + + +==Miscellaneous classes== + +class THREAD_ATTRIBUTES: defines the attributes of an Eiffel Thread regarding the thread scheduling policy and priority. + + +==Controlling execution: THREAD_CONTROL== + +* yield: the calling thread yields its execution in favor of an other thread of same priority. +* join_all: the calling thread waits for all other threads to finished (all its children). +* A parent thread can wait for the termination of a child process through the feature join of class THREAD_CONTROL (inherited by THREAD): + + thr: MY_THREAD + ... + + thr.launch + ... + thr.join + + + diff --git a/documentation/18.11/solutions/concurrent-computing/eiffelthread/index.wiki b/documentation/18.11/solutions/concurrent-computing/eiffelthread/index.wiki new file mode 100644 index 00000000..5a015796 --- /dev/null +++ b/documentation/18.11/solutions/concurrent-computing/eiffelthread/index.wiki @@ -0,0 +1,11 @@ +[[Property:link_title|EiffelThreads]] +[[Property:title|EiffelThreads]] +[[Property:weight|0]] +[[Property:uuid|AAF0CEF9-7268-492F-9119-872164995898]] +==EiffelThreads Library== + +Type: Library
+Platform: Any + +The EiffelThreads library includes the main components needed to build multi-threaded systems. + diff --git a/documentation/18.11/solutions/concurrent-computing/index.wiki b/documentation/18.11/solutions/concurrent-computing/index.wiki new file mode 100644 index 00000000..48f2e776 --- /dev/null +++ b/documentation/18.11/solutions/concurrent-computing/index.wiki @@ -0,0 +1,25 @@ +[[Property:modification_date|Tue, 20 Nov 2018 12:44:24 GMT]] +[[Property:publication_date|Tue, 20 Nov 2018 12:44:24 GMT]] +[[Property:link_title|Concurrency]] +[[Property:title|Concurrency]] +[[Property:weight|-10]] +[[Property:uuid|E76EF4EE-0D90-4AEE-8521-0293A0086AA2]] +== Building concurrent applications in Eiffel == + +'''Concurrency''' is a system's ability to perform several tasks at a time, as with an email client that can download new messages while you are scrolling through previously downloaded ones. + + +Many applications need concurrency, either for convenience or out of sheer necessity. Operating systems provide a concurrency mechanism in the form of "threading": a program can start several concurrent lines of control, or threads, which run in parallel. + + +In most programming languages, the way to obtain threaded applications is to rely on a threading library. Eiffel offers this possibility through the [[Eiffelthreads|EiffelThreads library]]. + + +Thread libraries are at a lower level of abstraction than modern programming languages, requiring you to manage the interaction of threads manually through such techniques as mutual exclusion semaphores. Eiffel offers a higher-level mechanism: [[SCOOP]] (Simple Concurrent Object-Oriented Programming), which greatly simplifies the writing of concurrent applications and avoids many of the typical pitfalls of concurrency such as "data races". SCOOP is the recommended approach to concurrent Eiffel programming. + +For details see: +* The [[SCOOP|SCOOP documentation]] for the recommended approach to concurrent programming in Eiffel. +* The [[EiffelThreads|EiffelThreads documentation]] if you need to exert fine control on the execution and synchronization of threads. + + + diff --git a/documentation/18.11/solutions/database-access/abel/index.wiki b/documentation/18.11/solutions/database-access/abel/index.wiki new file mode 100644 index 00000000..a9f6e418 --- /dev/null +++ b/documentation/18.11/solutions/database-access/abel/index.wiki @@ -0,0 +1,40 @@ +[[Property:title|ABEL]] +[[Property:weight|0]] +[[Property:uuid|585002f7-4f2c-e575-f3a2-0a339f349980]] +== Overview == + +ABEL is intended as an easy-to-use persistence library. It provides a high-level interface for storing and retrieving objects, selection criteria when querying objects, lazy loading of results, and transactions. ABEL can work with different storage backends such as MySQL or CouchDB transparently. + +== Features == + +* Store and retrieve objects +* Filter retrieved objects based on criteria +* Transaction support +* Read only and read-write access +* Lazy loading of query results +* Support for different backends +* Support for access to relational databases created by EiffelStore. + +== When to use it? == + +ABEL can be used whenever an application needs some basic persistency without the developer having to think about the data format or object-relational mapping. It may also be used to read and write table records for an existing database, provided that there is a set of classes matching the database tables. + +It is not a good idea to use ABEL in a high-performance setting. Due to its high level of abstraction there are a lot of internal data conversions to enable automatic object-relational mapping. + +== Current limitations == + +* The CouchDB backend has some severe limitations, e.g. it doesn't support polymorphism, SPECIAL, or transactions. +* The garbage collector currently only works for single-user systems and is rather primitive, as it needs to load the whole database into memory. +* The ESCHER plugin, which handles class schema evolution, has never been properly tested. Use at your own risk. + +== Future work == + +* Support for caching for performance reasons. +* Lazy retrieval of referenced objects in an object graph. This requires support in the compiler however. +* Some handy features for the backend that deals with existing databases: +** Allow to provide a custom class name to table name mapping. +** A way to automatically resolve 1:N or M:N relations. +** Support automatic creation of classes from tables, or tables from classes. +* Support other backends like Oracle, Microsoft SQL or EiffelStore. + + diff --git a/documentation/18.11/solutions/database-access/abel/tutorial/accessing-existing-database.wiki b/documentation/18.11/solutions/database-access/abel/tutorial/accessing-existing-database.wiki new file mode 100644 index 00000000..adad29dc --- /dev/null +++ b/documentation/18.11/solutions/database-access/abel/tutorial/accessing-existing-database.wiki @@ -0,0 +1,352 @@ +[[Property:title|Accessing an existing database]] +[[Property:weight|3]] +[[Property:uuid|683da4a5-2939-890e-8c71-2d59e5ebabe4]] +== Introduction == + +ABEL has a special backend to read and write existing databases. +This backend was designed to use ABEL alongside EiffelStore with very little setup. + +The drawback of this approach is that the backend has some of the limitations of EiffelStore: + +* Only flat classes can be stored and retrieved. +* The class name must match the type name in lowercase, and each attribute must match a column name. +* ABEL treats all objects as values without identity (like expanded types). There is a mechanism however to override this default. +* There is no concept of a root status. + +== The setup == + +Let's assume a simple EiffelStore application for managing a (very simple) MySQL customer database. +The database consists of a single table created by the following SQL statement: + + +CREATE TABLE customer ( + id INTEGER PRIMARY KEY AUTO_INCREMENT, + first_name VARCHAR (100), + last_name VARCHAR (100), + age INTEGER +) + + +In your Eiffel code you have a class which matches the table: + + +class + CUSTOMER + +inherit + ANY redefine out end + +create + make + +feature -- Access + + id: INTEGER + -- The customer ID. + + first_name: STRING + -- The customer's first name. + + last_name: STRING + -- The customer's last name. + + age: INTEGER + -- The age of the customer. + +feature -- Element change + + set_age (an_age: like age) + -- Set `age' to `an_age' + do + age := an_age + end + +feature -- Output + + out: STRING + -- String output of `Current'. + do + Result := id.out + ": " + first_name + " " + last_name + " " + age.out + "%N" + end + +feature {NONE} -- Initialization + + make (an_id: like id; first: like first_name; last: like last_name; an_age: like age) + -- Initialization for `Current'. + do + id := an_id + first_name := first + last_name := last + age := an_age + end + +end + + +== Connection setup == + +Because we're using an existing MySQL database, we need to choose the PS_MYSQL_RELATIONAL_REPOSITORY_FACTORY for initialization. + + +class + TUTORIAL + +create + make + +feature -- Access + + repository: PS_REPOSITORY + +feature {NONE} -- Initialization + + make + -- Set up the repository. + local + factory: PS_MYSQL_RELATIONAL_REPOSITORY_FACTORY + do + create factory.make + + -- Feel free to change the login credentials. + factory.set_database ("my_database") + factory.set_user ("root") + factory.set_password ("1234") + + repository := factory.new_repository + end + +end + + +That's it. You're now ready to read and write table records using the repository. + +== Querying objects == + +With the newly created repository, we can now query for CUSTOMER objects. +The procedure is the same as seen in [[Basic operations]]. + + + + print_customers + -- Print all customers. + local + query: PS_QUERY [CUSTOMER] + do + create query.make + repository.execute_query (query) + + across + query as cursor + loop + print (cursor.item) + end + + if query.has_error then + print ("An error occurred!%N") + end + + query.close + end + + +== Writing objects == + +You can also use ABEL to write or update customers, although the semantics are a bit different compared to other backends. +ABEL by default treats every object as a value tuple without identity (like an expanded type). +The reason is that the primary key of an object is usually stored directly inside the object, +and a user may change it and thus mess with ABEL's internal data structures. + +The implication of this is that a user is only allowed to call {PS_TRANSACTION}.insert to write an object. +The semantics of insert is to insert a new record if no other record with the same primary key exists, or else to update the existing record. +This might be confusing at first sight, but it is in line with the semantics of ABEL as seen in [[Dealing with references]]. + +The following code shows how to insert and update objects. + + + insert_customer + -- Insert a new customer. + local + albo: CUSTOMER + transaction: PS_TRANSACTION + do + -- Assume 42 is an valid, unused primary key. + create albo.make (42, "Albo", "Bitossi", 1) + + transaction := repository.new_transaction + + if not transaction.has_error then + -- This results in an insert, because + -- according to our previous assumption + -- there is no record with primary key 42 + transaction.insert (albo) + end + + -- Cleanup and error handling. + if not transaction.has_error then + transaction.commit + end + + if transaction.has_error then + print ("An error occurred.%N") + end + end + + update_customer + -- Update an existing customer. + local + factory: PS_CRITERION_FACTORY + query: PS_QUERY [CUSTOMER] + transaction: PS_TRANSACTION + do + create query.make + query.set_criterion (factory ("id", "=", 42)) + + transaction := repository.new_transaction + + if not transaction.has_error then + transaction.execute_query (query) + end + + across + query as cursor + loop + cursor.item.set_age (2) + -- The result is an update, because an object + -- with primary key 42 is already present. + transaction.insert (cursor.item) + end + + -- Cleanup and error handling + query.close + if not transaction.has_error then + transaction.commit + end + if transaction.has_error then + print ("An error occurred!%N") + end + end + + +== Managed types== + +Maybe you realized the weak spot in the previous section: +We assumed that a primary key does not exist yet. +This is a very dangerous assumption, especially in a multi-user setting. +The way to resolve this issue is to usually to declare the primary key column as auto-incremented and let the database handle primary key generation. + +It is possible to use this facility in ABEL by declaring a type as "managed" and specifying the primary key column. +This only works for tables which actually have an auto-incremented integer primary key column. + +There are some changes when declaring a type as managed: + +* ABEL will keep track of object identity. Thus it is possible (and recommended) to use {PS_TRANSACTION}.update. +* As ABEL now takes care of primary keys, it is not allowed to change the primary key of an object. If it happens anyway, an error will be returned. +* To insert a new object, you can just set the primary key attribute to zero. The database will then generate a new key. +* After a successful insert, ABEL will update the Eiffel object with the new primary key. + +Our customer database table fulfills all requirements for ABEL to manage its primary key handling, thus we can rewrite the above examples: + + +class + TUTORIAL + +create + make + +feature -- Access + + repository: PS_REPOSITORY + + generated_id: INTEGER + -- The ID generated by the database. + +feature {NONE} -- Initialization + + make + -- Set up the repository. + local + factory: PS_MYSQL_RELATIONAL_REPOSITORY_FACTORY + do + create factory.make + factory.set_database ("my_database") + factory.set_user ("root") + factory.set_password ("1234") + + -- Tell ABEL to manage the `CUSTOMER' type. + factory.manage ({CUSTOMER}, "id") + + repository := factory.new_repository + + insert_customer + update_customer + end + +feature -- Tutorial functions + + insert_customer + -- Insert a new customer. + local + albo: CUSTOMER + transaction: PS_TRANSACTION + do + -- Note that the ID is now set to 0. + create albo.make (0, "Albo", "Bitossi", 1) + + transaction := repository.new_transaction + + if not transaction.has_error then + -- The next statement will be an insert in any case. + transaction.insert (albo) + end + + -- The generated ID is now stored in `albo' + generated_id := albo.id + + -- Cleanup and error handling. + if not transaction.has_error then + transaction.commit + end + + if transaction.has_error then + print ("An error occurred.%N") + end + end + + update_customer + -- Update an existing customer. + local + factory: PS_CRITERION_FACTORY + query: PS_QUERY [CUSTOMER] + transaction: PS_TRANSACTION + do + create factory + create query.make + query.set_criterion (factory ("id", "=", generated_id)) + + transaction := repository.new_transaction + + if not transaction.has_error then + transaction.execute_query (query) + end + + across + query as cursor + loop + cursor.item.set_age (3) + -- It is possible to call update. + transaction.update (cursor.item) + end + + -- Cleanup and error handling + query.close + if not transaction.has_error then + transaction.commit + end + if transaction.has_error then + print ("An error occurred!%N") + end + end +end + + + diff --git a/documentation/18.11/solutions/database-access/abel/tutorial/advanced-queries.wiki b/documentation/18.11/solutions/database-access/abel/tutorial/advanced-queries.wiki new file mode 100644 index 00000000..f69a9935 --- /dev/null +++ b/documentation/18.11/solutions/database-access/abel/tutorial/advanced-queries.wiki @@ -0,0 +1,151 @@ +[[Property:title|Advanced Queries]] +[[Property:weight|-9]] +[[Property:uuid|a630a4bb-6b25-54ef-085b-7e18050a21a2]] +==The query mechanism== + +As you already know from [[Basic Operations]], queries to a database are done by creating a PS_QUERY[G] object +and executing it against a PS_TRANSACTION or PS_REPOSITORY. +The actual value of the generic parameter G determines the type of the objects that will be returned. +By default objects of a subtype of G will also be included in the result set. + +ABEL will by default load an object completely, meaning all objects that can be reached by following references will be loaded as well (see also [[Dealing with References]]). + +==Criteria== + +You can filter your query results by setting criteria in the query object, using feature set_criterion in PS_QUERY. +There are two types of criteria: predefined and agent criteria. + +===Predefined Criteria=== +When using a predefined criterion you pick an attribute name, an operator and a value. +During a read operation, ABEL checks the attribute value of the freshly retrieved object against the value set in the criterion, and filters away objects that don't satisfy the criterion. + +Most of the supported operators are pretty self-describing (see class PS_CRITERION_FACTORY below). +An exception could be the '''like''' operator, which does pattern-matching on strings. +You can provide the '''like''' operator with a pattern as a value. The pattern can contain the wildcard characters '''*''' and '''?'''. +The asterisk stands for any number (including zero) of undefined characters, and the question mark means exactly one undefined character. + +You can only use attributes that are strings or numbers, but not every type of attribute supports every other operator. +Valid combinations for each type are: + +* Strings: =, like +* Any numeric value: =, <, <=, >, >= +* Booleans: = + +Note that for performance reasons it is usually better to use predefined criteria, because they can be compiled to SQL and hence the result can be filtered in the database. + +===Agent Criteria=== +An agent criterion will filter the objects according to the result of an agent applied to them. + +The criterion is initialized with an agent of type PREDICATE [TUPLE [ANY]]. +There should be either an open target or a single open argument, and the type of the objects in the query result should conform to the agent's open operand. + +==Creating criteria objects== +The criteria instances are best created using the PS_CRITERION_FACTORY class. + +The main features of the class are the following: + + +class + PS_CRITERION_FACTORY +create + default_create + +feature -- Creating a criterion + + new_criterion alias "()" (tuple: TUPLE [ANY]): PS_CRITERION + -- Creates a new criterion according to a `tuple' + -- containing either a single PREDICATE or three + -- values of type [STRING, STRING, ANY]. + + new_agent (a_predicate: PREDICATE [TUPLE [ANY]]): PS_CRITERION + -- Creates an agent criterion. + + new_predefined (object_attribute: STRING; operator: STRING; value: ANY): PS_CRITERION + -- Creates a predefined criterion. + +feature -- Operators + + equals: STRING = "=" + + greater: STRING = ">" + + greater_equal: STRING = ">=" + + less: STRING = "<" + + less_equal: STRING = "<=" + + like_string: STRING = "like" + +end + + +Assuming you have an object factory: PS_CRITERION_FACTORY, to create a new criterion you have two possibilities: + +* The "traditional" way +** factory.new_agent (agent an_agent) +** factory.new_predefined (an_attr_name, an_operator, a_val) +* The "syntactic sugar" way +** factory (an_attr_name, an_operator, a_value) +** factory (agent an_agent) + + + create_criteria_traditional : PS_CRITERION + -- Create a new criteria using the traditional approach. + do + -- for predefined criteria + Result:= factory.new_predefined ("age", factory.less, 5) + + -- for agent criteria + Result := factory.new_agent (agent age_more_than (?, 5)) + end + + create_criteria_parenthesis : PS_CRITERION + -- Create a new criteria using parenthesis alias. + do + -- for predefined criteria + Result:= factory ("age", factory.less, 5) + + -- for agent criteria + Result := factory (agent age_more_than (?, 5)) + end + + age_more_than (person: PERSON; age: INTEGER): BOOLEAN + -- An example agent + do + Result:= person.age > age + end + + + +===Combining criteria=== + +You can combine multiple criterion objects by using the standard Eiffel logical operators. +For example, if you want to search for a person called "Albo Bitossi" with age <= 20, you can just create a criterion object for each of the constraints and combine them: + + + composite_search_criterion : PS_CRITERION + -- Combining criterion objects. + local + first_name_criterion: PS_CRITERION + last_name_criterion: PS_CRITERION + age_criterion: PS_CRITERION + do + first_name_criterion:= factory ("first_name", factory.equals, "Albo") + + last_name_criterion := factory ("last_name", factory.equals, "Bitossi") + + age_criterion := factory (agent age_more_than (?, 20)) + + Result := first_name_criterion and last_name_criterion and not age_criterion + + -- Shorter version: + Result := factory ("first_name", "=", "Albo") + and factory ("last_name", "=", "Bitossi") + and not factory (agent age_more_than (?, 20)) + end + + +ABEL supports the three standard logical operators and, or and not. +The precedence rules are the same as in Eiffel, which means that not is stronger than and, which in turn is stronger than or. + diff --git a/documentation/18.11/solutions/database-access/abel/tutorial/basic-operations.wiki b/documentation/18.11/solutions/database-access/abel/tutorial/basic-operations.wiki new file mode 100644 index 00000000..35015054 --- /dev/null +++ b/documentation/18.11/solutions/database-access/abel/tutorial/basic-operations.wiki @@ -0,0 +1,202 @@ +[[Property:title|Basic operations]] +[[Property:weight|-12]] +[[Property:uuid|8f8179e4-c9dc-7749-ce88-cde695f32d53]] +==Inserting== + +You can insert a new object using feature insert in PS_TRANSACTION. +As every write operation in ABEL needs to be embedded in a transaction, you first need to create a PS_TRANSACTION object. +Let's add three new persons to the database: + + + insert_persons + -- Populate the repository with some person objects. + local + p1, p2, p3: PERSON + transaction: PS_TRANSACTION + do + -- Create persons + create p1.make (...) + create ... + + -- We first need a new transaction. + transaction := repository.new_transaction + + -- Now we can insert all three persons. + if not transaction.has_error then + transaction.insert (p1) + end + if not transaction.has_error then + transaction.insert (p2) + end + if not transaction.has_error then + transaction.insert (p3) + end + + -- Commit the changes. + if not transaction.has_error then + transaction.commit + end + + -- Check for errors. + if transaction.has_error then + print ("An error occurred!%N") + end + end + + +==Querying== +A query for objects is done by creating a PS_QUERY [G] object and executing it using features of PS_REPOSITORY or PS_TRANSACTION. +The generic parameter G denotes the type of objects that should be queried. + +After a successful execution of the query, you can iterate over the result using the across syntax. +The feature print_persons below shows how to get and print a list of persons from the repository: + + + print_persons + -- Print all persons in the repository + local + query: PS_QUERY[PERSON] + do + -- First create a query for PERSON objects. + create query.make + + -- Execute it against the repository. + repository.execute_query (query) + + -- Iterate over the result. + across + query as person_cursor + loop + print (person_cursor.item) + end + + -- Check for errors. + if query.has_error then + print ("An error occurred!%N") + end + + -- Don't forget to close the query. + query.close + end + + +In a real database the result of a query may be very big, and you are probably only interested in objects that meet certain criteria, e.g. all persons of age 20. +You can read more about it in [[Advanced Queries]]. + +Please note that ABEL does not enforce any kind of order on a query result. + +==Updating== + +Updating an object is done through feature update in PS_TRANSACTION. +Like the insert operation, an update needs to happen within a transaction. +Note that in order to update an object, we first have to retrieve it. + +Let's update the age attribute of Berno Citrini by celebrating his birthday: + + + update_berno_citrini + -- Increase the age of Berno Citrini by one. + local + query: PS_QUERY[PERSON] + transaction: PS_TRANSACTION + berno: PERSON + do + print ("Updating Berno Citrini's age by one.%N") + + -- Create query and transaction. + create query.make + transaction := repository.new_transaction + + -- As we're doing a read followed by a write, we + -- need to execute the query within a transaction. + if not transaction.has_error then + transaction.execute_query (query) + end + + -- Search for Berno Citrini + across + query as cursor + loop + if cursor.item.first_name ~ "Berno" then + berno := cursor.item + + -- Change the object. + berno.celebrate_birthday + + -- Perform the database update. + transaction.update (berno) + end + end + + -- Cleanup + query.close + if not transaction.has_error then + transaction.commit + end + + if transaction.has_error then + print ("An error occurred.%N") + end + end + + + +To perform an update the object first needs to be retrieved or inserted within the same transaction. +Otherwise ABEL cannot map the Eiffel object to its database counterpart. + +==Deleting== + +ABEL does not support explicit deletes any longer, as it is considered dangerous for shared objects. +Instead of deletion it is planned to introduce a garbage collection mechanism in the + +==Dealing with Known Objects== + +Within a transaction ABEL keeps track of objects that have been inserted or queried. +This is important because in case of an update, the library internally needs to map the object in the current execution of the program to its specific entry in the database. + +Because of that, you can't update an object that is not yet known to ABEL. +As an example, the following functions will fail: + + + failing_update + -- Trying to update a new person object. + local + bob: PERSON + transaction: PS_TRANSACTION + do + create bob.make ("Robert", "Baratheon") + transaction := repository.new_transaction + -- Error: Bob was not inserted / retrieved before. + -- The result is a precondition violation. + transaction.update (bob) + transaction.commit + end + + update_after_commit + -- Update after transaction committed. + local + joff: PERSON + transaction: PS_TRANSACTION + do + create joff.make ("Joffrey", "Baratheon") + transaction := repository.new_transaction + transaction.insert (joff) + transaction.commit + + joff.celebrate_birthday + + -- Prepare can be used to restart a transaction. + transaction.prepare + + -- Error: Joff was not inserted / retrieved before. + -- The result is a precondition violation. + transaction.update (joff) + + -- Note: After commit and prepare,`transaction' + -- represents a completely new transaction. + end + + +The feature is_persistent in PS_TRANSACTION can tell you if a specific object is known to ABEL and hence has a link to its entry in the database. + + diff --git a/documentation/18.11/solutions/database-access/abel/tutorial/dealing-references.wiki b/documentation/18.11/solutions/database-access/abel/tutorial/dealing-references.wiki new file mode 100644 index 00000000..29772675 --- /dev/null +++ b/documentation/18.11/solutions/database-access/abel/tutorial/dealing-references.wiki @@ -0,0 +1,150 @@ +[[Property:title|Dealing with references]] +[[Property:weight|-6]] +[[Property:uuid|1190C592-50E0-4834-9D60-E1E357921335]] +In ABEL, a basic type is an object of type STRING, BOOLEAN, CHARACTER or any numeric class like REAL or INTEGER. +The PERSON class only has attributes of a basic type. +However, an object can contain references to other objects. ABEL is able to handle these references by storing and reconstructing the whole object graph +(an object graph is roughly defined as all the objects that can be reached by recursively following all references, starting at some root object). + +==Inserting objects with references== +Let's look at the new class CHILD: + + +class + CHILD + +create + make + +feature {NONE} -- Initialization + + make (first, last: STRING) + -- Create a new child. + require + first_exists: not first.is_empty + last_exists: not last.is_empty + do + first_name := first + last_name := last + age := 0 + ensure + first_name_set: first_name = first + last_name_set: last_name = last + default_age: age = 0 + end + +feature -- Access + + first_name: STRING + -- The child's first name. + + last_name: STRING + -- The child's last name. + + age: INTEGER + -- The child's age. + + father: detachable CHILD + -- The child's father. + +feature -- Element Change + + celebrate_birthday + -- Increase age by 1. + do + age := age + 1 + ensure + age_incremented_by_one: age = old age + 1 + end + + set_father (a_father: CHILD) + -- Set a father for the child. + do + father := a_father + ensure + father_set: father = a_father + end + +invariant + age_non_negative: age >= 0 + first_name_exists: not first_name.is_empty + last_name_exists: not last_name.is_empty +end + + +This adds some complexity: +Instead of having a single object, ABEL has to insert a CHILD's mother and father as well, and it has to repeat this procedure if their parent attribute is also attached. +The good news is that the examples above will work exactly the same. + +However, there are some additional caveats to take into consideration. +Let's consider a simple example with CHILD objects ''Baby Doe'', ''John Doe'' and ''Grandpa Doe''. +From the name of the object instances you can already guess what the object graph looks like: + +[[Image:Child object graph | center | 700px]] + +Now if you insert ''Baby Doe'', ABEL will by default follow all references and insert every single object along the object graph, which means that ''John Doe'' and ''Grandpa Doe'' will be inserted as well. +This is usually the desired behavior, as objects are stored completely that way, but it also has some side effects we need to be aware of: + +* Assume an insert of ''Baby Doe'' has happened to an empty database. If you now query the database for CHILD objects, it will return exactly the same object graph as above, but the query result will actually have three items as the object graph consists of three single CHILD objects. +* The insert of ''John Doe'' and ''Grandpa Doe'', after inserting ''Baby Doe'', is internally changed to an update operation because both objects are already in the database. This might result in some undesired overhead which can be avoided if you know the object structure. + +In our main tutorial class START we have the following two features that show how to deal with object graphs. +You will notice it is very similar to the corresponding routines for the flat PERSON objects. + + + insert_children + -- Populate the repository with some children objects. + local + c1, c2, c3: CHILD + transaction: PS_TRANSACTION + do + -- Create the object graph. + create c1.make ("Baby", "Doe") + create c2.make ("John", "Doe") + create c3.make ("Grandpa", "Doe") + c1.set_father (c2) + c2.set_father (c3) + + print ("Insert 3 children in the database.%N") + transaction := repository.new_transaction + + -- It is sufficient to just insert "Baby Joe", + -- as the other CHILD objects are (transitively) + -- referenced and thus inserted automatically. + if not transaction.has_error then + transaction.insert (c1) + end + + if not transaction.has_error then + transaction.commit + end + + if transaction.has_error then + print ("An error occurred during insert!%N") + end + end + + print_children + -- Print all children in the repository + local + query: PS_QUERY[CHILD] + do + create query.make + repository.execute_query (query) + + -- The result will also contain + -- all referenced CHILD objects. + across + query as person_cursor + loop + print (person_cursor.item) + end + + query.close + end + + +==Going deeper in the Object Graph== +ABEL has no limits regarding the depth of an object graph, and it will detect and handle reference cycles correctly. +You are welcome to test ABEL's capability with very complex objects, however, please keep in mind that this may impact performance significantly. + diff --git a/documentation/18.11/solutions/database-access/abel/tutorial/error-handling.wiki b/documentation/18.11/solutions/database-access/abel/tutorial/error-handling.wiki new file mode 100644 index 00000000..f040e781 --- /dev/null +++ b/documentation/18.11/solutions/database-access/abel/tutorial/error-handling.wiki @@ -0,0 +1,58 @@ +[[Property:title|Error handling]] +[[Property:weight|0]] +[[Property:uuid|5f3afec1-939d-b1f5-3715-8bbd2f44ce79]] +As ABEL is dealing with I/O and databases, a runtime error may happen at any time. +ABEL will inform you of an error by setting the has_error attribute to True in PS_QUERY or PS_TUPLE_QUERY and, +if available, in PS_TRANSACTION. +The attribute should always be checked in the following cases: + +* Before invoking a library command. +* After a transaction commit. +* After iterating over the result of a read-only query. + +ABEL maps database specific error messages to its own representation for errors, which is a hierarchy of classes rooted at PS_ERROR. +In case of an error, you can find an ABEL error description in the error attribute in all classes suppoorting the has_error attribute. +The following list shows all error classes that are currently defined with some examples (the PS_ prefix is omitted for brevity): + +* CONNECTION_SETUP_ERROR: No internet link, or a deleted serialization file. +* AUTHORIZATION_ERROR: Usually a wrong password. +* BACKEND_ERROR: An unrecoverable error in the storage backend, e.g. a disk failure. +* INTERNAL_ERROR: Any error happening inside ABEL. +* PS_OPERATION_ERROR: For invalid operations, e.g. no access rights to a table. +* TRANSACTION_ABORTED_ERROR: A conflict between two transactions. +* MESSAGE_NOT_UNDERSTOOD_ERROR: Malformed SQL or JSON statements. +* INTEGRITY_CONSTRAINT_VIOLATION_ERROR: The operation violates an integrity constraint in the database. +* EXTERNAL_ROUTINE_ERROR: An SQL routine or triggered action has failed. +* VERSION_MISMATCH: The stored version of an object isn't compatible any more to the current type. + +For your convenience, there is a visitor pattern for all ABEL error types. +You can just implement the appropriate functions and use it for your error handling code. + + +class + MY_PRIVATE_VISITOR + +inherit + PS_DEFAULT_ERROR_VISITOR + redefine + visit_transaction_aborted_error, + visit_connection_setup_error + end + +feature -- Visitor features + + visit_transaction_aborted_error (transaction_aborted_error: PS_TRANSACTION_ABORTED_ERROR) + -- Visit a transaction aborted error + do + print ("Transaction aborted") + end + + visit_connection_setup_error (connection_setup_error: PS_CONNECTION_SETUP_ERROR) + -- Visit a connection setup error + do + print ("Wrong login") + end + +end + + diff --git a/documentation/18.11/solutions/database-access/abel/tutorial/getting-started.wiki b/documentation/18.11/solutions/database-access/abel/tutorial/getting-started.wiki new file mode 100644 index 00000000..35d2f8ca --- /dev/null +++ b/documentation/18.11/solutions/database-access/abel/tutorial/getting-started.wiki @@ -0,0 +1,106 @@ +[[Property:title|Getting started]] +[[Property:weight|-15]] +[[Property:uuid|60a4120c-3994-c9b9-d22e-af7c6fe12147]] +== Setting things up == + +This tutorial only works with ABEL shipped with EiffelStudio 14.05. +You can find the code in the ''unstable'' directory. + +It is also possible to get the latest code from the [https://svn.eiffel.com/eiffelstudio/trunk/Src/unstable/library/persistency/abel SVN directory] . + +== Getting started == +We will be using PERSON objects to show the usage of the API. +In the source code below you will see that ABEL handles objects "as they are", +meaning that to make them persistent you don't need to add any dependencies to their class source code. + + +class PERSON + +create + make + +feature {NONE} -- Initialization + + make (first, last: STRING) + -- Create a newborn person. + require + first_exists: not first.is_empty + last_exists: not last.is_empty + do + first_name := first + last_name := last + age:= 0 + ensure + first_name_set: first_name = first + last_name_set: last_name = last + default_age: age = 0 + end + +feature -- Basic operations + + celebrate_birthday + -- Increase age by 1. + do + age:= age + 1 + ensure + age_incremented_by_one: age = old age + 1 + end + +feature -- Access + + first_name: STRING + -- The person's first name. + + last_name: STRING + -- The person's last name. + + age: INTEGER + -- The person's age. + +invariant + age_non_negative: age >= 0 + first_name_exists: not first_name.is_empty + last_name_exists: not last_name.is_empty +end + + +There are three very important classes in ABEL: +* The deferred class PS_REPOSITORY provides an abstraction to the actual storage mechanism. It can only be used for read operations. +* The PS_TRANSACTION class represents a transaction and can be used to execute read, insert and update operations. Any PS_TRANSACTION object is bound to a PS_REPOSITORY. +* The PS_QUERY [G] class is used to describe a read operation for objects of type G. + +To start using the library, we first need to create a PS_REPOSITORY. +For this tutorial we are going to use an in-memory repository to avoid setting up any external database. +Each ABEL backend will ship a repository factory class to make initialization easier. +The factory for the in-memory repository is called PS_IN_MEMORY_REPOSITORY_FACTORY. + + +class START + +create + make + +feature {NONE} -- Initialization + + make + -- Initialization for `Current'. + local + factory: PS_IN_MEMORY_REPOSITORY_FACTORY + do + create factory.make + repository := factory.new_repository + + create criterion_factory + explore + end + + repository: PS_REPOSITORY + -- The main repository. + + end + +end + +We will use criterion_factory later in this tutorial. +The feature explore will guide us through the rest of this API tutorial and show the possibilities in ABEL. + diff --git a/documentation/18.11/solutions/database-access/abel/tutorial/index.wiki b/documentation/18.11/solutions/database-access/abel/tutorial/index.wiki new file mode 100644 index 00000000..8dcc6447 --- /dev/null +++ b/documentation/18.11/solutions/database-access/abel/tutorial/index.wiki @@ -0,0 +1,5 @@ +[[Property:title|Tutorial]] +[[Property:weight|0]] +[[Property:uuid|d24ce584-52d5-36bb-adb2-68c67c843072]] + + diff --git a/documentation/18.11/solutions/database-access/abel/tutorial/tuple-queries.wiki b/documentation/18.11/solutions/database-access/abel/tutorial/tuple-queries.wiki new file mode 100644 index 00000000..e3ba5d82 --- /dev/null +++ b/documentation/18.11/solutions/database-access/abel/tutorial/tuple-queries.wiki @@ -0,0 +1,77 @@ +[[Property:title|Tuple queries]] +[[Property:weight|-3]] +[[Property:uuid|69046f75-708f-fc1e-b0be-1a17e22751e4]] +Consider a scenario in which you just want to have a list of all first names of CHILD objects in the database. +Loading every attribute of each object of type CHILD might lead to a very bad performance, especially if there is a big object graph attached to each CHILD object. + +To solve this problem ABEL allows queries which return data in TUPLE objects. +Tuple queries are executed by calling execute_tuple_query (a_tuple_query) in either PS_REPOSITORY or PS_TRANSACTION, +where a_tuple_query is of type PS_TUPLE_QUERY [G]. +The result is an iteration cursor over a list of tuples in which the attributes of an object are stored. + +==Tuple queries and projections== +The projection feature in a PS_TUPLE_QUERY defines which attributes shall be included in the result TUPLE. +Additionally, the order of the attributes in the projection array is the same as the order of the elements in the result tuples. + +By default, a PS_TUPLE_QUERY object will only return values of attributes which are of a basic type, so no references are followed during a retrieve. +You can change this default by calling set_projection. +If you include an attribute name whose type is not a basic one, ABEL will actually retrieve and build the attribute object, and not just another tuple. + +==Tuple queries and criteria== +You are restricted to use predefined criteria in tuple queries, because agent criteria expect an object and not a tuple. +You can still combine them with logical operators, and even include a predefined criterion on an attribute that is not present in the projection list. +These attributes will be loaded internally to check if the object satisfies the criterion, and then they are discarded for the actual result. + +==Example== + + + explore_tuple_queries + -- See what can be done with tuple queries. + local + query: PS_TUPLE_QUERY [CHILD] + transaction: PS_TRANSACTION + projection: ARRAYED_LIST [STRING] + do + -- Tuple queries are very similar to normal queries. + -- I.e. you can query for CHILD objects by creating + -- a PS_TUPLE_QUERY [CHILD] + create query.make + + -- It is also possible to add criteria. Agent criteria + -- are not supportedfor tuple queries however. + -- Lets search for CHILD objects with last name Doe. + query.set_criterion (criterion_factory ("last_name", criterion_factory.equals, "Doe")) + + -- The big advantage of tuple queries is that you can + -- define which attributes should be loaded. + -- Thus you can avoid loading a whole object graph + -- if you're just interested in e.g. the first name. + create projection.make_from_array (<<"first_name">>) + query.set_projection (projection) + + -- Execute the tuple query. + repository.execute_tuple_query (query) + + -- The result of the query is a TUPLE containing the + -- requested attribute. + + print ("Print all first names using a tuple query:%N") + + across + query as cursor + loop + -- It is possible to downcast the TUPLE + -- to a tagged tuple with correct type. + check attached {TUPLE [first_name: STRING]} cursor.item as tuple then + print (tuple.first_name + "%N") + end + end + + -- Cleanup and error handling. + query.close + if query.has_error then + print ("An error occurred!%N") + end + end + + diff --git a/documentation/18.11/solutions/database-access/eiffelstore/EiffelStore-ODBC-with-PostgreSQL.wiki b/documentation/18.11/solutions/database-access/eiffelstore/EiffelStore-ODBC-with-PostgreSQL.wiki new file mode 100644 index 00000000..0edc7cb9 --- /dev/null +++ b/documentation/18.11/solutions/database-access/eiffelstore/EiffelStore-ODBC-with-PostgreSQL.wiki @@ -0,0 +1,179 @@ +[[Property:modification_date|Thu, 18 Oct 2018 15:19:06 GMT]] +[[Property:publication_date|Mon, 24 Sep 2018 12:04:18 GMT]] +[[Property:uuid|6F78A05A-2054-4150-84FC-1D8663CA76E6]] +[[Property:weight|5]] +[[Property:title|EiffelStore ODBC with PostgreSQL]] +[[Property:link_title|EiffelStore ODBC]] +The following steps describe how to check the EiffelStudio installation and the required dependencies to use EiffelStore ODBC with PostgreSQL. The steps are also useful for other databases such as MySQL (for which you will to install the MySQL ODBC driver). + +{{note|For this documentation, tests used Ubuntu 18.04 64 bits and EiffelStudio 18.07 64 bits. }} + +* '''Install EiffelStudio''' + From here on, $YOUR_INSTALLATION_PATH denotes the path name of the EiffelStudio installation. + +{{seealso|
+[[Software_Installation_for_EiffelStudio|Software Installation for EiffelStudio]]
+}} + + +* '''Check that the Eiffel-specific environment variables are set''' + + They should be set in the ~/.bashrc control file (or /etc/profile.d/eiffel.sh if you want them for all users) + + +sudo gedit ~/.bashrc + +-- Export the following variables + +export ISE_EIFFEL=$YOUR_INSTALLATION_PATH/Eiffel_18.07 +export ISE_PLATFORM=linux-x86-64 +export PATH=$PATH:$ISE_EIFFEL/studio/spec/$ISE_PLATFORM/bin + +-- Refresh environment variables after edit + +. ~/.bashrc + +-- Or . /etc/profile.d/eiffel.sh if you put it there + + +* '''Use the estudio command to check that EiffelStudio is installed and where it is'' + +which estudio + +{{note|You should see the path to EiffelStudio, for example: /opt/Eiffel_18.07/studio/spec/linux-x86-64/bin/estudio. }} + +check EiffelStudio version using. + +ec -version + +{{note|You should see something like ISE EiffelStudio version 18.07.10.1981 GPL Edition - linux-x86-64 }} + +* '''Check/Install PostgreSQL''' + + +-- Install PostgreSQL +sudo apt install postgresql postgresql-contrib + +-- Check that PostgreSQL is working +sudo -u postgres psql +psql (10.5 (Ubuntu 10.5-0ubuntu0.18.04)) +Type "help" for help. + +postgres=# + + -- Exit postgresql +postgres=# \q + + +* '''Install and Check ODBC Driver Manager and ODBC Driver for PostgreSQL''' + + +-- Install the UnixODBC Driver Manager and the ODBC driver for PostgreSQL +sudo apt-get install unixodbc unixodbc-dev odbc-postgresql + +-- Check +odbcinst -j + +unixODBC 2.3.4 +DRIVERS............: /etc/odbcinst.ini +SYSTEM DATA SOURCES: /etc/odbc.ini +FILE DATA SOURCES..: /etc/ODBCDataSources +USER DATA SOURCES..: /home/websocket/.odbc.ini +SQLULEN Size.......: 8 +SQLLEN Size........: 8 +SQLSETPOSIROW Size.: 8 + + +* '''Configure PostgreSQL and ODBC Driver''' + + +-- Edit the file /etc/odbcinst.ini adding full path instead of file only + +[PostgreSQL] +Description=PostgreSQL ODBC driver (ANSI version) +Driver=/usr/lib/x86_64-linux-gnu/odbc/psqlodbca.so +Setup=/usr/lib/x86_64-linux-gnu/odbc/libodbcpsqlS.so +Debug=0 +CommLog=1 +UsageCount=1 + +[PostgreSQL Unicode] +Description=PostgreSQL ODBC driver (Unicode version) +Driver=/usr/lib/x86_64-linux-gnu/odbc/psqlodbcw.so +Setup=/usr/lib/x86_64-linux-gnu/odbc/libodbcpsqlS.so +Debug=0 +CommLog=1 +UsageCount=1 + + + +* '''Configure the Database name, username and password to use the Postgres ODBC Driver''' + +-- Edit file /etc/odbc.ini + +[PODBC] +Driver = PostgreSQL Unicode +Description = PostgreSQL Data Source +Servername = localhost +Port = 5432 +Protocol = 8.4 +UserName = postgres +Password = example +Database = example + +-- The previous files tells PODBC to use the PostgreSQL Unicode driver. Using as postgres as a user, example as password, and to connect to PostgreSQL running on the localhost on port 5432. + + +* '''Test the ODBC to PostgreSQL connection by running the isql command''' + +Read the /etc/odbc.ini. + +isql -v PODBC +encoding name too long ++---------------------------------------+ +| Connected! | +| | +| sql-statement | +| help [tablename] | +| quit | +| | ++---------------------------------------+ + + + +* '''Compile C code of the Eiffel library store:''' + +cd $YOUR_INSTALLATION_PATH/library/store/dbms/rdbms/odbc/Clib finish_freezing -library + +{{note|On debian at least before finish_freezing log in as superuser doing a '''sudo -i''' }} + +* '''Open EiffelStudio eSQL example and run it''' +The example is located on `$ISE_EIFFEL/examples/store/esql/` + + +-- You will see something like this. + + +Database user authentication: +Data Source Name: PODBC +Name: postgres +Password: example +encoding name too long + +Welcome to the SQL interpreter +Database used: DB + Type 'exit' to terminate + +SQL> select * from cities; + +names location +milan italy +SQL> insert into cities values ('Madrid', 'Spain'); +SQL> select * from cities; + +names location +milan italy +Madrid Spain +SQL> + + diff --git a/documentation/18.11/solutions/database-access/eiffelstore/EiffelStore-SQL-injection.wiki b/documentation/18.11/solutions/database-access/eiffelstore/EiffelStore-SQL-injection.wiki new file mode 100644 index 00000000..6bbf6d41 --- /dev/null +++ b/documentation/18.11/solutions/database-access/eiffelstore/EiffelStore-SQL-injection.wiki @@ -0,0 +1,86 @@ +[[Property:modification_date|Thu, 11 Oct 2018 20:09:39 GMT]] +[[Property:publication_date|Thu, 11 Oct 2018 20:09:39 GMT]] +[[Property:link_title|SQL injection]] +[[Property:uuid|438C838C-C115-44B4-8480-05A825FE1047]] +[[Property:weight|4]] +[[Property:title|Defending against SQL injections with EiffelStore]] +[[Property:weight|4]] + + += Introduction = +In this article, we will explain to you how to use EiffelStore API to avoid SQL injections. + += What is an SQL injection? = +An SQL injection attack is a coding technique that inserts, or "injects", an SQL query via the input data, passing unsafe input from the client to the application. A successful SQL injection can enable the attacker to read sensitive data from the database, modify database data (Insert/Update/Delete), or become administrator of the database server. To learn more about SQL injection, read the following articles. + +{{SeeAlso| To learn more about SQL injection, read the following articles. }} + +* [https://en.wikipedia.org/wiki/SQL_injection https://en.wikipedia.org/wiki/SQL_injection] +* [https://www.owasp.org/index.php/SQL_injection https://www.owasp.org/index.php/SQL_injection] + + += Template Query = +A template query is a string containing the fixed parts of the query and placeholders for the variable parts, and you can later substitute in values into those placeholders. (Bind variables to the query.). A template query could be static or dynamic. + +{{Note|the way you bind variables to the query is quite important and it will define if your query is safe and avoid a SQL Injection attack.}} + +== How to define placeholders (variables) in a SQL Template query? == +Variables syntax is simple: the ':' special character followed by the variable name, for example :value + + SELECT * FROM TABLE_NAME WHERE field1 = :value + +{{SeeAlso| To learn more about EiffelStore query variables read the following article}} +* [https://www.eiffel.org/doc/solutions/Query%20variables Query Variables] + +==How to bind variables/placeholders to a template query.== + +To avoid SQL Injections you will need to map variables names to values using the EiffelStore API (using EiffelStore supported connectors) + +* Queries returning a result will need to use: DB_SELECTION +* Queries updating the database (Insert, Update, Delete) will need to use: DB_CHANGE + +=== Safe binding === +The following example shows an attempt to do an SQL Injection attack, but as we are using EiffelStore API to bind the parameters the unsafe data will be escaped. + + + safe_query + local + l_connection: DATABASE_CONNECTION + db_selection: DB_SELECTION + l_query: STRING + do + ... + create db_selection.make + db_selection.set_query ("SELECT * FROM new_users where datetime = :datetime") + db_selection.set_map_name ("\''; DROP TABLE new_users; --", ":datetime") + db_selection.execute_query + db_selection.unset_map_name (":datetime") + .... + end + + +As you can observe in the previous example the binding to map the variable name :datetime to their value is done using feature BD_SELECTION.set_map_name and the API is responsible to do the necessary encoding. + +=== Unsafe binding === +If you use your own binding to map variables names to values, for example using String replacement, EiffelStore does not ensure that your query is safe, because it will depend on how do you handle escaping inputs before adding them to the query. + +The following example shows how we can bypass the EiffelStore API to bind placeholders using an unsafe String replacement, in this case, is up to the developer to escape the input value. The example is unsafe and subject to SQL Injections attacks when the input is unsafe. + + +unsafe_query + local + l_connection: DATABASE_CONNECTION + db_selection: DB_SELECTION + l_query: STRING + do + ... + check l_connection.is_connected end + create l_query.make_from_string ("SELECT * FROM new_users where datetime = :datetime") + l_query.replace_substring_all (":datetime", "\''; DROP TABLE new_users; --" ) + create db_selection.make + db_selection.set_query (l_query) + db_selection.execute_query + ... + end + + diff --git a/documentation/18.11/solutions/database-access/eiffelstore/eiffelstore-class-reference.wiki b/documentation/18.11/solutions/database-access/eiffelstore/eiffelstore-class-reference.wiki new file mode 100644 index 00000000..306d31de --- /dev/null +++ b/documentation/18.11/solutions/database-access/eiffelstore/eiffelstore-class-reference.wiki @@ -0,0 +1,5 @@ +[[Property:title|EiffelStore Class Reference]] +[[Property:weight|2]] +[[Property:uuid|a21dc8dc-51d8-09c5-3afd-d62effb3c23a]] +==View the [[ref:libraries/store/reference/index|EiffelStore Class Reference]]== + diff --git a/documentation/18.11/solutions/database-access/eiffelstore/eiffelstore-samples/esql-sample.wiki b/documentation/18.11/solutions/database-access/eiffelstore/eiffelstore-samples/esql-sample.wiki new file mode 100644 index 00000000..d15d1a1d --- /dev/null +++ b/documentation/18.11/solutions/database-access/eiffelstore/eiffelstore-samples/esql-sample.wiki @@ -0,0 +1,66 @@ +[[Property:title|Esql Sample]] +[[Property:weight|0]] +[[Property:uuid|04d03117-fdb2-8b73-677f-9b1a0c333dc4]] +This sample consists of a command line SQL parser. SQL statements are filtered through a monitor and sent to the RDBMS. + +==Compiling== + +To compile the example: +* Launch EiffelStudio. +* Click '''Add project''' +* Browse to ''$ISE_EIFFEL\examples\store\esql\''. +* Choose ''esql.ecf'' +* Choose the location where the project will be compiled, by default the same directory containing the configuration file. +* Choose the targe according to the installed DBMS. +* Click '''OK'''. + +==Running== + +This sample lets you interact with your database through a console. + +First you have to enter the database connection information: +* For ODBC: + +Database user authentication: +Data Source Name: handson +Name: smith +Password: mypass + + +{{note|''Name'' and ''Password'' are not required with ODBC. If you don't need ''Name'' and ''Password'', you can simply hit ''Return'' when prompted. }} + +* For Oracle: + +Database user authentication: +Name: smith@HANDSON +Password: mypass + + +{{note|You must specify the Oracle User Name and Net Service Name with the syntax ''@ ''where '''' stands for the User Name and '''' stands for the Net Service Name. }} + + +Then you can enter standard SQL queries to interact with your database, for instance: + +SQL> select firstname, lastname from CONTACTS where lastname = 'Smith' +John Smith +SQL> + + +{{note|Enter ''exit'' to quit the application. }} + +==Under the Hood== + +This sample showcases the use of the 3 basic classes to interact with your database: +* [[ref:libraries/store/reference/db_control_chart|DB_CONTROL]] to connect and disconnect to your database. +* [[ref:libraries/store/reference/db_selection_chart|DB_SELECTION]] to perform 'select' queries. +* [[ref:libraries/store/reference/db_change_chart|DB_CHANGE]] to perform SQL queries that output no result. + +The whole sample code is contained in the root class: +* ESQL for Oracle. +* ESQL_ODBC for ODBC. + + + + + + diff --git a/documentation/18.11/solutions/database-access/eiffelstore/eiffelstore-samples/index.wiki b/documentation/18.11/solutions/database-access/eiffelstore/eiffelstore-samples/index.wiki new file mode 100644 index 00000000..dec8004c --- /dev/null +++ b/documentation/18.11/solutions/database-access/eiffelstore/eiffelstore-samples/index.wiki @@ -0,0 +1,13 @@ +[[Property:title|EiffelStore Samples]] +[[Property:weight|3]] +[[Property:uuid|65a0aab3-bc1d-28b8-a6f0-6d71b4c6d54d]] +=EiffelStore Samples= + +The following basic examples showcases the different EiffelStore capabilities: +* [[Esql Sample|esql]] : A command line SQL parser: very useful to test your Database connection! +* [[Selector Sample|select]] : A basic example to perform smart database queries. +* [[Inserter Sample|insert]] : A basic example to easily insert data in your database. + + + + diff --git a/documentation/18.11/solutions/database-access/eiffelstore/eiffelstore-samples/inserter-sample.wiki b/documentation/18.11/solutions/database-access/eiffelstore/eiffelstore-samples/inserter-sample.wiki new file mode 100644 index 00000000..ffc2a3a1 --- /dev/null +++ b/documentation/18.11/solutions/database-access/eiffelstore/eiffelstore-samples/inserter-sample.wiki @@ -0,0 +1,81 @@ +[[Property:title|Inserter Sample]] +[[Property:weight|2]] +[[Property:uuid|fa0b8601-ca7a-b1cc-384d-f366be33ac40]] +This sample lets the user insert a DB_BOOK object in your database using EiffelStore insertion facilities. + +==Compiling== + +To compile the example: +* Launch EiffelStudio. +* Click '''Add project''' +* Browse to ''$ISE_EIFFEL\examples\store\insert\''. +* Clicking open loads the selected project +* Choose inserter.ecf +* Select the target according to the installed DBMS +* Choose the location where the project will be compiled, by default the same directory containing the configuration file. +* Click '''OK'''. + +==Running== + +This sample lets you interact with your database through a console. + +First you have to enter the database connection information: +* For ODBC: + +Database user authentication: + +Data Source Name: handson + +Name: smith + +Password: mypass + + +{{note|''Name'' and ''Password'' are not required with ODBC. If you don't need ''Name'' and ''Password'', you can simply hit '''Return''' when prompted ''.'' }} + +* For Oracle: + +Database user authentication: + +Name: smith@HANDSON + +Password: mypass + + +{{note|You must specify the Oracle User Name and Net Service Name with the syntax ''@ ''where '''' stands for the User Name and '''' stands for the Net Service Name. }} + + +Then you can insert a book in the database, for instance: + +What new book should I create? + +Author? John Smith + +Title? My book + +Quantity? 1 + +Price? 50 + +Year? 2001 + +Double value? 12.675 + +Object inserted + + +{{note|If your database does not contain a DB_BOOK table, this example will create it. }} + +==Under the Hood== + +This sample showcases the use of the [[ref:libraries/store/reference/db_store_chart|DB_STORE]] class to [[Data Object Coupling| perform database insertions]] where the SQL language is totally abstracted. + +The whole sample code is contained in the root class: +* INSERTER for Oracle. +* INSERTER_ODBC for ODBC. + + + + + + diff --git a/documentation/18.11/solutions/database-access/eiffelstore/eiffelstore-samples/selector-sample.wiki b/documentation/18.11/solutions/database-access/eiffelstore/eiffelstore-samples/selector-sample.wiki new file mode 100644 index 00000000..98127599 --- /dev/null +++ b/documentation/18.11/solutions/database-access/eiffelstore/eiffelstore-samples/selector-sample.wiki @@ -0,0 +1,89 @@ +[[Property:title|Selector Sample]] +[[Property:weight|1]] +[[Property:uuid|3d608710-5537-04e4-fa89-a608ee6864cd]] +This sample creates a DB_BOOK table in your database, enters sample data in it and lets you select rows from this table with author's name. + +==Compiling== + +To compile the example: +* Launch EiffelStudio. +* Click '''Add project''' +* Browse to ''$ISE_EIFFEL\examples\store\select\''. +* Clicking open loads the selected project +* Choose select.ecf +* Select the target according to the installed DBMS +* Choose the location where the project will be compiled, by default the same directory containing the configuration file. +* Click '''OK'''. + +==Running== + +In order to run this example, you must first create a file named data.sql from one of the files in the select example directory. You will see that the data.sql files in the example directory have names which include the names of the available DBMS handles. This is because the SQL can differ from one DBMS to another. For example, you'll see data.sql.oracle and data.sql.odbc. If you are using the Oracle DBMS, you should rename or make a copy of data.sql.oracle as data.sql and make sure it's in your execution directory before running the example. + + +{{note|The data.sql file must be available in the sample application current directory. If you run the sample from EiffelStudio, this directory should be the ''EIFGENs/target/W_CODE/'' directory of your project (where target is one of the installed DBMS). }} + +This sample lets you interact with your database through a console. + +First you have to enter the database connection information: +* For ODBC: + +Database user authentication: +Data Source Name: handson +Name: smith +Password: mypass + + +{{note|''Name'' and ''Password'' are not required with ODBC. If you don't need ''Name'' and ''Password'', you can simply hit ''Return'' when prompted. }} + +* For Oracle: + +Database user authentication: +Name: smith@HANDSON +Password: mypass + + +{{note|You must specify the Oracle User Name and Net Service Name with the syntax ''@ ''where '''' stands for the User Name and '''' stands for the Net Service Name. }} + + +Then you can select rows from this table with author's name, for instance: + +Author? ('exit' to terminate):Bertrand Meyer +Seeking for books whose author's name match: Bertrand Meyer + +Author:Bertrand Meyer +Title:Eiffel The Libraries +Quantity:11 +Price:20 +double_value:435.60000610351562 +First publication:07/01/1994 12:00:00.0 AM + + +Author:Bertrand Meyer +Title:Eiffel The Language +Quantity:9 +Price:51 +double_value:775.22998046875 +First publication:07/01/1992 12:00:00.0 AM + + + +Author? ('exit' to terminate): + + +{{note|Enter ''exit'' to quit the application. }} + +==Under the Hood== + +This sample showcases the use of the [[ref:libraries/store/reference/db_selection_chart|DB_SELECTION]] class to perform smart ''select'' queries, using: +* [[Data Object Coupling|Database data and Eiffel objects Coupling]] . +* [[Query variables|Variables Binding]] . + +The whole sample code is contained in the root class: +* SELECTOR for Oracle. +* SELECTOR_ODBC for ODBC. + + + + + + diff --git a/documentation/18.11/solutions/database-access/eiffelstore/eiffelstore-tutorial/eiffelstore-dataview-cluster.wiki b/documentation/18.11/solutions/database-access/eiffelstore/eiffelstore-tutorial/eiffelstore-dataview-cluster.wiki new file mode 100644 index 00000000..f08e3d57 --- /dev/null +++ b/documentation/18.11/solutions/database-access/eiffelstore/eiffelstore-tutorial/eiffelstore-dataview-cluster.wiki @@ -0,0 +1,432 @@ +[[Property:title|EiffelStore DataView Cluster]] +[[Property:weight|3]] +[[Property:uuid|75f8cc72-7ccf-28a4-f6b2-beeb2219dc43]] +==1. Introduction== + +DataView cluster helps the programmer creating a GUI for a RDBMS. It gives a basic solution for a RDBMS GUI and also enables the developer to customize his GUI from this basic interface. + +This cluster is client of EiffelStore to interface with a RDBMS and EiffelVision2 to create a GUI. However, the use of EiffelStore and EiffelVision 2 is sufficiently encapsulated to let the programmer use other database/graphic libraries. + +Notice finally that DataView is based on some common O-O ''design patterns''. Knowing these patterns will help you understand how the library works. It can also give an example of patterns use. + +==2. Specifications== + +This part draws the main capabilities that can be expected from the DataView cluster. These capabilities are not exhaustive since the cluster architecture enables to add easily new capabilities to it. + +===2.1. Required database structure=== + +The cluster has been designed to work well with relational databases on Third Normal Form. Database tables must also have an unique numeric ID. +* The cluster automatically performs associations between related tables. This is required to work fine with 3rd NF architectures. +* The unique ID enables to update the database content. If you only intend to display database table content, unique IDs are not required. +* The numeric ID enables to directly give IDs to new table rows. If you don't intend to create table rows, this is not necessary. Notice that with only a couple of redefinitions, the numeric ID requirement problem can be overcome. + +===2.2. Database content display=== + +The cluster provides facilities to: +* display a set of table rows. +* select a (current) table row in the set. +* display the current table row so that it can be edited. + +For instance, an interface can display a multi-column list of table rows. A given row can be selected in the list and its information can be then edited through a set of text fields and combo-boxes. + +The standard cluster usage is to define a GUI that will associate a given frame/window to a given database table, that is, the information that is displayed in a GUI area will be determined at compile-time. This enables to adapt the GUI display to the type of information displayed, which is recommended when creating a GUI for non-developer users (or any people that should not be aware of the database structure and functioning). Nevertheless, determining the type of information displayed by a frame/window at runtime is still possible as not hard-coded. + +Abstracting database in the GUI might not be as easy as only changing database attribute fields names. Information to display may not match the database tables structure. However, for consistency reasons, we can assume that he information to display within a GUI area belongs to a set of associated tables. The easiest solution is to create database views that directly contain the information to display on the GUI area. This implies though that the database has to be modified for the GUI needs. + +DataView cluster affords a second solution: +* Model-View separation enables to merge graphically information that is separated in the process part (i.e. that is from a different table). +* Table associations facilities enable to specify to display automatically content of table rows associated to a given table row. For instance, with a CONTACTS table associated to a COMPANIES table, the cluster can retrieve automatically a COMPANIES table row associated to a selected CONTACTS table row. + +===2.3. Actions performed on the database=== + +The cluster provides facilities for the following actions: +* Creating a table row +* Deleting a table row +* Updating the content of a table row +* Selecting a set of table rows + +Other capabilities can be added to these ones, for instance by writing descendants of DataView cluster classes that would handle more database operations. + +Operations relative to the database structure modification, for instance creating a database table, may be more difficult to add since the database structure is hard-coded. But these advanced capabilities might not be necessary in a GUI for non-developer users. + +==3. General description== + +===3.1. Global architecture=== + +The DataView cluster is based on 1 class called [[ref:libraries/store/reference/dv_table_component_chart|DV_TABLE_COMPONENT]] that represents the interface for 1 relational database table. An architecture using ''DataView'' is centered on database table structure rather than the GUI structure. The basic idea is to have: +* 1 database relational table +* 1 GUI window or frame +* 1 [[ref:libraries/store/reference/dv_table_component_chart|DV_TABLE_COMPONENT]] object + +This is then possible to adapt the code to have a GUI meeting the specifications, database structure can be totally abstracted in the interface, which might be more convenient for non-developer GUI users. + +===3.2. Library structure=== + +The cluster can be separated into 3 main parts: +* The '''model''': processes the information and interfaces with an abstract graphic interface (the handle) and an abstract database interface. +* The '''handle''': defines an abstract graphic interface for the model. +* The '''view''': implements the handle interface with EiffelVision2 widgets. + +The abstract database interface is defined in the EiffelStore generation.tables_access cluster. This cluster can indeed been used independently from the DataView cluster. + +===3.3. Model cluster structure=== + +The '''model''' cluster processes the information retrieved from the GUI and the database and update then both GUI and database. + +The cluster is based on the [[ref:libraries/store/reference/dv_table_component_chart|DV_TABLE_COMPONENT]] class which objects represents a database relational table (or view). + +DV_TABLE_COMPONENT objects can be interconnected to match the table associations. The [[ref:libraries/store/reference/dv_table_component_chart|DV_TABLE_COMPONENT]] class has been designed to work with 3rd Normal Form relational databases. [[ref:libraries/store/reference/dv_table_component_chart|DV_TABLE_COMPONENT]] achieves most of the work to retrieve associated table rows for a 3NF database. For instance, when deleting a table row, the component ensures that every associated table row is also deleted. + +[[ref:libraries/store/reference/dv_table_component_chart|DV_TABLE_COMPONENT]] objects can be customized by adding some subcomponents to it. Subcomponents enable to display table rows content on screen, to navigate among table rows and to perform different database queries. + +[[Image:sub-component-objects]] + +Process objects structure for a GUI + +===3.4. Design patterns=== + +This cluster adapts several well-known O-O design patterns. + +====3.4.1. Model-View separation pattern==== + +The GUI appearance is totally abstracted in the GUI processing part, this enables to change the GUI display without changing any part of the model part.This is implemented with 2 sets of classes: +* A set of interfaces that corresponds to each type of abstract widgets needed by the model. +* A set of classes that implements these interfaces. Notice that an implementation class can implement several interfaces and several classes can implement the same interface. + +Let's see an example through a BON diagram: + +[[Image:model-view-relationship]] + +Model-View separation pattern implementation in ''DataView'' +* Light blue classes represents the model cluster. +* Orange class represents the handle. +* Yellow and green classes represents the view cluster. +* Pink classes represents the EiffelVision2 library. + +====3.4.2. Strategy pattern==== + +DataView cluster provides the developer with a basic GUI implementation AND lets them customize their application. This is possible with a strategy pattern: + +The developer assigns different subcomponents to a [[ref:libraries/store/reference/dv_table_component_chart|DV_TABLE_COMPONENT]] object to define its behavior. The component object only uses the interface of each subcomponent. + +A default implementation is written for each interface to let the user use the cluster as quick as possible. To adapt components behavior to their needs, the developer can then create a new subcomponent class inheriting from the abstract interface. + +This BON diagram illustrates this for [[ref:libraries/store/reference/dv_creator_chart|DV_CREATOR]] and [[ref:libraries/store/reference/dv_searcher_chart|DV_SEARCHER]] subcomponents: + +[[Image:dv-table-component-strategy]] + +Strategy pattern used in ''DataView'' model cluster + +==4. Cluster interface== + +This part describes how to use the table component class and its subcomponents classes: +* The [[ref:libraries/store/reference/dv_searcher_chart|DV_SEARCHER]] class to [[#dv_searcher|select table rows from the database]] . +* The [[ref:libraries/store/reference/dv_tablerows_navigator_chart|DV_TABLEROW_NAVIGATOR]] class to [[#dv_tablerow_navigator|navigate among selected table rows]] . +* The [[ref:libraries/store/reference/dv_creator_chart|DV_CREATOR]] class to [[#dv_creator|create new table rows in the database]] . +* The [[ref:libraries/store/reference/dv_tablerow_fields_chart|DV_TABLEROW_FIELDS]] class to [[#dv_tablerow_fields|edit a table row content]] . + +===4.1. DV_TABLE_COMPONENT class=== + +This class is responsible for the management of a database table. Its behavior is determined by its assigned subcomponents. + +To create a valid and functional [[ref:libraries/store/reference/dv_tablerows_component_chart|DV_TABLE_COMPONENT]] object, follow these steps: +# Call set_tablecode to specify which table the component will deal with. +# Specify [[#output_handler|handlers to output messages]] . +# Set the [[#database_handler|database handler]] . +# Add different [[#controllers|controllers corresponding to actions to perform]] . +# Set [[#subcomponents|subcomponents]] . +# Set [[#associated_components|associated components]] . +# Call activate to let the component work. This will basically set different default values for non required information not set during the creation process. + +The component can then be used on an interface: +* Input interactions are done via component and subcomponents controllers (4). +* Output interactions are done via output handlers (2). + +====4.1.1. Output handlers==== + +Output handlers are specific to the [[ref:libraries/store/reference/dv_tablerows_component_chart|DV_TABLE_COMPONENT]] object, that is, you can output messages in a different way within your GUI. However, the same handlers will be used for subcomponents. + +3 handlers can be set: +* `status_handler` to display status information +* `warning_handler` to display warning information. Warnings usually correspond to database errors, they are called warnings because the database error is "caught" and the message should enable the user to round the problem. +* `confirmation_handler` to ask for confirmation before an action. + +These handlers have default values, which are: +* For `status_handler` and `warning_handler`, messages are displayed on standard output (with {ANY}.io.put_string) +* For `confirmation_handler`, action is executed without confirmation. + +====4.1.2. Database handler==== + +This handler is specific to the application. It must inherit from ABSTRACT_DB_TABLE_MANAGER. Since it is specific to the program, it can be set before creating any [[ref:libraries/store/reference/dv_table_component_chart|DV_TABLE_COMPONENT]] object through {DV_DATABASE_HANDLER}.set_database_handler.The [[ref:libraries/store/reference/db_table_manager_chart|DB_TABLE_MANAGER]] class is the default database handler for EiffelStore. + +4.1.3. Action controllers + +No subcomponent is associated to 'write', 'refresh' and 'delete' actions since these actions does not require specific behavioral choices. + +To perform 'write', 'refresh' and 'delete' at runtime, a controller is associated to each of these actions. This controller triggers the action when a determined user event is grabbed, for instance, when the user clicks a button. + +[[#dv_s_control|Controllers]] are implemented by the abstract class [[ref:libraries/store/reference/dv_sensitive_control_chart|DV_SENSITIVE_CONTROL]] of cluster user_interactions (handle). + +====4.1.4. Subcomponents==== + +Subcomponents can be assigned to a table component to specify its behavior to create table rows, select table rows from the database and navigate among selected table rows. A special subcomponent enable to display the ''current'' table row, i.e. the table row that can be edited to update the database. The default behavior for these subcomponents is that the functionality is not available, that is, subcomponents are not mandatory. + +These components share the table component output handlers. They are automatically activated when table component is activated. + +====4.1.5. Associated components==== + +Table components can be associated to reflect relation of database tables represented. Associated table components are organized: +* 1 master component enables to manually select database table rows. +* Slave components automatically select table rows that are associated to the current table row of the master component. + +{{note|Notice that table associations can be '''nested'''. }} + +2 types of associations are possible to reflect table relations: +* The slave table is dependent on the master table (1:N relationship) +* The slave table is necessary for the master table (N:1 relationship) + +Let us see an example with 3 relational tables: + +[[Image:table-objects-associations]] + +Tables architecture and corresponding component objects + +The object architecture leads to a GUI where the user can select a company and see the company country information and contacts in this company. + +Finally, notice that by default slave components have the same output handlers as their master and slave components are activated when the master component is. + +===4.2. DV_SEARCHER class=== + +====4.2.1. Overview==== + +[[ref:libraries/store/reference/dv_searcher_chart|DV_SEARCHER]] is responsible for retrieving table rows from the database. Let us see how it interacts with a table component: + +[[Image:component-search-relation]] + +Basic relationship between table component class and search class +* `display` assigns a set of table rows to the table component. +* `refresh` asks to refresh the table rows from the same database query. + +[[ref:libraries/store/reference/dv_searcher_chart|DV_SEARCHER]] component does not afford an extended interface. This interface is defined in its descendants. The implemented [[ref:libraries/store/reference/dv_searcher_chart|DV_SEARCHER]] descendants are: +* [[ref:libraries/store/reference/dv_typed_searcher_chart|DV_TYPED_SEARCHER]] performs different [[#dv_typed_searcher|basic searches]] used by the cluster. +* [[ref:libraries/store/reference/dv_interactive_searcher_chart|DV_INTERACTIVE_SEARCHER]] enables to create a graphic interface to [[#dv_interactive_searcher|let user set search parameters]] . + +====4.2.2. DV_TYPED_SEARCHER class==== + +This class provides 3 types of searches: +* "Every row" search: every rows of a table are fetched. +* "ID selection" search: the selection is qualified by an ID. +* "Qualified selection" search: the selection is qualified. + +=====4.2.2.1. "Every row" search===== + +Call read to set table rows on the associated table component. + +=====4.2.2.2. "ID selection" search===== + +Call read_from_tablerow to set table rows on the associated table component. Qualification ID is the ID of the table row in parameter. Table of row in parameter must be the table of rows to select. + +This capability is used by DataView cluster in [[ref:libraries/store/reference/dv_choice_creator_chart|DV_CHOICE_CREATOR]] to select a just-created table row and display it on the table component. + +=====4.2.2.3. "Qualified selection" search===== + +Call read_from_table row to set table rows on the associated table component. Table of row in parameter may not be the table of rows to select. + +To extract the qualifier, the search component needs additional information: +* The location of the qualifying value in the table row passed in parameter (set_row_attribute_code) +* The qualifying attribute location in the table rows to select (set_criterion) + +This capability is used in [[ref:libraries/store/reference/dv_tablerows_component_chart|DV_TABLE_COMPONENT]] when a table row is selected to set associated table rows to slave components. Take a look at add_necessary_table and add_dependent_table. + +====4.2.3. DV_INTERACTIVE_SEARCHER class==== + +This class enables to create a graphic interface to let user perform basic searches. These searches are qualified by one table attribute. This interface has 5 parts: +* A [[#dv_s_control| controller]] that enables to launch the search +* A [[#dv_s_string| text input field]] to set qualifying attribute +* A [[#dv_s_string| text input field]] to set qualifying value +* A [[#dv_s_integer| typed input field]] to set qualification type +* A [[#dv_s_check| Boolean input field]] to set case sensitivity + +Text input fields correspond to handle class [[ref:libraries/store/reference/dv_sensitive_string_chart|DV_SENSITIVE_STRING]] , typed input fields corresponds to handle class [[ref:libraries/store/reference/dv_sensitive_integer_chart|DV_SENSITIVE_INTEGER]] and Boolean input fields corresponds to handle class [[ref:libraries/store/reference/dv_sensitive_check_chart|DV_SENSITIVE_CHECK]] . + +===4.3. DV_TABLEROW_NAVIGATOR class=== + +====4.3.1. Overview==== + +Table component class contains a set of table rows. This class lets table component class know which of these rows is the current one. + +[[Image:component-navigate-relation]] + +Basic relationship between table component class and navigation class + +[[ref:libraries/store/reference/dv_choice_creator_chart|DV_CHOICE_CREATOR]] also uses the class to enable to select associated table rows when creating a new table row (for instance, when creating a company, an existing country should be selected). Let us see how this is designed: + +[[Image:dv-tablerows-navigator-clients]] + +DV_TABLEROWS_NAVIGATOR clients + +{{note|DV_TABLEROWS_COMPONENT class merely carries a set of table rows and enables to select one table row. }} + +DV_CONTROL_NAVIGATOR affords a way to navigate among searched table rows. + +====4.3.2. DV_CONTROL_NAVIGATOR class==== + +This class enables 2 navigation systems: +* Navigating among table rows with "previous" and "next" controllers. +* Navigating among table rows through a display list. + +{{tip|Notice that both systems can be used. }} + +You can directly set [[#dv_s_control| controllers]] for "previous" and"next" actions. A 3rd controller, "edit list", enables to show or raise the display list. + +{{caution|Notice that DV_CONTROL_NAVIGATOR only manages this controller sensitivity. }} + +You can assign a [[#dv_tablerow_list| display list]] to the navigator with a [[ref:libraries/store/reference/dv_tablerow_list_chart|DV_TABLEROW_LIST]] component. + +===4.4. DV_CREATOR class=== + +====4.4.1. Overview==== + +This class enables to create database table rows. + +[[Image:component-create-relation]] + +Basic relationship between table component class and navigation class + +[[ref:libraries/store/reference/dv_creator_chart|DV_CREATOR]] class contains minimum information to interact with [[ref:libraries/store/reference/dv_tablerows_component_chart|DV_TABLE_COMPONENT]] : when a table row is created, a creator component may display it on the table component. In this case, when the table component needs to refresh the table rows set, this refreshing action need to be managed by the creator component: +* `set_just_created` informs a table component that displayed table row set comes from the creator component. +* `refresh` lets the creation component refresh table component display. + +Much of the work, that is row creation, is totally abstracted in DV_CREATOR.DV_CHOICE_CREATOR implements DV_CREATOR and thus affords a creation procedure. + +====4.4.2. DV_CHOICE_CREATOR class==== + +=====4.4.2.1. Overview===== + +This class creates a new table row and sets its key values: +* Database handle gives the primary key value (ID) . +* The class asks the user for foreign key values (for table associations) by displaying available values in a list. + +DV_TABLEROW_NAVIGATOR is used to select a foreign key value, let us see how this is implemented: + +[[Image:dv-choice-creator-fkeys-selection]] + +[[ref:libraries/store/reference/dv_choice_creator_chart|DV_CHOICE_CREATOR]] suppliers for foreign keys selection + +[[ref:libraries/store/reference/dv_tablerow_id_provider_chart|DV_TABLEROW_ID_PROVIDER]] inherits from [[ref:libraries/store/reference/dv_tablerows_component_chart|DV_TABLEROWS_COMPONENT]] to interface with [[ref:libraries/store/reference/dv_tablerows_navigator_chart|DV_TABLEROWS_NAVIGATOR]] . + +Relation between [[ref:libraries/store/reference/dv_choice_creator_chart|DV_CHOICE_CREATOR]] and [[ref:libraries/store/reference/dv_tablerow_id_provider_chart|DV_TABLEROW_ID_PROVIDER]] is basically: + +[[Image:creator-provider-relation]] + +DV_CHOICE_CREATOR/DV_TABLEROW_ID_PROVIDER basic interactions + +Creation process and [[ref:libraries/store/reference/dv_choice_creator_chart|DV_CHOICE_CREATOR]] objects creation procedure can help you use this class. + +=====4.4.2.2. Creation process===== + +Table row creation process is: +# Table row creation is triggered by a [[#dv_s_control| controller]] ("create") +# DV_CHOICE_CREATOR creates a table row object +# DV_CHOICE_CREATOR requests a first foreign key value to [[ref:libraries/store/reference/dv_tablerow_id_provider_chart|DV_TABLEROW_ID_PROVIDER]] (through `select_from_table`) +# DV_TABLEROW_ID_PROVIDER loads the available table rows that can be referenced +# DV_TABLEROW_ID_PROVIDER assigns the table rows to DV_TABLEROWS_NAVIGATOR and pops up the interface with the table rows +# Table row selection is triggered by a [[#dv_s_control| controller]] ("ok") +# DV_TABLEROW_ID_PROVIDER retrieves the selected table row ID and gives it back to DV_CHOICE_CREATOR (through `add_foreign_key_value`) +# DV_CHOICE_CREATOR requests other foreign key values to DV_TABLEROW_ID_PROVIDER +# DV_CHOICE_CREATOR creates the database row with a new ID through the database handle + +=====4.4.2.3. Objects creation procedure===== + +To create a DV_CHOICE_CREATOR, follow these steps: +# Create an object conforming to DV_TABLEROWS_NAVIGATOR +# Create a DV_TABLEROW_ID_PROVIDER object and assign the DV_TABLEROWS_NAVIGATOR object to it +# Set a [[#dv_s_control| controller]] to trigger foreign key selection +# Set the action to perform to pop up the interface to select the foreign key +# Create a DV_CHOICE_CREATOR object and assign the DV_TABLEROW_ID_PROVIDER object to it +# Set a [[#dv_s_control| controller]] to trigger table row creation + +===4.5. DV_TABLEROW_FIELDS class=== + +====4.5.1. Overview==== + +This class enable to display and edit the current table row of a table component. Let us see first how it interacts with the table component: + +[[Image:component-fields-relation]] + +DV_TABLE_COMPONENT/DV_TABLEROW_FIELDS basic interactions +* refresh_tablerow refreshes display with a new table row +* update_tablerow requests an updated table row for database update. Unchanged values are kept from a default table row +* updated_tablerow is the last updated table row + +The class contains a list of fields that represent editable table attributes.The design is simple: + +[[Image:dv-tablerow-fields-design]] + +Table row edition capability design + +====4.5.2. DV_TABLEROW_FIELD class==== + +This class enables to edit a table row attribute value. The view is abstracted using the handle cluster [[ref:libraries/store/reference/dv_sensitive_string_chart|DV_SENSITIVE_STRING]] class that [[#dv_s_string|represents the editable text value]] . + +This class manages a field value but can also provide field name and type if [[#dv_s_string|graphic fields]] are provided. Notice that standard [[ref:libraries/store/reference/dv_tablerow_field_chart|DV_TABLEROW_FIELD]] objects can be generated through the [[ref:libraries/store/reference/dv_factory_chart|DV_FACTORY]] class, which is a component factory. + +==5. Handle cluster== + +This cluster provides the model with an interface to input or output data on the GUI. This enables to remove any link to a graphic implementation in the model, following the [[#model-view_sep|Model-View separation]] design pattern. The cluster contains a set of interface classes to design this: +* The [[ref:libraries/store/reference/dv_sensitive_control_chart|DV_SENSITIVE_CONTROL]] class to [[#dv_s_control|let the user trigger an action]] . +* The [[ref:libraries/store/reference/dv_sensitive_string_chart|DV_SENSITIVE_STRING]] class to [[#dv_s_string|input or output a text value]] . +* The [[ref:libraries/store/reference/dv_sensitive_string_chart|DV_SENSITIVE_INTEGER]] class to [[#dv_s_integer|input or output a quantity value]] . +* The [[ref:libraries/store/reference/dv_sensitive_check_chart|DV_SENSITIVE_CHECK]] class to [[#dv_s_check|input or output a tag value]] . +* The [[ref:libraries/store/reference/dv_tablerow_list_chart|DV_TABLEROW_LIST]] class to [[#dv_tablerow_list|display a set of table rows and grab events on it]] . + +===5.1. DV_SENSITIVE_CONTROL class=== + +The [[ref:libraries/store/reference/dv_sensitive_control_chart|DV_SENSITIVE_CONTROL]] class lets a model class trigger a specific action on a determined user event. Furthermore, the model class lets the user know when its state enables to trigger the action, by setting the controller sensitivity (i.e. if the controller is insensitive, the action cannot be triggered). + +{{note|sensitivity excepted, these controllers could have been implemented by Eiffel ''agents''. }} + +{{note|sensitivity enables to let the user know ''before''triggering an action if this is possible or not. The other possibility is to let the user know ''after'' trying to trigger the action that it was not possible(with a warning for instance): this is often less convenient. }} + +The standard controllers are buttons or menu items: the specific action is triggered when button is clicked or menu item selected. + +[[ref:libraries/store/reference/dv_sensitive_control_chart|DV_SENSITIVE_CONTROL]] is inherited by [[ref:libraries/store/reference/dv_button_chart|DV_BUTTON]] that implements an EiffelVision2 button. Other implementations can be added, such as a menu item. + +===5.2. DV_SENSITIVE_STRING class=== + +The [[ref:libraries/store/reference/dv_sensitive_string_chart|DV_SENSITIVE_STRING]] class lets a model class input or output a text graphically. As for controllers, the model class lets the user know when a text value can be input by setting the widget sensitivity. + +The standard graphical widgets to perform this are text fields, but several other widgets can be used: +* A combo-box so that the interface can suggest different values. +* A label if the text only need to be output. + +{{note|customized, specific widgets can be defined, you can for instance take a look at the DV_STRING_LIST class. }} + +===5.3. DV_SENSITIVE_INTEGER class=== + +This class lets a model class input or output an INTEGER value graphically. As for controllers, the model class lets the user know when an integer value can be input by setting the widget sensitivity. + +Different widgets can be used to implement this: +* A text field. Notice that the value entered should be checked to ensure it is an INTEGER value. +* A combo-box. Each combo-box option is associated to an integer. +* A scroll button. + +===5.4. DV_SENSITIVE_CHECK class=== + +This class lets a model class input or output a BOOLEAN value graphically. As for controllers, the model class lets the user know when a Boolean value can be input by setting the widget sensitivity. + +The standard widget to implement this is a check box. + +===5.5. DV_TABLEROW_LIST class=== + +The [[ref:libraries/store/reference/dv_tablerow_list_chart|DV_TABLEROW_LIST]] class provides an interface to display a set of table rows so that the user can select a particular row. +* The model can be informed of a row selection or deselection: the class accepts actions (implemented by ''agents'') that are triggered when a row is selected or deselected. +* The model can retrieve the currently selected row: the class yields the current index position in the list. + +[[ref:libraries/store/reference/dv_tablerow_multilist_chart|DV_TABLEROW_MULTILIST]] implements DV_TABLEROW_LIST with an EiffelVision2 multi-column list. + +{{note|This class is used for the [[#dv_control_navigator|standard implementation]] of [[ref:libraries/store/reference/dv_tablerows_navigator_chart|DV_TABLEROW_NAVIGATOR]] to [[#dv_tablerow_navigator|navigate among table rows]] selected from the database. }} + + + + diff --git a/documentation/18.11/solutions/database-access/eiffelstore/eiffelstore-tutorial/eiffelstore-generation-cluster/data-structures-creation.wiki b/documentation/18.11/solutions/database-access/eiffelstore/eiffelstore-tutorial/eiffelstore-generation-cluster/data-structures-creation.wiki new file mode 100644 index 00000000..368250ce --- /dev/null +++ b/documentation/18.11/solutions/database-access/eiffelstore/eiffelstore-tutorial/eiffelstore-generation-cluster/data-structures-creation.wiki @@ -0,0 +1,653 @@ +[[Property:modification_date|Wed, 26 Sep 2018 16:39:34 GMT]] +[[Property:publication_date|Wed, 26 Sep 2018 16:04:05 GMT]] +[[Property:title|Data structures creation]] +[[Property:weight|1]] +[[Property:uuid|d8845cb9-2581-f85d-aad1-460816711356]] +==1. Overview== +{{Warning|The wizard is not delivered anymore}} + +EiffelStore enables to create data structures mapped to your own database. This part describes how the EiffelStore wizard generates these structures mapped to your database and how you can map your own classes to your database with EiffelStore. + +'''Tip:''' We recommend that you read [[Data structures use|what are and how to use]] these data structures before reading this section. + +The EiffelStore wizard generates the database-specific classes from an EiffelStore generation system based on template files containing tags. + +Let us see first [[#generation_system| how the EiffelStore generation system works]] . Let us see then [[#wizard_generation| how the EiffelStore wizard uses this system]] for the data structures generation. + +==2. EiffelStore generation system== + +This part describes the class creation in 4 steps: +* [[#capabilities|Mapping system possibilities]] +* [[#mapping_system|General mapping system]] +* [[#tags_descr|Tags description]] +* [[#gen_impl_overview|Implementation overview]] + +===2.1. Capabilities=== + +Let us see first what information you can map into your classes. +2 kinds of classes can be generated: +* Classes that represents a database table. +* Classes that represents the whole database. + +====2.1.1. Database table classes==== + +You can insert information about a database table: +* The table name +* The number of attributes of table + +You can also select a piece of code, map it to a table attribute and repeat the operation for every attribute. Information that can be inserted is: +* The attribute names +* The attribute types +* The attribute default creation values +* The attribute positions in the table + +Thus you can get for instance class attributes that correspond to database attributes: + + + class CONTACTS + + feature + + id: INTEGER + + lastname: STRING + + firstname: STRING + + + +You can also modify the piece of code to map for the first and last attributes, for cosmetics reasons. You can also choose to only map a piece of code to attributes of a given type. + +====2.1.2. Database content classes==== + +Database content classes can basically store the list of your database tables. + +You can select a piece of code and map it to database table information: +* Database table name. +* Database table position in the database. + +The mapped pieces of code are then concatenated in your file. + +===2.2. General mapping system=== + +EiffelStore follows this sequence of steps to generate a class: +# You provide meta-data about the table or view +# You provide the template +# It parses the template to find the tags +# It replaces each tag by the meta-data value corresponding to the tag + +Let us take an example: +{| border="1" +|- +| template file extract +| corresponding result file extract +|- +| attribute_count: +| attribute_count: 5 +|} + +This works for meta-data on the class or view. For meta-data on class (or view) attributes, a second tag type enables to specify text areas that are mapped to specific table (or view) attributes. + +Let us take an example: +{| border="1" +|- +| template file extract +| corresponding result file extract +|- +| :
+| companyid: DOUBLE
companyname: STRING +|} + +Text contained in the tag 'A' is mapped to each table (or view) attribute and the resulting texts are concatenated. Let us see now the details about each tag. + +===2.3. Tags description=== + +====2.3.1. Database table tags description==== + +The available tags for database table classes generation can be separated into 3 types: +* Tags corresponding to [[#table_meta-data|table meta-data]] +* Tags corresponding to [[#attribute_meta-data|attribute meta-data]] +* Tags to [[#enclosing_tag|enclose attribute meta-data]] + +=====2.3.1.1. Table meta-data tags===== +{| border="1" +|- +| '''Tag name''' +| '''Tag description''' +| '''Options''' +|- +| '''Option name''' +| '''Option description''' +|- +| +| Table name +| U +| in uppercase +|- +| I +| with initial capital +|- +| L +| in lowercase +|- +| +| Attribute count +| N/A +|} + +=====2.3.1.2. Attribute meta-data tags===== +{| border="1" +|- +| '''Tag name''' +| '''Tag description''' +| '''Options''' +|- +| '''Option name''' +| '''Option description''' +|- +| +| Attribute name +| U +| in uppercase +|- +| I +| with initial capital +|- +| L +| in lowercase +|- +| +| Attribute position in the table +| N/A +|- +| +| Attribute type name +| U +| in uppercase +|- +| I +| with initial capital +|- +| L +| in lowercase +|- +| +| Attribute type default value +| N/A +|} + +'''Note''': Attribute tags are only valid within an enclosing tag. + +=====2.3.1.3. Enclosing tags===== + +The tag encloses text that will be mapped to attributes matching criteria. These criteria are specified by the tag options: +* First option: attribute type criterion +{| border="1" +|- +| '''Option name''' +| '''Option description''' +|- +| A +| All attributes +|- +| I +| INTEGER attributes +|- +| S +| STRING attributes +|- +| D +| DATE attributes +|- +| B +| BOOLEAN attributes +|- +| C +| CHARACTER attributes +|- +| F +| DOUBLE attributes +|} + +* Second option: attribute position criterion +{| border="1" +|- +| '''Option name''' +| '''Option description''' +|- +| A +| All attributes +|- +| F +| First attribute +|- +| I +| Intermediate attributes +|- +| L +| Last attribute +|} + +* '''Note''': this option is generally used to have a valid and nice layout or indentation. + +'''Note''': several options can be selected for one criterion. + +====2.3.2. Database content tags description==== + +The tags described above can be reused for database content:database content class mapping is equivalent to the previous mapping but within a different scope: +* class corresponds to the database rather than tables +* class content deals with tables rather than table attributes + +The meaning of available tags is so modified: +* [[#system_meta-data_ext|System meta-data tags]] +* [[#table_meta-data_ext| Table meta-data tags]] +* [[#enclosing_tag_ext| Enclosing tags]] + +'''Note''': every tag is not available for this mapping. + +=====2.3.2.1. System meta-data tags===== +{| border="1" +|- +| '''Tag name''' +| '''Tag description''' +|- +| +| Table count +|} + +=====2.3.2.2. Table meta-data tags===== +{| border="1" +|- +| '''Tag name''' +| '''Tag description''' +| '''Options''' +|- +| '''Option name''' +| '''Option description''' +|- +| +| Table name +| U +| in uppercase +|- +| I +| with initial capital +|- +| L +| in lowercase +|- +| +| Table position in the database +| N/A +|} + +=====2.3.2.3. Enclosing tags===== + +The tag encloses text that will be mapped to tables matching a position criterion. This criterion is specified by the tag options: +{| border="1" +|- +| '''Option name''' +| '''Option description''' +|- +| A +| All tables +|- +| F +| First table +|- +| I +| Intermediate tables +|- +| L +| Last table +|} + +===2.4. Implementation overview=== + +The data structure generation system is implemented with 4 EiffelStore classes: +* DB_CLASS_GENERATOR abstractly generates a class mapped to database meta-data. +* DB_TABLE_CLASS_GENERATOR generates a class mapped to a database table. +* DB_ACCESS_CLASS_GENERATOR generates a class mapped to the database. +* DB_TEMPLATE_TAGS defines available tags for mapping and their meaning. + +[[Image:estore-generation.generator]] + +Generation classes BON diagram + +==3.EiffelStore wizard== + +{{Warning|The wizard is not delivered anymore}} + +The EiffelStore wizard uses the [[#generation_system| EiffelStore generation system]] described above to generate the data structures mapped to your database. + +The wizard generates 3 types of classes: +* [[#wiz_table_classes|Classes storing database table rows content]] +* [[#wiz_descr_classes|Classes describing a database table]] +* [[#wiz_access_class|A class describing the database and giving access to the previous types of classes]] + +The wizard uses one different template for each class. +===3.1. Table classes=== + +For each selected database table, a class is created from the same template, mapping the database table. This template is: + + indexing + description: "Class which allows EiffelStore to retrieve/store% + %the content of a table row from database table " + author: "EiffelStore Wizard" + date: "$Date: 2004-12-09 23:29:16 +0100 (Thu, 09 Dec 2004) $" + revision: "$Revision: 46989 $" + + class + + + inherit + DB_TABLE + -- redefine + -- out + -- end + undefine + Tables, + is_valid_code + end + + DB_SPECIFIC_TABLES_ACCESS_USE + + create + make + + feature -- Access + + : + + table_description: DB_TABLE_DESCRIPTION is + -- Description associated to the . + do + tables._description.set_ (Current) + Result := tables._description + end + + feature -- Initialization + + set_default is + do + := + + end + + feature -- Basic operations + + set_ (a_: ) is + do + := a_ + end + + feature -- Output + + out: STRING is + -- Printable representation of current object. + do + Result := "" + + if /= Void then + Result.append (": " + .out + "%N") + end + + end + + end -- class CODES + + + +'''Note''': the template content can be adjusted, for instance to add comments or change the indexing. However, the fundamental template structure should not be changed to use data structures as described in the [[Data structures use|corresponding section]] . + +===3.2. Description classes=== + +For each selected database table, a class is also created from a unique template, mapping the database table. This template is: + + indexing + description: "Description of class " + author: "EiffelStore Wizard" + date: "$Date: 2004-12-09 23:29:16 +0100 (Thu, 09 Dec 2004) $" + revision: "$Revision: 46989 $" + + class + _DESCRIPTION + + inherit + DB_TABLE_DESCRIPTION + -- rename + -- Tables as Abstract_tables + undefine + Tables, + is_valid_code + end + + DB_SPECIFIC_TABLES_ACCESS_USE + + create + {DB_SPECIFIC_TABLES_ACCESS} make + + feature -- Access + + Table_name: STRING is "" + + Table_code: INTEGER is + + Attribute_number: INTEGER is + -- Number of attributes in the table. + + Id_code: INTEGER is + -- Table ID attribute code. + do + Result := + end + + : INTEGER is + + attribute_code_list: ARRAYED_LIST [INTEGER] is + -- Feature code list + once + create Result.make (Attribute_number) + Result.extend () + end + + description_list: ARRAYED_LIST [STRING] is + -- Feature name list. Can be interpreted as a list + -- or a hash-table. + once + create Result.make (Attribute_number) + Result.extend ("") + end + + type_list: ARRAYED_LIST [INTEGER] is + -- Feature type list. Can be interpreted as a list + -- or a hash-table. + once + create Result.make (Attribute_number) + Result.extend (_type) + end + + to_delete_fkey_from_table: HASH_TABLE [INTEGER, INTEGER] is + -- List of tables depending on this one and their + -- foreign key for this table. + -- Deletion on this table may imply deletions on + -- depending tables. + once + end + + to_create_fkey_from_table: HASH_TABLE [INTEGER, INTEGER] is + -- List of associated necessary tables and the + -- linking foreign keys. + -- Creation on this table may imply creations on + -- associated necessary tables. + once + end + + attribute (i: INTEGER): ANY is + -- Get feature value of feature whose code is 'i'. + do + inspect i + + when then + Result := . + + end + end + + set_attribute (i: INTEGER; value: ANY) is + -- Set feature value of feature whose code is `i' to `value'. + -- `value' must be of type STRING, INTEGER, BOOLEAN, CHARACTER, + -- DOUBLE or DATE_TIME. References are made automatically from + -- expanded types. + local + integer_value: INTEGER_REF + double_value: DOUBLE_REF + boolean_value: BOOLEAN_REF + character_value: CHARACTER_REF + date_time_value: DATE_TIME + string_value: STRING + do + inspect i + + when then + string_value ?= value + .set_ (string_value) + when then + double_value ?= value + if double_value /= Void then + .set_ (double_value.item) + else + .set_ (0.0) + end + + when then + integer_value ?= value + if integer_value /= Void then + .set_ (integer_value.item) + else + .set_ (0) + end + + when then + date_time_value ?= value + .set_ (date_time_value) + + when then + character_value ?= value + if character_value /= Void then + .set_ (character_value.item) + else + .set_ ('%U') + end + + when then + boolean_value ?= value + if boolean_value /= Void then + .set_ (boolean_value.item) + else + .set_ (False) + end + + end + end + + feature {} -- Basic operations + + set_ (a_: ) is + -- Associate the description to a piece of . + require + not_void: a_ /= Void + do + := a_ + ensure + = a_ + end + + feature {NONE} -- Implementation + + : + -- Piece of associated with the description + + end -- class CODES_DESCRIPTION + + +'''Note''': As for the table class generation, the template content can be adjusted, for instance to add comments or change the indexing. However, the fundamental template structure should not be changed. + +Some additional tags are directly replaced by the wizard: +* The and tags are replaced with information on associated tables. +* The tag is replaced by information on the primary key (table ID). +* The tag is replaced by the table position in the database. + +===2.3.3. Access class=== + +The DB_SPECIFIC_TABLES_ACCESS class is mapped to the database from the following template: + + indexing + description: "Description of database tables.% + %Use this class through DB_SPECIFIC_TABLES_ACCESS_USE." + author: "EiffelStore Wizard" + date: "$Date: 2004-12-09 23:29:16 +0100 (Thu, 09 Dec 2004) $" + revision: "$Revision: 46989 $" + + class + DB_SPECIFIC_TABLES_ACCESS + + inherit + DB_TABLES_ACCESS + + creation + make + + feature -- Access + + : INTEGER is + + Table_number: INTEGER is + + code_list: ARRAYED_LIST [INTEGER] is + -- Table code list. + once + create Result.make (Table_number) + Result.extend () + end + + name_list: ARRAYED_LIST [STRING] is + -- Table name list. Can be interpreted as a list + -- or a hash-table. + once + create Result.make (Table_number) + Result.extend ("") + end + + obj (i: INTEGER): DB_TABLE is + -- Return instance of table with code `i'. + do + inspect i + + when then + create {} Result.make + + end + end + + description (i: INTEGER): DB_TABLE_DESCRIPTION is + -- Return description of table with code `i'. + do + inspect i + + when then + Result := _description + + end + end + + _description: _DESCRIPTION is + -- Unique description of table `'. + once + create Result.make + end + + + + end -- class DB_SPECIFIC_TABLES_ACCESS + diff --git a/documentation/18.11/solutions/database-access/eiffelstore/eiffelstore-tutorial/eiffelstore-generation-cluster/data-structures-use.wiki b/documentation/18.11/solutions/database-access/eiffelstore/eiffelstore-tutorial/eiffelstore-generation-cluster/data-structures-use.wiki new file mode 100644 index 00000000..94cc9e12 --- /dev/null +++ b/documentation/18.11/solutions/database-access/eiffelstore/eiffelstore-tutorial/eiffelstore-generation-cluster/data-structures-use.wiki @@ -0,0 +1,223 @@ +[[Property:title|Data structures use]] +[[Property:weight|0]] +[[Property:uuid|25885469-d6c8-5d1c-bbf8-c5fca5524d36]] +==1. Overview== + +EiffelStore affords a context that optimizes and facilitates the use of the classes that maps your database content. + +The main advantage of database-specific structures is the static checking: you can determine at compile-time the type of information you are accessing or modifying. + +However, it can be more flexible to determine the type of data you are dealing with at run-time. This can be particularly useful for GUI applications, take a look at the [[EiffelStore DataView Cluster|DataView cluster]] . + +Each data structure carries some meta-data about its type so that the run-time typing hazards can be avoided with assertions based on this meta-data. + +The advantage of this system is two-fold: +* You can choose to use compile-time type checking or not, depending on your own needs. +* If you choose run-time type checking, assertions ensure that each object type is valid and prevent cat calls. + +Let us see first [[#capabilities|what you can do]] with data structures and their context, then [[#implementation|how it is implemented]] . + +==2. Data structure capabilities== + +Database-specific classes and their context let you perform the following operations: +* [[#cap_storage|Storing table/view rows content]] +* [[#cap_manipulation|Manipulating abstract table/view rows content]] +* [[#cap_objects_metadata|Getting objects metadata]] +* [[#cap_database_metadata|Accessing database metadata]] +* [[#cap_more|More interesting features]] + +===2.1. Storing table/view rows content=== + +You can store table/view rows content into classes that have the table or view name: one database table/view row correspond to one Eiffel object. Each table attribute will correspond to a class attribute with the same name. ''set'' commands enable to change the object content to insert rows in the database or update rows. [[ref:libraries/store/reference/db_selection_flatshort|DB_SELECTION]] class can directly map database results into these objects, and you can directly create a table/view row from one object with the [[ref:libraries/store/reference/db_store_flatshort|DB_STORE]] class. Take a look at the [[Data Object Coupling|data-object coupling]] section. + +===2.2. Manipulating abstract table/view rows content=== + +Each table/view storage structure inherits from the [[ref:libraries/store/reference/db_table_flatshort|DB_TABLE]] abstract class. This enables to handle [[ref:libraries/store/reference/db_table_flatshort|DB_TABLE]] objects as abstract database table/view structures. + +You can then access or modify [[ref:libraries/store/reference/db_table_flatshort|DB_TABLE]] attributes: instead of accessing attributes with their ''name'', which implies that the object type is known at compile-time, attributes can then be accessed with a ''code''. + + tablerow: DB_TABLE + ... + display_attribute (code: INTEGER) + -- Display attribute with `code'. + do + io.putstring (tablerow.table_description.attribute (code).out) + end + + +{{note|to access attributes data with ''code'', you need to use the [[ref:libraries/store/reference/db_table_description_flatshort|DB_TABLE_DESCRIPTION]] object associated to your [[ref:libraries/store/reference/db_table_flatshort|DB_TABLE]] object. }} + +===2.3. Getting objects metadata=== + +While manipulating DB_TABLE objects, you can easily get: +* Which database table/view the object references. +* What are the types of its attributes. + +'''Note:''' you also get objects metadata through the DB_TABLE_DESCRIPTION object associated to your DB_TABLE object. +Objects metadata used in assertions ensures objects type validity. To illustrates this, let's look at the contract form of a class that manipulates "abstract" table/view rows: + + set_table_code (code: INTEGER) + -- Assign `code' to `tablecode'. + + tablecode: INTEGER + -- Table code. + + compute (tablerow: DB_TABLE) + -- Compute `tablerow'. + require + type_is_ok: tablerow.table_description.Table_code = tablecode + + +===2.4. Accessing database metadata=== + +Basic database metadata is also available: the DB_SPECIFIC_TABLES_ACCESS_USE class (generated), stores INTEGER codes for each database table/view. These codes afford related table/view name and related new storing objects (i.e. that conforms to DB_TABLE class). + + tables: DB_SPECIFIC_TABLES_ACCESS + ... + new_object (code: INTEGER): DB_TABLE + -- New object of table with `code'. + do + Result := tables.obj (code) + end + + +===2.5. More interesting features=== + +The DB_TABLE_DESCRIPTION class offers more features to get table row attributes as conveniently as possible: +* The table/view row primary key value (ID) +* The list of table/view row attributes +* A selection of table/view row attributes +* The list of table/view row attributes mapped to a function. +* Printable attribute values (i.e. the associated STRING values) + +==3. Implementation== + +Database-specific classes can be divided into 3 types: +* Classes holding database table rows content (inheriting from DB_TABLE) +* Classes describing database tables (inheriting from DB_TABLE_DESCRIPTION) +* A class describing the database and giving access to the previous types of classes (inheriting from DB_TABLES_ACCESS) + +One database table is hence associated to one table class and one description class. Both classes are closely [[#table-descr_relationship| interrelated]] to provide what the developer need. The [[#table_access_classes|table access classes]] describes the database tables and gives access to both table and description classes. + +Each database-specific (generated) class inherits from an abstract class. These abstract classes gathers all the facilities that are not specific to your database, and so that can be inherited by all the database-specific classes. + +Let us see abstract and database-specific classes relationship: + +[[Image:tables-access-inherit]] + +General and generated classes relationships +* Yellow classes are abstract. +* Green classes are database-specific. + +==2. Table and description classes relationship== + +Table classes, that inherit from DB_TABLE, and description classes, that inherit from DB_TABLE_DESCRIPTION, both deals with database tables. This section explains what are their own role and their relationship. + +===2.1. Table classes=== + +As seen in the previous section, table classes merely store table rows attribute values. Their objects can be considered as database table rows, or more precisely, database table rows on the Eiffel side. These classes inherit from DB_TABLE. + +Each of these classes are associated to a description class. + +'''Tip:''' Use table classes to ''carry'' data. + +===2.2. Description classes=== + +The description classes goal is 3-fold: +* [[#cap_objects_metadata|Getting meta-data]] about the table represented at run-time. +* [[#cap_manipulation|Getting table rows data]] dynamically. +* [[#cap_more|Facilitating data management]] . + +These descriptions inherit from [[ref:libraries/store/reference/db_table_description_flatshort|DB_TABLE_DESCRIPTION]] . + +Since they only describes a table and provide tools, description objects can be unique. EiffelStore ensures their unicity for resources optimization. + +'''Tip:''' Use description classes to ''access and modify'' data. + +===2.3. Relationship=== + +Each table class is associated to the description class corresponding to the same database table. + +A table class object provides the associated table description: + + + row: DB_TABLE + description: DB_TABLE_DESCRIPTION + ... + row := db_manager.database_result + description := row.table_description + + +As descriptions are unique, every table row object is associated to the same description. The following figure illustrates this: +[[Image:table-descr-objects]] + +table and description objects relationship + +As seen in the previous section, to manipulate abstract table/view rows content, you have to use the description class. The following example shows how to output a table row ID value. + + + row: DB_TABLE + description: DB_TABLE_DESCRIPTION + ... + -- Link description unique object to `row' content. + description := row.table_description + io.putstring (description.attribute (description.id_name) + ": ") + io.putstring (description.attribute (description.id_code).out) + + + +As descriptions are unique, this means that description objects are also associated to a specific table object to deal with it (i.e. access or modify its content). Actually, the table_description feature associates the description with the current object and then returns this description. + +{{note|The table_description feature is still a query as the association part should not be visible at the interface level. }} + +On the whole, you have to pay attention to always execute table_descriptionon your table/view row to get the appropriate description. + +==3. Table access classes== + +===3.1. Overview=== + +Table access classes provide facilities to manage table row and table description objects. They also give basic database table meta-data. + +The following figure shows table access classes and their relations. +* Yellow classes are EiffelStore classes +* Green class is generated +* Pink class is an application class + +[[Image:db-specific-tables-access-use]] + +Table access classes BON diagram + +[[Image:table-descr-access-objects]] + +Relationship between the tables access object, description and table objects + +===3.2. DB_SPECIFIC_TABLES_ACCESS class=== + +The DB_SPECIFIC_TABLES_ACCESS class stores the unique table description object. It also provides the following facilities: +* Every database table code +* Table descriptions from a table code +* Sample table class objects from a table code +* Table names from a table code + +'''Note''': database table codes given in the class match the table codes provided by DB_TABLE_DESCRIPTION. + +===3.3. Abstract access class=== + +The DB_TABLES_ACCESS class provides an interface for the DB_SPECIFIC_TABLES_ACCESS class which is non-specific to the database. This can be used by non database-specific code (for instance the [[EiffelStore DataView Cluster|DataView cluster]] ) to access database tables. + +Unique table description objects and table codes are of course not directly available from this class, but the following features are still available: +* Table descriptions from a table code +* Sample table class objects from a table code +* Table names from a table code + +===3.4. Use classes=== + +The DB_SPECIFIC_TABLES_ACCESS object can be accessed as a kind of "global variable" by any class which inherits from DB_SPECIFIC_TABLES_ACCESS_USE. This class also ensures DB_SPECIFIC_TABLES_ACCESS object unicity. + +The DB_TABLES_ACCESS_USE class affords the same possibility but with no reference to the DB_SPECIFIC_TABLES_ACCESS object. The unique DB_SPECIFIC_TABLES_ACCESS should be set to this class as of type DB_TABLES_ACCESS. +
+ + + + + diff --git a/documentation/18.11/solutions/database-access/eiffelstore/eiffelstore-tutorial/eiffelstore-generation-cluster/index.wiki b/documentation/18.11/solutions/database-access/eiffelstore/eiffelstore-tutorial/eiffelstore-generation-cluster/index.wiki new file mode 100644 index 00000000..330bcd9b --- /dev/null +++ b/documentation/18.11/solutions/database-access/eiffelstore/eiffelstore-tutorial/eiffelstore-generation-cluster/index.wiki @@ -0,0 +1,12 @@ +[[Property:title|EiffelStore Generation Cluster]] +[[Property:weight|2]] +[[Property:uuid|f443ed73-14bb-9a3a-b7c7-35c2660e7784]] +The EiffelStore library lets the user associate database elements with Eiffel objects. These database elements are basically database table rows, database view rows or more generally sets of database attribute values. The easiest way to manipulate database elements is to insert their content into Eiffel objects and to work on these Eiffel objects as database elements. + +A first solution to implement this is to use some adaptable structures that will fit to any database element. This is done in EiffelStore through the [[ref:libraries/store/reference/db_tuple_flatshort|DB_TUPLE]] class, which contains mainly an ARRAY [STRING] containing element attribute names and an ARRAY [ANY] containing element attribute values. This solution has one major drawback: any static checking is impossible: the developer cannot be sure at compile time of the nature of a [[ref:libraries/store/reference/db_tuple_flatshort|DB_TUPLE]] , i.e. what it represents, and cannot know if attributes number, names and types are correct. To overcome this problem, a second solution is to use data structures that statically fits to the expected database element, as introduced in the [[Data Object Coupling|DataObject Coupling]] section. + +The major problem of this technique is that structures are static: one structure, so one class instead of one object, should be created for each database element. + + + + diff --git a/documentation/18.11/solutions/database-access/eiffelstore/eiffelstore-tutorial/eiffelstore-implementation-layer.wiki b/documentation/18.11/solutions/database-access/eiffelstore/eiffelstore-tutorial/eiffelstore-implementation-layer.wiki new file mode 100644 index 00000000..8f7912a8 --- /dev/null +++ b/documentation/18.11/solutions/database-access/eiffelstore/eiffelstore-tutorial/eiffelstore-implementation-layer.wiki @@ -0,0 +1,90 @@ +[[Property:title|EiffelStore Implementation Layer]] +[[Property:weight|1]] +[[Property:uuid|80cd0938-6837-3c17-8515-b4ac60a51d09]] +Each interface class has an implementation counterpart that implements specific DBMS handling. The class prefix indicates clearly its layer, for instance: +* [[ref:libraries/store/reference/db_selection_flatshort|DB_SELECTION]] is the interface to perform a database selection query. +* [[ref:libraries/store/reference/database_selection_flatshort|DATABASE_SELECTION]] [ [[ref:libraries/store/reference/database_flatshort|DATABASE]] ] is its implementation. + +The abstract [[ref:libraries/store/reference/database_flatshort|DATABASE]] class represents a DBMS, i.e. it is the Eiffel-side database call interface. It is inherited for instance by the instantiable ORACLE and ODBC classes. + +EiffelStore enables to link common interface objects with database-specific implementation objects using a '''handle'''. This handle also enables to switch between different databases. + +Let us see in 4 steps how EiffelStore implements this handle system: + +==The active database handle== + +The HANDLE_USE class provides access to the unique HANDLE instance. This object stores all the information about the active database, mainly: +* Database login information: + + login: LOGIN [DATABASE] + -- Session login + + +* Database status information: + + status: DB_STATUS + -- Status of active database + + + +==Association between interface and implementation== + +The association between an interface object and its implementation counterpart is done at the interface object creation. + +Every interface class inherits from the HANDLE_USE class and can access the active database handle. This handle contains a DB [DATABASE] object that provides implementation objects corresponding to every interface objects. + +The creation procedure for a DB_CHANGE object is for instance: + + make + -- Create an interface object to change active base. + do + implementation := handle.database.db_change + create ht.make (name_table_size) + implementation.set_ht (ht) + end + + +==Access to the DBMS call interface== + +Every implementation class can access the active database call interface by inheriting from the HANDLE_SPEC [DATABASE] class. This class provides access to the DATABASE object, i.e. an instance of class ORACLE or ODBC. + +DATABASE descendants are actually wrappers for the DBMS call interfaces written in C. More precisely, call interfaces as delivered by the DBMS companies are called in an EiffelStore C library. The C libraries are then wrapped into Eiffel classes, DATABASE descendants. + +==Active database selection== + +As seen in the [[Database Connection|interface connection]] part, active database selection is performed by the {DATABASE_APPL}.set_base feature: when a DATABASE_APPL object calls set_base, database represented by this object is activated. + +Let us give some details about the set_base feature: +* Database call interface global reference is updated through {HANDLE_SPEC}.update_handle. +* All information about the database is set to the handle, mainly: +** Login information. +** Status information. + +{{note|When database is inactive, its information is stored in the DATABASE_APPL object. }} + + +The corresponding code looks like: + + session_status: DB_STATUS + -- A session management object reference. + + ... + + set_base + ... + update_handle + if session_status = Void then + create session_status.make + end + handle.set_status (session_status) + ... + + +{{seealso|
+[[EiffelStore Interface Layer|The interface layer]]
+}} + + + + + diff --git a/documentation/18.11/solutions/database-access/eiffelstore/eiffelstore-tutorial/eiffelstore-interface-layer/data-modification.wiki b/documentation/18.11/solutions/database-access/eiffelstore/eiffelstore-tutorial/eiffelstore-interface-layer/data-modification.wiki new file mode 100644 index 00000000..e1d34268 --- /dev/null +++ b/documentation/18.11/solutions/database-access/eiffelstore/eiffelstore-tutorial/eiffelstore-interface-layer/data-modification.wiki @@ -0,0 +1,40 @@ +[[Property:title|Data Modification]] +[[Property:weight|1]] +[[Property:uuid|ef5568ff-dc7c-4c85-0174-335fdab1bd84]] +Use the [[ref:libraries/store/reference/db_change_flatshort|DB_CHANGE]] class to perform any operation on your database that does not require access to a result. You can for instance modify table row content, drop table rows, create and delete tables. + +{{note|Take a look at the [[Data Object Coupling|Data Storing]] capability if you want to '''insert''' table rows. }} + +[[ref:libraries/store/reference/db_change_flatshort|DB_CHANGE]] allows you to modify the database data using the SQL language: +* Prepare your SQL query and use modify: + + modification: DB_CHANGE + -- Modification tool. + + ... + + create modification.make + modification.modify ("Update CONTACTS set Firstname = ' John'") + + +* Commit your changes with your session control: + + session_control: DB_CONTROL + -- Session control. + + ... + + session_control.commit + + +{{tip|It is always better to check the database status for errors before committing changes. }} + + +{{seealso|
+[[Data Object Coupling|Data storing]]
+[[Stored Procedures|Stored procedures]]
+[[EiffelStore Implementation Layer|Implementation]]
+}} + + + diff --git a/documentation/18.11/solutions/database-access/eiffelstore/eiffelstore-tutorial/eiffelstore-interface-layer/data-object-coupling.wiki b/documentation/18.11/solutions/database-access/eiffelstore/eiffelstore-tutorial/eiffelstore-interface-layer/data-object-coupling.wiki new file mode 100644 index 00000000..b6ec3bab --- /dev/null +++ b/documentation/18.11/solutions/database-access/eiffelstore/eiffelstore-tutorial/eiffelstore-interface-layer/data-object-coupling.wiki @@ -0,0 +1,102 @@ +[[Property:title|Data Object Coupling]] +[[Property:weight|4]] +[[Property:uuid|c51311cd-8782-0bc3-3ef7-000ea6eee37c]] +A smart way to work with relational databases is to have Eiffel objects directly mapping relational tables. Three EiffelStore classes enable this coupling: +* [[ref:libraries/store/reference/db_repository_flatshort|DB_REPOSITORY]] objects [[#describe|describe a relational table]] and allow Eiffel to create objects mapping database tables. +* [[ref:libraries/store/reference/db_store_flatshort|DB_STORE]] works directly with [[ref:libraries/store/reference/db_repository_flatshort|DB_REPOSITORY]] objects to [[#insert|insert data into relational tables]] . +* [[ref:libraries/store/reference/db_selection_flatshort|DB_SELECTION]] can [[#map|map a database query result into Eiffel objects]] . + +==Describing relational tables with DB_REPOSITORY== + +A [[ref:libraries/store/reference/db_repository_flatshort|DB_REPOSITORY]] object stores available information about a table. To access this information, you mainly have to give the table name and load the table description: + + repository: DB_REPOSITORY + + ... + + create repository.make ("CONTACTS") + repository.load + if repository.exists then + ... + end + + + +{{tip|Loading a table description is often a costly operation: table has to be fetched among existing tables then every table column description must be loaded. Hence it is better to store and reuse a repository (maybe with a HASH_TABLE) once it has been loaded. }} + + +Using the table information, [[ref:libraries/store/reference/db_repository_flatshort|DB_REPOSITORY]] then helps generating Eiffel classes mapping relational tables: +* You can directly use {[[ref:libraries/store/reference/db_repository_flatshort|DB_REPOSITORY]] }.generate_class. Generated class may look like: + +class CONTACTS + +feature -- Access + + id: INTEGER + ... +feature -- Settings + + set_id (an_id: INTEGER) + -- Set an_id to id. + do + id := an_id + end + ... + + + +{{note|The EiffelStore Wizard uses the generation.generator cluster to generate the classes mapped to your database. }} + + +==Inserting data in the database== + +[[ref:libraries/store/reference/db_store_flatshort|DB_STORE]] lets you easily insert rows into a table using: +* the table description provided by [[ref:libraries/store/reference/db_repository_flatshort|DB_REPOSITORY]] . +* a class mapping the relational table. +This is straight-forward since you only have to give [[ref:libraries/store/reference/db_store_flatshort|DB_STORE]] the object filled with the table values. Suppose you want to add a contact into your database: + + storage: DB_STORE + contacts_rep: DB_REPOSITORY + a_contact: CONTACTS + + ... + + create storage.make + -- contacts_rep is loaded and exists. + storage.set_repository (contacts_rep) + -- a_contact carries values to insert into the database. + storage.put (a_contact) + + +==Accessing database content with Eiffel objects== + +[[ref:libraries/store/reference/db_selection_flatshort|DB_SELECTION]] lets you map data retrieved from the database into Eiffel objects: Result column names must match object attributes names so you can use for instance classes created by [[ref:libraries/store/reference/db_repository_flatshort|DB_REPOSITORY]] . Class DB_ACTION redefines ACTION and can be used to retrieve Eiffel objects directly into an ARRAYED_LIST: + + selection: DB_SELECTION + list_filling: DB_ACTION [CONTACTS] + contact: CONTACTS + + ... + + selection.object_convert (contact) + create list_filling.make (selection, contact) + selection.set_action (list_filling) + ... + selection.load_result + if selection.is_ok then + Result := list_filling.list + end + + + +{{note|You can see how actions are used in [[ref:libraries/store/reference/db_selection_flatshort|DB_SELECTION]] . }} +
+ +{{seealso|
+[[Database Selection|Performing a database selection.]]
+[[Data structures use|Database-specific structures use.]]
+}} + + + + diff --git a/documentation/18.11/solutions/database-access/eiffelstore/eiffelstore-tutorial/eiffelstore-interface-layer/database-connection.wiki b/documentation/18.11/solutions/database-access/eiffelstore/eiffelstore-tutorial/eiffelstore-interface-layer/database-connection.wiki new file mode 100644 index 00000000..28a0c589 --- /dev/null +++ b/documentation/18.11/solutions/database-access/eiffelstore/eiffelstore-tutorial/eiffelstore-interface-layer/database-connection.wiki @@ -0,0 +1,44 @@ +[[Property:title|Database Connection]] +[[Property:weight|0]] +[[Property:uuid|2cf2cb7c-e28d-5d06-b03e-e2b17c1f6879]] +* To connect to your database, you have to create a '''handle''': this handle actually links the interface classes with the corresponding implementation classes mapped to your DBMS. This handle is implemented by the DATABASE_APPL class: + + database_appl: DATABASE_APPL [ODBC] + -- Database handle. + + ... + + create database_appl.login (a_name, a_psswd) + database_appl.set_base + +
+ +{{note|Calling set_base links the EiffelStore interface to this specific handle. }} + +{{tip|You can manage handles to many databases: as an instance of DATABASE_APPL stands for a specific database handle, you only have to create one instance of DATABASE_APPL for every DBMS handle you wish to create. Do not forget to call set_base to activate appropriate handle. }} + + +{{note|The generic parameter of DATABASE_APPL specifies the actual DBMS used. }} + +* Once your handle is created, you have to create a session manager which will allow you to manage your database; specifically, to establish a connection, disconnect and also handle errors. The class DB_CONTROL enables your application to control the functioning and status of your database and to request any information about it. + + session_control: DB_CONTROL + -- Session control. + + ... + + create session_control.make + session_control.connect + + +{{note|Take a look at the [[Database control|database control]] part to see how to use DB_CONTROL capabilities. }} + + +{{seealso|
+[[Database control|Database control and error handling]]
+[[EiffelStore Implementation Layer|Implementation]]
+}} + + + + diff --git a/documentation/18.11/solutions/database-access/eiffelstore/eiffelstore-tutorial/eiffelstore-interface-layer/database-control.wiki b/documentation/18.11/solutions/database-access/eiffelstore/eiffelstore-tutorial/eiffelstore-interface-layer/database-control.wiki new file mode 100644 index 00000000..388d2f6d --- /dev/null +++ b/documentation/18.11/solutions/database-access/eiffelstore/eiffelstore-tutorial/eiffelstore-interface-layer/database-control.wiki @@ -0,0 +1,73 @@ +[[Property:title|Database control]] +[[Property:weight|7]] +[[Property:uuid|432c6e51-36d5-b469-c924-eb821713256a]] +Use the [[ref:libraries/store/reference/db_control_flatshort|DB_CONTROL]] class to check or change database status and behavior. The main operations you are likely to use are: +* Handling database errors. +* Connecting to the database. +* Committing changes in the database. + +==Handling database errors== + +Every EiffelStore interface class has an is_ok feature. This enables to check directly if the last database operation has been successful. + +When an error is detected, you can use [[ref:libraries/store/reference/db_control_flatshort|DB_CONTROL]] to obtain further information about the error: +* error_message provides a description of the error that occurred. +* error_code returns a code corresponding to the error type. This code enables to handle specific errors within your code without parsing the error_message. +* warning_message provides a warning message about the last transaction performed. + +Once you have handled your error, for instance by displaying the error_message on screen, you can call reset to perform new database transactions. + +==Managing database connection== + +[[ref:libraries/store/reference/db_control_flatshort|DB_CONTROL]] lets you connect, check your connection, and disconnect from the database. + +The following example sum up these capabilities: + + session_control: DB_CONTROL + + ... + + session_control.connect + if session_control.is_connected then + -- Perform your transactions here. + session_control.disconnect + end + + +==Committing changes in the database== + +With many database systems, modifications you make to the database are usually not saved immediately. Rather, changes are accumulated in a "transaction". At some point the entire transaction is committed to the database (i.e., the changes are actually made to the data) or the entire transaction is rolled back (i.e., absolutely no changes are made to the data.) You can manage database modification through 2 commands: +* ''Commit'' saves the changes in the database. +* ''Rollback'' restores the database content to its state after the most recent commit. + +The following example illustrates the use of these commands: + + session_control: DB_CONTROL + + ... + + from + until + transaction_completed or else not session_control.is_ok + loop + -- Perform your transaction here. + end + if session_control.is_ok then + session_control.commit + else + session_control.rollback + end + + +The loop performs a multi-step transaction. If transaction is not carried out entirely, the database could stay in an invalid state: this code ensures that database remains in a valid state. + +{{caution|Some databases can be in an auto-commit mode. Furthermore, some special database commands can automatically commit database changes. }} + +{{seealso|
+[[Database Connection|Database connection]]
+[[EiffelStore Implementation Layer|Implementation]]
+}} + + + + diff --git a/documentation/18.11/solutions/database-access/eiffelstore/eiffelstore-tutorial/eiffelstore-interface-layer/database-selection.wiki b/documentation/18.11/solutions/database-access/eiffelstore/eiffelstore-tutorial/eiffelstore-interface-layer/database-selection.wiki new file mode 100644 index 00000000..2421cfcf --- /dev/null +++ b/documentation/18.11/solutions/database-access/eiffelstore/eiffelstore-tutorial/eiffelstore-interface-layer/database-selection.wiki @@ -0,0 +1,40 @@ +[[Property:title|Database Selection]] +[[Property:weight|2]] +[[Property:uuid|de759a74-b3e1-c937-e620-67526c116925]] +Use the [[ref:libraries/store/reference/db_selection_flatshort|DB_SELECTION]] class to select data from the database. Once you have selected the data, you can [[Selection Access|access]] it with convenience using adaptative EiffelStore structures. + +{{note|Take a look at the [[Data Object Coupling|Database/Eiffel objects Coupling]] if you need information about your database structure. }} + +[[ref:libraries/store/reference/db_selection_flatshort|DB_SELECTION]] enables your application to get database content using SQL 'select' queries: +* You can carry out 'select' queries in an intuitive way using directly the SQL language: + + selection: DB_SELECTION + -- Selection tool + + ... + + create selection.make + selection.set_query ("select * from CONTACTS where firstname = 'John'") -- Set query text + selection.execute_query -- Execute query + + ... -- Process query results + + selection.terminate -- Clear database cursor + + + +{{tip|
+1) Always check the database status for errors after your 'select' query.
+2) EiffelStore supports a finite number of concurrent queries. Call {DB_SELECTION}.terminate to free resources from a completed query. }} + +* You can also customize your selection using [[Query variables|bind variables]] . + +{{seealso|
+[[Query variables|Binding variables in a database query.]]
+[[Data Object Coupling|Coupling database objects with Eiffel objects.]]
+[[Selection Access|Accessing selected data from the database.]]
+}} + + + + diff --git a/documentation/18.11/solutions/database-access/eiffelstore/eiffelstore-tutorial/eiffelstore-interface-layer/index.wiki b/documentation/18.11/solutions/database-access/eiffelstore/eiffelstore-tutorial/eiffelstore-interface-layer/index.wiki new file mode 100644 index 00000000..08532ec5 --- /dev/null +++ b/documentation/18.11/solutions/database-access/eiffelstore/eiffelstore-tutorial/eiffelstore-interface-layer/index.wiki @@ -0,0 +1,9 @@ +[[Property:title|EiffelStore Interface Layer]] +[[Property:weight|0]] +[[Property:uuid|abd6c880-e0d8-0961-8cd2-d2ca43c1ce28]] +The Interface layer gathers a set of classes covering all the capabilities an application needs to interface efficiently with a DBMS. + +Each of the following sections describes a particular database capability accessed through the EiffelStore interface layer. In general, each of these capabilities is made available in the interface layer by one class. + + + diff --git a/documentation/18.11/solutions/database-access/eiffelstore/eiffelstore-tutorial/eiffelstore-interface-layer/query-variables.wiki b/documentation/18.11/solutions/database-access/eiffelstore/eiffelstore-tutorial/eiffelstore-interface-layer/query-variables.wiki new file mode 100644 index 00000000..f63b2a27 --- /dev/null +++ b/documentation/18.11/solutions/database-access/eiffelstore/eiffelstore-tutorial/eiffelstore-interface-layer/query-variables.wiki @@ -0,0 +1,54 @@ +[[Property:title|Query variables]] +[[Property:weight|5]] +[[Property:uuid|37222a07-a8f8-e57d-45f0-3b28cd66d660]] +If you have to execute database queries which only differ in the expression values, you can create a template query and then bind variables into this template for each execution. + +This mechanism can be applied for requests with a result ([[ref:libraries/store/reference/db_selection_chart|DB_SELECTION]] ) or without ([[ref:libraries/store/reference/db_change_chart|DB_CHANGE]] ). Hence both classes inherits from STRING_HDL that actually handle variable binding. + +To use variable binding: +* [[#create|Create]] a template query. +* [[#bind|Bind]] variables to the query. + +==Creating a template query== + +Template queries are parsed to replace each variable by its bound value. To create a template query, you have hence to put directly variables where the values would take place. + +Variables syntax is simple: the ':' special character followed by the variable name. + + selection: DB_SELECTION + Bind_var: STRING = "firstname" + + ... + + create selection.make + selection.set_query ("Select * from CONTACTS where Firstname = ':" + Bind_var + "'") + + +{{note|The code example shows how to bind variables to a [[ref:libraries/store/reference/db_selection_chart|DB_SELECTION]] object but the mechanism is exactly the same for [[ref:libraries/store/reference/db_change_chart|DB_CHANGE]] objects. }} + +==Binding variables to a query== + +Once you have created your query, you can map variable names to values and execute the query: + + selection: DB_SELECTION + Bind_var: STRING is "firstname" + + ... + + loop + io.read_line + selection.set_map_name (io.laststring, Bind_var) + selection.execute_query + ... + selection.unset_map_name (Bind_var) + end + + +{{seealso|
+[[Database Selection|Performing a database selection.]]
+[[Data Modification|Modifying database content.]]
+}} + + + + diff --git a/documentation/18.11/solutions/database-access/eiffelstore/eiffelstore-tutorial/eiffelstore-interface-layer/selection-access.wiki b/documentation/18.11/solutions/database-access/eiffelstore/eiffelstore-tutorial/eiffelstore-interface-layer/selection-access.wiki new file mode 100644 index 00000000..ea20f447 --- /dev/null +++ b/documentation/18.11/solutions/database-access/eiffelstore/eiffelstore-tutorial/eiffelstore-interface-layer/selection-access.wiki @@ -0,0 +1,116 @@ +[[Property:title|Selection Access]] +[[Property:weight|3]] +[[Property:uuid|3b4fdde3-d903-55c8-0068-cee2407db280]] +Once you have [[Database Selection|selected data]] from the database, it returns a set of rows containing queried columns values. Each row loaded with DB_SELECTION is stored in a DB_RESULT object. The easiest way to access the data is thus to refer to DB_RESULT objects themselves. + + +{{note|Take a look at the [[Data Object Coupling|Database/Eiffel objects Coupling]] to learn advanced data handling features. }} + +To use DB_RESULT, process in 2 steps: +* [[#retrieve|retrieve]] DB_RESULT objects. +* [[#access|access]] DB_RESULT content. + +==Retrieving DB_RESULT objects== + +[[ref:libraries/store/reference/db_selection_flatshort|DB_SELECTION]] class provides different ways to customize result loading: +* You want to access an '''unique''' row: [[ref:libraries/store/reference/db_result_flatshort|DB_RESULT]] object is accessible via cursor: + + selection: DB_SELECTION + my_result: DB_RESULT + + ... + + selection.query ("...") + if selection.is_ok then + selection.load_result + my_result := selection.cursor + end + + +* You want to load a '''complete list''' of rows: [[ref:libraries/store/reference/db_selection_flatshort|DB_SELECTION]] can store [[ref:libraries/store/reference/db_result_flatshort|DB_RESULT]] objects in a list. To do this, you have mainly to provide a LIST object to DB_SELECTION with set_container: + + selection: DB_SELECTION + container: ARRAYED_LIST [DB_RESULT] + + ... + + create container.make (Max_results) + ... + selection.set_container (container) + selection.load_result + ... + from + container.start + until + container.after + loop + ... + end + + +{{tip|Provide [[ref:libraries/store/reference/db_selection_flatshort|DB_SELECTION]] with the LIST structure convenient for what you need to do with the results. }} + +* You want to '''select part''' of the result set: you can set an action in [[ref:libraries/store/reference/db_selection_flatshort|DB_SELECTION]] that will be executed each time a row is loaded. This action can for instance manipulate current row and define a stop condition. +** You need to define a descendant of class ACTION and set it to [[ref:libraries/store/reference/db_selection_flatshort|DB_SELECTION]] : + +class + MY_ACTION +inherit + ACTION + redefine + execute, found + end + + ... + + execute + do + i := i + 1 + end + + ... + + found: BOOLEAN + do + Result := i >= Max_result + end + +** Then set action to [[ref:libraries/store/reference/db_selection_flatshort|DB_SELECTION]] : + + selection: DB_SELECTION + action: MY_ACTION + + ... + + selection.set_action (action) + selection.query ("...") + if selection.is_ok then + selection.load_result + end + + + + +==Accessing content of DB_RESULT== + +A DB_RESULT object merely carries data retrieved from the database. You have to convert it to a DB_TUPLE to access data within the retrieved row conveniently, i.e. mostly the column values: + + selection: DB_SELECTION + tuple: DB_TUPLE + + ... + + create tuple.make_from_cursor (selection.cursor) + if tuple.count >= 2 and then tuple.column_name (2).is_equal ("Firstname") then + io.putstring (tuple.item (2).out) + end + + + +{{seealso|
+[[Database Selection|Performing a database selection.]]
+[[Data Object Coupling|Coupling database data and Eiffel objects.]]
+}} + + + diff --git a/documentation/18.11/solutions/database-access/eiffelstore/eiffelstore-tutorial/eiffelstore-interface-layer/stored-procedures.wiki b/documentation/18.11/solutions/database-access/eiffelstore/eiffelstore-tutorial/eiffelstore-interface-layer/stored-procedures.wiki new file mode 100644 index 00000000..acd6555d --- /dev/null +++ b/documentation/18.11/solutions/database-access/eiffelstore/eiffelstore-tutorial/eiffelstore-interface-layer/stored-procedures.wiki @@ -0,0 +1,81 @@ +[[Property:title|Stored Procedures]] +[[Property:weight|6]] +[[Property:uuid|9979af90-07c3-8b20-448e-04454a75c801]] +When sending requests to the database, the request is first parsed then executed. Instead of parsing many times the same requests, i.e. with only changes in expression values, most of RDBMS enable to '''precompile''' requests. These requests can then be executed as routines and are identified by a name and a signature. + +EiffelStore lets you use stored procedures with [[ref:libraries/store/reference/db_proc_flatshort|DB_PROC]] class to: +* [[#execute|Execute]] a stored procedure. +* [[#create|Create]] a stored procedure. + +==Executing a stored procedure== + +To execute a stored procedure: +* Create a [[ref:libraries/store/reference/db_proc_flatshort|DB_PROC]] object and load the stored procedure you want to use: + + procedure: DB_PROC + + ... + + create procedure.make ("UPDATE") + procedure.load + if procedure.exists then + ... + end + + +* Execute the procedure through a [[ref:libraries/store/reference/db_selection_chart|DB_SELECTION]] (if a result is expected) or a [[ref:libraries/store/reference/db_change_chart|DB_CHANGE ]] object (otherwise). + +{{note|Requests with a result ([[ref:libraries/store/reference/db_selection_chart|DB_SELECTION]] ) or without ([[ref:libraries/store/reference/db_change_chart|DB_CHANGE]] ) are both abstract '''expressions'''. DB_PROC executes an abstract expression using an object of [[ref:libraries/store/reference/db_expression_chart|DB_EXPRESSION]] type, which corresponds to an abstract expression. [[ref:libraries/store/reference/db_selection_chart|DB_SELECTION]] and [[ref:libraries/store/reference/db_change_chart|DB_CHANGE]] inherits from [[ref:libraries/store/reference/db_expression_chart|DB_EXPRESSION]] . }} + +You can execute your request mostly like a basic one: +** Create your request. +** Bind request variables. Variables are stored procedure arguments. + +{{note|Take a look at how to [[Query variables|bind variables]] to a query. }} + +** Execute the query through the DB_PROC object. + + procedure: DB_PROC + expr: DB_CHANGE + + ... + + procedure.execute (expr) + expr.clear_all + + +** Check for errors and load result if any. + + +==Creating a stored procedure== + +DB_PROC also enables you to create or drop stored procedures: +* Use store to create a procedure. +* Use drop to delete one. +The following example shows how to overwrite a procedure in the database: + + procedure: DB_PROC + + ... + + create procedure.make ("NEW_PROCEDURE") + procedure.load + if procedure.exists then + procedure.drop + end + procedure.load + if not procedure.exists then + procedure.set_arguments (<<"one_arg">>, <<"">>) + procedure.store ("update contacts set firstname = one_arg where contactid = 1") + end + + + +{{seealso|
+[[Database Selection|Performing a database selection.]]
+[[Data Object Coupling|Coupling database data and Eiffel objects.]]
+}} + + + + diff --git a/documentation/18.11/solutions/database-access/eiffelstore/eiffelstore-tutorial/index.wiki b/documentation/18.11/solutions/database-access/eiffelstore/eiffelstore-tutorial/index.wiki new file mode 100644 index 00000000..9ef5228c --- /dev/null +++ b/documentation/18.11/solutions/database-access/eiffelstore/eiffelstore-tutorial/index.wiki @@ -0,0 +1,11 @@ +[[Property:title|EiffelStore Tutorial]] +[[Property:weight|1]] +[[Property:uuid|542caa33-5dc1-d2ea-414b-b1739045edd9]] +EiffelStore's main classes are grouped into 2 main layers: +* The [[EiffelStore Interface Layer|interface layer]] provides a high-level, unique interface for every DBMS. +* The [[EiffelStore Implementation Layer|implementation layer]] customizes high-level routines to various DBMS handles. + +Other clusters can facilitate your database management: +* The [[EiffelStore Generation Cluster|generation cluster]], with the EiffelStore wizard, generates a facilitated and dynamic interface to your database. +* The [[EiffelStore DataView Cluster|dataview cluster]] lets you create a customized database GUI. + diff --git a/documentation/18.11/solutions/database-access/eiffelstore/index.wiki b/documentation/18.11/solutions/database-access/eiffelstore/index.wiki new file mode 100644 index 00000000..968f12ac --- /dev/null +++ b/documentation/18.11/solutions/database-access/eiffelstore/index.wiki @@ -0,0 +1,10 @@ +[[Property:title|EiffelStore]] +[[Property:weight|1]] +[[Property:uuid|f43ab3e6-4551-632a-384b-4964d1436730]] +==EiffelStore Library== + +Type: Library
+Platform: Any
+ +EiffelStore provides facilities for interfacing an application with various DataBase Management Systems (DBMS). It contains a powerful set of classes grouped into layers representing different levels of abstraction. + diff --git a/documentation/18.11/solutions/database-access/index.wiki b/documentation/18.11/solutions/database-access/index.wiki new file mode 100644 index 00000000..98b35ea5 --- /dev/null +++ b/documentation/18.11/solutions/database-access/index.wiki @@ -0,0 +1,6 @@ +[[Property:title|Database access]] +[[Property:weight|-8]] +[[Property:uuid|f5d26942-de52-76cc-0f41-66b959a78999]] +== Database access solutions == + + diff --git a/documentation/18.11/solutions/dates-and-times/eiffeltime/eiffeltime-class-reference.wiki b/documentation/18.11/solutions/dates-and-times/eiffeltime/eiffeltime-class-reference.wiki new file mode 100644 index 00000000..2f0cf641 --- /dev/null +++ b/documentation/18.11/solutions/dates-and-times/eiffeltime/eiffeltime-class-reference.wiki @@ -0,0 +1,5 @@ +[[Property:title|EiffelTime Class Reference]] +[[Property:weight|2]] +[[Property:uuid|ab08dc65-7d32-f681-d7de-e391081736eb]] +==View the [[ref:libraries/time/reference/index|EiffelTime Class Reference]]== + diff --git a/documentation/18.11/solutions/dates-and-times/eiffeltime/eiffeltime-tutorial/absolute-time.wiki b/documentation/18.11/solutions/dates-and-times/eiffeltime/eiffeltime-tutorial/absolute-time.wiki new file mode 100644 index 00000000..79ecd99e --- /dev/null +++ b/documentation/18.11/solutions/dates-and-times/eiffeltime/eiffeltime-tutorial/absolute-time.wiki @@ -0,0 +1,123 @@ +[[Property:title|Absolute time]] +[[Property:weight|0]] +[[Property:uuid|195849fc-1a9c-d734-2d2b-acae78133886]] +The classes dealing with date and those dealing with time have many similarities. These classes descend from more abstract classes implementing the notion of value ([[ref:libraries/time/reference/time_value_chart|TIME_VALUE]] , [[ref:libraries/time/reference/date_value_chart|DATE_VALUE]] , [[ref:libraries/time/reference/date_time_value_chart|DATE_TIME_VALUE]] ). From this notion come two kinds of heirs which are the absolute notion of time (classes [[ref:libraries/time/reference/date_chart|DATE]] , [[ref:libraries/time/reference/time_chart|TIME]] and [[ref:libraries/time/reference/date_time_chart|DATE_TIME]] ) and the notion of duration (classes [[ref:libraries/time/reference/date_duration_chart|DATE_DURATION]] , [[ref:libraries/time/reference/time_duration_chart|TIME_DURATION]] , [[ref:libraries/time/reference/date_time_duration_chart|DATE_TIME_DURATION]] ). + +[[ref:libraries/time/reference/date_chart|DATE]] , [[ref:libraries/time/reference/time_chart|TIME]] and [[ref:libraries/time/reference/date_time_chart|DATE_TIME]] inherit from the deferred class [[ref:libraries/time/reference/absolute_chart|ABSOLUTE]]. These classes model absolute temporal values, i.e., specific times and dates. Because ABSOLUTE inherits from COMPARABLE, the ordering functions <, <=, >, and >= are available on instances of [[ref:libraries/time/reference/absolute_chart|ABSOLUTE]] and its descendants. + +==TIME== + +[[ref:libraries/time/reference/time_chart|TIME]] models times of day, supporting queries: hour, minute, and second. It is possible to use more precision for time. However, this section deals with precision only to the second. See [[More precision]] for additional information on higher precision. + +====Creation==== + +There are three ways to create an instance of the class TIME: by choosing the time (make), by getting the time from the system (make_now), or by choosing the number of seconds elapsed from the origin (make_by_seconds). The arguments of make and make_by_seconds have to respect the range of a day (see preconditions). + +====Origin and cyclic representation==== + +The origin for instances of TIME is 0 hour 0 minute and 0 second. The notion of time is relative to a day, and has a cyclic representation. So, days begin at 0:0:0 and end at 23:59:59. If a second is added to 23:59:59 then the result will be 0:0:0. Subtracting a minute from 0:0:0 will yield 23:59:0. + +====Comparison==== + +Instances of [[ref:libraries/time/reference/time_chart|TIME ]] may be compared. Functions <, <=, >, and >= are available for ordering instances. Function is_equal (or ~) can be used to test object equality, whereas = will compare references. + +====Measurement==== + +The query duration applied to an instance of [[ref:libraries/time/reference/time_chart|TIME ]] returns an instance of [[ref:libraries/time/reference/time_duration_chart|TIME_DURATION]]. It is the duration from the origin until the current time. + +The query seconds returns the total number of seconds since the origin. This query may be useful to get the number of seconds between two events. + +The feature - returns an [[Interval]] between two instances of TIME. The duration of this interval is given by the function duration. However, this duration is non-canonical (See [[Duration|Duration]] for a definition of canonical form). In TIME, the feature relative_duration returns the same duration, but more efficiently and in canonical form. + +====Operations==== +* Set values for hour, minute, and second with set_hour, set_minute, and set_second. Arguments must satisfy the rules of creation. +* Add hours, minutes, and seconds with features hour_add, minute_add, and second_add. Features add and + take an instance of TIME_DURATION as an argument and add it to the current time. +* Adjust an instance of TIME to the next or the previous hour, minute, or second with features hour_forth, hour_back, minute_forth, minute_back, second_forth, and second_back. It is more efficient to use these features rather than the addition commands listed above (e.g., hour_back will outperform hour_add (-1) ). + +==DATE== + +DATE models dates, and supports queries year, month and day. Working with dates is more complicated than working with times of day because of the irregularities in elements of dates. Months, for example, have varying numbers of days. The number of days in a year varies between non-leap years and leap years. The only limit to magnitude for dates comes from INTEGER representation. If, as in most cases, INTEGER size is 32 bits, the range for a date is -2^31 to 2^31 days, or about 5.8 million years from the origin. So, unless you're trying to determine if the "big bang" occurred on a Tuesday, this should probably be adequate. + +====Creation==== + +There are three ways to create an instance of the class DATE: by choosing the date (make, make_month_day_year, make_day_month_year), by getting the date from the system (make_now), or by choosing the number of days elapsed from the origin (make_by_days). The arguments of each creation procedure, when considered together, must represent a valid date. For example, a month of February and day of 29 will be invalid if the value for the year is not a leap year. + +====Origin==== + +The origin for instances of DATE is January 1, 1600. + +====Comparison==== + +Instances of DATE may be compared. Functions <, <=, >, and >= are available for ordering instances by value. Function is_equal (or ~) can be used to test object equality, while = will compare references. + +====Measurement==== + +Each instance of DATE has a function (duration) which returns the duration since the origin until the current date (it is an instance of DATE_DURATION). This duration is definite, i.e. it contains only days (See [[Duration]]). However, it may be useful to deal directly with days (no need of DATE_DURATION). In this case, the function days of DATE yields the number of days since origin. + +====Status Report==== + +You can obtain information about instances from status reporting queries. Some examples are: +* leap_year is True if the instance is a leap year. +* year_day returns the number of days from the beginning of the year to this instance. So, for example, for the date January 31, year_day would return 31. For February 1, year_day would return 32. +* day_of_the_week returns the number of days the instance is from the beginning of the week. Values range from 1 (Sunday) through 7 (Saturday). + +====Operations==== + +DATE operations look much like those of TIME: +* Set year, month, and day with set_year, set_month, and set_day. Arguments must satisfy the rules of creation. These rules are more complicated than those of TIME. For example you cannot set day to 31 if the current month is April, whereas you can if the month is January. These restrictions also apply to make. Similarly for years: you cannot set year to a non-leap year if the current date is February 29th. However, two features are available to set month and year even if day is too large: set_month_cut_days and set_year_cut_days will cut day down to the largest value allowed. +* Add years, months and days with features year_add, month_add, and day_add. There is no restriction on adding a year or a month. However, these features have to return a correct result, i.e., the day is checked before each addition. Adding one month to August 31st will yield September 30th. 31 is cut to 30 since there are only 30 days in September. Features add and + take an instance of DATE_DURATION as an argument and add it to the instance of date. It is written so that years and months are added first, the days last.(see DATE_DURATION below) +* Move to the next or the previous year, month or day with features year_forth, year_back, month_forth, month_back, day_forth, and day_back. It more efficient to use these features than the addition commands (e.g., year_back performs better than year_add (-1) ). +* Features relative_duration and definite_duration return the duration between the current date and the argument. relative_duration returns a result which is canonical (See [[Duration]]), while definite_duration returns a definite result which may be not canonical.For example, suppose date1 is April 20th and date2 is May 28th. Both features will yield instances of DURATION; however, relative_duration will yield 1 month and 8 days whereas definite_duration will yield 38 days. + +==DATE_TIME== + +[[ref:libraries/time/reference/date_time_chart|DATE_TIME]] provides a combined date and time. DATE_TIME is client of both TIME and DATE. Some features from DATE and TIME are offered directly as features of DATE_TIME. Other features of DATE and TIME may be called indirectly with the correct DATE_TIME attribute (time or date). + +====Creation==== + +There are several ways to create an instance: +* Choose values for each of the attributes of the date and the time (make). +* Get the current date and time from the system (make_now). +* Associate an instance of DATE with an instance of TIME (make_by_date_time). +{{caution|The creation procedure make_by_date_time copies only the references of its arguments, so that if the time (or the date) is changed, the instance previously initialized will be also changed. If this effect has to be avoided, using twin's of the arguments is required.}} +* Encapsulate an instance of DATE (make_by_date). The attribute time is set to the origin, i.e. 0:0:0. The attribute date is set with the same reference as the argument (See caution just mentioned above). + +====Origin==== + +The origin for instances of DATE_TIME is 0:0:0 on January 1, 1600. + +====Access==== + +An instance of DATE_TIME has attributes which are instances of classes TIME and DATE, respectively. As a convenience, some features of TIME and DATE have been made available directly as features of DATE_TIME (and passed through to time and date). These include days, seconds, duration, date_duration, and time_duration. + +====Comparison==== + +Instances of DATE_TIME can be compared. Functions <, <=, >, and >= are available for ordering instance by value. Function is_equal (or ~) is used to test object equality, while = compares references. + +====Measurement==== + +duration returns an instance of DATE_TIME_DURATION which represents the duration of time between the instance and the origin. + +====Element change==== + +It is possible to change reference of time and date with the features set_time and set_date. To change only one element (for example hour), features from TIME or DATE have to be used. + +====Operations==== + +Add hours, minutes, and seconds with features hour_add, minute_add, and second_add. + +{{caution|Using the addition features from TIME on the time attribute is also possible but the date will not be modified in the case time makes a cycle. So, for example use: my_date_time.hour_add (more_hours) instead of: my_date_time.time.hour_add (more_hours) }} + +day_add is available on instances of DATE_TIME to add days. + +Feature add (or +) takes an instance of DATE_TIME_DURATION as an argument. Internally, add first adds the the date duration, and then the time duration. + +{{info|Adding the time duration first would yield undesirable results in rare cases such as in this example: the current date/time is August 30th 23:59:59. The duration being added is one month and one second. Applying feature add makes the current date/time October 1st 0:0:0, because the date duration is added first. Adding the time duration first would yield September 30th 0:0:0 ! The same effect would occur with leap years.}} + +Feature relative_duration and definite_duration return the duration between the current date (with time) and the argument. relative_duration returns a result which is canonical (see [[Duration]]), while definite_duration returns a result which is definite but may be not canonical. + +==Obtaining a DATE from a DATE_TIME and vice versa== + +Obtaining an instance of DATE which represents the date portion of an instance of DATE_TIME can be done by applying the query date to the instance of DATE_TIME. + +You can ask for a new instance of DATE_TIME from an instance of DATE by using the query to_date_time. The new instance will have the same date as the target, and have its time set to the origin (0:0:0). A DATE_TIME instance can be initialized with a specific DATE by using DATE_TIME's creation procedure make_by_date. diff --git a/documentation/18.11/solutions/dates-and-times/eiffeltime/eiffeltime-tutorial/date-time-string-conversion.wiki b/documentation/18.11/solutions/dates-and-times/eiffeltime/eiffeltime-tutorial/date-time-string-conversion.wiki new file mode 100644 index 00000000..bf93bfa8 --- /dev/null +++ b/documentation/18.11/solutions/dates-and-times/eiffeltime/eiffeltime-tutorial/date-time-string-conversion.wiki @@ -0,0 +1,110 @@ +[[Property:title|DATE TIME to STRING Conversion]] +[[Property:weight|3]] +[[Property:uuid|88972ba4-694b-8558-b0c8-87b1fc40afc4]] +The classes TIME, DATE, and DATE_TIME provide a query formatted_out which can be used to retrieve a string containing the date or time in a format specified by a string or format conversion codes that the caller provides as an argument. The conversion is done in the DATE_TIME_CODE_STRING class. So for example, if a DATE instance referenced by my_date has a value of February 3, 2008, then applying the query: + + my_date.formatted_out ("[0]dd mmm yyyy") + +will return the string: + +03 FEB 2008 + + + +The following table lists format conversion codes. +{| +|- +| '''Code''' +| '''Description''' +|- +| dd +| day - numeric +|- +| [0]dd +| day - numeric (padded with '0' to 2 figures) +|- +| ddd +| day - text (3 letters e.g "MON", "TUE") +|- +| yyyy +| year - numeric (4 figures) +|- +| yy +| year - numeric (2 figures) +|- +| mm +| month - numeric +|- +| [0]mm +| month - numeric (padded with '0' to 2 figures) +|- +| mmm +| month - text (3 letters e.g "DEC", "JAN") +|- +| hh +| hour - numeric (24 hour clock scale by default) +|- +| [0]hh +| hour - numeric (padded with '0' to 2 figures) +|- +| hh12 +| hour - numeric (12 hour clock scale) +|- +| mi +| minute - numeric +|- +| [0]mi +| minute - numeric (padded with '0' to 2 figures) +|- +| ss +| seconds - numeric +|- +| [0]ss +| seconds - numeric (padded with '0' to 2 figures) +|- +| ff +| fractional seconds - numeric (precise to figures) +|- +| am +| meridiem indicator. Includes "AM" for ante meridiem times (before noon) and "PM" for post meridiem times (after noon). +|- +| ':', '/', '-' and ',' +| separators e.g. "03/FEB/08" +|} + + +These are some examples of output with their associated format code: +{| +|- +| '''Code''' +| '''Output''' +|- +| yy/mm/dd +| 08/2/3 +|- +| mmm-[0]dd-yy +| FEB-03-08 +|- +| dd,mm,yyyy +| 3,2,2008 +|- +| hh-mi-ss +| 13-6-32 +|- +| hh12,mi,ss +| 1,6,32 +|- +| hh12:[0]mi:[0]ss:ff2 am +| 1:06:32.25 PM +|- +| [0]hh:[0]mi:[0]ss.ff3 +| 13:06:32.248 +|- +| [0]mm/dd/yy hh12:mi:ss.ff3 +| 02/3/08 1:6:32.248 +|} + + + + + diff --git a/documentation/18.11/solutions/dates-and-times/eiffeltime/eiffeltime-tutorial/duration.wiki b/documentation/18.11/solutions/dates-and-times/eiffeltime/eiffeltime-tutorial/duration.wiki new file mode 100644 index 00000000..fc17214b --- /dev/null +++ b/documentation/18.11/solutions/dates-and-times/eiffeltime/eiffeltime-tutorial/duration.wiki @@ -0,0 +1,152 @@ +[[Property:title|Duration]] +[[Property:weight|1]] +[[Property:uuid|64672bd0-b696-0c39-1e30-5ac64aae4a99]] +The classes TIME_DURATION, DATE_DURATION, and DATE_TIME_DURATION model time durations. + +The classes dealing with duration inherit from DURATION, which in turn inherits from GROUP_ELEMENT and PART_COMPARABLE. From this lineage comes the query zero, the addition features infix + and infix - and the unary features prefix +, and prefix -. + +Duration is used as an amount of time, without link to an origin. It may be added to the respective absolute notion So, TIME + TIME_DURATION is possible, but not TIME + DATE_TIME_DURATION nor DATE_TIME + TIME_DURATION ... see classes TIME, DATE, and DATE_TIME in [[Absolute time]]. + +Attributes of durations are allowed to take values which do not fall in the expected range, even negative values (e.g., hour = -1, minute = 75, day = 40...). However, queries are available in each class to test for canonical format and to provide equivalent instances in canonical format. + +An instance is ''canonical'' if the values for all of its relevant attributes fall into the specific ranges defined for each type of duration, documented in sections below (for example, for a canonical instance of TIME_DURATION, the value of second will be in 0..59). In such a case, the value of query canonical is True. For example, an instance of TIME_DURATION such as 12:-10:60 is not canonical. The query to_canonical will return a new instance with equivalent value, but with its components in canonical form, in the case of our example: 11:51:0. These features are also present in DATE_DURATION and DATE_TIME_DURATION. + +Ordering is partial for DATE_DURATION and DATE_TIME_DURATION for reasons explained below, and total for TIME_DURATION. + +==TIME_DURATION== + +====Creation==== + +Instances can be created either by specifying a value for each of the attributes hour, minute, and second (make), or by specifying only a number of seconds (make_by_seconds). Any integer value is accepted. So, for example, it is possible to create a duration with 1 hour and -60 minutes. + +====Access==== + +The query zero provides a TIME_DURATION with 0 hour, 0 minute and 0 second. + +The total number of seconds in the current duration can be obtained by applying the query seconds_count. + +====Comparison==== + +Instances of TIME_DURATION may be compared. The order is the order of the respective total number of seconds. So, 1:-40:0 is less than 0:0:1800, for example. Functions <, >, <=, and >= are available. The BOOLEAN query is_equal (or the object equality operator ~) tests object equality, = will compare references. + +====Element change==== + +Set hour, minute, and second with set_hour, set_minute, and set_second. Arguments do not need to satisfy any range rule. + +====Operations==== +* Add hours, minutes and seconds with features hour_add, minute_add and second_add. +* infix + and infix - are available for producing sums and differences of durations. +* prefix - is available for producing the inverse of a duration. + +====Conversion==== + +Two features provide a conceptual link with the notion of ''day'': +* The first, to_days returns the number of days equivalent to the current duration. For example, a duration such as 23:60:0 is equivalent to one day. For negative duration, the result is never 0. -1 hour is equivalent to -1 day (i.e. the result of to_days is -1). +* The second is time_modulo_day. This query returns an instance of TIME_DURATION. The result represents the difference between the current duration and the number of days yielded by to_days. It implies that the result is always positive and less than one day. + +{{sample|Suppose the value of an instance of TIME_DURATION is 25:70:600. Then applying to_days will return 1 (one day) and applying time_modulo_day will return 2:20:0. Now suppose that the value of the TIME_DURATION is negative, say -23:-80:300. In this case, applying to_days will return -2 (minus two days) and time_modulo_day will return 23:45:0.}} + + +Durations may be in canonical or non-canonical form. This can be tested using the BOOLEAN query canonical. Canonical form depends upon whether the features hour, minute, and second have values that fall into a particular range. An instance of TIME_DURATION is canonical if: +:* in the case of a positive duration (> zero), all of the three features have to be positive or 0, minute and second less than 60. +:* in the case of a negative duration (< zero), all of the three features have to be negative or 0, minute and second strictly greater than -60. + +Two queries help you work with canonical form: +* The value of the query canonical is True if duration is in canonical form. +* The query to_canonical yields a new, canonical TIME_DURATION equivalent to the duration to which it is applied. + + +==DATE_DURATION== + +DATE_DURATION is similar to TIME_DURATION, but models durations in dates rather than times. Dealing with the Gregorian calendar is complicated by its irregularities. For example, a date duration of one month may be equal to 28, 29, 30, 31 days, depending on a date of reference. Sometimes though, it is useful to deal with a precise date duration, just a number of days, independent of any particular date. This issue leads to a unique point of design in the DATE_DURATION class: a separation is made between two kinds of instances: ''definite'' date durations and the ''relative'' date durations. The BOOLEAN query definite is True for definite date durations and false for relative date durations. + +An instance is ''definite'' if and only if its attributes month and year are 0. Then only the number of days is used. + +''Relative'' (non-definite) durations allow their attributes year, month, and day to have meaningful values, but disallow comparisons with other durations, for reasons which will be explained below. + +The distinction between definite and relative date duration makes a difference when a duration is added to a date. In the case of a definite DATE_DURATION, there is no ambiguity: a given number of days is added to the date. In the case of a relative DATE_DURATION, the result is relative to the duration's origin_date. For example, a one month duration may be equal to 28 days if the date is in February or 31 days if the date is in August. + +===About ''relative'' DATE_DURATIONs=== + +Relative durations cannot be compared with any other durations (including zero). This is because of the complexities of the Gregorian calendar. If we consider how many days there are in a duration of one month, we cannot point to a specific integer value that will be correct in all cases ... it depends upon which month we are considering ... and in some cases whether it is a leap year. + +If a comparison (> or <) is applied in a state in which either the current instance or the argument or both are relative durations, the result will be always False. + +We are able to determine if two durations have equal value by applying the feature is_equal (or the object equality operator ~). + +When adding a relative DATE_DURATION to a DATE, the years and the months are added first, then the date may be cut (for example, June 31 cut to June 30) and finally the days are added. For example, if one month is added to the date August 31st, the result is September 30th. + +Nevertheless, there is a way to compare relative durations: a relative date_duration may be canonical. It means that the duration has its attributes month and day in a fixed range. month must be between 1 and 12, and day larger than 1 and less than a value between 27 and 30. This value is fixed simply: (in the case of a positive duration) when setting day to 0 and adding one more month, the addition of the start date and this new duration must yield a date strictly after the final date (yielded by adding date and tested duration). For example is 0/0/30 (i.e. 0 year, 0 month and 30 days) canonical? +* If the origin date is 01/15 (15th of January), the final date is 02/14. We cannot convert 30 days into 1 month in this case. The duration is canonical. +* If the origin date is 04/15 (15th of April), the final date is 05/15. The duration is not canonical since it is possible to convert days into 1 month. The origin date is used to determine whether the duration is positive or not. If the final date is after the origin date the duration is positive, otherwise it is negative. That does not mean we can compare it to zero, that is only used to determine the sign of the canonical standard. If the duration is negative, it is canonical only if all the attributes are negative. + +A way to compare two relative durations is to make them canonical from the same date, and then to compare the fields. It is the same as adding the durations to the same date, and to compare the final dates to each other. + +===About ''definite'' DATE_DURATIONs=== + +Definite durations are characterized by the attribute day. Whenever a duration has its attributes year and month equal to 0, this duration is then definite. On the other hand, if one of these two attributes is not 0, the duration is relative. + +The number of days between an origin date and the result of (date + duration) does not depend on the origin date. It is possible to compare definite date_duration to each other.The order is the one of day. + +A definite duration may be canonical or not. It is canonical if the number of day is small enough. + +===General description=== + +====Creation==== + +Two creation features are available: make takes three arguments (year, month, and day). If year and month are null, the duration will be definite; make_by_days takes only the number of day. The duration is automatically definite. + +====Comparison==== + +Features <, >, <=, and >= are available. If both instances are definite, numbers of days are compared. If one of them is non-definite, the result is False. + +====Element change==== + +Features set_day, set_month, and set_year are available to set one of these three attributes day, month, year. + +====Operations==== +* Add years, months and days with features year_add, month_add, and day_add. +* DATE_DURATION inherits from GROUP_ELEMENT. infix and prefix +, infix and prefix - are available to compose instances of each other. + +====Conversion==== +* to_canonical is used to get a new duration equivalent to the current one and canonical. It needs an argument from class DATE, which is the origin of calculations. +* to_definite is used to get a new duration equivalent to the current one and definite. As with the previous feature, one argument is needed. +* to_date_time is used to get an instance of DATE_TIME_DURATION. It will have the same date of the current duration and time set to zero. + +==DATE_TIME_DURATION== + +DATE_TIME_DURATION is client of DATE_DURATION and TIME_DURATION. Most of the common features described in DATE_DURATION are present in the class. The class deals with its attributes date and time in the same way as DATE_TIME. + +There are, as in DATE_DURATION, definite and non-definite durations. It is the date part which gives the definite non-definite status. Features canonical and to_canonical are present in DATE_TIME_DURATION. They have to deal with the attributes time. + +====Creation==== + +There are still several ways to create an instance: +* Provide values for all the components of date and time (make). +* Provide a value for day and values for all the components of time. The instance is then definite (make_definite). +* by gathering an instance of DATE with an instance of TIME (make_by_date_time). This feature copies the references of its arguments, so that if the time (or the date) is changed, the instance previously initialized will be also changed. If this effect has to be avoided, the use of twins is required. +* by encapsulating an instance of DATE (make_by_date). The attribute time is set to zero, i.e. 0:0:0. The attribute date is set with the same reference than the argument. + +====Access==== + +seconds_count is the amount of seconds of the time part only. To get the total amount of seconds of the current duration, first shift it to a definite duration, then multiply day by the number of seconds in day and add to it seconds_count. Take care that the duration is not more than 68 years. If it is, the number of seconds will be larger than 2 billion, which is the upper limit for INTEGER (4 bytes). + +====Comparison==== + +The rules are the same than those for DATE_DURATION. Features <, >, <=, and >= are available. If both instances are definite, numbers of days are compared. If one of them is non-definite, the result is False. + +====Element change==== + +It is possible to change reference of time and date with the features set_time and set_date. To change only one element (for example hour), features from TIME_DURATION or DATE_DURATION have to be used. + +====Operations==== +* DATE_TIME_DURATION inherits from GROUP_ELEMENT. infix and prefix +, infix and prefix - are available to compose instances to each other. +* Only day_add is present. To add only one element, features from TIME_DURATION or DATE_DURATION have to be used. + +====Conversion==== +* canonical and to_canonical are available in the class. To be canonical an instance of the class must have its attributes time and date canonical. Then time must have the same sign than the one of the current duration. The sign of the current instance is determined by adding it to the argument (from DATE_TIME). That will yield a final date. If this final date is after the origin (= the argument), the current duration is considered positive. Otherwise, it is considered negative. Finally time must be less than one day (if positive) or more than minus one day (if negative). to_canonical returns a duration equivalent to the current one (for the argument) and canonical. +* time_to_canonical looks like to_canonical but focuses mainly on time. It requires a definite duration so that it is possible to compare it to zero. It yields a definite duration equivalent to the current one with a canonical time. hour is then cut so that it stands in the range of one day (0 to 23 if positive and -23 to 0 if negative). The attribute day is also modified to keep the result equivalent to the current duration. time_to_canonical does not need any argument because only time and day are modified. + + + + diff --git a/documentation/18.11/solutions/dates-and-times/eiffeltime/eiffeltime-tutorial/index.wiki b/documentation/18.11/solutions/dates-and-times/eiffeltime/eiffeltime-tutorial/index.wiki new file mode 100644 index 00000000..c47f37c0 --- /dev/null +++ b/documentation/18.11/solutions/dates-and-times/eiffeltime/eiffeltime-tutorial/index.wiki @@ -0,0 +1,23 @@ +[[Property:title|EiffelTime Tutorial]] +[[Property:weight|0]] +[[Property:uuid|2c1bfedd-d515-cd6b-bd22-b06326fc98d8]] +The library EiffelTime is designed to provide software components for the effective modeling and manipulation of ''dates and times''. EiffelTime is built on three notions of time: + +* ''Absolutes'' are used to denote specific times. For example, an absolute time would be used to denote a particular event, like the starting time for a meeting, say 3:45 p.m. + +* ''Intervals'' denote the interval between events. So, an interval could express the fact that the meeting will run from 3:45 p.m. until 6:00 p.m. + +* ''Durations'' are used to represent the length of an interval. So, a duration can express the fact that the meeting lasts for 2 hours and 15 minutes. + + +As you read this documentation you will notice other concepts that are used in various classes. Here are some examples: +* There is a concept of ''origin'' which allows absolute instances to have an anchor in time. The origin for an absolute time is 00:00:00, the earliest time of day. The origin for dates is January 1, 1600. A similar notion, origin date, is used with certain date durations. +* Durations can be in ''canonical'' or ''non-canonical'' form. Canonical form means that the values for components of the duration fall into the expected range for each component. So, for example a time duration with a value for minutes that is larger than 59 would be in non-canonical form. +* Date durations can be ''relative'' or ''definite''. Definite date durations consist only of a number of days. Relative date durations can have values for a number of years and months. As you will see, comparison and arithmetic are affected by whether date durations are relative or definite. +You will read more about these and other EiffelTime concepts in the detailed pages that follow. + + +{{note|When you use [[EiffelStudio: Project settings window|project settings]] to [[Adding a library|add]] the EiffelTime library, you will see that there are library choices for different default formatting. The default EiffelTime library uses English formatting by default. However, you can choose the option that uses German or French default formatting by selecting the library whose name contains "german" or "french". }} + + + diff --git a/documentation/18.11/solutions/dates-and-times/eiffeltime/eiffeltime-tutorial/interval.wiki b/documentation/18.11/solutions/dates-and-times/eiffeltime/eiffeltime-tutorial/interval.wiki new file mode 100644 index 00000000..ed53b427 --- /dev/null +++ b/documentation/18.11/solutions/dates-and-times/eiffeltime/eiffeltime-tutorial/interval.wiki @@ -0,0 +1,41 @@ +[[Property:title|Interval]] +[[Property:weight|2]] +[[Property:uuid|d33d0216-fa71-60dc-f3b0-61ff42d621e6]] +Class INTERVAL [G -> ABSOLUTE] deals with intervals between two instances of the same class (an actual generic parameter substituting for G) which conforms to ABSOLUTE (specifically: DATE, TIME, DATE_TIME). +====Creation==== + +The creation procedure make (s, e: G) takes as arguments two instances of type G (or G's actual type from a declaration, e.g., my_time_interval: INTERVAL [TIME] ), which will become the start bound and the end bound of the INTERVAL. The start bound argument must be "before" the end bound argument (i.e., s <= e). make creates twins of its arguments so that the objects referenced as arguments will not change even if the values in the INTERVAL change. + +====Interval measurement==== + +The measurement of an interval is done by applying the query duration. Although the result of duration will be an instance of class DURATION, it will be a direct instance of the DURATION descendant that is appropriate to the actual value of the generic parameter G. So, for an INTERVAL [TIME], the result of duration will be a direct instance of TIME_DURATION. + +====Comparison==== + +* infix < and infix > compare two intervals on a "strict" basis. This means that int_1 < int_2 is True if int_1 starts and ends strictly before int_2. In other words, int_1 must have a start bound less than that of int_2 and an end bound less than that of int_2. +* infix <= and infix >= compare two intervals on a non-strict basis. So, int_1 <= int_2 is True if int_1 has a start bound less than or equal to that of int_2 and an end bound less than or equal to that of int_2. +* is_equal (or ~)performs object comparison. +* intersects is true if one (target) INTERVAL shares some of the same bounded area with a second (argument) INTERVAL. +* overlaps is similar to intersects with the exception that the argument INTERVAL has to be after the target INTERVAL. is_overlapped is the opposite of overlaps. +* meets and is_met are used to test whether two intervals have a common bound. +* strict_includes can be used to test whether the target INTERVAL strictly includes the argument INTERVAL. So, int_1.strict_includes (int_2) will be True if the start bound of int_2 is greater than the start bound of int_1 and the end bound of int_2 is less than the end bound of int_1. is_strict_included_by provides the opposite of strict_includes. +* includes and is_included_by test for inclusion on a non-strict basis. + +====Status Report==== + +* empty is True if the INTERVAL is empty, i.e., if the value of the start bound is equal to the value of the end bound. +* has, strict_before, strict_after, before, and after test the position of an element relative to the current interval. + +====Element change==== + +set_start_bound and set_end_bound are available to change the bounds. set_start_bound and set_end_bound create new objects from their arguments (twins), so that if these bounds are altered later, the original objects which had been referenced as arguments will not change. + +====Operations==== + +* union provides a new INTERVAL that includes the entire range covered by both the target INTERVAL and an argument INTERVAL which intersects the target. +* intersection returns a new INTERVAL that represents the area common to both the target INTERVAL and the argument INTERVAL. intersection returns Void if the target and argument do not intersect. +* gather requires that a target and argument INTERVAL have a common bound (i.e., int_1.meets (int_2) is True) and then returns a new INTERVAL with the union of the two. + + + + diff --git a/documentation/18.11/solutions/dates-and-times/eiffeltime/eiffeltime-tutorial/more-precision.wiki b/documentation/18.11/solutions/dates-and-times/eiffeltime/eiffeltime-tutorial/more-precision.wiki new file mode 100644 index 00000000..2521aca2 --- /dev/null +++ b/documentation/18.11/solutions/dates-and-times/eiffeltime/eiffeltime-tutorial/more-precision.wiki @@ -0,0 +1,42 @@ +[[Property:title|More precision]] +[[Property:weight|4]] +[[Property:uuid|fadf5bc2-bb72-f681-b9c4-bab7f0633209]] +The classes TIME and TIME_DURATION are designed to deal with time in high precision, limited only by platform numerical representation. + +The classes TIME and TIME_DURATION have an attribute fine_second of type DOUBLE which allows high precision. This attribute represents the number of seconds with fractions. From fine_second are calculated the values for second and fractional_second. second is the truncated-to-integer part of fine_second and fractional_second is the fractional part of fine_second. + +When fine_second is positive, 3.55 for example, second and fractional_second are both positive (3 and 0.55, respectively). When fine_second is negative (- 3.55 for example), then second and fractional_second are both negative (- 3 and - 0.55). + +Manipulation on second and fractional_second are in fact always made through fine_second. Users who do not want to deal with precision do not need to care about this. + +Features dealing with fine_second and fractional_second are described here. + +====Creation (common to TIME, TIME_DURATION)==== +* make_fine is similar to make except that it takes a DOUBLE for its third argument (instead of an INTEGER, as is the case with make). fine_second is then set to this value. +* make_by_fine_seconds is similar to make_by_seconds except that it takes a DOUBLE for an argument (instead of an INTEGER, as is the case withmake_by_seconds). + +====Measurement and access==== + +In TIME: + +* fine_seconds looks like seconds but it contains fractions. + +In TIME_DURATION: + +* fine_seconds_count looks like seconds_count but it contains fractions. + +====Element change==== +* Set fine_second directly with set_fine_second. +* Set fractional_second directly with set_fractionals. + + +{{note|Use of the feature set_second (in either TIME and TIME_DURATION) will result in fractional_second having a value of zero. }} + +====Operations==== + +* fine_second_add looks like second_add except that it takes a DOUBLE as an argument. + + + + + diff --git a/documentation/18.11/solutions/dates-and-times/eiffeltime/index.wiki b/documentation/18.11/solutions/dates-and-times/eiffeltime/index.wiki new file mode 100644 index 00000000..38241800 --- /dev/null +++ b/documentation/18.11/solutions/dates-and-times/eiffeltime/index.wiki @@ -0,0 +1,8 @@ +[[Property:title|EiffelTime]] +[[Property:weight|9]] +[[Property:uuid|3d96626f-11f3-67a2-dec6-69f7faf4a8d6]] +==EiffelTime Library== + +Type: Library
+Platform: Any + diff --git a/documentation/18.11/solutions/dates-and-times/index.wiki b/documentation/18.11/solutions/dates-and-times/index.wiki new file mode 100644 index 00000000..9391271c --- /dev/null +++ b/documentation/18.11/solutions/dates-and-times/index.wiki @@ -0,0 +1,7 @@ +[[Property:title|Dates and times]] +[[Property:weight|-13]] +[[Property:uuid|082fd8e1-b531-6cf1-3409-9cd9bc6483ad]] +== Date and time manipulation solutions== + + + diff --git a/documentation/18.11/solutions/gui-building/eiffelbuild/eiffelbuild-how-tos/create-object.wiki b/documentation/18.11/solutions/gui-building/eiffelbuild/eiffelbuild-how-tos/create-object.wiki new file mode 100644 index 00000000..7a9ec1df --- /dev/null +++ b/documentation/18.11/solutions/gui-building/eiffelbuild/eiffelbuild-how-tos/create-object.wiki @@ -0,0 +1,27 @@ +[[Property:title|Create an object]] +[[Property:weight|1]] +[[Property:uuid|b2ef8e81-a045-dce2-725f-c8db5ab1b6db]] +An EiffelBuild [[EiffelBuild Notation|object]] is a representation of an EiffelVision 2 component and its properties. + +To create a new instance of an object, [[EiffelBuild Notation|pick]] a type from the [[Type selector|type selector]] and [[EiffelBuild Notation|drop]] onto an existing [[EiffelBuild Notation|object]] (Accessible from the [[Layout constructor|layout constructor]] or [[Builder window|builder window]] ). You will only be able to complete the [[EiffelBuild Notation|drop]] if the targeted [[EiffelBuild Notation|object]] will accept a new object of the transported type. + +{{note|Once an [[EiffelBuild Notation|object]] has been [[Create an object|created]] , it will always be contained in a parent [[EiffelBuild Notation|object]] until [[Delete an object|deleted]] . }} + +==Creating Window and Dialog Objects== + +Window and dialog objects are created by picking a type from the [[Type selector|type selector]] and dropping into the [[Widget selector|widget selector]] . If the target of the drop is a directory within the widget selector, the new object is created within that directory, otherwise in the root of the project location. Window and dialog objects are generated as individual classes by EiffelBuild. + +{{note|If there are no other windows or directories in the project, the newly created object is set as the root window.}} + +==Creating objects for re-use== + +If you wish to create an object that may be re-used in multiple locations within your EiffelBuild project, pick the type from the [[Type selector|type selector]] and drop into the [[Widget selector|widget selector]] . This ensures that at generation time, the object is generated as a seperate class (as with all objects in the [[Widget selector|widget selector]] ). Objects within the [[Widget selector|widget selector]] may be used in a client fashion within other object structures as required, and any changes made to these objects are reflected at all locations in which they are used. + +{{seealso|
+[[Type selector|Type selector]]
+[[Reparent an Object|Reparent an object]]
+[[Delete an object|Delete an object]] }} + + + + diff --git a/documentation/18.11/solutions/gui-building/eiffelbuild/eiffelbuild-how-tos/delete-object.wiki b/documentation/18.11/solutions/gui-building/eiffelbuild/eiffelbuild-how-tos/delete-object.wiki new file mode 100644 index 00000000..6315531f --- /dev/null +++ b/documentation/18.11/solutions/gui-building/eiffelbuild/eiffelbuild-how-tos/delete-object.wiki @@ -0,0 +1,16 @@ +[[Property:title|Delete an object]] +[[Property:weight|2]] +[[Property:uuid|87dbc23d-4f9c-bd2a-8451-30031b494d37]] +To remove an [[EiffelBuild Notation|object]] from your EiffelBuild system, [[EiffelBuild Notation|pick]] the object you wish to delete, and [[EiffelBuild Notation|drop]] it on [[Image:icon-delete-small-color]] in the [[Main toolbar|main toolbar]] . + +You may also delete via the keyboard by pressing the delete key while the tool containing the objects representation has the focus. Whichever [[EiffelBuild Notation|object]] has the selection is deleted. + +{{note|To restore a deleted object, you may use the [[History|History]] }} + +{{seealso|
+[[History|History]]
+[[Type selector|Type selector]] }} + + + + diff --git a/documentation/18.11/solutions/gui-building/eiffelbuild/eiffelbuild-how-tos/eiffelbuild-starting-project/eiffelbuild-creating-new-project.wiki b/documentation/18.11/solutions/gui-building/eiffelbuild/eiffelbuild-how-tos/eiffelbuild-starting-project/eiffelbuild-creating-new-project.wiki new file mode 100644 index 00000000..619b26a1 --- /dev/null +++ b/documentation/18.11/solutions/gui-building/eiffelbuild/eiffelbuild-how-tos/eiffelbuild-starting-project/eiffelbuild-creating-new-project.wiki @@ -0,0 +1,24 @@ +[[Property:title|EiffelBuild: Creating a new project]] +[[Property:weight|0]] +[[Property:uuid|8668676c-a189-5512-319e-34d70d4039e3]] +When a project is not open in Build, there are only two menu options available. 'File' and 'Help'. To create a new project, select 'file', 'New project' as illustrated below: + +[[Image:new-project]] + +This will bring up a directory dialog from which you can select the directory in which you wish to create the new Build project. + +Selecting a directory that does not already contain a Build project will create a new project in that directory and the Build tools will become available for development of the newly created project. If a directory was selected that already contains a Build project, the following dialog will be displayed: + +[[Image:overwrite-project]] + +Selecting 'Ok' will create a new project, overwriting the existing project, and the Build tools will become available for development of the newly created project. + +Selecting 'Cancel' will return you to the directory selection dialog, from which you can select the directory in which you wish to create the new Build project. + +{{seealso|
+[[Retrieving a project from a Build project file|Retrieving a project from a Build project file]]
+}} + + + + diff --git a/documentation/18.11/solutions/gui-building/eiffelbuild/eiffelbuild-how-tos/eiffelbuild-starting-project/index.wiki b/documentation/18.11/solutions/gui-building/eiffelbuild/eiffelbuild-how-tos/eiffelbuild-starting-project/index.wiki new file mode 100644 index 00000000..4d7127fb --- /dev/null +++ b/documentation/18.11/solutions/gui-building/eiffelbuild/eiffelbuild-how-tos/eiffelbuild-starting-project/index.wiki @@ -0,0 +1,5 @@ +[[Property:title|EiffelBuild: Starting a project]] +[[Property:weight|0]] +[[Property:uuid|803e2034-dec3-340c-e68e-fdbaefac8a5a]] + + diff --git a/documentation/18.11/solutions/gui-building/eiffelbuild/eiffelbuild-how-tos/eiffelbuild-starting-project/retrieving-project-build-project-file.wiki b/documentation/18.11/solutions/gui-building/eiffelbuild/eiffelbuild-how-tos/eiffelbuild-starting-project/retrieving-project-build-project-file.wiki new file mode 100644 index 00000000..efada97a --- /dev/null +++ b/documentation/18.11/solutions/gui-building/eiffelbuild/eiffelbuild-how-tos/eiffelbuild-starting-project/retrieving-project-build-project-file.wiki @@ -0,0 +1,21 @@ +[[Property:title|Retrieving a project from a Build project file]] +[[Property:weight|1]] +[[Property:uuid|556cfd8a-f4df-9778-cbb1-eb4a9d795f01]] +When a project is not open in Build, there are only two menus available, 'File' and 'Help'. To retrieve an existing project, select 'file', 'Open Project + +[[Image:open-project]] + +A directory dialog will be displayed from which you can select the Build project file that you wish to retrieve. All build project files are named 'build_project.bpr' and are qualified by the directory in which they reside. + +You may also open a recent EiffelBuild project via the 'Recent Projects' entry of the 'file' menu as shown below: + +[[Image:recent-projects]] + +This list contains the most recent projects that have been used within EiffelBuild, and if none are available, this list is empty and the menu option disabled. + +{{seealso|
+[[EiffelBuild: Creating a new project|Creating a new project]] }} + + + + diff --git a/documentation/18.11/solutions/gui-building/eiffelbuild/eiffelbuild-how-tos/import-project.wiki b/documentation/18.11/solutions/gui-building/eiffelbuild/eiffelbuild-how-tos/import-project.wiki new file mode 100644 index 00000000..fb87c315 --- /dev/null +++ b/documentation/18.11/solutions/gui-building/eiffelbuild/eiffelbuild-how-tos/import-project.wiki @@ -0,0 +1,22 @@ +[[Property:title|Import a project]] +[[Property:weight|5]] +[[Property:uuid|ad0b96e1-ca74-5344-44f1-e066205fb76d]] +The contents of an existing project may be imported into the currently open project, permitting re-use of existing structures. All versions of EiffelBuild before 5.4 limited each project to a single titled window, with 5.4 removing this limitation. The ability to import multiple EiffelBuild projects into a single project is useful for maintaining larger systems with many windows. + +To import the contents of an existing project, select 'Import Project' from the 'File' menu as illustrated below: + +[[Image:import-project]] + +Upon selection of the menu item, a file dialog is displayed prompting for the EiffelBuild project to be imported (".bpr" files) . Selecting a valid EiffelBuild project file causes the import to commence, during which, EiffelBuild is unresponsive. Please be patient, as importing a large EiffelBuild project may take a little while, depending on the speed of the system. + +Upon completion of the import, there are two possible outcomes: +* No name clashes occurred: No names from the imported project clashes with those of the open project. In this case, notification of success is displayed in the status bar for a short period of time. +* One or more name clashes occurred: One or more objects or constants from the imported project had names that matched that of objects in the open project. As the names are used directly in the generated code, they must be unique within their scope (accessible within the code), and therefore EiffelBuild must resolve these clashes. A dialog is displayed on screen showing all the names that were resolved by EiffelBuild: +[[Image:import-project-clashes]] + +{{note|If a name clash occurs, the names of the imported project are modified, not the open project. }} + + + + + diff --git a/documentation/18.11/solutions/gui-building/eiffelbuild/eiffelbuild-how-tos/index.wiki b/documentation/18.11/solutions/gui-building/eiffelbuild/eiffelbuild-how-tos/index.wiki new file mode 100644 index 00000000..6928a2ff --- /dev/null +++ b/documentation/18.11/solutions/gui-building/eiffelbuild/eiffelbuild-how-tos/index.wiki @@ -0,0 +1,5 @@ +[[Property:title|EiffelBuild How To's]] +[[Property:weight|0]] +[[Property:uuid|1df547c8-ca5b-f014-5b4f-a39ecefaa746]] + + diff --git a/documentation/18.11/solutions/gui-building/eiffelbuild/eiffelbuild-how-tos/reparent-object.wiki b/documentation/18.11/solutions/gui-building/eiffelbuild/eiffelbuild-how-tos/reparent-object.wiki new file mode 100644 index 00000000..fd9fef60 --- /dev/null +++ b/documentation/18.11/solutions/gui-building/eiffelbuild/eiffelbuild-how-tos/reparent-object.wiki @@ -0,0 +1,22 @@ +[[Property:title|Reparent an Object]] +[[Property:weight|4]] +[[Property:uuid|bf920606-6a40-83fc-5069-034d32f8cd7a]] +To reparent an [[EiffelBuild Notation|object]] , you need to [[EiffelBuild Notation|pick]] the [[EiffelBuild Notation|object]] and [[EiffelBuild Notation|drop]] it on the [[EiffelBuild Notation|object]] you wish it to be parented in. The [[EiffelBuild Notation|object]] will be removed from its current parent, and inserted in the new parent at the next available position. + +When an [[EiffelBuild Notation|object]] is inserted into a parent, it is always added at the next available position. If you wish to place an [[EiffelBuild Notation|object]] at a particular position within a parent, you must hold down the '''Shift''' key, and drop on an [[EiffelBuild Notation|object]] already contained in parent, Your [[EiffelBuild Notation|object]] will then be inserted in the parent, in the position preceding the child [[EiffelBuild Notation|object]] that you dropped on. + +You can access [[EiffelBuild Notation|objects]] from both the [[Builder window|builder window]] and [[Layout constructor|layout constructor]] . + +{{note|Although window and dialog objects may be accessed within the [[Widget selector|widget selector]] , it is not possible to build into these objects, you should use the [[Layout constructor|layout constructor]] or [[Builder window|builder window]] directly in this situation. }} + +For more information about an [[EiffelBuild Notation|objects]] capacity and permitted children, see the [[EiffelVision Introduction|EiffelVision 2]] documentation. + +{{seealso|
+[[Create an object|Create an object]]
+[[Delete an object|Delete an object]]
+[[Builder window|Builder window]]
+[[Layout constructor|Layout constructor]] }} + + + + diff --git a/documentation/18.11/solutions/gui-building/eiffelbuild/eiffelbuild-how-tos/save-project.wiki b/documentation/18.11/solutions/gui-building/eiffelbuild/eiffelbuild-how-tos/save-project.wiki new file mode 100644 index 00000000..dd7b9f81 --- /dev/null +++ b/documentation/18.11/solutions/gui-building/eiffelbuild/eiffelbuild-how-tos/save-project.wiki @@ -0,0 +1,15 @@ +[[Property:title|Save a project]] +[[Property:weight|3]] +[[Property:uuid|f2c46797-34c5-5de7-fcad-3447c3db61f5]] +To save the project that is currently open, select '''Save''' from the '''File''' menu or click on [[Image:icon-save-color]] in the [[Main toolbar|main toolbar]] . + +Alternatively, you may use the keyboard shortcut - '''Ctrl+S''' + +{{note|If no changes have been made to the system, the save command will be disabled. }} + +{{seealso|
+[[EiffelBuild: Key shortcuts|Key shortcuts]] }} + + + + diff --git a/documentation/18.11/solutions/gui-building/eiffelbuild/eiffelbuild-reference/builder-window.wiki b/documentation/18.11/solutions/gui-building/eiffelbuild/eiffelbuild-reference/builder-window.wiki new file mode 100644 index 00000000..33887ab8 --- /dev/null +++ b/documentation/18.11/solutions/gui-building/eiffelbuild/eiffelbuild-reference/builder-window.wiki @@ -0,0 +1,33 @@ +[[Property:title|Builder window]] +[[Property:weight|7]] +[[Property:uuid|e82ca336-cab6-bc60-6ddc-b359a7c86811]] +The Builder window provides a view of the [[EiffelBuild Notation|objects]] in your system, in which the [[EiffelBuild Notation|objects]] may be manipulated. + +This window may either be shown or hidden (default). To change between these two states, click [[Image:icon-builder-window-color]] on the [[Main toolbar| main toolbar]] , or select '''Show/Hide builder window''' from the '''View''' menu. + +[[Image:builder-window]] + +The content of this window is a representation of the [[EiffelBuild Notation|objects]] you have defined in your project. Each [[EiffelBuild Notation|object]] is represented by the [[EiffelVision Introduction|EiffelVision 2]] control matching its type. For example, an [[EiffelBuild Notation|object]] representing an EV_BUTTON will be displayed in here using an EV_BUTTON. As this view provides direct access to the objects ( [[EiffelBuild Notation|Pick]] any of the controls in this window), it enables you to build your interface within a view which provides rich visual feedback. +Because this window is just a view of the [[EiffelBuild Notation|objects]] , it will be always synchronized with the [[Layout constructor| layout constructor]] . This means you can [[Reparent an Object| re-parent objects]] , using the [[EiffelBuild Notation|pick and drop]] transport method, seamlessly between the two views.
+ +{{note|Holding Ctrl while right clicking on an [[EiffelBuild Notation|object]] in the Builder Window creates a new [[Object editor|object editor]] targeted to the [[EiffelBuild Notation|object]] . Holding Ctrl and Shift while right clicking on an [[EiffelBuild Notation|object]] , highlights it within the [[Layout constructor|layout constructor]] .}} + +==Visual Differences== + +Although the builder window attempts to show you the interface you are developing, it is not a completely accurate representation (Unlike the [[Display window|display window]] ). The main difference is that all [[EiffelBuild Notation|objects]] representing descendents of EV_CONTAINER are parented in a frame. This was implemented so that you would be able to easily manipulate the containers. + +Imagine that this was not the case, and each container [[EiffelBuild Notation|object]] was just represented by an [[EiffelVision Introduction|EiffelVision 2]] object matching its type. Because these containers have no visible screen space when filled with children, manipulation of them would have been difficult, and the functionality of this view would be compromised. + +In the screenshot above, you can see that there are two [[EiffelBuild Notation|objects]] representing containers in your project, an EV_VERTICAL_BOX, and an EV_HORIZONTAL_BOX (Excluding the EV_TITLED_WINDOW [[EiffelBuild Notation|object]] represented by this window). + +The properties of the [[EiffelBuild Notation|objects]] in you system are always reflected in this window, with a few exceptions: +* `user_can_resize`, `maximum_width`, `maximum_height` and `title_string` are not reflected in this window. +* `minimum_width` and `minimum_height` are not reflected in any of the controls representing [[EiffelBuild Notation|objects]] within this window. + +{{seealso|
+[[Display window|Display window]]
+[[Layout constructor| Layout constructor]] }} + + + + diff --git a/documentation/18.11/solutions/gui-building/eiffelbuild/eiffelbuild-reference/component-selector.wiki b/documentation/18.11/solutions/gui-building/eiffelbuild/eiffelbuild-reference/component-selector.wiki new file mode 100644 index 00000000..d68dd816 --- /dev/null +++ b/documentation/18.11/solutions/gui-building/eiffelbuild/eiffelbuild-reference/component-selector.wiki @@ -0,0 +1,40 @@ +[[Property:title|Component selector]] +[[Property:weight|8]] +[[Property:uuid|c70ce7e5-e720-ca96-8f1f-5024e9d6dabe]] +The component selector allows you to build and retrieve user defined [[EiffelBuild Notation|components]] for use in your project. + +[[Image:component-selector]] + +==Creating a component== + +To define a new [[EiffelBuild Notation|component]] , [[EiffelBuild Notation|pick]] the [[EiffelBuild Notation|object]] that you wish to create the component from, and then [[EiffelBuild Notation|drop]] it anywhere in the component selector. The following dialog will appear: + +[[Image:component-namer]] + +Modify the suggested name as desired, and then click '''OK''' to create the new component. If you click '''Cancel''', the component will not be created. + +The component that has been created will contain enough information to allow a copy to be built of the existing object. This includes all the children of the original object (to any depth) and the properties (width, height, color etc)of all objects within the structure. The only properties of the objects that will not be set inside a component are the user defined names, and any events connected to the objects. + +==Using a component== +To create a new set of [[EiffelBuild Notation|objects]] from a [[EiffelBuild Notation|component]] , [[EiffelBuild Notation|pick]] the [[EiffelBuild Notation|component]] , and [[EiffelBuild Notation|drop]] onto an [[EiffelBuild Notation|object]] representation. If an object is full, or does not allow other objects of the new type to be contained, then you will not be able to [[EiffelBuild Notation|drop]] on it.
+ +If the [[EiffelBuild Notation|pick and drop]] completed successfully, then you should have a new set of objects matching the structure of the [[EiffelBuild Notation|component]] . + +==Deleting a component== + +To remove a [[EiffelBuild Notation|component]] from your EiffelBuild system, [[EiffelBuild Notation|pick]] it, and then [[EiffelBuild Notation|drop]] it on [[Image:icon-delete-small-color]] in the [[Main toolbar| main toolbar]] . + +{{note|The deletion of a [[EiffelBuild Notation|component]] cannot be undone. }} + +==Viewing a component== + +To view an existing component, use the [[Component viewer|component_viewer]] . + +{{seealso|
+[[Component viewer|Component_viewer]]
+[[Builder window|Builder window]]
+[[Layout constructor| Layout Constructor]] }} + + + + diff --git a/documentation/18.11/solutions/gui-building/eiffelbuild/eiffelbuild-reference/component-viewer.wiki b/documentation/18.11/solutions/gui-building/eiffelbuild/eiffelbuild-reference/component-viewer.wiki new file mode 100644 index 00000000..519ce1d0 --- /dev/null +++ b/documentation/18.11/solutions/gui-building/eiffelbuild/eiffelbuild-reference/component-viewer.wiki @@ -0,0 +1,30 @@ +[[Property:title|Component viewer]] +[[Property:weight|10]] +[[Property:uuid|51a8cb3e-7486-7ab4-b608-95acfedd32f7]] +The Component viewer allows you to view the structure of a [[EiffelBuild Notation|component]] without having to create new [[EiffelBuild Notation|objects]] from the [[EiffelBuild Notation|component]] . + +This tool is displayed in a separate window, and may either be shown or hidden (default). To change between these two states, click [[Image:icon-component-viewer-color]] on the [[Main toolbar| main toolbar]] , or select '''Show/Hide component viewer''' from the '''View''' menu. + +[[Image:component-viewer]] + +==Targeting a component== + +To target a [[EiffelBuild Notation|component]] into the tool, [[EiffelBuild Notation|pick]] the [[EiffelBuild Notation|component]] from the [[Component viewer|component_viewer]] , and [[EiffelBuild Notation|drop]] on the [[Image:icon-component-viewer-color]] displayed in the tool bar of the component viewer (See screenshots above). Any existing component displayed is simply removed. + +Alternatively, you can hold down the Ctrl key while starting a [[EiffelBuild Notation|pick]] on a [[EiffelBuild Notation|component]] in the [[Component selector| component_selector]] . This will automatically target the [[EiffelBuild Notation|component]] to the component viewer. If the viewer is currently hidden, it will also make it visible. + +==View types== + +Looking at the left-hand screenshot above, you can see that the [[Image:icon-component-display-view-color]] button is depressed, meaning the component viewer is in display view mode. Clicking on [[Image:icon-component-build-view-color]] will put the component viewer into build mode view as shown in the right-hand screenshot. These modes are mutually exclusive and are described below: +* '''Builder view''' - This view is similar to the view used by the [[Display window|display window]] . i.e. the [[EiffelVision Introduction|EiffelVision 2]] controls are displayed exactly as is defined in the [[EiffelBuild Notation|component]] . +* '''Display view''' - This view is similar to the view used by the [[Builder window|builder window]] . i.e. all [[EiffelVision Introduction|EiffelVision 2]] containers are represented by frames so they are immediately visible. This makes the actual structure represented by the [[EiffelBuild Notation|component]] completely visible. + +{{note|The type of the "root_object" within the component is displayed in the toolbar of the component viewer. }} + +{{seealso|
+[[Builder window|Builder window]]
+[[Layout constructor| Layout constructor]] }} + + + + diff --git a/documentation/18.11/solutions/gui-building/eiffelbuild/eiffelbuild-reference/constants.wiki b/documentation/18.11/solutions/gui-building/eiffelbuild/eiffelbuild-reference/constants.wiki new file mode 100644 index 00000000..296e2cd3 --- /dev/null +++ b/documentation/18.11/solutions/gui-building/eiffelbuild/eiffelbuild-reference/constants.wiki @@ -0,0 +1,177 @@ +[[Property:title|Constants]] +[[Property:weight|12]] +[[Property:uuid|f658bc39-da5f-1f12-ccf6-16b9c08732c2]] +EiffelBuild supports the use of constants, permitting you to define a particular value and use it comprehensively throughout your system. If a constant is in use, any changes are reflected immediately in all clients, providing a quick way of globally changing object properties. The Eiffel code generated by EiffelBuild, generates all constants as actual Eiffel constants for use in your system. + +The following constant types are supported by EiffelBuild: +* '''String''' - Representing the Eiffel STRING type. +* '''Integer''' - Representing the Eiffel INTEGER type. +* '''Directory''' - Representing a directory location, of type STRING. +* '''Pixmap''' - Representing an EV_PIXMAP, and either absolute, or built from a directory constant. +* '''Font''' - Representing a font, of type EV_FONT. +* '''Color''' - Representing a color, of type EV_COLOR. + + +==Constants Dialog== + +Modification to all constant types is performed from the constants dialog, accessible from the [[Main toolbar|main toolbar]] via the [[Image:icon-format-onces-color]] button. The constants dialog has the following appearance: + +[[Image:constants-dialog]] + +The screenshot above, shows the constants dialog displayed for a project containing twelve constants, a few of each available type. Each of the constants in the project are displayed in the multi column list occupying most of the dialog. + +The "Type", "Name" and "Value" fields displayed along the bottom of the dialog are used to permit addition and modification of constants. The "OK" button displayed in the top right hand corner of the dialog closes the dialog when modifications to the constants are complete. +===Adding a new constant=== + +To add a new constant to your project, select the type of the constant that you wish to add from the "Type" combo box. Depending on the type of constant selected, the remaining fields, and associated buttons will be modified appropriately, and the steps required to add the constant differ: +* '''String''' and '''Integer''' - Enter the name in the "Name" field, and value in the "Value" field. The "New" button is only enabled when the name is valid, and a valid entry is set, and clicking it adds the new constant. +* '''Directory''' - Enter a name for the directory in the "Name" field, and then select "New" which displays a choose directory dialog. Selecting a directory from this dialog and pressing "OK" adds the new directory constant to the project. +* '''Pixmap''' - Select the "New" button, which brings up the Pixmap Constant Dialog enabling you to select a constant. The use of this dialog is described further down this page. +* '''Font''' - Enter a name in the "Name" field, and then select "New" which displays a font dialog. Selecting a font from this dialog and pressing "OK" adds the new font constant to the project. +* '''Color''' - Enter a name in the "Name" field, and then select "New" which displays a color dialog. Selecting a color from this dialog and pressing "OK" adds the new color constant to the project. + +{{note|After adding a new constant, it is immediately displayed with all constants in the dialog. }} + + +===Modifying an existing constant=== + +To modify a constant that already exists, select the constant in the multi column list, and depending on the type of the constant, perform the following: +* '''String''' and '''Integer''' - Modify the value, which in turn, enables the "Modify" button, which must be selected for the value to change. Note that if you change the name, the "New" button is enabled as this will now add a new constant. +* '''Directory''' - Select the "Modify" button which displays a directory dialog, permitting selection of the new value. +* '''Pixmap''' - Select the "Modify" button which displays the Pixmap Constant Dialog, in a mode which permits you to select the new pixmap you wish to use. +* '''Font''' - Select the "Modify" button which displays a font dialog, permitting selection of the new font. +* '''Color''' - Select the "Modify" button which displays a color dialog, permitting selection of the new color. + +===Removing constants=== + +To remove a constant from the project, select it in the multi column list, and select the "Remove" button, or press the delete key. If the constant is not in use within the system, it will be removed, otherwise the following dialog is displayed: + +[[Image:constant-in-use]] + +As objects are reliant on the constant you are removing, you must confirm that you really wish to remove it from the system. If you select "OK", the constant is removed, and the object property relying on that constant is converted to a manifest value. For example, if you are using an Integer constant with a value of 100, and you remove the constant, the property no longer references the constant, but is set explicitly to 100. + +{{note|You may sort the constants displayed in the dialog, by clicking the associated column header. }} + +==String constant== + +A String constant represents an Eiffel STRING, and may be any valid STRING. For example, in the generated constants file, for a String constant named `modify_button_text`, the following code is generated: + + modify_button_text: STRING + -- `Result' is STRING constant named modify_button_text. + once + Result := "Modify" + end + + + +==Integer constant== + +A Integer constant represents an Eiffel INTEGER, and may be any valid INTEGER value. For example, in the generated constants file, for an Integer constant named `medium_padding`, the following code is generated: + + medium_padding: INTEGER + -- `Result' is INTEGER constant named medium_padding. + once + Result := 8 + end + +==Directory constant== + +A Directory constant is an Eiffel representation of a directory, as a STRING value. For example, in the generated constants file, for a Directory constant named `pixmap_location`, the following code is generated: + + pixmap_location: STRING + -- `Result' is DIRECTORY constant named pixmap_location. + once + Result := "C:\pixmaps" + end + + +==Pixmap constant== + +A pixmap constant is a representation of a pixmap image, and two types are available: +* '''Absolute''' - The generated code contains a constant of type EV_PIXMAP, built from a single, absolute path, based on the location of the original pixmap on disk as follows: + + main_pixmap: EV_PIXMAP + -- `Result' is PIXMAP constant named main_pixmap. + local + a_file_name: FILE_NAME + once + create Result + create a_file_name.make_from_string ("C:\pixmaps\main_pixmap.png") + -- Now set `Result' based on `a_file_name'. + set_with_named_file(Result, a_file_name) + end + +* '''Relative''' - The generated code contains a constant of type EV_PIXMAP, built from a file name and a directory constant. This type of pixmap constant is the most frequently used, as it is more flexible. By redefining the value of the directory constant on which it is based, your systems may easily account for the installation location of the pixmap. A relative Pixmap constant is generated as follows: + + main_pixmap: EV_PIXMAP + -- `Result' is PIXMAP constant named main_pixmap. + local + a_file_name: FILE_NAME + once + create Result + create a_file_name.make_from_string (pixmap_location) + a_file_name.set_file_name("main_pixmap.png") + -- Now set `Result' based on `a_file_name'. + set_with_named_file(Result, a_file_name) + end + +Where `pixmap_location` is the name of the Directory constant to which the pixmap is relative. + + +==Font constant== + +A Font constant represents an EV_FONT. For example, in the generated constants file, for a font constant named `times_new_roman`, the following code is generated: + + times_new_roman: EV_FONT + -- `Result' is EV_FONT constant named `times_new_roman'. + once + create Result + Result.set_family (feature {EV_FONT_CONSTANTS}.Family_roman) + Result.set_weight (feature {EV_FONT_CONSTANTS}.Weight_regular) + Result.set_shape (feature {EV_FONT_CONSTANTS}.Shape_regular) + Result.set_height_in_points (12) + Result.preferred_families.extend ("Times New Roman") + end + +==Color constant== + +A Color constant represents an EV_COLOR. For example, in the generated constants file, for a color constant named `red`, the following code is generated: + + red: EV_COLOR + -- `Result' is EV_COLOR constant named `red'. + once + Result := create {EV_COLOR}.make_with_8_bit_rgb (255, 0, 0) + end + +===Pixmap constant dialog=== + +The Pixmap Constant dialog is used to select pixmaps for addition to an EiffelBuild project, and is displayed from the Constants dialog when necessary. The Pixmap Constant dialog has the following appearance: + +[[Image:pixmap-selection-dialog]] + +An individual pixmap may be selected, or a whole directory of pixmaps may be selected from this dialog for addition. In the screenshot above, a directory containing two pixmaps was selected. The "Build from" option at the bottom of the dialog permits you to select if you wish to add an absolute or relative pixmap, and if multiple pixmaps are being added, the currently selected pixmap from the list above is active. The relative "DIRECTORY" for relative pixmaps is filled in automatically if EiffelBuild finds a directory constant in the system that matches the path chosen. If not, you may enter a name in this field to create a new directory matching the required path. If you do not enter a directory name for one or more relative pixmaps, upon closing the dialog, you will be prompted to enter a name for a directory constant used for these pixmaps. +{{note|If you are selecting new pixmaps, and they appear in the dialog as unchecked, it means that an equivalent pixmap already exists in the project. }} + + +==Loading constants== + +The generation of an EiffelBuild project creates two constants classes, an interface class and an implementation class, named to match the setting from the [[EiffelBuild: Project settings window|project settings]] . For example, if you have specified the name "constants" for the constants, two classes are generated, CONSTANTS and the implementation, CONSTANTS_IMP. + +By default, all constant values are hard coded into the implementation class, but it is possible to set these to be loaded from an external file upon execution of the generated system. To do this, the "Load constants from file" setting of the [[EiffelBuild: Project settings window|project settings]] must be checked, which causes a file "constants.txt" to be generated, containing the definitions of all Integer and String constant values. As the system is executed, the values of these constants are loaded from the file, and by providing different versions of the file, at the time of deployment, multiple languages may be accounted for in your generated system. + +==Using constants== + +Constants may be associated to properties of your [[EiffelBuild Notation|objects]] via an [[Object editor|object editor]] targeted to that [[EiffelBuild Notation|object]] . The [[Image:icon-format-onces-color]] button denotes the use of a constant value. For more information regarding using constants, in [[Object editor|object editors]] , see [[Object editor|object editor]] . + +When an EiffelBuild project is generated, all constants are added to a class, inherited by each window class. There is an "_IMP" and interface versions of these classes as with each window. For more information regarding the generation of constants, see [[EiffelBuild: Code Generation|code generation]] . +{{note|To modify pixmap constants based on the current installation of an EiffelBuild generated interface, simply redefine the Directory constant used to access the pixmaps within the interface constants class (not "_IMP"), which is not re-generated if it already exists. }} + +{{seealso|
+[[EiffelBuild: Code Generation|Code generation]]
+[[Object editor|Object editor]]
+[[EiffelBuild: Project settings window|Project settings]] }} + + + + + diff --git a/documentation/18.11/solutions/gui-building/eiffelbuild/eiffelbuild-reference/display-window.wiki b/documentation/18.11/solutions/gui-building/eiffelbuild/eiffelbuild-reference/display-window.wiki new file mode 100644 index 00000000..009a756f --- /dev/null +++ b/documentation/18.11/solutions/gui-building/eiffelbuild/eiffelbuild-reference/display-window.wiki @@ -0,0 +1,20 @@ +[[Property:title|Display window]] +[[Property:weight|6]] +[[Property:uuid|baed48d9-3a5a-c1a3-be32-dae7cab6071b]] +The Display window provides a view of the [[EiffelBuild Notation|objects]] in your system, but unlike the [[Layout constructor|layout constructor]] and [[Builder window|builder window]] , the objects cannot be manipulated. + +This window may either be shown or hidden (default). To change between these two states, click [[Image:icon-display-window-color]] on the [[Main toolbar|main toolbar]] , or select '''Show/Hide display window''' from the '''View''' menu. + +[[Image:display-window]] + +This view is provided so that you can really see what your project will look like when it has been generated and is running as a stand alone [[EiffelVision Introduction|EiffelVision 2]] system. + +All properties that have been set on the [[EiffelBuild Notation|objects]] in your project are set in the [[EiffelVision Introduction|EiffelVision 2]] control matching its type. + +{{seealso|
+[[Builder window|Builder window]]
+[[Layout constructor|Layout constructor]] }} + + + + diff --git a/documentation/18.11/solutions/gui-building/eiffelbuild/eiffelbuild-reference/eiffelbuild-code-generation.wiki b/documentation/18.11/solutions/gui-building/eiffelbuild/eiffelbuild-reference/eiffelbuild-code-generation.wiki new file mode 100644 index 00000000..a8627f53 --- /dev/null +++ b/documentation/18.11/solutions/gui-building/eiffelbuild/eiffelbuild-reference/eiffelbuild-code-generation.wiki @@ -0,0 +1,52 @@ +[[Property:title|EiffelBuild: Code Generation]] +[[Property:weight|15]] +[[Property:uuid|536487f0-f681-3812-87cf-3580c51ef8dd]] +To generate Eiffel code representing your system, select '''Generate code''' from the '''Project''' menu or click [[Image:icon-code-generation-color]] on the [[Main toolbar|main toolbar]] . +The length of time taken to generate your code is dependent on the speed of the system you are running, and the size of your interface, but typically takes a couple of seconds. A progress bar is displayed during the generation of your system. + +The code will be generated according to the options you selected in the [[EiffelBuild: Project settings window|project settings]] . + +==Generated classes== + +The generation of an EiffelBuild project causes the following files to be generated: +* A constants class and its respective implementation class. For example, if the constants class is named as "constants" in the [[EiffelBuild: Project settings window|project settings]] , two classes, CONSTANTS and CONSTANTS_IMP are generated. +* A class and implementation class for each window, dialog and "top level" widget in the system (each of which is contained in the [[Widget selector|widget selector]] ), named to correspond with the name attribute of the object. For example, for a window in the project named "main_window", the files MAIN_WINDOW and MAIN_WINDOW_IMP are generated. +* An optional file named "constants.txt" which contains definitions of all INTEGER and STRING constants. This is only generated if "Load constants from file" is selected in the [[EiffelBuild: Project settings window|project settings]] . The generated code loads the constants from this file, and allows simple modification for localization, i.e. for foreign languages provide a different version of this file with all strings converted. + +For each "top level" widget class in the system (contained in the [[Widget selector|widget selector]] ), the following class hierarchy is generated: + +[[Image:class-project-diagram]] + +If the "generate as client" option is selected for a particular object (changeable from the [[Object editor|object editor]] , only for objects contained in the [[Widget selector|widget selector]] ), a client supplier relationship exists between the generated widget class and the EiffelVision widget, as illustrated below: + +[[Image:class-project-diagram-client]] + +{{note|All other diagrams on this page show only the non client version of the settings, where the generated widget inherits from the EiffelVision class. }} + +==Project build type== + +If [[Build Tab|build type]] is selected as '''Project''' in the [[EiffelBuild: Project settings window|project settings]] , then all the classes listed above in "Generated classes" are generated, along with the following: +* A project configuration file called "build_project.ecf". +* An application class which launches the root window of the project. + +The generated files comprise a complete project with a configuration file enabling you to compile and execute the generated system as is. The following diagram illustrates the hierarchy of the generated project, showing only the root window of the project: + +[[Image:complete-project-diagram]] + + +==Modifying code after generation== + +The choice to generate an interface and an implementation class for the windows and constants was to enable modification of the interface using EiffelBuild, once you had hand edited code. The rule is that the implementation classes are re-generated every time, but the interface classes are not. It follows from this that you should not add hand written code to the implementation classes (ending in _IMP), as any changes you make will be lost when re-generation takes place. + +Using this mechanism, you can generate your initial system using EiffelBuild, and implement any event features that have been generated (in the interface) by EiffelBuild. If you then decide that you wish to modify the look and the feel of the interface, you can return to EiffelBuild, make the necessary adjustments and then re-generate the system. + +{{note|When returning to EiffelBuild to modify the interface, if you delete or rename controls, then it is quite possible that you will break your existing code. Care should be taken with all changes of this type. }} + +Looking at a generated system, you will see that the [[Object editor|events]] connected to your controls are defined as deferred in the implementation and actually implemented in the interface class. This means that if you return to EiffelBuild with a previously generated system, and add a new event to a control, then you will have to implement the definition in the interface class yourself (as the class interface class is not re-generated). + +{{seealso|
+[[EiffelBuild: Project settings window|Project settings]] }} + + + + diff --git a/documentation/18.11/solutions/gui-building/eiffelbuild/eiffelbuild-reference/eiffelbuild-general-interface-description/docking.wiki b/documentation/18.11/solutions/gui-building/eiffelbuild/eiffelbuild-reference/eiffelbuild-general-interface-description/docking.wiki new file mode 100644 index 00000000..edddc844 --- /dev/null +++ b/documentation/18.11/solutions/gui-building/eiffelbuild/eiffelbuild-reference/eiffelbuild-general-interface-description/docking.wiki @@ -0,0 +1,43 @@ +[[Property:title|Docking]] +[[Property:weight|3]] +[[Property:uuid|1434e995-4445-cbce-187c-cd7e078197e9]] +The docking mechanism permits customization of the EiffelBuild interface through the re-ordering of tools to suit your preferences. You may simply "drag" one of the supported tools to a new location as desired. The [[Type selector|Type Selector]] , [[Component selector|Component Selector]] and [[Widget selector|Widget Selector]] all support docking. + +==Performing a dock== + +To dock one of the three supported tools, press and hold the left mouse button on the title of the tool, and move the mouse so that it points to the new location for the tool. Upon releasing the mouse button, the dock completes, and based on the mouse location, the following may occur: +* '''Re-positioning in the main window''' - If the mouse is held over the three part vertical split area displayed to the left hand side of the EiffelBuild window, the position of the tool within this structure may be modified, providing simple re-ordering. A small grayed area indicates the insertion position of the tool, only displayed if the tools position will be changed upon release. The gray area indicating the new insertion point has the following appearance: + + +[[Image:docking-insert]] + + +In this case, the tool being docked will be moved to immediately above the component selector. If no feedback is provided regarding the insertion, upon releasing the mouse button to complete the dock, the tool is moved to an external window. +* '''Docking externally''' - Completing a dock while not above the left hand area of the main window, or if no insert feedback is provided, causes the tool to be moved from its current location to an external window. A tool that is docked externally has the following appearance: + + +[[Image:docked-external]] + + +The tool may now be freely moved to any location on screen, in the same fashion as you would move any standard window. The window in which the tool is contained is always displayed "on top" of the main window. There are two methods of restoring the dialog back to its original location in the main window: +** '''Docking back''' - Start a drag from the title of the tool, and point the mouse to the position in which you wish to insert the tool within the main window. If the position is valid, feedback (the gray bar) is displayed, and completing the dock closes the dialog, and re-inserts the tool. If no feedback is provided, the pointed position is not valid, and completing the dock simply moves the window to that position on screen. +** '''Closing the window''' - Clicking the cross displayed to the right hand side of the windows title bar causes the window to be destroyed, and the tool contained to be restored back to its original position within the main window. + + +{{note|The position of tools that have been docked, is maintained automatically between EiffelBuild sessions. When a new project is opened, they are restored to the positions that they had during the last use. }} + +==Main window with externally docked tools== + +The following screenshot illustrates the appearance of the main window with all dockable tools external: + + +[[Image:main-window-with-docked-tools]] + + +{{seealso|
+[[EiffelBuild: General interface description|General interface description]] }} + + + + + diff --git a/documentation/18.11/solutions/gui-building/eiffelbuild/eiffelbuild-reference/eiffelbuild-general-interface-description/eiffelbuild-key-shortcuts.wiki b/documentation/18.11/solutions/gui-building/eiffelbuild/eiffelbuild-reference/eiffelbuild-general-interface-description/eiffelbuild-key-shortcuts.wiki new file mode 100644 index 00000000..0837e1cd --- /dev/null +++ b/documentation/18.11/solutions/gui-building/eiffelbuild/eiffelbuild-reference/eiffelbuild-general-interface-description/eiffelbuild-key-shortcuts.wiki @@ -0,0 +1,46 @@ +[[Property:title|EiffelBuild: Key shortcuts]] +[[Property:weight|2]] +[[Property:uuid|ac57a648-456c-e423-e141-2f1f0eff95cb]] +Many operations in EiffelBuild do not require the use of the mouse. The same effect can be achieved through the keyboard only. + +This page gathers all the keyboard shortcuts available in the environment. + +==Key shortcut reference== +{| +|- +| '''Key shortcut''' +| '''action''' +|- +| ''- file shortcuts -'' +|- +| Ctrl+O +| Open project. +|- +| Ctrl+N +| New Project. +|- +| Ctrl+S +| Save project +|- +| ''- code generation shortcuts -'' +|- +| Ctrl+G +| Generate code from project. +|- +| ''- miscellaneous shortcuts -'' +|- +| Delete +| Delete object from currently selected tool. +|- +| Ctrl+T +| Tool always on top. +|} + +'''Note''': These shortcuts are not always available and are dependent on the state of EiffelBuild. For example, Ctrl+S does nothing if there is no modified project open. + +{{seealso|
+[[EiffelBuild: General interface description|General interface description]] }} + + + + diff --git a/documentation/18.11/solutions/gui-building/eiffelbuild/eiffelbuild-reference/eiffelbuild-general-interface-description/eiffelbuild-window-overview.wiki b/documentation/18.11/solutions/gui-building/eiffelbuild/eiffelbuild-reference/eiffelbuild-general-interface-description/eiffelbuild-window-overview.wiki new file mode 100644 index 00000000..33a5b7fa --- /dev/null +++ b/documentation/18.11/solutions/gui-building/eiffelbuild/eiffelbuild-reference/eiffelbuild-general-interface-description/eiffelbuild-window-overview.wiki @@ -0,0 +1,30 @@ +[[Property:title|EiffelBuild window overview]] +[[Property:weight|0]] +[[Property:uuid|7a64cd29-c65d-88e9-4eb2-4123825e4a86]] +==Window layout== + +The use of EiffelBuild is based around one main window which remains throughout the execution. The appearance of the main window is as follows: + +[[Image:main-window]] + +The window contains several different tools, highlighted below: +* The [[Type selector|type selector]] - Situated at the top left of the window, this tool contains all the available EiffelVision 2 types available for interface construction. +* The [[Component selector| component selector]] - Situated in the middle left of the window, below the [[Type selector|type selector]] , this tool contains all the user defined components. +* The [[Widget selector|widget selector]] - Situated in the bottom left of the window contains all of the EiffelVision 2 windows contained in the open project. Each of these windows are generated by EiffelBuild as separate classes. +* The [[Layout constructor| layout constructor]] tool - Situated in the middle of the window, this tool displays a graphical representation of the interface that is currently being built. +* The docked [[Object editor|object editor]] - Situated to the right hand side of the window, this object editor automatically targets itself to the selected [[EiffelBuild Notation|object]] in the [[Layout constructor| layout constructor]] . + +The [[Type selector|type selector]] , [[Component selector|component selector]] and [[Widget selector|widget selector]] may all be docked from their original position, permitting re-ordering and customization of the main window. Each of these may be docked external to the main window, permitting each to be displayed in their own movable window. For more information regarding the docking mechanism, see [[Docking|docking]] . + +{{seealso|
+[[Main toolbar| Main toolbar]]
+[[Layout constructor| Layout constructor]]
+[[Type selector|Type selector]]
+[[Object editor|Object editor]]
+[[Component selector| Component_selector]]
+[[Docking| Docking]]
+}} + + + + diff --git a/documentation/18.11/solutions/gui-building/eiffelbuild/eiffelbuild-reference/eiffelbuild-general-interface-description/index.wiki b/documentation/18.11/solutions/gui-building/eiffelbuild/eiffelbuild-reference/eiffelbuild-general-interface-description/index.wiki new file mode 100644 index 00000000..1a9cefb4 --- /dev/null +++ b/documentation/18.11/solutions/gui-building/eiffelbuild/eiffelbuild-reference/eiffelbuild-general-interface-description/index.wiki @@ -0,0 +1,5 @@ +[[Property:title|EiffelBuild: General interface description]] +[[Property:weight|2]] +[[Property:uuid|e16b365e-469e-e2ab-e955-7f4e81630fe3]] + + diff --git a/documentation/18.11/solutions/gui-building/eiffelbuild/eiffelbuild-reference/eiffelbuild-general-interface-description/main-toolbar.wiki b/documentation/18.11/solutions/gui-building/eiffelbuild/eiffelbuild-reference/eiffelbuild-general-interface-description/main-toolbar.wiki new file mode 100644 index 00000000..5742471d --- /dev/null +++ b/documentation/18.11/solutions/gui-building/eiffelbuild/eiffelbuild-reference/eiffelbuild-general-interface-description/main-toolbar.wiki @@ -0,0 +1,68 @@ +[[Property:title|Main toolbar]] +[[Property:weight|1]] +[[Property:uuid|66eef528-98c1-f238-9e67-694245941aca]] +At the top of the EiffelBuild development window, one toolbar is displayed by default, as shown below: +[[Image:toolbar]] + +The complete list of the icons in the toolbar is displayed below.
+{| +|- +| Icon +| Command +|- +| [[Image:icon-delete-small-color]] +| Delete [[EiffelBuild Notation|object]] / [[EiffelBuild Notation|component]] . +|- +| [[Image:icon-save-color]] +| [[Save a project|Save]] current project. +|- +| [[Image:icon-object-editor-color]] +| New [[Object editor|object editor]] +|- +| [[Image:icon-undo-color]] +| [[History|Undo]] last action. +|- +| [[Image:icon-cmd-history-color]] +| Display full [[History|history]] . +|- +| [[Image:icon-redo-color]] +| [[History|Redo]] last undone action. +|- +| [[Image:icon-code-generation-color]] +| [[EiffelBuild: Code Generation|Generate]] code. +|- +| [[Image:icon-system-color]] +| Display [[EiffelBuild: Project settings window|project settings]] . +|- +| [[Image:icon-builder-window-color]] +| Show/hide [[Builder window|builder window]] . +|- +| [[Image:icon-display-window-color]] +| Show/hide [[Display window|display window]] . +|- +| [[Image:icon-component-viewer-color]] +| Show/hide [[Component viewer|component viewer]] . +|- +| [[Image:icon-format-onces-color]] +| Display [[Constants|Constants]] dialog. +|- +| [[Image:icon-cut-color]] +| Cut selected object to clipboard. +|- +| [[Image:icon-copy-color]] +| Copy selected object to clipboard. +|- +| [[Image:icon-past-color]] +| Paste contents of clipboard. +|- +| [[Image:icon-clipboard-color]] +| View clipboard contents. +|} + + +The screenshot at the top of this page shows all of the buttons enabled. As the state of the currently open project changes, the state of each of these buttons is updated to reflect this. For example, immediately after saving the project, the save button is disabled until the project is modified again. + +{{note|It is not possible to customize the toolbar. }} + + + diff --git a/documentation/18.11/solutions/gui-building/eiffelbuild/eiffelbuild-reference/eiffelbuild-notation.wiki b/documentation/18.11/solutions/gui-building/eiffelbuild/eiffelbuild-reference/eiffelbuild-notation.wiki new file mode 100644 index 00000000..3a6cb4a7 --- /dev/null +++ b/documentation/18.11/solutions/gui-building/eiffelbuild/eiffelbuild-reference/eiffelbuild-notation.wiki @@ -0,0 +1,43 @@ +[[Property:title|EiffelBuild Notation]] +[[Property:weight|1]] +[[Property:uuid|82803f2a-4089-a426-29b8-1799b2a9c1a5]] +This page contains descriptions of terms found within the EiffelBuild documentation. + +==Object== + +An EiffelBuild object is a representation of a Vision2 component and its properties. When developing with EiffelBuild, you manipulate objects to build the desired interface. + +Each object type has a different set of properties that may be manipulated, and these correspond directly to the properties available within the [[EiffelVision Introduction|EiffelVision 2]] type. There is property which is specific to an EiffelBuild object, '''Name''' which is used for your identification purposes and as the attribute name in the generated code. + +For more information on manipulating objects within EiffelBuild, see: +* How to [[Create an object|create an object]] +* How to [[Reparent an Object| reparent an object]] . +* [[Object editor|Object editor]] for details on modifying object properties. + +Within EiffelBuild, there may be multiple views of a single object displayed simultaneously. Any modifications to an object will immediately update all views. Both the [[Layout constructor| layout constructor]] and the [[Builder window|builder window]] provide views of the objects within your project, and in these, the objects may be manipulated. The [[Display window|display window]] also provides a view of the objects in your system, except the objects cannot be manipulated from this view. It can be thought of as a preview of the project you are developing. + +==Component== + +EiffelBuild components are templates representing user defined object structures. From a component, you can quickly build a matching structure of objects. Components are available in EiffelBuild so that you do not repeatedly create the same structures over and over again while developing your projects. + +You specify a new component by creating it from an existing object structure. See [[Component selector| component_selector]] for more detailed instructions on the use of components. + +To view an existing component, use the [[Component viewer|component_viewer]] . + +It is not possible to modify a component once created, except to [[Component selector| delete]] it. + +==Pick and Drop== + +The pick and drop mechanism is one of Eiffel Software 's exclusive technologies and is provided by [[EiffelVision Introduction|EiffelVision 2]] . In EiffelBuild, it allows you to easily send data from a component of the interface to another. + +You can '''Pick''' a reference to a '''development object''', such as an object or component with a single click of the '''right''' mouse button. Then as you start moving the mouse around - not pressing any of its buttons - a pebble tracks the cursor position, and a line continuously connects the pebble to the object's original position. + +You may terminate this situation in either of two ways: +* If the pebble you are dragging is the regular cursor, you can right-click again to confirm the pick-and-drop and so effectively send the dragged development object to the targeted component. This is known as '''Dropping'''. +Right-clicking when the pebble is the '''no''' cursor, will only stop the pick-and-drop because the component you are hovering with the mouse does not accept your development object. + +* If, for any reason, you change your mind, you can cancel the pick-and-drop by left-clicking anywhere or by pressing the Escape key. + + + + diff --git a/documentation/18.11/solutions/gui-building/eiffelbuild/eiffelbuild-reference/eiffelbuild-preferences.wiki b/documentation/18.11/solutions/gui-building/eiffelbuild/eiffelbuild-reference/eiffelbuild-preferences.wiki new file mode 100644 index 00000000..e1256223 --- /dev/null +++ b/documentation/18.11/solutions/gui-building/eiffelbuild/eiffelbuild-reference/eiffelbuild-preferences.wiki @@ -0,0 +1,24 @@ +[[Property:title|EiffelBuild Preferences]] +[[Property:weight|14]] +[[Property:uuid|6255b3d8-392a-7cae-4c15-90515664a9b6]] +The EiffelBuild preferences are used to handle all user defined preferences. For example, each time a dialog is displayed with a "do not show again" option, your chosen setting is recorded in the preferences. Various properties of the EiffelBuild interface are recorded by the preferences, on a user by user basis, permitting you to adapt the behavior of EiffelBuild to suit your needs. + +During use of EiffelBuild, many settings and options that you select, will modify the preferences, ensuring the desired behavior is maintained. To access all of the available EiffelBuild preferences, you may use the Preferences dialog, accessible from the "View", "Preferences", "Preferences..." menu option. The preference dialog has the following appearance: + +[[Image:preferences-dialog]] + +To the left hand side of the dialog is a tree, containing the preferences structure, while on the right, the actual preferences in the selected tree node are displayed. To modify the value of a particular preference, double click on its "Literal Value" which displays a small dialog permitting modification of the value. Dependent on the type of the property, the dialog displayed may change appropriately. + +The button marked "Restore Defaults" in the lower left hand corner of the dialog, may be selected to restore the preferences back to their defaults when EiffelBuild was first launched. + +When you have finished modifying the preferences, select the "Close" button to close the dialog. + +{{note|The preferences are saved automatically by EiffelBuild, even if the open project is not saved, the preferences are saved whenever a property changes. }} + +{{seealso|
+[[EiffelBuild: General interface description|General interface description]]
+[[EiffelBuild Reference|EiffelBuild reference]] }} + + + + diff --git a/documentation/18.11/solutions/gui-building/eiffelbuild/eiffelbuild-reference/eiffelbuild-project-settings-window/build-tab.wiki b/documentation/18.11/solutions/gui-building/eiffelbuild/eiffelbuild-reference/eiffelbuild-project-settings-window/build-tab.wiki new file mode 100644 index 00000000..decb15fd --- /dev/null +++ b/documentation/18.11/solutions/gui-building/eiffelbuild/eiffelbuild-reference/eiffelbuild-project-settings-window/build-tab.wiki @@ -0,0 +1,42 @@ +[[Property:title|Build Tab]] +[[Property:weight|0]] +[[Property:uuid|ca866291-46b8-6b7f-2492-37c228d53a8f]] +This tab contains information about the type of project you wish to build, and associated information. + +Here is the appearance of the Build tab when 'build type' is selected as 'Project': + +[[Image:project-build]] + +If 'build'_type' is selected as 'Class', then the tab will have the following appearance: + +[[Image:project-build-class]] + +The options available in this tab are as follows: +* '''Build type''' +Select 'Project' if you wish to generate a complete project including an ace file, and an application class, which will launch the GUI you are developing. + +Select `Class` if you wish to generate a single class that represents the GUI you are developing. This option is useful if you wish to incorporate your current project into an existing EiffelVision 2 system. + +* '''Always rebuild ace''' +This option causes the ace file to be completely re-generated every time you generate your project. If you do not wish the ace file to be re-generated, then disable this option. This check box is only available if 'build type' is set to 'project'. + +* '''Project name''' +This entry will be added to the generated ace file as the SYSTEM attribute. The executable built from compiling this ace file will have this name. This option is only available if you have specified 'build_type' as 'Project'. + +* '''Application class name''' +This entry will be the class name for the generated EiffelVision 2 application which will launch your GUI. This option is only available if you have specified 'build_type' as 'Project'. + +* '''Constants class name''' +This entry is used as the name of the constants class generated by EiffelBuild to define all [[Constants|constants]] contained in your project. Two classes are actually generated from this name, an implementation and an interface class. For example, if you specify a name "constants", two classes, CONSTANTS_IMP and CONSTANTS (inheriting from CONSTANTS_IMP) are generated, and all other classes generated by EiffelBuild, inherit CONSTANTS for access to these constants. + + + +{{seealso|
+[[EiffelBuild: Code Generation|Code generation]]
+[[EiffelBuild: Project settings window|Project settings window]]
+[[Generation Tab|Generation tab]]
+}} + + + + diff --git a/documentation/18.11/solutions/gui-building/eiffelbuild/eiffelbuild-reference/eiffelbuild-project-settings-window/generation-tab.wiki b/documentation/18.11/solutions/gui-building/eiffelbuild/eiffelbuild-reference/eiffelbuild-project-settings-window/generation-tab.wiki new file mode 100644 index 00000000..144a85c6 --- /dev/null +++ b/documentation/18.11/solutions/gui-building/eiffelbuild/eiffelbuild-reference/eiffelbuild-project-settings-window/generation-tab.wiki @@ -0,0 +1,19 @@ +[[Property:title|Generation Tab]] +[[Property:weight|1]] +[[Property:uuid|a332d8b6-3156-086b-0c71-a92b1725322d]] +This tab contains information about the available code generation options. + +Here is the appearance of the Generation tab with default settings for a Build project: + +[[Image:project-generation]] + +The options available in this tab are as follows: +* '''Attribute declarations''' +** '''Local''' - All attributes (corresponding to widgets and items generated by EiffelBuild) are declared as local variables. +** '''Attributes''' -- All attributes are declared as attributes of the class with the following export status: +*** '''Exported''' - All attributes are exported to ANY. +*** '''Export only named''' - Only those attributes that have been named are exported to ANY while unnaned attributes are not exported.. +*** '''Export None''' - None of the attributes are exported. +** '''Grouped''' - Should different objects of same type be declared individually, or grouped?
+ + diff --git a/documentation/18.11/solutions/gui-building/eiffelbuild/eiffelbuild-reference/eiffelbuild-project-settings-window/index.wiki b/documentation/18.11/solutions/gui-building/eiffelbuild/eiffelbuild-reference/eiffelbuild-project-settings-window/index.wiki new file mode 100644 index 00000000..854c8c09 --- /dev/null +++ b/documentation/18.11/solutions/gui-building/eiffelbuild/eiffelbuild-reference/eiffelbuild-project-settings-window/index.wiki @@ -0,0 +1,23 @@ +[[Property:title|EiffelBuild: Project settings window]] +[[Property:weight|13]] +[[Property:uuid|7844e875-28d8-8710-385c-c62d1be6a9e0]] +This is where global settings regarding your project are going to be made. In here you can specify: +* The type of project you wish to generate +* The system name +* Class names +* Code generation options + +The project window can be raised by clicking [[Image:icon-display-window-color]] on the [[Main toolbar| main toolbar]] , or by selecting '''Settings...''' from the '''Project''' menu. + +The window is organized as two tabs: +# [[Build Tab|Build]] +# [[Generation Tab|Generation]] + +All options are enabled and saved into the project settings file, 'build_project.bpr' as soon as the window is closed. + +{{seealso|
+[[EiffelBuild: Code Generation|Code generation]] }} + + + + diff --git a/documentation/18.11/solutions/gui-building/eiffelbuild/eiffelbuild-reference/history.wiki b/documentation/18.11/solutions/gui-building/eiffelbuild/eiffelbuild-reference/history.wiki new file mode 100644 index 00000000..517534fc --- /dev/null +++ b/documentation/18.11/solutions/gui-building/eiffelbuild/eiffelbuild-reference/history.wiki @@ -0,0 +1,36 @@ +[[Property:title|History]] +[[Property:weight|11]] +[[Property:uuid|5bc08c08-be0d-bebd-dcfe-ec20b40c1e26]] +EiffelBuild has an limitless undo/redo mechanism built in. However, this mechanism only applies to the structure of the [[EiffelBuild Notation|objects]] you are developing in your project. + +For example, every time you [[Create an object|create]] , [[Reparent an Object| reparent]] or [[Delete an object|delete]] an [[EiffelBuild Notation|object]] in your project, this is recorded in the history. If you modify properties of an [[EiffelBuild Notation|object]] (Using an [[Object editor|object editor]] ), these modifications are not recorded in the history. + +==Undo== + +To undo a change, click [[Image:icon-undo-color]] on the [[Main toolbar| main toolbar]] You can repeatedly undo, until you get to the beginning of the history, at which point, this button is disabled. + +==Redo== + +To redo a change (only applicable after one ore more undo's), click [[Image:icon-redo-color]] on the [[Main toolbar| main toolbar]] . You can repeatedly redo, until the history becomes current again, and at which point, this button is disabled. + +==History window== + +[[Image:history-window]] + +The screenshot above shows the appearance of the history window. + +This visibility of the window may be toggled by clicking [[Image:icon-cmd-history-color]] on the [[Main toolbar| main toolbar]] . You may also select '''History''' from the '''View''' menu to show the history window, and click the '''Close''' button to close the window manually. + +Looking at the screenshot above, you will see that the last action in the history list is selected. This is always the case while working, until you start undoing your changes. To go back six steps, so that (in this case), there is just the one BUTTON added to the HORIZONTAL_BOX, you could click the undo button on the [[Main toolbar| main toolbar]] six times, or you can simply select the third item in this list. both have the same effect. You can also redo by selecting an item below the currently selection in the history list (Only possible after an undo). + +If you execute an action which will be added to the history while the history is not at the final position, all history events after this current position will be removed, and the history will be up to date again. + +{{note|If you use the history list to move through many recorded actions at once, there may be a slight delay dependent on the systems complexity and steps moved. }} + +{{seealso|
+[[Builder window|Builder window]]
+[[Layout constructor| Layout constructor]] }} + + + + diff --git a/documentation/18.11/solutions/gui-building/eiffelbuild/eiffelbuild-reference/index.wiki b/documentation/18.11/solutions/gui-building/eiffelbuild/eiffelbuild-reference/index.wiki new file mode 100644 index 00000000..2ac298a0 --- /dev/null +++ b/documentation/18.11/solutions/gui-building/eiffelbuild/eiffelbuild-reference/index.wiki @@ -0,0 +1,5 @@ +[[Property:title|EiffelBuild Reference]] +[[Property:weight|1]] +[[Property:uuid|15b53149-5a31-9a1a-e9ad-739174678064]] +EiffelBuild is the high-level interface builder by Eiffel Software which allows you to develop graphical user interface (GUI) applications simply and quickly. + diff --git a/documentation/18.11/solutions/gui-building/eiffelbuild/eiffelbuild-reference/layout-constructor.wiki b/documentation/18.11/solutions/gui-building/eiffelbuild/eiffelbuild-reference/layout-constructor.wiki new file mode 100644 index 00000000..0ce9b349 --- /dev/null +++ b/documentation/18.11/solutions/gui-building/eiffelbuild/eiffelbuild-reference/layout-constructor.wiki @@ -0,0 +1,57 @@ +[[Property:title|Layout constructor]] +[[Property:weight|3]] +[[Property:uuid|eb93c9bf-53b3-6718-5c30-d17133633c6f]] +The layout constructor provides a view of the [[EiffelBuild Notation|objects]] you have defined in your system, in which the [[EiffelBuild Notation|objects]] may be manipulated. The root node of the tree is the object currently selected within the [[Widget selector|widget selector]] and objects may be added/moved within the displayed widget structure by picking and dropping the objects as required. For example, in the screenshot below, you could add another list to the vertical box, by picking a list from the [[Type selector|type selector]] and dropping it on the vertical box object. + + +[[Image:layout-constructor]] + + +Each item in the tree represents one object. The screenshot above represents the following [[EiffelVision Introduction|EiffelVision 2]] interface definition - An EV_TITLED_WINDOW containing one child, of type EV_VERTICAL_BOX. Within the vertical box there is an EV_HORIZONTAL_BOX and an EV_LIST. The list is empty, but the horizontal box contains three different objects of type EV_BUTTON. + +{{note|The widget displayed as the root of the Layout Constructor is the currently selected object in the [[Widget selector|Widget Selector]] . To edit the contents of a different widget, select the widget you wish to manipulate from the [[Widget selector|widget selector]] .}} + +The information displayed, only shows you the structure of the [[EiffelBuild Notation|objects]] , and although it gives you an indication of the final appearance of the interface you are building, you cannot see the details of the interface. i.e. color, sizes, tool tips etc. To view an accurate representation of the widget structure you are building, show the [[Display window|Layout window]] . + +All [[EiffelBuild Notation|objects]] displayed in the Layout Constructure are [[EiffelBuild Notation|pickable]] , so can be easily manipulated, e.g. [[Delete an object|deleted]] or [[Reparent an Object|reparented]] . + +{{note|If the [[EiffelBuild Notation|object]] in the tree has the '''Name''' property set, then the text corresponds to the name, otherwise, the text is the type of the [[EiffelBuild Notation|object]] . }} + +If you have just started a new project, then the layout constructor will only contain one tree item, TITLED_WINDOW. +==Selection== + +The currently selected object within the Layout Constructor is automatically targetted to the docked [[Object editor|object editor]] which is situated to the right hand side of the main EiffelBuild Window. This enables you to quickly and easily edit the properties of the selected object. Note that Ctrl-right clicking on an object in the Layout Constructor displays a floating [[Object editor|object editor]] targeted to that object. + +==Expanding/Collapsing== + +To Expand all of the items displayed in the layout constructor, select '''Expand layout tree''' from the '''View''' menu, or select the small cross icon displayed at the top of the tool. + +Similarly, if you wish to collapse all of the items in the layout constructor, select '''Collapse layout tree''' from the '''View''' menu. + + +==Highlighting an Object== +An [[EiffelBuild Notation|object]] contained in a system may be highlighted in the Layout Constructor by [[EiffelBuild Notation|picking]] it, and [[EiffelBuild Notation|dropping]] on the button displayed at the top of the Layout Constructor. Clicking this button with the mouse has no effect. The ability to highlight an object in this fashion proves to be particularly useful when building directly into the [[Builder window|builder window]] , as a particular object may be quickly highlighted in the Layout Constructor, and its properties edited. + +==Locked Objects== + +Objects that are instances of other objects are displayed as locked objects within the Layout Constructor as illustrated below: + + +[[Image:layout-constructor-locked]] + + +The object of type OK_CANCEL_BUTTONS is a locked instance of another object as illustrated by the locked icon displayed on top of it's type icon. As a locked object is simply an instance of another object, its internal structure may not be manipulated directly within the Layout Constructor. To change the structure of a locked object, you must directly change the object of which it is an instance. +To add a locked object to your interface, simply pick the object that you wish to re-use from the [[Widget selector|widget selector]] and drop it into the desired parent object within the Layout Constructor. In this case, the instance of the OK_CANCEL_BUTTONS object is actually comprised of a number of widgets which may only be modified through manipulation of the original OK_CANCEL_BUTTONS_OBJECT. Changes made to this original object are then applied to all instances within your interface structures. + +You may convert an existing widget structure into a locked instance of a widget by picking the object to be used as the root of the structure (may not be locked) and dropping it into the [[Widget selector|widget selector]] . This creates a new "top level" object within the [[Widget selector|widget selector]] and places a locked instance of this at the original location in the widget structure where it was picked from. + +{{note|Double clicking on a locked object within the Layout Constructor, targets the object of which it is an instance to the Layout Constructor. }} + +{{seealso|
+[[Builder window|Builder window]]
+[[Object editor|Object editor]]
+[[Display window|Layout window]] }} + + + + diff --git a/documentation/18.11/solutions/gui-building/eiffelbuild/eiffelbuild-reference/object-editor/index.wiki b/documentation/18.11/solutions/gui-building/eiffelbuild/eiffelbuild-reference/object-editor/index.wiki new file mode 100644 index 00000000..e6415692 --- /dev/null +++ b/documentation/18.11/solutions/gui-building/eiffelbuild/eiffelbuild-reference/object-editor/index.wiki @@ -0,0 +1,73 @@ +[[Property:title|Object editor]] +[[Property:weight|5]] +[[Property:uuid|f00025e2-f39b-d0a2-9b2b-207768771905]] +An object editor is a tool which allows you to edit the properties of a selected [[EiffelBuild Notation|object]] . Common properties include minimum width and height, color, text etc. + +An object editor can only reference one [[EiffelBuild Notation|object]] at once, and when not empty, it is considered to be "targeted" to the [[EiffelBuild Notation|object]] whose properties it references. + +[[Image:object-editor]] + +The screenshot above shows a floating object editor. The docked object editor is almost identical except that it is located within the EiffelBuild main window. + +==Docked object editor== + +The docked object editor is displayed to the right hand side of the EiffelBuild main window. This editor is always displayed and is permanently linked to the [[Layout constructor| layout constructor]] . This means that whenever the selected [[EiffelBuild Notation|object]] changes in the [[Layout constructor| layout constructor]] , the docked object editor becomes targeted to this [[EiffelBuild Notation|object]] . + +==Floating object editors== + +These object editors appear in their own window, and you may open as many of these as you wish. + +To open a new floating object editor, [[EiffelBuild Notation|drop]] an [[EiffelBuild Notation|object]] on [[Image:icon-object-editor-color]] , displayed in the [[Main toolbar| main toolbar]] and also in each existing object editor. The new object editor will then be targeted to the [[EiffelBuild Notation|object]] that was [[EiffelBuild Notation|dropped]] . + +{{note|If the [[EiffelBuild Notation|object]] targeted to floating object editor is deleted, then the editor will be destroyed. This helps stop the screen becoming cluttered with empty editors. }} + +As a shortcut to a complete [[EiffelBuild Notation|pick and drop]] transport, you may hold down the Ctrl key while starting the [[EiffelBuild Notation|pick]] , which will immediately open a new floating object editor targeted to the [[EiffelBuild Notation|object]] you clicked. + +==General use== + +When an object editor is targeted to an [[EiffelBuild Notation|object]] , you will see that controls are available within the editor to customize that [[EiffelBuild Notation|object]] . Although every different type of [[EiffelBuild Notation|object]] will have different sets of properties that may be modified, the manipulation of these properties is as standardized as possible. Below are some general rules that apply: +* String properties inputted via a text field are updated within the object every time a key is pressed +* Integer properties inputted via a text field are only updated within the object when return is pressed, or the input box looses the focus. +* Almost without exception, a push button which controls a property, will open up a dialog, allowing the property to be edited. Examples are colors, pixmaps and events. +* If when you attempt to modify a property, it returns back to its original value, it means that the value you attempted to enter was invalid. For example, looking at the screen show above, if you enter -50 into the minimum_height text field and press return, it will revert back to 23. This is because the minimum_height of an EV_BUTTON may not be set to less than 0. To find allowable values for properties of an [[EiffelBuild Notation|object]] , consult the [[EiffelVision Introduction|EiffelVision 2]] documentation. + +All properties that may be manipulated in an object editor correspond directly to a property of the [[EiffelVision Introduction|EiffelVision 2]] control that is represented by the [[EiffelBuild Notation|object]] (Displayed in an object editor as '''type'''). There is one exception to that rule though, and that is the '''Name''' field which is specific to EiffelBuild. This field is used for your identification of the [[EiffelBuild Notation|object]] and as the attribute name in the generated code. For example, when EiffelBuild generates code corresponding to the [[EiffelBuild Notation|object]] targeted in the editor shown above, it would declare the EiffelVision 2 component as - button1: EV_BUTTON + +{{note|You may have as many object editors targeted to the same [[EiffelBuild Notation|object]] as you wish. Whenever a change is made to the [[EiffelBuild Notation|object]] through one of the editors, all other editors targeted to that [[EiffelBuild Notation|object]] are synchronized. }} + +==Using Constants== + +All fields that may use constants have a button marked with the constants symbol [[Image:icon-format-onces-color]] , which when selected, modifies the field to allow selection of the desired constant. A combo box is displayed with all valid constants (matching the type of the property) displayed, from which you may select the constant you wish to use. To remove the use of the constant, simply press the constants button again, which removes the constant, and sets the property to a manifest value representing the previous value of the last selected constant. + +==Advanced property manipulation== + +Although many of the properties of [[EiffelBuild Notation|objects]] are relatively simple, and can be manipulated with STRING or INTEGER values, there are others that require more complicated control mechanisms. The following [[EiffelBuild Notation|object]] properties have more complicated interfaces warranting further explanation: +* [[Merging radio button groups]] +* [[Positioning table children]] +* [[Positioning fixed children]] + +For all "top level" objects (those contained within the [[Widget selector|widget selector]] which are to be generated as individual classes), a check button marked "Generate as client" is available towards the top of the Object Editor. If this is checked, the generated class uses the widget type of the object as a client, otherwise it inherits directly from the widget's class. + +==Event connection== + +As well as being able to manipulate the standard properties of an [[EiffelBuild Notation|object]] , facilities are provided for connecting to the events of an [[EiffelBuild Notation|object]] . Looking at the object editor screenshot above, you will see that there is a button marked '''Select events''' which is also available in all targeted editors. + +{{note|The button will be marked '''Modify events''' when one or more events are already selected for the current [[EiffelBuild Notation|object]] . }} + +Clicking this button will cause the following dialog to be displayed: + +[[Image:event-selection-dialog]] + +Looking at the screenshot above, you will see that this dialog contains all the action_sequences available for the EV_BUTTON to which the object editor is targeted. + +If you check a button connected with one of the action sequences, you will be then able to enter the name of a feature that you wish to connect to the action sequence. The screenshot above shows the user has connected a feature named `button_pressed` to the `select_actions`. When [[EiffelBuild: Code Generation|code is generated]] , this will cause EiffelBuild to generate an empty feature named `button_pressed` already connected to the `select_actions` of the button. + +{{note|You will only be allowed to enter valid and unique Eiffel feature names. If a name is invalid, it will be highlighted in red, and a dialog will warn you when you attempt to close the dialog. }} + +{{seealso|
+[[Create an object|Create an object]]
+[[Delete an object|Delete an object]] }} + + + + diff --git a/documentation/18.11/solutions/gui-building/eiffelbuild/eiffelbuild-reference/object-editor/merging-radio-button-groups.wiki b/documentation/18.11/solutions/gui-building/eiffelbuild/eiffelbuild-reference/object-editor/merging-radio-button-groups.wiki new file mode 100644 index 00000000..3873bebb --- /dev/null +++ b/documentation/18.11/solutions/gui-building/eiffelbuild/eiffelbuild-reference/object-editor/merging-radio-button-groups.wiki @@ -0,0 +1,26 @@ +[[Property:title|Merging radio button groups]] +[[Property:weight|0]] +[[Property:uuid|069fa6c5-ed77-9cd3-f565-d41d43c406fe]] +If the current [[Object editor|object editor]] contains an EV_CONTAINER [[EiffelBuild Notation|object]] , then the following control will be available: + +[[Image:empty-radio-merge]] + +With this control, you can merge two or more instances of EV_CONTAINER together, so that any EV_RADIO_BUTTON contained are grouped. + +==Merging== + +To create a new merge, [[EiffelBuild Notation|pick]] an [[EiffelBuild Notation|object]] of type EV_CONTAINER, and [[EiffelBuild Notation|drop]] it anywhere on the control. This will merge the radio button group of the EV_CONTAINER referenced in the object editor, to the transported one. Each merge, will show up as a new item in the control. +{{note|Container objects may only be grouped once, and as such, you will not be permitted to add an [[EiffelBuild Notation|object]] that is already contained in the list. }} + + +==Unmerging== + +To unmerge a container [[EiffelBuild Notation|object]] from a group, [[EiffelBuild Notation|pick]] the representation of that [[EiffelBuild Notation|object]] from the list, and [[EiffelBuild Notation|drop]] on [[Image:icon-delete-small-color]] . This will unmerge the [[EiffelBuild Notation|object]] from the current group of containers. + +==Locating group member== + +To locate the [[EiffelBuild Notation|object]] referenced by a list item in the control, left click the item that you wish to locate. This will display the representation of the associated [[EiffelBuild Notation|object]] within the [[Layout constructor|layout constructor]] , and the associated icon will be animated for a short period of time. + + + + diff --git a/documentation/18.11/solutions/gui-building/eiffelbuild/eiffelbuild-reference/object-editor/positioning-fixed-children.wiki b/documentation/18.11/solutions/gui-building/eiffelbuild/eiffelbuild-reference/object-editor/positioning-fixed-children.wiki new file mode 100644 index 00000000..3c452604 --- /dev/null +++ b/documentation/18.11/solutions/gui-building/eiffelbuild/eiffelbuild-reference/object-editor/positioning-fixed-children.wiki @@ -0,0 +1,23 @@ +[[Property:title|Positioning fixed children]] +[[Property:weight|2]] +[[Property:uuid|2c465f1b-99d6-7689-67ff-e9b45145a0c0]] +If the current [[EiffelBuild Notation|object]] in the object editor is of type EV_FIXED, a button marked "position children..." will be contained in the object editor. Click this button, to display the following window: + +[[Image:fixed-child-positioner]] +* '''Moving''' - Press and hold the left mouse button within the selected child, and move the mouse. +* '''Resizing''' - Move the mouse over the border of the child, until the cursor changes to a resize cursor, then press and hold the left mouse button to re-size the child. + +{{note|As placing a child in an EV_FIXED does not modify the size of the child, it is possible that some children have a size of 0x0 pixels, and hence do not show up in the diagram. In this case, there will be the following displayed in the status bar "Widget is 0x0 pixels, click HERE to enlarge". If you subsequently click on the status bar, then the widget will be enlarged to a more useful size. }} + +==Grid Properties== + +The grid properties are displayed in the bottom right hand side of the window. You may modify the following attributes: +* '''Snap to grid''' - Select this option if you wish all widget coordinates to be snapped to the grid displayed in the window. +* '''Visible''' - If selected, then the grid is visible. +* '''Grid size''' - The spacing between grid elements in pixels. + +When you have finished manipulating the children of the table, click the button marked "Done" to close the dialog. + + + + diff --git a/documentation/18.11/solutions/gui-building/eiffelbuild/eiffelbuild-reference/object-editor/positioning-table-children.wiki b/documentation/18.11/solutions/gui-building/eiffelbuild/eiffelbuild-reference/object-editor/positioning-table-children.wiki new file mode 100644 index 00000000..46460729 --- /dev/null +++ b/documentation/18.11/solutions/gui-building/eiffelbuild/eiffelbuild-reference/object-editor/positioning-table-children.wiki @@ -0,0 +1,18 @@ +[[Property:title|Positioning table children]] +[[Property:weight|1]] +[[Property:uuid|7e302887-c3fd-1f30-866e-545aba53454e]] +If the current [[EiffelBuild Notation|object]] in the object editor is of type EV_TABLE, a button marked "position children..." is contained in the object editor. Click this button, to display the following window: + +[[Image:table-child-positioner]] + +Each of the children are displayed on a grid representing the table cells that each occupies (by default 1x1). To manipulate a child of the table, click the left mouse button inside the desired child, and it will be highlighted in red. You may the manipulate the selected child in the following ways: +* '''Moving''' - Press and hold the left mouse button within the selected child, and move the mouse. +* '''Resizing''' - Move the mouse over the border of the child, until the cursor changes to a resize cursor, then press and hold the left mouse button to re-size the child. + +{{note|Each child, may only occupy a unique set of cells within the table, and if you attempt to move or re-size a child to an invalid position, it will be displayed in gray. }} + +When you have finished manipulating the children of the table, click the button marked "Done" to close the dialog. + + + + diff --git a/documentation/18.11/solutions/gui-building/eiffelbuild/eiffelbuild-reference/type-selector.wiki b/documentation/18.11/solutions/gui-building/eiffelbuild/eiffelbuild-reference/type-selector.wiki new file mode 100644 index 00000000..f417cbee --- /dev/null +++ b/documentation/18.11/solutions/gui-building/eiffelbuild/eiffelbuild-reference/type-selector.wiki @@ -0,0 +1,41 @@ +[[Property:title|Type selector]] +[[Property:weight|4]] +[[Property:uuid|893343c2-417f-90c5-147e-941bc232fe43]] +The type selector contains all the available EiffelVision 2 types supported by EiffelBuild. These are the basic building blocks for your system. + +[[Image:type-selector]] + +The types are organized into three groups - Primitives, Containers and Items. All types that may be used in EiffelBuild have a text in uppercase, corresponding to their type in [[EiffelVision Introduction|EiffelVision 2]] . For example, looking at the screenshot above, the BUTTON item represents an EV_BUTTON, and the COMBO_BOX item represents EV_COMBO_BOX. + +{{note|The types available in the type selector are fixed, and cannot be modified. Almost all [[EiffelVision Introduction|EiffelVision 2]] components are available. }} + +==Creating a new object== +[[EiffelBuild Notation|Objects]] are the building blocks used in EiffelBuild to construct your interface. To create a new [[EiffelBuild Notation|object]] for use in your system, [[EiffelBuild Notation|pick]] the type corresponding to the type of object you wish to create,and [[EiffelBuild Notation|drop]] onto an [[EiffelBuild Notation|object]] representation. If an object is full, or does not allow other objects of the new type to be contained, then you will not be able to [[EiffelBuild Notation|drop]] on it.
+ +For example, if you have just started a new project, [[EiffelBuild Notation|pick]] HORIZONTAL_BOX from the type selector, and drop it on the EV_TITLED_WINDOW [[EiffelBuild Notation|object]] displayed in the [[Layout constructor| layout constructor]] . This will build you a new [[EiffelBuild Notation|object]] of type EV_HORIZONTAL_BOX, parented in the window. If you then [[EiffelBuild Notation|pick]] a BUTTON from the type selector, you will not be able to [[EiffelBuild Notation|drop]] it on the EV_TITLED_WINDOW, as a window may only contain one child and is therefore currently full. You may however, [[EiffelBuild Notation|drop]] on the EV_HORIZONTAL_BOX object you had just created, as the box is empty, and has space for multiple children. Doing so, will create a new [[EiffelBuild Notation|object]] of type EV_BUTTON, parented in the box. + +This shows how simple it is to Build new [[EiffelBuild Notation|objects]] in EiffelBuild, you just need access to the parent [[EiffelBuild Notation|object]] to [[EiffelBuild Notation|drop]] the selected type into. + +You may drop an object directly from the Type Selector into the [[Widget selector|widget selector]] which creates the object as a "top level object" ensuring that upon generation, it is represented by an individual set of classes. These top level objects may then be re-used within your interface as desired. + +{{note|To understand the types accepted, and the capacity of objects, you should consult the [[EiffelVision Introduction|EiffelVision 2]] library reference. }} + +==Changing the type of an existing object== + +Why would you want to change the type of an existing [[EiffelBuild Notation|object]] , when you could just delete it and create a new [[EiffelBuild Notation|object]] ? + +Imagine you have spent some time constructing a complicated interface. You have an EV_VERTICAL_BOX with children many levels deep. You realize that you wanted the EV_VERTICAL_BOX to be of type EV_HORIZONTAL_BOX. If you delete the object, all children contained will also be deleted, which in this case, is not what you want. Changing the type of the object does actually delete the object internally, but will automatically re-parent all of its children into the new object. + +To perform a type change, [[EiffelBuild Notation|pick]] the [[EiffelBuild Notation|object]] that you wish to change, and [[EiffelBuild Notation|drop]] it on an item in the type selector representing the desired new type. All existing children of the old [[EiffelBuild Notation|object]] will be automatically re-parented in the new object. + +The following rules govern if the type of an existing object may be changed to a new type: +* The parent of the existing [[EiffelBuild Notation|object]] must accept children of type corresponding to the new type. +* The new type must be able to accept all of the existing [[EiffelBuild Notation|objects]] children. + +{{seealso|
+[[Layout constructor|Layout constructor]]
+}} + + + + diff --git a/documentation/18.11/solutions/gui-building/eiffelbuild/eiffelbuild-reference/widget-selector.wiki b/documentation/18.11/solutions/gui-building/eiffelbuild/eiffelbuild-reference/widget-selector.wiki new file mode 100644 index 00000000..bc3cc1bd --- /dev/null +++ b/documentation/18.11/solutions/gui-building/eiffelbuild/eiffelbuild-reference/widget-selector.wiki @@ -0,0 +1,59 @@ +[[Property:title|Widget selector]] +[[Property:weight|9]] +[[Property:uuid|0626dd3a-28f2-ade6-8e6a-f992c2198fd6]] +The Widget Selector allows you to manage windows, dialogs and "top level" objects within the EiffelBuild project, with all windows accessible through this tool. Using the widget selector, you may add new windows to your project; delete windows; assign a root window (launched from the generated application); and group windows into directories. All objects contained in the Widget Selector are generated as individual classes at generation time. The Widget Selector has the following appearance: + +[[Image:window-selector]] + +==Adding Objects== + +To add an Object to your project, [[EiffelBuild Notation|pick]] the object type from the [[Type selector|type selector]] , and [[EiffelBuild Notation|drop]] into the Widget Selector. There are two possible drop targets within the widget selector: +* '''The Widget Selector itself''' - The newly created object is added to the root directory of the project. +* '''A Directory node''' - The newly created object is added to the directory that was the target of the drop. +Both of these outcomes create a new object in your project that is to be generated as an individual class during code generation. +{{note|The selected object in the Widget Selector is automatically targeted as the root window of the [[Layout constructor|layout constructor]] , permitting building. You may not build directly into the representation of an object within the Widget Selector, as this must be performed within the [[Layout constructor|layout constructor]] or [[Builder window|builder window]] . }} + + +==Root Window== + +The root window of a project is launched by the application class of the generated EiffelBuild project when executed. By assigning a window as a root, you ensure that it will be displayed on screen as the "root" window of the generated system when the system is launched. + +The root window of the project is highlighted with a star, indicating that it is the root. Looking at the screenshot at the top of this page, the window named "main_window" is currently flagged as the root window of the project. To set a window as the root window of the project, select the window in the Widget Selector, and press the [[Image:icon-titled-window-main-small-color]] button displayed at the top of the Widget Selector. +==Directories== + +The ability to add directories to your project permit organization of objects into sub groups as necessitated by your design. To add a directory to the project, select the [[Image:icon-new-cluster-small-color]] button displayed at the top of the Widget Selector, which displays the following dialog, prompting for the name of the directory to add: + +[[Image:new-directory-dialog]] + +Enter a unique name that is not already in use, and select "OK" to add the directory to your project. The newly added directory is then visible, as a node in the Widget Selector. + +{{note|Creating a new directory in the Widget Selector causes the actual directory on the disk to be created immediately. }} + +You may insert objects into a directory, or move an object between directories by [[EiffelBuild Notation|picking]] the object from its representation in the Widget Selector, and [[EiffelBuild Notation|dropping]] on the desired directory. Each object contained in the Widget Selector is generated as a seperate class and the parent directory is used as the generated location on disk. +{{note|If you move an object between directories within an EiffelBuild project that has already generated the Eiffel code for that object, the code files are moved immediately on the disk. }} + +Directories may be nested as deeply as required, and the following buttons are available to help with directory nesting: +* [[Image:directory-search-small]] Selecting this button recursively adds all directories from the current project location to the project. +* [[Image:icon-show-hide-directory-color]] Selecting this button causes all directories included within the project that do not contain one or more objects to be hidden/shown within the Widget Selector. +Note that any directories that do not contain objects or have object nested within their structure recursively are displayed grayed out to indicate that there are no objects within. +==Expanding== + +The [[Image:icon-expand-all-small-color]] button displayed at the top of the Widget Selector expands all nodes contained. + +==Client Representations== + +All objects within the Widget Selector that are used as clients within other object structures have client information displayed as subnodes of their representation, as illustrated in the following screenshot: + +[[Image:widget-selector-clients]] + +The OK_CANCEL_BUTTONS object is used is used in two different places within the project: once within INPUT_DIALOG and once within MAIN_WINDOW. If you select the tree node representing the instance of OK_CANCEL_BUTTONS within MAIN_WINDOW, the MAIN_WINDOW is targetted to the [[Type selector|type selector]] with the instance of the OK_CANCEL_BUTTONS object selected. + +To use an instance of a widget contained within the Widget Selector as a client, simply pick the representation of the object and drop into the desired parent object within the [[Type selector|type selector]] + +{{seealso| [[Layout constructor|Layout constructor]] }} + + + + + + diff --git a/documentation/18.11/solutions/gui-building/eiffelbuild/eiffelbuild-version-history.wiki b/documentation/18.11/solutions/gui-building/eiffelbuild/eiffelbuild-version-history.wiki new file mode 100644 index 00000000..02473688 --- /dev/null +++ b/documentation/18.11/solutions/gui-building/eiffelbuild/eiffelbuild-version-history.wiki @@ -0,0 +1,71 @@ +[[Property:title|EiffelBuild Version History]] +[[Property:weight|2]] +[[Property:uuid|8cc0540e-8ee7-c005-0534-a2ed62f41c96]] + +== 7.3 Release == +* Fixed a crash which could occur when generating a project. +* Fixed a crash when saving a project if it contained a pixmap with no path specified. + +==6.8 Release== +* Fixed bug#13069 and bug#17427 for the incorrect generated code of the '''change_actions''' on an EV_SPIN_BUTTON. +* Fixed the icon view mode display for widgets where content was shown incorrectly in previous releases. +* Fixed code generation of widgets when generated as clients. + +==6.7 Release== +Updated the generated code to the latest Eiffel syntax as specified by ECMA. + +==6.5 Release== +* Fixed bug#15947 to make the generated code compile in void-safe mode. +* Fixed bug#13296 when retrieving a project using an EV_SPIN_BUTTON element. +* Fixed bug#12880 by improving speed of key navigation which was slowed down by attempting to refresh the object editor each time a new widget was highlighted. Now it is only done when the highlight doesn't change for a while. + +==6.0 Release== +* Code generation includes the facility of closing the application when last window is closed. +* The EiffelBuild binary has been renamed into '''esbuilder'''. +* Fixed crash when generating code which included a combo box in read-only mode. +* Fixed bug#12920 where pressing a digit while dropping was not adding x-time the selected widgets (where x is the digit pressed). +* Fixed bug#12210 where pixmaps set on a menu would be incorrectly displayed in the generated executable (The last added one will always be shown for all menu entries with a pixmap). +* Fixed bug#11878 where EiffelBuild would crash when saving a project just after removing an event. +* Fixed bug#11738 where EiffelBuild would crash when picking and dropping a top level widget into the Generate button. + +==5.7 Release== +* Fixed positioning bug when moving items within their current parent by dropping on another item in that parent with the shift key held down. +* Fixed bug where modifying the "User can resize" property of a window while the tools were always shown on top stopped the tools from being shown on top. +* Added support for multi-line tooltips. +* Added support for `is_item_expanded` from EV_SPLIT_AREA. +* Added the ability to specify a directory for generation, into which location all files are to be generated. +* Event selection dialogs now contain the name of the object to which they refer in their title for cases where multiple dialogs are open simultaneously +* The project settings dialog is now completely navigatable via the keyboard on Windows platforms. +* Added support for Ctrl+Z and Ctrl+Y to navigate through the history. +* The font selection dialog now shows the currently selected font when displayed. +* Deleting an object that is contained within an object editor now clears the contents of the object editor. +* Preferences window now has the focus when displayed so it is fully navigatable via the keyboard. +* Code generation improved to allow the modifying of constants and subsequent update of the interface, permitting multiple languages to be supported. + +==5.6 Release== +* Added support for the generation of any widget as a class. You now may place widgets within the "Widget Selector" to enable this. The "Widget Selector" is simply the old "Widget Selector" renamed. +* Added clipboard functionality, permitting the copying/pasting of objects. +* Added support for new constant types: Font and Color. + +==5.5 Release== +* Added support for EV_RICH_TEXT which has been added to EiffelVision2. +* Notebook item texts may now be set to string constants. +* Better support for corrupt installations with warning dialogs now displayed. +* Fixed bug with generated code for notebooks often hiding the first item when they were actually displayed. + +==5.4 Release== +* Added support for multiple windows, including dialogs. +* Added support for constants of type Integer, String, Directory and Pixmap. +* New tool, "Widget Selector" added to handle organization of windows, including the ability to define subdirectories in a project, and group windows accordingly. +* Tip of the day dialog added. +* Recent projects are now available from the "File" menu. +* The contents of EiffelBuild projects may now be imported. +* The ability to reset the minimum dimensions of widgets have been added. In the previous version, it was not possible to complete undo the effects of setting a widgets minimum size. +* Preferences added, which allow you to customize the default behavior of EiffelBuild. For example, dialogs may be displayed or hidden as desired. +* The layout of EiffelBuild and its tools is now maintained between sessions. +* Docking added, permitting the re-ordering of particular tools within the interface, including making them "float" externally. +* Smarter code generation options, permitting only named attributes to be exported. + + + + diff --git a/documentation/18.11/solutions/gui-building/eiffelbuild/index.wiki b/documentation/18.11/solutions/gui-building/eiffelbuild/index.wiki new file mode 100644 index 00000000..467effd6 --- /dev/null +++ b/documentation/18.11/solutions/gui-building/eiffelbuild/index.wiki @@ -0,0 +1,5 @@ +[[Property:title|EiffelBuild]] +[[Property:weight|0]] +[[Property:uuid|2af28db0-bc8f-daa6-daf2-18b08a11b606]] +EiffelBuild is the high-level interface builder by Eiffel Software which allows you to develop graphical user interface (GUI) applications simply and quickly. + diff --git a/documentation/18.11/solutions/gui-building/eiffelvision-2/How-to-build-a-concurrent-graphical-application--EiffelVision-with-SCOOP.wiki b/documentation/18.11/solutions/gui-building/eiffelvision-2/How-to-build-a-concurrent-graphical-application--EiffelVision-with-SCOOP.wiki new file mode 100644 index 00000000..2fc73005 --- /dev/null +++ b/documentation/18.11/solutions/gui-building/eiffelvision-2/How-to-build-a-concurrent-graphical-application--EiffelVision-with-SCOOP.wiki @@ -0,0 +1,35 @@ +[[Property:uuid|D1DDF411-5387-4A81-9A85-3EF8A2A4220D]] +[[Property:weight|0]] +[[Property:title|How to build a concurrent graphical application: EiffelVision with SCOOP]] +==How can I build a concurrent graphical application in Eiffel?== + +Eiffel has a great library for producing graphical applications: EiffelVision. Eiffel also has a powerful concurrency mechanism: SCOOP. + +How do you make the two work together? This note gives you simple guidelines to ensure that the EiffelVision-SCOOP marriage is a harmonious and productive one. + +The first question: why does the problem even exist? Let's go back to the pre-SCOOP days. Any graphical application has an "event loop", which keeps watching for graphical user events, such as a mouse click, and triggering the corresponding application responses, such as saving a file (if the user clicked ''OK'' on a ''File Save'' dialog). If you were using multithreading, the event loop would run in the main thread, also called the GUI (Graphical User Interface) thread. + +Enter SCOOP. The old technique cannot work because a processor stuck in a loop cannot process any logged call! If you perform calls on a graphical widget, say the ''OK'' button, they will be logged right away, but they can only execute once the processor has exited its event loop. Not what you want. + +So here is what you should do: + +In a creation procedure used to initialize GUI objects, create an EV_APPLICATION object, using an instruction such as + create my_app +with my_app of type EV_APPLICATION. (This may be a root creation procedure or a creation procedure of a separate object in case the root processor is going to be used for other operations.) + +Then in the same creation procedure create all the GUI elements. They will all be in the same processor that created the EV_APPLICATION object. + +After that start the application, using + my_app.launch +In the pre-SCOOP world, launch would start the event loop. Here it only creates a separate object (of type EV_APPLICATION_HANDLER), which will run the event loop, forwarding events to the EV_APPLICATION object. + +This is all the creation procedure should do. Make sure it terminates with the preceding step. Otherwise, the event loop will never run! + +Now you can start using EiffelVision as you are used to, by sending GUI requests to the EV_APPLICATION object: + +* For requests coming from the same processor just use the EV_APPLICATION object directly. +* For requests coming from another processor, you can get the access through the feature ev_separate_application of class EV_SHARED_APPLICATION. + +Note that only one EV_APPLICATION object can be used, therefore all GUI objects have to be created in the region of this object. + +That's all! Happy concurrent Eiffeling. \ No newline at end of file diff --git a/documentation/18.11/solutions/gui-building/eiffelvision-2/converting-eiffelvision-2-systems-void-safety.wiki b/documentation/18.11/solutions/gui-building/eiffelvision-2/converting-eiffelvision-2-systems-void-safety.wiki new file mode 100644 index 00000000..9f7586a6 --- /dev/null +++ b/documentation/18.11/solutions/gui-building/eiffelvision-2/converting-eiffelvision-2-systems-void-safety.wiki @@ -0,0 +1,86 @@ +[[Property:title|Converting EiffelVision 2 Systems to Void-Safety]] +[[Property:weight|1]] +[[Property:uuid|96e01318-700b-da6e-42d1-14fee219daf5]] +==Introduction== + +In order to convert systems that employ EiffelVision 2 (Vision2) to [[Void-safe Programming in Eiffel|void-safety]], some adjustments may be needed depending on its usage. This page describes the various usage scenarios of Vision2 that will need to be converted in order to adhere to void-safety. + +==Inheritance Purely from an Interface Class== + +If you have classes that inherit from a Vision2 interface class such as EV_DRAWING_AREA, the first change that has to be made is to alter `initialize' so that any types that are attached (i.e. types that remain non-void throughout the lifetime of its container [parent object]) are instantiated via `create_interface_objects'. This feature needs to be redefined if the type from Vision2 is instantiable. If not, then it may need to be made effective (such as when the class inherits directly from EV_ANY). It is important that any attached types in the interface class are instantiated in `create_interface_objects' and these objects are initialized via `initialize'. Attached types should not be instantiated in `initialize' due to the Bridge Pattern implementation, and initialization of these types in `create_interface_objects' MUST be performed in `initialize', otherwise unexpected behavior may occur as the Bridge Pattern has not been fully set up at this point in time. + +Example from EV_TIMEOUT + + create_interface_objects + -- + do + create actions + end + + create_implementation + -- Create implementation of timeout. + do + create {EV_TIMEOUT_IMP} implementation.make + end + + + +==Inheritance from an Implementation Interface Class with Associating Interface Class== + +If you have an existing, custom platform-dependent implementation, a few more changes will be needed above and beyond those required for the interface class. + +For interface class changes, now the interface object is passed to the implementation after creation, via `assign_interface'. This means that `make' no longer takes an argument (see `create_implementation' above). This also means that to adhere to void-safety all of the types are now created and initialized via the creation routine of the implementation object. + +An example from the conversion of the Windows implementation of EV_BUTTON_IMP: + + + make (an_interface: like interface) + -- Create `Current' with interface `an_interface'. + do + base_make (an_interface) + wel_make (default_parent, "", 0, 0, 0, 0, 0) + extra_width := 20 + text_alignment := default_alignment + -- Retrieve the theme for the button. + open_theme := application_imp.theme_drawer.open_theme_data (wel_item, "Button") + end + + initialize + -- Initialize `Current'. + do + Precursor {EV_PRIMITIVE_IMP} + set_default_font + end + + interface: EV_BUTTON; + + +would become: + + + make + -- Initialize `Current'. + do + wel_make (default_parent, "", 0, 0, 0, 0, 0) + extra_width := 20 + text_alignment := default_alignment + -- Retrieve the theme for the button. + open_theme := application_imp.theme_drawer.open_theme_data (wel_item, "Button") + Precursor {EV_PRIMITIVE_IMP} + set_default_font + end + + interface: detachable EV_BUTTON note option: stable attribute end; + + +The following steps are needed during the conversion: + +* The attribute `interface' needs to be made a stable attribute. The converted `interface' attribute shows the syntax for doing so. + +* Copy any initialization of the widget from `make' to `initialize' excluding `base_make' setup. Any initialization code that relies on `interface' would have to be rewritten so that `interface' gets passed to the new creation routine, which in turn calls the original `make'. See EV_PRINT_PROJECTOR_IMP on Windows `make_with_context' for an example of this. + +* Remove `make', rename `initialize' to `make', and make sure that any calls to Precursor do not override any settings set in `initialize'. The ordering may need to be changed in order to make the code void-safe. See EV_POPUP_WINDOW_IMP.make (Windows implementation) where the setting of `user_can_resize' is performed after the Precursor call so that is doesn't get overriden. + + +{{SeeAlso|[[Void-Safe Programming in Eiffel]]}} + diff --git a/documentation/18.11/solutions/gui-building/eiffelvision-2/eiffelvision-2-class-reference.wiki b/documentation/18.11/solutions/gui-building/eiffelvision-2/eiffelvision-2-class-reference.wiki new file mode 100644 index 00000000..f8195afb --- /dev/null +++ b/documentation/18.11/solutions/gui-building/eiffelvision-2/eiffelvision-2-class-reference.wiki @@ -0,0 +1,5 @@ +[[Property:title|EiffelVision 2 Class Reference]] +[[Property:weight|2]] +[[Property:uuid|bb50444f-5fd1-9136-a224-0ce37d3bd856]] +==View the [[ref:libraries/vision2/reference/index|EiffelVision 2 Class Reference]] == + diff --git a/documentation/18.11/solutions/gui-building/eiffelvision-2/eiffelvision-2-samples/accelerator-sample.wiki b/documentation/18.11/solutions/gui-building/eiffelvision-2/eiffelvision-2-samples/accelerator-sample.wiki new file mode 100644 index 00000000..245c0648 --- /dev/null +++ b/documentation/18.11/solutions/gui-building/eiffelvision-2/eiffelvision-2-samples/accelerator-sample.wiki @@ -0,0 +1,32 @@ +[[Property:title|Accelerator Sample]] +[[Property:weight|0]] +[[Property:uuid|e3a8eac2-94c6-287a-314b-b4d056f9c1ad]] +[[Image:accelerator|accelerator]]
+
+ +==Compiling== + +* Launch EiffelStudio. +* Click '''Add project''' +* Browse to ''$ISE_EIFFEL\examples\vision2\accelerator\''. +* Choose ''accelerator.ecf'' +* Choose the location where the project will be compiled, by default the same directory containing the configuration file. +* Click '''OK'''. + + +==Running== +After launching the application, you will see a window displayed with a similar appearance to the one above. When the window has the focus, the key combination Ctrl + Q will exit the application. +==Under the Hood== +An EV_ACCELERATOR is created and associated with the EV_TITLED_WINDOW used for the main window of the application. The association is made by adding the accelerator to the accelerators list of the window. +This sample contains the following class: +* ACCELERATOR + + +{{seealso|
+[[ref:libraries/vision2/reference/ev_accelerator_chart|EV_ACCELERATOR]]
+[[ref:libraries/vision2/reference/ev_key_chart|EV_KEY]]
+}} + + + + diff --git a/documentation/18.11/solutions/gui-building/eiffelvision-2/eiffelvision-2-samples/cursor-sample.wiki b/documentation/18.11/solutions/gui-building/eiffelvision-2/eiffelvision-2-samples/cursor-sample.wiki new file mode 100644 index 00000000..bb336014 --- /dev/null +++ b/documentation/18.11/solutions/gui-building/eiffelvision-2/eiffelvision-2-samples/cursor-sample.wiki @@ -0,0 +1,33 @@ +[[Property:title|Cursor Sample]] +[[Property:weight|1]] +[[Property:uuid|8a00cb23-d093-1b2f-9caf-213e570f96a9]] +[[Image:cursor-test|cursor_test]]
+
+ +==Compiling== + +* Launch EiffelStudio. +* Click '''Add project''' +* Browse to ''$ISE_EIFFEL\examples\vision2\cursor\''. +* Choose ''cursor.ecf'' +* Choose the location where the project will be compiled, by default the same directory containing the configuration file. +* Click '''OK'''. + + +==Running== + +After launching the application, you will see a window displayed with a similar appearance to the one above. Selecting "File", "Close" or pressing the close icon at any time will exit the application. + +To the right hand side of the window you will see an EV_MULTI_COLUMN_LIST containing rows, each with an associated EV_PIXMAP. If you select one of the rows of the list, then press the button marked "Apply", the cursor displayed when over the label displayed to the right hand side of the window will be pixmap of the currently selected list row. +==Under the Hood== + +The pixmaps used in the EV_MULTI_COLUMN_LIST were standard pixmaps provided with EiffelVision 2, accessible through EV_STOCK_PIXMAPS. set_pixmap was used to set the EV_PIXMAP of the EV_MULTI_COLUMN_LIST_ROW. An agent was added to the select_actions of the EV_BUTTON which calls set_pointer_style on the desired widget. + +This sample contains the following class: +* CURSOR_TEST + + + + + + diff --git a/documentation/18.11/solutions/gui-building/eiffelvision-2/eiffelvision-2-samples/gauges-sample.wiki b/documentation/18.11/solutions/gui-building/eiffelvision-2/eiffelvision-2-samples/gauges-sample.wiki new file mode 100644 index 00000000..d2416942 --- /dev/null +++ b/documentation/18.11/solutions/gui-building/eiffelvision-2/eiffelvision-2-samples/gauges-sample.wiki @@ -0,0 +1,38 @@ +[[Property:title|Gauges Sample]] +[[Property:weight|2]] +[[Property:uuid|91aa8c8b-7cc9-06c1-a6f0-96844ff078d5]] +[[Image:gauges|gauges]]
+
+ +==Compiling== + +* Launch EiffelStudio. +* Click '''Add project''' +* Browse to ''$ISE_EIFFEL\examples\vision2\gauges\''. +* Choose ''gauges.ecf'' +* Choose the location where the project will be compiled, by default the same directory containing the configuration file. +* Click '''OK'''. + + +==Running== + +After launching the application, you will see a window displayed with a similar appearance to the one above. The spin buttons at the top of the window control the current minimum, maximum and value of the three gauges displayed below. Modifying the values of the spin buttons will alter the three gauges in real time. Also, if you interact with one of the three gauges, any change in one, will be reflected in the others and in the spin buttons. + +==Under the Hood== + +The change_actions of each EV_GAUGE are used to synchronize all of the gauges. + +This sample contains the following class: +* GAUGES + + +{{seealso|
+EV_GAUGE
+EV_SCROLL_BAR
+EV_RANGE
+EV_PROGRESS_BAR
+EV_SPIN_BUTTON }} + + + + diff --git a/documentation/18.11/solutions/gui-building/eiffelvision-2/eiffelvision-2-samples/index.wiki b/documentation/18.11/solutions/gui-building/eiffelvision-2/eiffelvision-2-samples/index.wiki new file mode 100644 index 00000000..cd9de196 --- /dev/null +++ b/documentation/18.11/solutions/gui-building/eiffelvision-2/eiffelvision-2-samples/index.wiki @@ -0,0 +1,14 @@ +[[Property:title|EiffelVision 2 Samples]] +[[Property:weight|3]] +[[Property:uuid|79c05bf8-367e-001d-0c13-f668e34fa5b0]] +EiffelVision 2 ships with a number of samples provided to demonstrate different aspects of the library. If you are a new EiffelVision 2 user then it is suggested that you first compile and run the + +* [[Widgets Sample|Widgets]] sample. Demonstrates both the appearance and behavior of the available widgets. + +Then explore other samples: +* [[Accelerator Sample|Accelerator]] - Demonstrates the use of an [[ref:libraries/vision2/reference/ev_accelerator_chart|EV_ACCELERATOR]] . +* [[Cursor Sample|Cursor]] - Demonstrates how to modify the displayed [[ref:libraries/vision2/reference/ev_cursor_chart|EV_CURSOR]] for an [[ref:libraries/vision2/reference/ev_widget_chart|EV_WIDGET]] . +* [[Gauges Sample|Gauges]] - Demonstrates different types of [[ref:libraries/vision2/reference/ev_gauge_chart|EV_GAUGE]] . +* [[Standard_dialogs Sample|Standard_dialogs]] - Demonstrates different types of [[ref:libraries/vision2/reference/ev_standard_dialog_chart|EV_STANDARD_DIALOG]] . +* [[Viewport Sample|Viewport]] - Demonstrates [[ref:libraries/vision2/reference/ev_viewport_chart|EV_VIEWPORT]] . + diff --git a/documentation/18.11/solutions/gui-building/eiffelvision-2/eiffelvision-2-samples/standard-dialogs-sample.wiki b/documentation/18.11/solutions/gui-building/eiffelvision-2/eiffelvision-2-samples/standard-dialogs-sample.wiki new file mode 100644 index 00000000..ea52a226 --- /dev/null +++ b/documentation/18.11/solutions/gui-building/eiffelvision-2/eiffelvision-2-samples/standard-dialogs-sample.wiki @@ -0,0 +1,29 @@ +[[Property:title|Standard_dialogs Sample]] +[[Property:weight|3]] +[[Property:uuid|31d0608e-0136-b3db-0745-9e8697dcc60d]] +[[Image:standard-dialogs|Standard_dialogs]]
+
+ +==Compiling== + +* Launch EiffelStudio. +* Click '''Add project''' +* Browse to ''$ISE_EIFFEL\examples\vision2\standard_dialogs\''. +* Choose ''standard_dialogs.ecf'' +* Choose the location where the project will be compiled, by default the same directory containing the configuration file. +* Click '''OK'''. + + +==Running== + +After launching the application, you will see a window displayed with a similar appearance to the one above. If you select an item from the "Standard Dialog" menu, a dialog of that type will be displayed. Selecting "Exit" from the "File" menu will exit the application. + +==Under the Hood== + +This sample contains the following class: +* STANDARD_DIALOGS + + + + + diff --git a/documentation/18.11/solutions/gui-building/eiffelvision-2/eiffelvision-2-samples/viewport-sample.wiki b/documentation/18.11/solutions/gui-building/eiffelvision-2/eiffelvision-2-samples/viewport-sample.wiki new file mode 100644 index 00000000..6de3bc0c --- /dev/null +++ b/documentation/18.11/solutions/gui-building/eiffelvision-2/eiffelvision-2-samples/viewport-sample.wiki @@ -0,0 +1,39 @@ +[[Property:modification_date|Wed, 12 Sep 2018 00:07:36 GMT]] +[[Property:publication_date|Wed, 12 Sep 2018 00:07:36 GMT]] +[[Property:title|Viewport Sample]] +[[Property:weight|4]] +[[Property:uuid|e8722685-0343-c411-83b1-32f0c4e0175b]] +[[Image:viewport|viewport]]
+
+ +==Compiling== + +To compile the example: +* Launch EiffelStudio. +* Click '''Add project''' +* Browse to ''$ISE_EIFFEL\examples\vision2\viewport\''. +* Choose ''viewport.ecf'' +* Choose the location where the project will be compiled, by default the same directory containing the configuration file. +* Click '''OK'''. + +==Running== + +After launching the application, you will see a window displayed with a similar appearance to the one above. Modifying the values of the spin buttons will alter the position of the pixmapped button, relative to the viewport in which it is contained. + +==Under the Hood== + +The features set_x_offset and set_y_offset are used to modify the position of the EV_VIEWPORT relative to the EV_BUTTON contained within. + +This sample contains the following class: +* VIEWPORT + + +{{seealso|
+[[ref:libraries/vision2/ev_viewport_chart.html|EV_VIEWPORT]]
+[[ref:libraries/vision2/ev_spin_button_chart.html|EV_SPIN_BUTTON]]
+[[ref:libraries/vision2/reference/ev_button_chart|EV_BUTTON]]
+}} + + + + diff --git a/documentation/18.11/solutions/gui-building/eiffelvision-2/eiffelvision-2-samples/widgets-sample.wiki b/documentation/18.11/solutions/gui-building/eiffelvision-2/eiffelvision-2-samples/widgets-sample.wiki new file mode 100644 index 00000000..48f7ba65 --- /dev/null +++ b/documentation/18.11/solutions/gui-building/eiffelvision-2/eiffelvision-2-samples/widgets-sample.wiki @@ -0,0 +1,45 @@ +[[Property:title|Widgets Sample]] +[[Property:weight|-1]] +[[Property:uuid|04aa62bd-ef9c-152c-5c69-4fe7e750649f]] +[[Image:widgets|widgets]]
+
+ +==Compiling== + +* Launch EiffelStudio. +* Click '''Add project''' +* Browse to ''$ISE_EIFFEL\examples\vision2\widgets\''. +* Choose ''widgets.ecf'' +* Choose the location where the project will be compiled, by default the same directory containing the configuration file. +* Click '''OK'''. + + +==Running== + +After launching the application, you will see a window displayed with a similar appearance to the one above. You may exit the application at any time, by clicking on the close icon, or you may select "exit" from the "File" menu. Selected "Help", "about" displays a dialog with details about the application. + +The left hand side of the main window contains a tree, showing the widgets available within EiffelVision 2. If you select one of these widgets in the tree, then the type of widget you selected will be displayed in the middle of the main_window. Controls will also the be available to the right hand side of the widget, which allow you to modify its state. These controls do not represent all the available feature of the widget, but demonstrate many of the most common. The text area below the currently selected widget displays the events that have occurred on the widget. Only those events inherited by EV_WIDGET are displayed. + +==Under the Hood== + +This sample contains the following classes: +* ABOUT_DIALOG +* COLORIZABLE_CONTROL +* CONTAINER_CONTROL +* DESELECTABLE_CONTROL +* DRAWABLE_CONTROL +* GAUGE_CONTROL +* ITEM_LIST_CONTROL +* MAIN_WINDOW +* PIXMAPABLE_CONTROL +* SELECTABLE_CONTROL +* SENSITIVE_CONTROL +* TEXT_COMPONENT_CONTROL +* TEXTABLE_CONTROL +* WIDGET_CONTROL +* WIDGETS + + + + + diff --git a/documentation/18.11/solutions/gui-building/eiffelvision-2/eiffelvision-introduction.wiki b/documentation/18.11/solutions/gui-building/eiffelvision-2/eiffelvision-introduction.wiki new file mode 100644 index 00000000..66e77b30 --- /dev/null +++ b/documentation/18.11/solutions/gui-building/eiffelvision-2/eiffelvision-introduction.wiki @@ -0,0 +1,86 @@ +[[Property:title|EiffelVision Introduction]] +[[Property:weight|0]] +[[Property:uuid|f964651a-e36d-4e9e-00ea-37803a26373a]] +The EiffelVision 2 library offers an object-oriented cross-platform framework for graphical user interface (GUI) development. Using EiffelVision 2, developers can access all necessary GUI components, called [[Widgets|widgets]] (buttons, windows, list views, etc.) as well as truly graphical elements such as points, lines, arcs, polygons and the like—to develop a modern, functional and professional graphical interactive application. + +EiffelVision 2 has played a major role at Eiffel Software and provided numerous Eiffel projects with a powerful, portable graphics development platform. EiffelStudio is totally reliant on EiffelVision 2 for its graphical elements and overall interaction with the user. + + +==Scope== + +The EiffelVision 2 library addresses all the major needs of developers of systems supporting modern graphical interfaces. EiffelVision 2 runs on Microsoft Windows and all major variations of Unix (including Linux). All versions are fully source-compatible: with only a recompile, applications will run on every supported platform with the native look-and-feel. + +EiffelVision 2 provides an effective way of building advanced graphical applications using user interface standards and toolkits (such as Microsoft Windows and GTK) without having to learn the details of the toolkits. Instead, you can use EiffelVision 2 to work entirely in terms of high level abstractions representing windows, buttons, labels, graphical figures, menus, etc., and apply clearly understandable operations to the corresponding objects. + + +==Architecture== + +EiffelVision 2 relies on a two-tiered architecture illustrated by the following figure. + + +[[Image:vision2--figure1]] + + +The two tiers play complementary roles: +* At the top level, EiffelVision 2 provides a fully portable graphics library. +* At the lower level, platform-specific libraries cover the graphical mechanisms of graphics platforms such as Windows and GTK. + +The lower tier serves for the implementation of the upper tier, but can also be used independently. For example [[WEL]] has had resounding success with Windows developers who need an advanced mechanism for building Windows-specific graphical applications, taking advantage of every facility of the Windows API (Application Programming Interface) and of the Eiffel approach, but do not need portability on the client side. The GEL library is a '''wrapper''' library, automatically generated from the entire GTK API by a tool named '''The Gote Converter'''. + + +==Features== + +As stated before, the library has undergone some drastic changes since the previous release. Names have been changed to improve consistency. Contracts have been added wherever possible. The following is a summary of the other re-engineered aspects of the library: +* Taking full advantage of the '''agent''' mechanism of Eiffel, [[uuid:fc32d1b5-72d6-2955-18fd-bce988ed8323|events]] are now triggered through '''action sequences''' (lists of actions) that will be executed in order. This system does not require separate classes to be written for each event, however the command pattern can still be used if desired. +* The [[EiffelVision Pick and Drop|Pick-and-Drop]] mechanism now relies on the Eiffel type system. A '''pebble''' (some transportable object) is now any Eiffel class and can always be dropped on a widget that accepts the type (or a more general type) of that pebble. +* [[Containers|containers]] ( [[Widgets|widgets]] that contain other [[Widgets|widgets]] ) are now derived from [[EiffelBase]] classes. For example you can now insert [[Widgets|widgets]] in any position and iterate over them. + + +==Design== + +EiffelVision 2 provides programmers with high-level classes that provide all mechanisms and data structures needed to build advanced user interfaces for deployment on almost all platforms without having to worry about detailed requirements of of those platforms (toolkits). + +The abstract design has been derived from an analysis of user interfaces. Therefore we have classes with names like MENU, WINDOW, BUTTON, LINE or POLYGON. The features of these classes are simple, clearly defined properties or commands, like the feature `minimize` (a command) on WINDOW or `text` (a property of type STRING) on BUTTON. + +{{note| All class names in EiffelVision 2 are pre-pended with EV_ to avoid name clashes with existing classes. Thus, BUTTON becomes EV_BUTTON, etc. }} + + +==Properties== + +When talking about a property of a class, like `text`, in fact we are talking about multiple features. One is a query of the state of the property, in this case simply the query `text`. The other is the set-routine, which is by convention named `set_text` taking exactly one argument of the type of the property. A property can be read-only, which means that it cannot be set by clients of the class. + + text: STRING + + set_text (a_text: STRING) + ... + do + ... + end + + +Boolean properties have a different convention. Instead of one set-routine, it has one enable-routine and one disable-routine. The first one sets the property to true, and the second to false. This has been done this way because sometimes these enable/disable features have trivial equivalents, for example for feature `enable_visible` a clearer name is `show`. + + is_sensitive: BOOLEAN + + enable_sensitive + ... + do + ... + end + + + disable_sensitive + ... + do + ... + end + + + +==Implementation== + +For flexibility, EiffelVision 2 is built using the bridge pattern. This means that every platform-dependent component of the library consist of two classes, plus an implementation class for each platform (currently two). One is the interface. All the features of interfaces do nothing except delegate the call to the implementation object which is coupled to it. This object has the static type of the implementation-interface with the name of the interface class, with an "_I" suffix. The implementation classes (with an "_IMP" suffix) then inherit from this implementation-interface class to implement platform-specific features. At run time, these platform-specific implementation objects (instantiated from the "_IMP" classes) are then polymorphically attached to the to the "_I"-typed attributes (typically named "implementation") to provide the platform-specific services. + +{{SeeAlso| The book titled ''Design Patterns: Elements of Reusable Object-Oriented Software'' by Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides, contains a complete description of the Bridge Pattern.}} + + diff --git a/documentation/18.11/solutions/gui-building/eiffelvision-2/eiffelvision-library-reference-manual/events.wiki b/documentation/18.11/solutions/gui-building/eiffelvision-2/eiffelvision-library-reference-manual/events.wiki new file mode 100644 index 00000000..a31851f9 --- /dev/null +++ b/documentation/18.11/solutions/gui-building/eiffelvision-2/eiffelvision-library-reference-manual/events.wiki @@ -0,0 +1,21 @@ +[[Property:title|Events]] +[[Property:weight|4]] +[[Property:uuid|fc32d1b5-72d6-2955-18fd-bce988ed8323]] +An event is considered to be an external action that occurs during a program's execution. Correctly dealing with events is vital part of developing an EiffelVision 2 application. For example, if a user clicks on a button, you will want to respond to this event by calling a routine that deals with the request. EiffelVision 2 contains action sequences for all kinds of widget events. To view the kind of events available to every widget, click [[ref:libraries/vision2/reference/ev_widget_action_sequences_chart|here]]. The Events cluster contains classes for event handling within EiffelVision 2. + + +==How Do I Connect to an Event?== + +Every widget and item has an action sequence associated with it that relates to some kind of event. For example an [[ref:libraries/vision2/reference/ev_button_chart|EV_BUTTON]] has a select_actions action sequence. This gets fired when the user selects (clicks) the button. To have a procedure called on this event, you need to create an agent based on this procedure, and then add this to the action sequence (via extend). For a more detailed description of agents and their uses click [[ET: Agents|here]] . + +An example of adding an agent to an action_sequence: + + my_button.select_actions.extend (agent print ("Button Clicked!%N")) + + +All EiffelVision 2 action sequences inherit from [[ref:libraries/vision2/reference/ev_action_sequence_chart|EV_ACTION_SEQUENCE]] and when it is called, all of the agents held within are fired, thus calling all of the procedures represented by the agents. The signature of any agent that you place in an action sequence must conform to those of the action sequence's actual generic parameter(s). + +When you want an agent to be called from a certain action sequence and the signatures do not match, you may use [[ref:libraries/vision2/reference/ev_action_sequence_chart|force_extend]] . This will call your agent but there are no guarantees as to the arguments passed to your procedure. + + + diff --git a/documentation/18.11/solutions/gui-building/eiffelvision-2/eiffelvision-library-reference-manual/figures.wiki b/documentation/18.11/solutions/gui-building/eiffelvision-2/eiffelvision-library-reference-manual/figures.wiki new file mode 100644 index 00000000..e55d176d --- /dev/null +++ b/documentation/18.11/solutions/gui-building/eiffelvision-2/eiffelvision-library-reference-manual/figures.wiki @@ -0,0 +1,166 @@ +[[Property:title|Figures]] +[[Property:weight|7]] +[[Property:uuid|c12fee6e-5e99-ae59-8ac5-f57abb4c1878]] +{{ReviewRequested}} + + +The EiffelVision 2 figure cluster provides a high-level way of drawing on an [[ref:libraries/vision2/reference/ev_drawable_chart|EV_DRAWABLE]] descendant. It offers a number of advantages: +* The model (tree of figures) is separated from the graphical representation by using projectors that take a "world" (an entire set of figures) and project it onto any device, not just a drawing area. +* Instead of drawing with static APIs like draw_line, you can use real figure objects, which internally remember their location, rotation and scaling; later on you can perform limitless transformations on them, either individually or as part of an entire branch in the tree of figures: move, rotation, scaling, change of color... +* For projection devices that support the mouse, pointer events propagate to the affected figures. + + +==Figure Classes== + +Every basic figure class inherits from [[ref:libraries/vision2/reference/ev_atomic_figure_chart|EV_ATOMIC_FIGURE]]. An atomic figure has the property of having its own graphical representation. [[ref:libraries/vision2/reference/ev_figure_group_chart|EV_FIGURE_GROUP]] on the other hand is a collection of figures. Finally, [[ref:libraries/vision2/reference/ev_figure_chart|EV_FIGURE]] is the common ancestor to those two. Since [[ref:libraries/vision2/reference/ev_figure_group_chart|EV_FIGURE_GROUP]] is a collection of EV_FIGUREs, it can contain both atomic figures and subgroups, thus forming a tree of figures. + +Any "branch" of that tree that wishes to be drawn (i.e. rendered to a device or file) (especially the top-level root) must be a figure group of type [[ref:libraries/vision2/reference/ev_figure_world_chart|EV_FIGURE_WORLD]]. It inherits from [[ref:libraries/vision2/reference/ev_figure_group_chart|EV_FIGURE_GROUP]], and adds some features for grid and background color, required for drawing. + +===Figures=== + +{| border="1" +|- +| class +| open/closed +| points +| description +|- +| [[ref:libraries/vision2/reference/ev_figure_arc_chart|EV_FIGURE_ARC]] +| open +| 2 +| a segment of an open ellipse +|- +| [[ref:libraries/vision2/reference/ev_figure_dot_chart|EV_FIGURE_DOT]] +| open +| 1 +| a single point +|- +| [[ref:libraries/vision2/reference/ev_figure_ellipse_chart|EV_FIGURE_ELLIPSE]] +| closed +| 2 +| an ellipse inside imaginary rectangle +|- +| [[ref:libraries/vision2/reference/ev_figure_equilateral_chart|EV_FIGURE_EQUILATERAL]] +| closed +| 2 +| a figure with any number of sides of the same length +|- +| [[ref:libraries/vision2/reference/ev_figure_line_chart|EV_FIGURE_LINE]] +| open +| 2 +| a straight line between two points +|- +| [[ref:libraries/vision2/reference/ev_figure_picture_chart|EV_FIGURE_PICTURE]] +| open +| 1 +| an image positioned by its top-left point +|- +| [[ref:libraries/vision2/reference/ev_figure_pie_slice_chart|EV_FIGURE_PIE_SLICE]] +| closed +| 2 +| a part of a closed ellipse +|- +| [[ref:libraries/vision2/reference/ev_figure_polygon_chart|EV_FIGURE_POLYGON]] +| closed +| * +| a figure defined by any number of points +|- +| [[ref:libraries/vision2/reference/ev_figure_polyline_chart|EV_FIGURE_POLYLINE]] +| open +| * +| a figure consisting of any number of connecting lines +|- +| [[ref:libraries/vision2/reference/ev_figure_rectangle_chart|EV_FIGURE_RECTANGLE]] +| closed +| 2 +| a figure with four sides +|- +| [[ref:libraries/vision2/reference/ev_figure_star_chart|EV_FIGURE_STAR]] +| open +| 2 +| any number of lines emerging from a center point +|- +| [[ref:libraries/vision2/reference/ev_figure_text_chart|EV_FIGURE_TEXT]] +| open +| 1 +| a string positioned by its top-left point displayed in the specified font +|} + + +A closed figure is a figure that has some area enclosed when drawn that can optionally be filled with a color. Closed figures inherit [[ref:libraries/vision2/reference/ev_closed_figure_chart|EV_CLOSED_FIGURE]] which gives them the property fill_color. Open figures inherit [[ref:libraries/vision2/reference/ev_atomic_figure_chart|EV_ATOMIC_FIGURE]] directly, as does [[ref:libraries/vision2/reference/ev_closed_figure_chart|EV_CLOSED_FIGURE]]. + +===Points=== + +Central in the design of the figures are points. Figures are defined from their points. For example, an ellipse is not a center point with two radii, but is instead the largest fitting ellipse inside an imaginary rectangle, so of two points. + +As you can see in the table above, each figure has a certain number of points. These values can be 1, 2 or * (any number). For each value there is a class the figure inherits from. These are: +* 1 (figure has one point): [[ref:libraries/vision2/reference/ev_single_pointed_figure_chart|EV_SINGLE_POINTED_FIGURE]]. +* 2 (figure has two points): [[ref:libraries/vision2/reference/ev_double_pointed_figure_chart|EV_DOUBLE_POINTED_FIGURE]]. +* * (figure has zero or more points): [[ref:libraries/vision2/reference/ev_multi_pointed_figure_chart|EV_MULTI_POINTED_FIGURE]]. + +These classes offer features to handle the given number of points. [[ref:libraries/vision2/reference/ev_single_pointed_figure_chart|EV_SINGLE_POINTED_FIGURE]] offers the feature: + + + point: EV_RELATIVE_POINT + + +[[ref:libraries/vision2/reference/ev_double_pointed_figure_chart|EV_DOUBLE_POINTED_FIGURE]] inherits [[ref:libraries/vision2/reference/ev_single_pointed_figure_chart|EV_SINGLE_POINTED_FIGURE]] for its first point, which is renamed to point_a. It adds point_b, so it has the features: + + + point_a: EV_RELATIVE_POINT + point_b: EV_RELATIVE_POINT + + +[[ref:libraries/vision2/reference/ev_multi_pointed_figure_chart|EV_MULTI_POINTED_FIGURE]] internally holds an array of points: + + + i_th_point (i: INTEGER): EV_RELATIVE_POINT + + +===Relative Point=== + +The points that the figures use are of type [[ref:libraries/vision2/reference/ev_relative_point_chart|EV_RELATIVE_POINT]]. Each point is relative to the location of the parent figure group (point), which is relative to the location of its parent figure group, and so on up to the top-level (world) figure group. Thus, each figure is defined by a set of relative points and a reference point (origin). If the reference point is not attached (as may be the case for immediate children of the top-level group, when it has no point object), the subordinate relative points are relative to point (0,0). The absolute coordinates are calculated only when needed by adding the absolute coordinates of the reference point to the relative coordinates. + +{{note|Even the top-level (world) figure group can be "moved" by calling its set_point feature, passing a new relative point. However, if this is done, then THAT relative point is relative to point (0,0). If you do this, do so before extend-ing it with figures and sub-groups so that they receive the point in question as their reference point.}} + + +==Figure Worlds== + +In order to put the figures you want to display in a context, you insert them (or the figure groups that contain them) into a top-level a "figure world" object: an instance of [[ref:libraries/vision2/reference/ev_figure_world_chart|EV_FIGURE_WORLD]]. This is a descendant of [[ref:libraries/vision2/reference/ev_figure_group_chart|EV_FIGURE_GROUP]] and hence works in the same way. This figure world is later associated with one or more projectors. [[ref:libraries/vision2/reference/ev_figure_world_chart|EV_FIGURE_WORLD]], as previously mentioned, adds a number of features to [[ref:libraries/vision2/reference/ev_figure_group_chart|EV_FIGURE_GROUP]]. These extra features are needed for graphical representation by a projector. One is the background color. This feature is used to erase the canvas for a graphical projector in the specified color. The other features are to manage the grid. + + +==Projectors== + +A projector is an object that knows what a figure world should look like. The figure world itself is only a hint of its representation. For example, if a line is "20" long, this might mean 20 pixels, miles, centimeters or whatever. It is up to the projector to interpret units. Also, color might be interpreted as gray scale. Typically, a projector will do the best possible job projecting the "world" of figures onto its device. + +With EiffelVision come these projectors: +* [[ref:libraries/vision2/reference/ev_postscript_projector_chart|EV_POSTSCRIPT_PROJECTOR]] +* [[ref:libraries/vision2/reference/ev_drawing_area_projector_chart|EV_DRAWING_AREA_PROJECTOR]] +* [[ref:libraries/vision2/reference/ev_pixmap_projector_chart|EV_PIXMAP_PROJECTOR]] +The first one maps figure worlds to a postscript file. The other two are descendants of [[ref:libraries/vision2/reference/ev_widget_projector_chart|EV_WIDGET_PROJECTOR]], and can project on widgets that inherit from [[ref:libraries/vision2/reference/ev_drawable_chart|EV_DRAWABLE]], two of which are [[ref:libraries/vision2/reference/ev_drawing_area_chart|EV_DRAWING_AREA]] and [[ref:libraries/vision2/reference/ev_pixmap_chart|EV_PIXMAP]], eventually using double-buffering, which normally results in a smoother animation but requires fast copying from memory to the video buffer (and thus can be slow if the display is remote). + + +==Events== + +The other features of drawing area and widget is that they generate pointer events. These events are translated by projectors to the map of the figure world. These projectors send the event to the appropriate figure. Every figure is set up to receive all the common pointer events, including Pick-and-Drop events: +* pointer_motion_actions +* pointer_button_press_actions +* pointer_double_press_actions +* pointer_button_release_actions +* pointer_enter_actions +* pointer_leave_actions +* pick_actions +* conforming_pick_actions +* drop_actions +There are no events for keyboard focus and no key press events. If you need to use these events, use them from pixmap or drawing area. + +When using events, keep the z-order in mind. This is the order in which the figures are stacked in the "figure world". The first item of a figure group is the figure that is the farthest away. Any figure can be obscured by (visible) figures in front of it. Events are only received by a figure when the (mouse) pointer is over its exposed areas, i.e. areas not obscured by (visible) figures in front of it. If a figure is fully obscured by visible figures in front of it, then it will receive no pointer events. + + +==Rotation and Scaling== + +Relative Points, which supply the location, scale and orientation for EV_FIGURE_... objects, also support rotation and scaling. Both rotation and scaling can be entered at any point in the tree of relative points. One of the most useful of these points is the point of an [[ref:libraries/vision2/reference/ev_figure_group_chart|EV_FIGURE_GROUP]], which rotation and/or scaling will then propagate down the tree to all the contained figures and sub-groups, by way of something like my_figure_group.point.set_angle (...). Rotation is in radians progressing counter-clockwise from the positive X axis. Scaling is multiplied into the chain of relative points. This means that when a relative point which is the root of a tree of several points is moved, the entire tree is moved. When it is scaled the entire tree is scaled, and the same for rotation. + +The scaling factor has two components: horizontal (x) and vertical (y), which can be set separately or together. If the x/y scaling factor is 0.5, everything at that point and below in the tree is displayed at half its normal size. + + diff --git a/documentation/18.11/solutions/gui-building/eiffelvision-2/eiffelvision-library-reference-manual/index.wiki b/documentation/18.11/solutions/gui-building/eiffelvision-2/eiffelvision-library-reference-manual/index.wiki new file mode 100644 index 00000000..a7d2ef29 --- /dev/null +++ b/documentation/18.11/solutions/gui-building/eiffelvision-2/eiffelvision-library-reference-manual/index.wiki @@ -0,0 +1,24 @@ +[[Property:title|EiffelVision Library Reference Manual]] +[[Property:weight|1]] +[[Property:uuid|b343b38b-c8b2-4247-072d-ecc1bc3e387a]] +EiffelVision 2 is a platform-independent Graphical User Interface (GUI) library that allows easy, simultaneous development of Windowed applications for both Windows- & Unix-based platforms. Heavily relying on the EiffelBase library, EiffelVision 2 has been designed primarily with ease of use in mind. By reusing EiffelBase structures, existing, as well as new Eiffel users will find EiffelVision to be surprising intuitive and easy to use. In very little time, users will be producing professional Windowed application skeletons which will run on a multitude of platforms with no change of source code. + +The EiffelVision 2 library includes the following interface clusters: + +* The [[Kernel| kernel]] cluster includes classes that are key to an EiffelVision 2 application. The most important class in this cluster is [[ref:libraries/vision2/reference/ev_application_chart| EV_APPLICATION]] which is the main entry point for all EiffelVision 2 applications. + +* The [[Widgets| widgets]] cluster contains classes used to create EiffelVision 2 widgets. Widgets are the visible objects that the user sees and interacts with in the application. Examples of widgets are windows, buttons and labels. + +* The [[Items| items]] cluster includes the classes needed to create items. Items are widgets that can only be contained within a certain type of widget. Example: [[ref:libraries/vision2/reference/ev_list_chart| EV_LIST]] widgets may only contain objects of type [[ref:libraries/vision2/reference/ev_list_item_chart|EV_LIST_ITEM]] . Items provide an abstract way of dealing with an item-widget's internal data structures and provide, in many cases, the same functionality that a widget does. + +* The [[Events| events]] cluster contains classes that allow for user-initiated events, such as the clicking of a button to be dealt with via the use of a linked list of agents ([[ref:libraries/vision2/reference/ev_action_sequence_chart|EV_ACTION_SEQUENCE]]). An Agent can be thought of as an object that encapsulates a certain procedure. When a user clicks a button on the screen, the corresponding [[ref:libraries/vision2/reference/ev_button_chart| EV_BUTTON]] object has its pointer_button_press_actions fired, and this, in turn, fires all of the agents held within this list, thus calling all of the procedures represented by the agents. Every widget and item has a number of [[ref:libraries/base/reference/action_sequence_chart|ACTION_SEQUENCE]] objects, each of which are linked to a certain type of event. To link any number of different procedure calls with an event, it is only necessary to extend the action-sequence list associated with that event, with agents representing those calls. + +* The [[Properties| properties]] cluster contains classes that allow for the customization of Vision 2 widgets and items. Classes such as [[ref:libraries/vision2/reference/ev_colorizable_chart|EV_COLORIZABLE]] and [[ref:libraries/vision2/reference/ev_fontable_chart|EV_FONTABLE]] contain routines that allow for (respectively) color and font to be altered for a widget. + +* The [[Support| support]] cluster includes classes that provide more professional touches to an application, whether these are keyboard shortcuts ([[ref:libraries/vision2/reference/ev_accelerator_list_chart|EV_ACCELERATOR_LIST]]) or graphical output ([[ref:libraries/vision2/reference/ev_graphical_format_chart|EV_GRAPHICAL_FORMAT]]) for drawable widgets such as [[ref:libraries/vision2/reference/ev_pixmap_chart|EV_PIXMAP]] . + +* The [[Figures| figures]] cluster allows for the projection of two-dimensional shapes (figures) onto an [[ref:libraries/vision2/reference/ev_drawable_chart|EV_DRAWABLE]] or printer via the use of an [[ref:libraries/vision2/reference/ev_projector_chart|EV_PROJECTOR]] . + +To see differences between released versions of EiffelVision, click [[Revisions and Bug Fixes|Here]] + + diff --git a/documentation/18.11/solutions/gui-building/eiffelvision-2/eiffelvision-library-reference-manual/items.wiki b/documentation/18.11/solutions/gui-building/eiffelvision-2/eiffelvision-library-reference-manual/items.wiki new file mode 100644 index 00000000..6b158bf4 --- /dev/null +++ b/documentation/18.11/solutions/gui-building/eiffelvision-2/eiffelvision-library-reference-manual/items.wiki @@ -0,0 +1,41 @@ +[[Property:title|Items]] +[[Property:weight|3]] +[[Property:uuid|3143511c-28bd-cc5c-c710-700796778982]] +An EiffelVision 2 "item" is an object that is used to display information inside certain primitives. For example, [[ref:libraries/vision2/reference/ev_list_chart|EV_LIST]] may hold items of type [[ref:libraries/vision2/reference/ev_list_item_chart|EV_LIST_ITEM]]. All EiffelVision 2 items are descendants of [[ref:libraries/vision2/reference/ev_item_chart|EV_ITEM]], which in turn is a descendant of [[ref:libraries/vision2/reference/ev_pixmapable_chart|EV_PIXMAPABLE]], which means that an item can display a [[ref:libraries/vision2/reference/ev_pixmap_chart|EV_PIXMAP]] object. + + +==Item Holders== + +Below is a structure showing some of the EiffelVision 2 item-containing components and the items that they accept: +* [[ref:libraries/vision2/reference/ev_list_chart|EV_LIST]] accepts items of type: +** [[ref:libraries/vision2/reference/ev_list_item_chart|EV_LIST_ITEM]] + +* [[ref:libraries/vision2/reference/ev_combo_box_chart|EV_COMBO_BOX]] accepts items of type: +** [[ref:libraries/vision2/reference/ev_list_item_chart|EV_LIST_ITEM]] + +* [[ref:libraries/vision2/reference/ev_window_chart|EV_WINDOW]] accepts items of type (use set_menu_bar): +** [[ref:libraries/vision2/reference/ev_menu_bar_chart|EV_MENU_BAR]] accepts items of type: +*** [[ref:libraries/vision2/reference/ev_menu_chart|EV_MENU]] accepts items of type: +**** [[ref:libraries/vision2/reference/ev_menu_chart|EV_MENU]] +**** [[ref:libraries/vision2/reference/ev_menu_item_chart|EV_MENU_ITEM]] +**** [[ref:libraries/vision2/reference/ev_menu_separator_chart|EV_MENU_SEPARATOR]] +**** [[ref:libraries/vision2/reference/ev_radio_menu_item_chart|EV_RADIO_MENU_ITEM]] +**** [[ref:libraries/vision2/reference/ev_check_menu_item_chart|EV_CHECK_MENU_ITEM]] + +* [[ref:libraries/vision2/reference/ev_multi_column_list_chart|EV_MULTI_COLUMN_LIST]] accepts items of type: +** [[ref:libraries/vision2/reference/ev_multi_column_list_row_chart|EV_MULTI_COLUMN_LIST_ROW]] + +* [[ref:libraries/vision2/reference/ev_tool_bar_chart|EV_TOOL_BAR]] accepts items of type: +** [[ref:libraries/vision2/reference/ev_tool_bar_button_chart|EV_TOOL_BAR_BUTTON]] +** [[ref:libraries/vision2/reference/ev_tool_bar_radio_button_chart|EV_TOOL_BAR_RADIO_BUTTON]] +** [[ref:libraries/vision2/reference/ev_tool_bar_separator_chart|EV_TOOL_BAR_SEPARATOR]] +** [[ref:libraries/vision2/reference/ev_tool_bar_toggle_button_chart|EV_TOOL_BAR_TOGGLE_BUTTON]] + +* EV_TREE accepts items of type: +** [[ref:libraries/vision2/reference/ev_dynamic_tree_item_chart|EV_DYNAMIC_TREE_ITEM]] accepts items of type: +*** [[ref:libraries/vision2/reference/ev_dynamic_tree_item_chart|EV_DYNAMIC_TREE_ITEM]] +*** [[ref:libraries/vision2/reference/ev_tree_item_chart|EV_TREE_ITEM]] +** [[ref:libraries/vision2/reference/ev_tree_item_chart|EV_TREE_ITEM]] accepts items of type: +*** [[ref:libraries/vision2/reference/ev_dynamic_tree_item_chart|EV_DYNAMIC_TREE_ITEM]] +*** [[ref:libraries/vision2/reference/ev_tree_item_chart|EV_TREE_ITEM]] + diff --git a/documentation/18.11/solutions/gui-building/eiffelvision-2/eiffelvision-library-reference-manual/kernel.wiki b/documentation/18.11/solutions/gui-building/eiffelvision-2/eiffelvision-library-reference-manual/kernel.wiki new file mode 100644 index 00000000..b115ed4f --- /dev/null +++ b/documentation/18.11/solutions/gui-building/eiffelvision-2/eiffelvision-library-reference-manual/kernel.wiki @@ -0,0 +1,93 @@ +[[Property:title|Kernel]] +[[Property:weight|1]] +[[Property:uuid|d830dc77-cd77-1f52-0e39-e0ec1cffa028]] +The kernel cluster contains classes that provide functionality common to most Windowed application. These classes are considered the core of any EiffelVision 2 application. The most important of these classes is [[ref:libraries/vision2/reference/ev_application_chart|EV_APPLICATION]]. This class is used to initialize the graphical toolkit and event loop of your EiffelVision 2 application. Kernel also includes classes such as [[ref:libraries/vision2/reference/ev_timeout_chart| EV_TIMEOUT]] that calls procedures (via agents) at specified intervals, and [[ref:libraries/vision2/reference/ev_color_chart| EV_COLOR]] which is used for coloring widgets and items. To start programming with EiffelVision 2, you first have to correctly initialize [[ref:libraries/vision2/reference/ev_application_chart|EV_APPLICATION]]. + + +==Launching Your Application with EV_APPLICATION — The Heart of All EiffelVision 2 Systems== + +[[ref:libraries/vision2/reference/ev_application_chart|EV_APPLICATION]] is the basis for every EiffelVision 2 application and is considered the most important class in the library. It is responsible for initializing the underlying toolkit that is driving the windowing system on the platform that you compile your system on. It is also where the main event loop that drives your application is executed. + +{{note|It is an '''error''' to attempt to create any EiffelVision 2 components before the application object has been created (see the Flat Contracts view of [[ref:libraries/vision2/reference/ev_environment_chart|EV_ENVIRONMENT]]). }} + +You may inherit [[ref:libraries/vision2/reference/ev_application_chart|EV_APPLICATION]] or use it as a client in order to create your EiffelVision 2 application. A simple method of using EV_APPLICATION is as follows: + +# Create an instance of EV_APPLICATION. +# Create one or more windows for your application. +# Launch the application. + +An example of an EiffelVision 2 application using inheritance from [[ref:libraries/vision2/reference/ev_application_chart|EV_APPLICATION]] is shown below. + + +class + HELLOWORLD_APP + +inherit + EV_APPLICATION + +create + make + +feature + + make + -- Create the application. + local + helloworld_window: EV_TITLED_WINDOW + do + default_create + create helloworld_window + helloworld_window.set_title ("Helloworld!") + helloworld_window.close_request_actions.extend (agent destroy) + helloworld_window.show + launch + end + +end + + +The following EiffelVision 2 application functions identically, but instead of inheriting from [[ref:libraries/vision2/reference/ev_application_chart|EV_APPLICATION]], it is used in a client/supplier relationship. + + +class + HELLOWORLD_APP + +create + make + +feature + + make + -- Create the EiffelVision 2 application with a helloworld window. + local + app: EV_APPLICATION + helloworld_window: EV_TITLED_WINDOW + do + create app + create helloworld_window + helloworld_window.set_title ("Helloworld!") + helloworld_window.close_request_actions.extend (agent app.destroy) + helloworld_window.show + app.launch + end + +end + + + +==What Does Launch Actually Do?== + +In EiffelVision 2, to launch an application means to pass control to the underlying graphical toolkit. Simply creating an application does not launch it. An explicit call to launch is required for the event processing to begin. + +{{note|An EiffelVision 2 system is event based. This means that the way you control the execution within an EiffelVision 2 system is by responding appropriately to [[Events|events]] as they occur. Therefore, if you call launch on an [[ref:libraries/vision2/reference/ev_application_chart|EV_APPLICATION]], the processing for the application will continue indefinitely unless you have provided a way to exit the application. It is essential to initialize your components correctly, so your application can be exited (i.e. call destroy on the application object). }} + + +==Building Your Application Skeleton== + +Now that you have a basic application skeleton set up, you can now: +* [[Widgets|Create widgets and set their properties.]] +* [[Containers|Add containers (that control widget layout) to your window(s), then place your created widgets in those containers.]] +* [[Events|Add code to respond to user actions with agents and action sequences.]] + +Once you have learned the basics of GUI programming within EiffelVision 2, you will be well on your way to creating powerful multi-platform applications. The Application Programming Interface (API) of EiffelVision 2 has been designed in a way to ensure that the library is as intuitive, consistent and stylistic as possible. Heavy reuse of components from the EiffelBase library is one of the main ingredients that makes this possible. + diff --git a/documentation/18.11/solutions/gui-building/eiffelvision-2/eiffelvision-library-reference-manual/properties/eiffelvision-pick-and-drop.wiki b/documentation/18.11/solutions/gui-building/eiffelvision-2/eiffelvision-library-reference-manual/properties/eiffelvision-pick-and-drop.wiki new file mode 100644 index 00000000..bb366e98 --- /dev/null +++ b/documentation/18.11/solutions/gui-building/eiffelvision-2/eiffelvision-library-reference-manual/properties/eiffelvision-pick-and-drop.wiki @@ -0,0 +1,88 @@ +[[Property:title|EiffelVision Pick and Drop]] +[[Property:weight|0]] +[[Property:uuid|309203de-6536-fe26-4f73-cb1f4a450e6f]] +Pick-and-Drop is a unique user-interface action that permits a user to request an action be performed on a specified object. It is a more-ergonomic alternative to the typical drag-and-drop or "select-and-click" user operations found in most modern graphical user interfaces. Users of EiffelStudio have come to value Pick-and-Drop as both intuitive, and easier on the wrist and fingers with long-term use. + +Pick-and-Drop uses the metaphor of '''pebbles and holes'''. The typical method of doing a pick-and-drop is that the end user selects the object to receive an action with a single right-click of the mouse. At that point, the mouse arrow turns into a "pebble" connected to the "point of picking" via a visible "band". This "pebble" is often a symbol representing the type of object that was "picked". In the case of the screen-shot below, it is a blue ellipse: the "pebble" symbol for a class. + +[[Image:EiffelStudio during class pick and drop2|thumbnail|360px|center|EiffelStudio During Class Pick-and-Drop]] + + +The "pebble" may then be dropped into any compatible "hole" (drop target—a widget configured to accept "pebbles" of this type). Such "receiving" widgets are often tool-bar buttons or editing areas (or in the case of the screen-shot above, the editor "tab" bar), but can be any widget that inherits from [[ref:libraries/vision2/reference/ev_pick_and_dropable_chart|EV_PICK_AND_DROPABLE]] and is properly configured. The user then can either "drop the pebble into the hole" with a second right-click (on the receiving object), or may cancel the operation by single-clicking the left mouse button. + +[[Image:EiffelStudio after class pick and drop2|thumbnail|360px|center|EiffelStudio After Class Pick-and-Drop]] + + +{{note|See [[uuid:a3789781-153b-7f4d-bb94-4bdf8923fb56|Retargeting Through Pick-and-Drop]] to see how EiffelStudio uses the Pick-and-Drop user interface.}} + + +Because the Pick-and-Drop operation has been so popular, classes have been added to the EiffelVision 2 library to make implementing this user interface very easy. + +From a technical viewpoint, Pick-and-Drop is a mechanism which allows data to be transported from a '''source''' object to a '''target'''. Any EiffelVision 2 object inheriting from [[ref:libraries/vision2/reference/ev_pick_and_dropable_chart|EV_PICK_AND_DROPABLE]] can be used to transport or receive data. + + +==A Simple Pick-and-Drop Example== + +The two necessary components for a Pick-and-Drop operation are a '''source''' and a '''target''', both of which must [[uuid:b8c10baa-4f50-adfe-a6f8-9cb56a8f1917#Conformance|conform]] to [[ref:libraries/vision2/reference/ev_pick_and_dropable_chart|EV_PICK_AND_DROPABLE]]. The data that is to be transported is known as a '''pebble'''. + +The following steps need to be undertaken to set up a simple pick and drop: +* Set the '''source''' by calling set_pebble. +* Set one or more '''targets''' by adding an [[ET: Agents|agent]] to their drop_actions list. To make the '''target''' accept that type of '''pebble''', the arguments of the [[ET: Agents|agent]] must match the type of the '''pebble''' to be transported for the '''source'''. Otherwise the transport will not be permitted. + +A simple example of this is demonstrated here: + + button1.set_pebble ("A PND transport has occured%N") + button2.drop_actions.extend (agent print (?)) + + +Because print takes an argument of type [[ref:libraries/base/reference/string_8_chart|STRING_8]], button2 becomes a valid drop-target for the pebble contained by button1. Right clicking the mouse pointer over the '''source''' will start the transport, and right clicking with the mouse pointer over a valid '''target''' will complete the transport. The transport can be canceled anytime with a simple left click, just as you would do in EiffelStudio. + +{{note|Any type of object can be used as the '''pebble'''. When a transport completes, the '''pebble''' that was transported is passed as an argument to all agents in the '''target's''' drop_actions list to which the '''pebble''' [[uuid:b8c10baa-4f50-adfe-a6f8-9cb56a8f1917#Conformance|conforms]].}} + + +==Three Different Modes of Transport== + +There are three different modes of transport available for pick and drop. They are listed below with details of their use: +* Pick and Drop Mode.
+::This is the default mode for pick and drop, but can be set by calling set_pick_and_drop_mode on the '''source''' object. Right clicking on a '''source''' starts the transport and right clicking on a valid '''target''' completes the transport. During execution, a band is drawn from the screen position where the pick started to the current mouse position. Pressing the left mouse button or the escape key during execution will end the transport. +* Drag and Drop Mode
+::This mode can be set by calling set_drag_and_drop_mode on the '''source''' object. Left clicking on a '''source''' starts the transport and releasing the left mouse button over a valid '''target''' completes the transport. During execution, a band is drawn from the screen position where the pick started to the current mouse position. Releasing the left mouse button or pressing the escape key during execution will end the transport. +* Target Menu Mode
+::This mode can be set by calling set_target_menu_mode on the '''source''' object. Right clicking on a '''source''' brings up a menu of all the valid drop '''targets''' in the system. Selecting one of these targets completes the transport. + + +==Accept and Deny Cursors== + +When mode_is_pick_and_drop or mode_is_drag_and_drop then the shape of the mouse cursor changes to reflect whether the current GUI component below the mouse accepts the pebble or not. Calling set_accept_cursor or set_deny_cursor on the '''source''' object allows you to customize the Accept- and Deny-Cursor respectively—used to represent a valid or invalid '''target''' respectively while the mouse pointer (pebble) is being moved around. The default Accept-Cursor is the standard mouse pointer. The default Deny-Cursor is a red circle with a diagonal line across it: the universal "not permitted" symbol. + +Example: + + + add_some_widgets + -- Add some widgets with a Pick-and-Drop example into `main_window'. + local + my_hbox: EV_HORIZONTAL_BOX + my_button1: EV_BUTTON + my_button2: EV_BUTTON + bullseye_pix_buffer: EV_PIXEL_BUFFER + bullseye_ptr_style: EV_POINTER_STYLE + do + create my_hbox + create my_button1.make_with_text ("Button1") + create my_button2.make_with_text ("Button2") + my_hbox.extend (my_button1) + my_hbox.extend (my_button2) + my_hbox.extend (create {EV_BUTTON}.make_with_text ("Button3")) + main_window.extend (my_hbox) + + my_button2.set_pebble ("A Pick-and-Drop has occurred.") + my_button1.drop_actions.extend (agent my_button1.set_text (?)) + my_button1.drop_actions.extend (agent io.put_string (?)) + create bullseye_pix_buffer.make_with_size (32, 32) + bullseye_pix_buffer.set_with_named_file ("BULLSEYE.png") + create bullseye_ptr_style.make_with_pixel_buffer (bullseye_pix_buffer, 32, 32) + my_button2.set_accept_cursor (bullseye_ptr_style) + end + + + diff --git a/documentation/18.11/solutions/gui-building/eiffelvision-2/eiffelvision-library-reference-manual/properties/index.wiki b/documentation/18.11/solutions/gui-building/eiffelvision-2/eiffelvision-library-reference-manual/properties/index.wiki new file mode 100644 index 00000000..5cc9d7b2 --- /dev/null +++ b/documentation/18.11/solutions/gui-building/eiffelvision-2/eiffelvision-library-reference-manual/properties/index.wiki @@ -0,0 +1,47 @@ +[[Property:title|Properties]] +[[Property:weight|5]] +[[Property:uuid|0d46c1eb-bce4-2d67-0272-da4aa5950c65]] +The Properties cluster contains all the common properties available for EiffelVision 2 [[Widgets|widgets]] and [[Items|items]]. Every EiffelVision 2 widget has the same set of properties inherited from EV_WIDGET, but many widgets also inherit additional properties, further refining the behavior of the widget. + +EV_WIDGET inherits the following properties: +* [[ref:libraries/vision2/reference/ev_pick_and_dropable_chart|EV_PICK_AND_DROPABLE]] +** For an overview of the Pick and Drop mechanism, click [[EiffelVision Pick and Drop|here]] . + +* [[ref:libraries/vision2/reference/ev_sensitive_chart|EV_SENSITIVE]] +** If an EiffelVision 2 component inherits from [[ref:libraries/vision2/reference/ev_sensitive_chart|EV_SENSITIVE]], it can be made to ignore events.
+:::Use disable_sensitive to disable event handling, and enable_sensitive to restore event handling. + +* [[ref:libraries/vision2/reference/ev_colorizable_chart|EV_COLORIZABLE]] +** If a EiffelVision 2 component inherits from [[ref:libraries/vision2/reference/ev_colorizable_chart|EV_COLORIZABLE]], it has facilities for modifying its foreground and background colors.
+:::Use set_foreground_color to set foreground_color and set_background_color to set background_color.
+:::Use set_default_colors to restore the colors to their defaults. + +* [[ref:libraries/vision2/reference/ev_help_contextable_chart|EV_HELP_CONTEXTABLE]] +** If a EiffelVision 2 component inherits from [[ref:libraries/vision2/reference/ev_help_contextable_chart|EV_HELP_CONTEXTABLE]], facilities are provided for associating help to the component when F1 or Shift F1 is pressed. + +* [[ref:libraries/vision2/reference/ev_positioned_chart|EV_POSITIONED]] +** If a EiffelVision 2 component inherits from [[ref:libraries/vision2/reference/ev_positioned_chart|EV_POSITIONED]], it is possible to query its current position, size and minimum size.
+:::Use x_position and y_position to find its position relative to its parent.
+:::Use width and height to find its size.
+:::Use minimum_width and minimum_height to find its minimum size. + +* [[ref:libraries/vision2/reference/ev_containable_chart|EV_CONTAINABLE]] +** If a EiffelVision 2 component inherits from [[ref:libraries/vision2/reference/ev_containable_chart|EV_CONTAINABLE]], it is able make calls on its parent. Use parent to make calls on the current parent. + + +{{note|[[ref:libraries/vision2/reference/ev_containable_chart|EV_CONTAINABLE]] has no features for setting the parent. In EiffelVision 2, a child has no features for setting its parent, while a parent such a descendant of EV_CONTAINER contains routines for adding children (one example is extend). }} + + +The following are several more properties used within EiffelVision 2: +* [[ref:libraries/vision2/reference/ev_deselectable_chart|EV_DESELECTABLE]] +* [[ref:libraries/vision2/reference/ev_drawable_chart|EV_DRAWABLE]] +* [[ref:libraries/vision2/reference/ev_fontable_chart|EV_FONTABLE]] +* [[ref:libraries/vision2/reference/ev_pixmapable_chart|EV_PIXMAPABLE]] +* [[ref:libraries/vision2/reference/ev_positionable_chart|EV_POSITIONABLE]] +* [[ref:libraries/vision2/reference/ev_selectable_chart|EV_SELECTABLE]] +* [[ref:libraries/vision2/reference/ev_textable_chart|EV_TEXTABLE]] +* [[ref:libraries/vision2/reference/ev_tooltipable_chart|EV_TOOLTIPABLE]] + +For a full list of properties available, see the "interface/properties" sub-cluster of the EiffelVision 2 library. + + diff --git a/documentation/18.11/solutions/gui-building/eiffelvision-2/eiffelvision-library-reference-manual/support.wiki b/documentation/18.11/solutions/gui-building/eiffelvision-2/eiffelvision-library-reference-manual/support.wiki new file mode 100644 index 00000000..b8e989cd --- /dev/null +++ b/documentation/18.11/solutions/gui-building/eiffelvision-2/eiffelvision-library-reference-manual/support.wiki @@ -0,0 +1,22 @@ +[[Property:title|Support]] +[[Property:weight|6]] +[[Property:uuid|fd72dc5e-32bd-55aa-0e2e-2c7af69c72fd]] +The support cluster contains many classes providing useful facilities within the library. Many of the classes within this cluster are constants classes, which are filled with constants values for specific contexts, generally indicated by their names. The following constants classes are available within this cluster: + +* [[ref:libraries/vision2/reference/ev_character_format_constants_chart|EV_CHARACTER_FORMAT_CONSTANTS]] +* [[ref:libraries/vision2/reference/ev_dialog_constants_chart|EV_DIALOG_CONSTANTS]] +* [[ref:libraries/vision2/reference/ev_drawable_constants_chart|EV_DRAWABLE_CONSTANTS]] +* [[ref:libraries/vision2/reference/ev_font_constants_chart|EV_FONT_CONSTANTS]] +* [[ref:libraries/vision2/reference/ev_key_constants_chart|EV_KEY_CONSTANTS]] +* [[ref:libraries/vision2/reference/ev_paragraph_constants_chart|EV_PARAGRAPH_CONSTANTS]] +* [[ref:libraries/vision2/reference/ev_pointer_constants_chart|EV_POINTER_CONSTANTS]] +* [[ref:libraries/vision2/reference/ev_pointer_style_constants_chart|EV_POINTER_STYLE_CONSTANTS]] +* [[ref:libraries/vision2/reference/ev_postscript_page_constants_chart|EV_POSTSCRIPT_PAGE_CONSTANTS]] +* [[ref:libraries/vision2/reference/ev_scroll_constants_chart|EV_SCROLL_CONSTANTS]] +* [[ref:libraries/vision2/reference/ev_text_alignment_constants_chart|EV_TEXT_ALIGNMENT_CONSTANTS]] + + +In a similar vein to constant classes, the following two classes are provided to provide support for default [[ref:libraries/vision2/reference/ev_color_chart|EV_COLOR]]s and [[ref:libraries/vision2/reference/ev_pixmap_chart|EV_PIXMAP]]s. +* [[ref:libraries/vision2/reference/ev_stock_colors_chart|EV_STOCK_COLORS]] +* [[ref:libraries/vision2/reference/ev_stock_pixmaps_chart|EV_STOCK_PIXMAPS]] + diff --git a/documentation/18.11/solutions/gui-building/eiffelvision-2/eiffelvision-library-reference-manual/widgets/containers.wiki b/documentation/18.11/solutions/gui-building/eiffelvision-2/eiffelvision-library-reference-manual/widgets/containers.wiki new file mode 100644 index 00000000..7d8102c9 --- /dev/null +++ b/documentation/18.11/solutions/gui-building/eiffelvision-2/eiffelvision-library-reference-manual/widgets/containers.wiki @@ -0,0 +1,64 @@ +[[Property:title|Containers]] +[[Property:weight|1]] +[[Property:uuid|aa71e29d-f0e0-9eb2-a289-675d24aac927]] +A container is a EiffelVision 2 widget that may contain other widgets. All containers inherit from [[ref:libraries/vision2/reference/ev_container_chart|EV_CONTAINER]]. Some containers such as [[ref:libraries/vision2/reference/ev_cell_chart|EV_CELL]] may only hold one widget while containers such as [[ref:libraries/vision2/reference/ev_box_chart|EV_BOX]] may hold multiple widgets. Since all containers inherit from type [[ref:libraries/vision2/reference/ev_widget_chart|EV_WIDGET]], this means that a container may be placed inside another container. Windows inherit from [[ref:libraries/vision2/reference/ev_cell_chart|EV_CELL]] and are therefore also classified as containers. + +{{note|Containers may only contain other widgets. Items may only be placed in certain primitives. For example, an [[ref:libraries/vision2/reference/ev_list_item_chart| EV_LIST_ITEM]] may only be contained in an [[ref:libraries/vision2/reference/ev_list_chart| EV_LIST]]. }} + + +==Inheritance from EiffelBase== + +Wherever possible, EiffelVision 2 containers reuse the container structures provided by [[EiffelBase]]. This provides three main advantages: + +# Familiarity for operations such as access, insertions, and removals. Anybody who already uses [[EiffelBase]] should find it easy to use EiffelVision 2 containers. +# The underlying structures used have been tried and tested for many years and their designs have proven to be robust and effective. +# Containers provide powerful methods of traversing and searching their contents. In the original EiffelVision library, you needed to keep references to widgets since you could not query the contents of their containers. + +For example, [[ref:libraries/vision2/reference/ev_container_chart|EV_CONTAINER]] inherits from BOX and COLLECTION. Descendents of [[ref:libraries/vision2/reference/ev_container_chart|EV_CONTAINER]] such as [[ref:libraries/vision2/reference/ev_box_chart|EV_TABLE]] may also inherit from other structures in [[EiffelBase]]. + + +==Using Containers== + +The main role of a container is to position its children in a certain way. An [[ref:libraries/vision2/reference/ev_horizontal_box_chart| EV_HORIZONTAL_BOX]] for example positions its children side by side. To achieve vertical stacking you would use an [[ref:libraries/vision2/reference/ev_vertical_box_chart| EV_VERTICAL_BOX]] . +A code example of adding widgets to a container is as follows: + + add_to_container + -- Add 3 buttons to a hbox and then show in window. + local + my_window: EV_TITLED_WINDOW + my_hbox: EV_HORIZONTAL_BOX + my_button: EV_BUTTON + do + create my_window + create my_hbox + create my_button.make_with_text ("Button1") + my_hbox.extend (my_button) + my_hbox.extend (create {EV_BUTTON}.make_with_text ("Button2")) + my_hbox.extend (create {EV_BUTTON}.make_with_text ("Button3")) + my_window.extend (my_hbox) + my_window.show + end + + +The mapping of a EiffelVision 2 container interface is very close to that of containers in [[EiffelBase]], such as a linked list. +* To add a widget to a container call extend. +* To remove a widget from the container call prune. +* To empty a container call wipe_out. +* To traverse the container, you can use features such as start, forth, item, and off. + +{{note|When a widget is added to a container, the container is the parent of the widget. }} + + +==Size of a Widget Within a Container== + +The size of a widget in a container is always at least its minimum size. By default, when a widget is added to a container it is expandable. This means that if the container gets bigger, the widget will expand to fit the extra space. This convenient functionality means that you don't have to worry about handling the size of the widget (such as when a user alters the size of a window) as this is all performed automatically. If, on the other hand, you decide you want the widget to remain at a certain size (its minimum size), [[ref:libraries/vision2/reference/ev_box_chart| EV_BOX]] (and therefore its descendants) contain the convenient call disable_item_resize. + + +==Sizing of Containers== + +Since [[ref:libraries/vision2/reference/ev_container_chart|EV_CONTAINER]] inherits from type [[ref:libraries/vision2/reference/ev_widget_chart|EV_WIDGET]], the following facilities are provided for setting the minimum size: set_minimum_width, set_minimum_height and set_minimum_size. It is important to remember that as a general rule, '''the current size of a container is always at least the minimum size of all its contents.''' + +{{note|The exception to this is: [[ref:libraries/vision2/reference/ev_fixed_chart|EV_FIXED]], [[ref:libraries/vision2/reference/ev_viewport_chart|EV_VIEWPORT]], and [[ref:libraries/vision2/reference/ev_scrollable_area_chart|EV_SCROLLABLE_AREA]] which do actually allow their contents to be larger than their current size.}} + + + diff --git a/documentation/18.11/solutions/gui-building/eiffelvision-2/eiffelvision-library-reference-manual/widgets/eiffelvision-dialogs.wiki b/documentation/18.11/solutions/gui-building/eiffelvision-2/eiffelvision-library-reference-manual/widgets/eiffelvision-dialogs.wiki new file mode 100644 index 00000000..f8cba2a5 --- /dev/null +++ b/documentation/18.11/solutions/gui-building/eiffelvision-2/eiffelvision-library-reference-manual/widgets/eiffelvision-dialogs.wiki @@ -0,0 +1,32 @@ +[[Property:title|EiffelVision Dialogs]] +[[Property:weight|2]] +[[Property:uuid|85cfcfd3-a46e-4e2e-330a-61c2d1579b0f]] +This cluster contains all the dialogs provided by EiffelVision 2. + +==Standard Dialog Boxes== + +A standard dialog box provides a way of interacting with the underlying platform (such as Windows or Linux) to perform basic tasks such as opening a file or printing a document. EiffelVision 2 provides six standard dialogs that allow the user to perform common tasks. They are: +* [[ref:libraries/vision2/reference/ev_color_dialog_chart|EV_COLOR_DIALOG]] — allows the user to select an RGB color (useful for graphical apps such as a Paint Program). +* [[ref:libraries/vision2/reference/ev_directory_dialog_chart|EV_DIRECTORY_DIALOG]] — allows the user to select a directory. +* [[ref:libraries/vision2/reference/ev_file_open_dialog_chart|EV_FILE_OPEN_DIALOG]] — allows the user to select an existing file to be opened. +* [[ref:libraries/vision2/reference/ev_file_save_dialog_chart|EV_FILE_SAVE_DIALOG]] — allows the user to select a filename to be used for creation of a file. +* [[ref:libraries/vision2/reference/ev_font_dialog_chart|EV_FONT_DIALOG]] — allows the user to select a font (useful for a Word Processor for example). +* [[ref:libraries/vision2/reference/ev_print_dialog_chart|EV_PRINT_DIALOG]] — allows the user to confirm or change printer settings for printing (may be used in conjunction with [[ref:libraries/vision2/reference/ev_print_projector_chart|EV_PRINT_PROJECTOR]]). + + +==Creating Custom Dialog Boxes== + +If you wish to provide a custom dialog in your application, [[ref:libraries/vision2/reference/ev_dialog_chart| EV_DIALOG]] has been provided to facilitate this. + + +==Message Dialog Boxes== + +A message dialog box gives your application a standard way of displaying information, or asking simple questions. This information can be displayed with the following message dialog boxes. +* [[ref:libraries/vision2/reference/ev_message_dialog_chart|EV_MESSAGE_DIALOG]] — displays a simple message with an "OK" button. +* [[ref:libraries/vision2/reference/ev_information_dialog_chart|EV_INFORMATION_DIALOG]] — displays information to the user (in Windows this dialog box contains an "information" icon). +* [[ref:libraries/vision2/reference/ev_question_dialog_chart|EV_QUESTION_DIALOG]] — displays a question and allows user to respond with "Yes" or "No" button. +* [[ref:libraries/vision2/reference/ev_warning_dialog_chart|EV_WARNING_DIALOG]] — displays a warning to the user. +* [[ref:libraries/vision2/reference/ev_confirmation_dialog_chart|EV_CONFIRMATION_DIALOG]] — allows the user to confirm an action that has been requested. +* [[ref:libraries/vision2/reference/ev_error_dialog_chart|EV_ERROR_DIALOG]] — displays an error message. + + diff --git a/documentation/18.11/solutions/gui-building/eiffelvision-2/eiffelvision-library-reference-manual/widgets/index.wiki b/documentation/18.11/solutions/gui-building/eiffelvision-2/eiffelvision-library-reference-manual/widgets/index.wiki new file mode 100644 index 00000000..455941fb --- /dev/null +++ b/documentation/18.11/solutions/gui-building/eiffelvision-2/eiffelvision-library-reference-manual/widgets/index.wiki @@ -0,0 +1,60 @@ +[[Property:title|Widgets]] +[[Property:weight|2]] +[[Property:uuid|595bb73e-146a-ea19-221f-40f3415aad34]] +==What Is a Widget?== + +A Widget is the fundamental building block of your application's GUI. Components such as Windows, Buttons, Text fields, Check Boxes, List Boxes and layout Containers are examples of widgets. The widget set in EiffelVision 2 provides you with the flexibility to easily create powerful graphical applications. All widgets in EiffelVision 2 inherit from [[ref:libraries/vision2/reference/ev_widget_chart| EV_WIDGET]], thus the features provided in EV_WIDGET may be called on any widget. + + +==Variations of Widgets== +Within EiffelVision 2, widgets have been classified into three different groups: + +* [[Primitives|Primitives]] — These are elements of the user interface that are mainly responsible for interaction with the user, such as an [[ref:libraries/vision2/reference/ev_button_chart|EV_BUTTON]]. + +* [[Containers|Containers]] — These are used to contain other widgets and position them in a certain way, such as an [[ref:libraries/vision2/reference/ev_vertical_box_chart| EV_VERTICAL_BOX ]] that stacks its child widgets one by one vertically. + +* [[EiffelVision Dialogs|Dialogs]] — These are pop up dialog boxes used for interacting with the user for tasks such as opening a file (EV_FILE_OPEN_DIALOG) or displaying a message (EV_MESSAGE_DIALOG). You may also construct your own dialog boxes by inheriting from EV_DIALOG. + + +==How Do I Create a Widget?== + +All widgets in EiffelVision 2 are based around the default_create mechanism in Eiffel. This means that all that needs to be done to create a widget is to declare a reference to a type (such as [[ref:libraries/vision2/reference/ev_button_chart|EV_BUTTON]] ) and then call create on that reference. An example of this is as follows. + + my_button: EV_BUTTON + create my_button + + +Along with the default creation, EiffelVision 2 also includes a few additional creation features for convenience. An example of this is make_with_text for all widgets that may have text associated with them (those that inherit from [[ref:libraries/vision2/reference/ev_textable_chart| EV_TEXTABLE]] ), this saves a call to set_text upon default creation of the textable widget. Thus: + + create my_button.make_with_text ("Click Me") + + +would replace + + create my_button + my_button.set_text ("Click Me") + + +{{note|When a widget is created, no extra initialization has to be performed. '''The only exception is with windows, for which it is necessary to call show in order for the windows to be displayed on screen'''. This permits widgets to be added to a window while it is still invisible, and then when made visible with show, the window and all its visible widgets are displayed at once.}} + + +==Sizing== + +Since [[ref:libraries/vision2/reference/ev_primitive_chart|EV_PRIMITIVE]] inherits from type [[ref:libraries/vision2/reference/ev_widget_chart|EV_WIDGET]], the following facilities are provided for setting the minimum size: set_minimum_width, set_minimum_height and set_minimum_size. + +The minimum size of a widget is the smallest possible size that it can be inside its parent container. If an [[ref:libraries/vision2/reference/ev_button_chart|EV_BUTTON]] was created and set with a minimum_size of width/height (100, 100), if this button was inserted in to an [[ref:libraries/vision2/reference/ev_horizontal_box_chart| EV_HORIZONTAL_BOX]], then the box's size could never be below (100, 100) or it would violate the minimum size of the button. '''The size of a container must always be greater or equal to the minimum sizes of its children.''' + +{{note|In EiffelVision 2, there is no way to set the current size of the primitive. The current size is dependent on the size of the parent or the minimum_size. }} + + +==Now What Do I Do?== + +Now that you can create a widget, you will need to actually make it usable to your intended user. This will usually involve these three steps.
+ +* Setting [[Properties| properties]] for the widget such as color and minimum size. + +* Making the widget respond to user [[Events| events]] via the use of agents and action sequences. + +* Placing the widget inside a [[Containers| container]] widget (either a window or a child of a window) so it can be shown on the screen. + + diff --git a/documentation/18.11/solutions/gui-building/eiffelvision-2/eiffelvision-library-reference-manual/widgets/primitives.wiki b/documentation/18.11/solutions/gui-building/eiffelvision-2/eiffelvision-library-reference-manual/widgets/primitives.wiki new file mode 100644 index 00000000..37930ba5 --- /dev/null +++ b/documentation/18.11/solutions/gui-building/eiffelvision-2/eiffelvision-library-reference-manual/widgets/primitives.wiki @@ -0,0 +1,18 @@ +[[Property:title|Primitives]] +[[Property:weight|0]] +[[Property:uuid|09d70dd5-2e30-7615-88ac-4babe4eb7aa6]] +A primitive is an EiffelVision 2 widget that may not contain other widgets. Primitives may be placed in [[Containers|containers]], but a primitive [[Widgets|widget ]] may not contain any child widgets. Some examples of primitives are [[ref:libraries/vision2/reference/ev_button_chart|EV_BUTTON]] and [[ref:libraries/vision2/reference/ev_label_chart|EV_LABEL]]. All EiffelVision 2 primitives inherit from [[ref:libraries/vision2/reference/ev_primitive_chart|EV_PRIMITIVE]]. + + +==Features of a Primitive== + +All primitives inherit from [[ref:libraries/vision2/reference/ev_tooltipable_chart|EV_TOOLTIPABLE]] and therefore may have tooltips assigned to them. They all inherit many features from [[ref:libraries/vision2/reference/ev_widget_chart|EV_WIDGET]]. Each descendent of [[ref:libraries/vision2/reference/ev_primitive_chart|EV_PRIMITIVE]] will typically have many features specific to its type. For example, [[ref:libraries/vision2/reference/ev_separator_chart|EV_SEPARATOR]] has no extra features, but [[ref:libraries/vision2/reference/ev_label_chart|EV_LABEL]] has features for modifying the current font and text to be displayed. + + +==Widgets as Item Holders== + +Although no primitive can contain another widget, certain primitives may contain one or more [[Items|items]]. One example of this is an [[ref:libraries/vision2/reference/ev_list_chart| EV_LIST]] containing [[ref:libraries/vision2/reference/ev_list_item_chart|EV_LIST_ITEM]]s. + + + + diff --git a/documentation/18.11/solutions/gui-building/eiffelvision-2/index.wiki b/documentation/18.11/solutions/gui-building/eiffelvision-2/index.wiki new file mode 100644 index 00000000..d9f21901 --- /dev/null +++ b/documentation/18.11/solutions/gui-building/eiffelvision-2/index.wiki @@ -0,0 +1,15 @@ +[[Property:link_title|EiffelVision 2]] +[[Property:title|EiffelVision 2]] +[[Property:weight|10]] +[[Property:uuid|c72b1a5c-9cbf-f8c8-a4c2-619e392799b0]] +==EiffelVision 2 Library== + +EiffelVision 2 (also called just "EiffelVision", or even just "Vision") is the basic tool for building graphical and GUI (Graphical User Interface) applications in Eiffel. + +EiffelVision is portable: you can use it to design the graphical part of your applications independently of the target platform; then on each platform, such as Windows or X (Linux, Unix etc.), it will use the native graphical mechanisms to produce the platform's native look-and-feel. + +Type: Library + +Platform: Any + + diff --git a/documentation/18.11/solutions/gui-building/eiffelvision-2/revisions-and-bug-fixes.wiki b/documentation/18.11/solutions/gui-building/eiffelvision-2/revisions-and-bug-fixes.wiki new file mode 100644 index 00000000..478fbbf4 --- /dev/null +++ b/documentation/18.11/solutions/gui-building/eiffelvision-2/revisions-and-bug-fixes.wiki @@ -0,0 +1,944 @@ +[[Property:title|Revisions and Bug Fixes]] +[[Property:weight|10]] +[[Property:uuid|eb11a237-0c75-0427-452a-303d4f276b97]] +This document contains details of modifications and bug fixes to the EiffelVision 2 library listed by the release version of EiffelStudio. All bug fixes and modifications are relative to the previously released version + +==EiffelStudio 14.05== +'''Improvements''' +* Made it possible to query {EV_TEXT_COMPONENT}.start_selection and {EV_TEXT_COMPONENT}.end_selection even if there is no selection. In that case they return the same value which is the caret position. +* Created a set of classes to make it easier to develop AutoTest tests for code based on Vision2. + +'''Changes''' +* Made {EV_TEXT_COMPONENT}.selection_start and {EV_TEXT_COMPONENT}.selection_end obsolete because '''selection_end''' was returning a character position and not a caret position which is counter-intuitive since '''set_selection''' is using caret positions. Introduced '''start_selection''' and '''end_selection''' instead that return the selection start and end in caret positions. + + +'''Bug fixes''' +*'''Platform Independent''' +** Fixed a bug that would allow pick and drop on disabled items because code allowed to be dropped on. + +*'''GTK''': +** Fixed issue where if a menu entry is of the form '''my_entry''', then only '''myentry''' will appear ( bug#18716). +** Fixed a bug in {EV_TEXT}.selected_text where if the text contained non-ASCII character, then it will just return the UTF-8 sequence of those Unicode characters instead of the Unicode characters. +** Fixed {EV_DRAWABLE}.draw_sub_pixel_buffer and {EV_PIXEL_BUFFER}.sub_pixel_buffer when the rectangle provided is larger than the image it would cause a crash. +** Fixed a precondition violation in the implementation of {EV_PIXEL_BUFFER}.get_pixel. + +*'''Windows''': +** Fixed contract violations when closing/destroying a dialog. +** Fixed contract violation when wiping out a notebook. +** Fixed various issues on Windows with EV_TEXTABLE components when the text contains Unicode characters that generate a surrogate pair in UTF-16, the Windows API always refers to UTF-16 code units while at the Eiffel level we still refer to character position. +** Fixed a by one error when mapping a caret position to the actual caret position of the underlying Windows implementation which has %R%N and not just %N. + +==EiffelStudio 13.11== +'''Improvements''' +* Added support for GTK3. + +'''Bug fixes''' +*'''Platform Independent''' +** Fixed a drawing issue in EV_GRID causing some invalid drawing. +** Fixed a crash with retrieving a RTF file containing a color or a font whose index is not starting at 1, or that it is referring to a non-defined index. +** Fixed a bug introduced at rev#90517 with `new_line_string` that became TN instead of %N. +** Fixed a bug retrieving font in a font table to allow spaces between the components of a font entry in the table.  +** Added code protection to find out about paragraphs as we would get an out of bound acess if the last character was a %N. This solved the case where copy/pasting some text from Word would save incorrectly, and thus the RTF being created was invalid and was losing some formatting info. + +*'''Windows''' +** Fixed bug#18612: unsetting column text on addition of a new column we set with an empty text when there is no previous column text set, this prevents a side effect of unsetting a text mask on the wel list view control which doesn't seem to like being reset back when a new column is replacing it when the text mask actually is set. +** Fixed a crash when selecting text in a EV_RICH_TEXT widget. + +==EiffelStudio 7.3== +'''Improvements''' +* Added {EV_PIXEL_BUFFER}.stretched which gives you a stretched version of an EV_PIXEL_BUFFER. The quality of the stretched image is much better than the previous implementation of EV_PIXMAP for Windows. On Unix it is the same quality as EV_PIXMAP. +* Improved stretching of EV_PIXMAP on Windows by using the Color on Color stretching mode of the Win32 API StretchBlt. + + +'''Bug fixes''' +*'''Platform Independent''' +** Fixed inconsistencies in maximize/restore window behavior between Windows and Gtk platforms. +** Fixed {EV_GRID_COLUMN}.required_width_of_item_span to only take into account visible item. + +*'''Windows''' +** Fixed a resizing bug when you have a vertical/horizontal box with a minimum size set. If one of the items has a minimum size larger than its parent, then in some circumstances the child will be shrunk beyond its minimum size causing some visual glitches. + +==EiffelStudio 7.1== + +'''New''' +* Added experimental GTK3 support with HTML5 backend. +* Added SCOOP compatibility. + +'''Improvements''' +* Added a hint facility for the height of the drop down in a combo box. Currently the hint is only followed on Windows. +* Improved keyboard navigation of EV_GRID's including tab handling of activatable grid items. +* Improved keyboard activation/settings for certain type of grid items. +* Improved latency of asynchronous agents calling through do_once_on_idle when adding from another thread. + +'''Bug fixes''' + +*'''Platform Independent''' +** Fixed problems when keyboard navigating in EV_GRID's when hidden columns are present. + +*'''Windows''' +** Added support for high resolution wheel mice. +** Fixed a potential crash when using an EV_FIXED if resizing causes some redraw operations. +** Fixed an issue where the pick and drop lines would disappear after performing an Alt+Tab to switch between applications. +** Made sure colors are not shared between a widget and the original color object used to set the color of the widget. + +*'''GTK''' +** Fixed a bug (PR#18082). The fix ensures that in cases in which a descendant of EV_TEXTABLE contains pixmaps but no text, the pixmaps are properly centered. +** Fixed internationalization handling for keyboard input. + +==EiffelStudio 7.0== +'''Improvements''' +* Added multi-monitor functionality to EV_SCREEN. +* Optimized communication between worker thread and gui thread in {EV_APPLICATION}.do_once_on_idle. + +'''Bug fixes''' +*'''Platform Independent''' +** Improved multi-monitor handling for EV_GRID item activation popups. + +*'''Windows''' +** Fixed rendering of activate button in dialogs when theming is enabled. + +*'''GTK''' +** Fixed bug in `set_item_size` for EV_FIXED and EV_VIEWPORT where sometimes item would not shrink if set when displayed. + +==EiffelStudio 6.8== +'''Improvements''' +* Allowed setting the text of a combo box that has been disabled. +* Resize actions are now called after a container has completed its resizing. +* On Windows, increased the splitter size to make it more visible and easier to grab. +* The API now accepts READABLE_STRING_GENERAL as input for strings, which let you accept immutable strings without conversions. + +'''Bug fixes''' +*'''Platform Independent''' +** Fixed incorrect drawing of connector line for root tree nodes in an EV_GRID. + +*'''Windows''' +** Improved resizing on Windows with deeply nested windows that would not properly resize. +** Use the proper default font to follow the current active theme. +** Fixed a bug where terminating a pick and drop and moving your mouse quickly could result in a drop to a different widget than the one where pick and drop was terminated via the right click. + +==EiffelStudio 6.7== + +'''Improvements''' +* Optimized integration with EiffelGraph library for improved projection speed and efficiency + +'''Bug fixes''' +*'''Platform Independent''' +** Fixed various catcalls at runtime. + +*'''Unix'''' +** Fixed an initialization issue due to recent changes in the GTK API. + +*'''Windows''' +** Fixed an issue with EV_TREE, EV_LIST, EV_HEADER, EV_TOOL_BAR and EV_MULTI_COLUMN_LIST where setting a pebble on the control (not just the item) would allow pick and drop but the line drawn was restricted to the control. + +==EiffelStudio 6.6== + +'''Improvements''' +* Optimized integration with EiffelGraph library for improved projection speed and efficiency + +'''Bug fixes''' +*'''Platform Independent''' +** Fixed multi-threading dead-lock problem when extending idle actions whilst blocking the main thread with a mutex via an idle action. + +==EiffelStudio 6.5== + +'''Improvements''' +* Improved the pick and drop mechanism on Windows platforms to not use the `wel_hook.dll`. The visible change is that when the cursor is outside the vision2 application its shape changes depending on what is beneath. + +'''Bug fixes''' +*'''Platform Independent''' +** Fixed potential crash with tab navigation code when a key press was sent to a widget that is in the process of being unparented. + + +==EiffelStudio 6.4== + +As part of the void-safety conversion for EiffelStudio 6.4, EiffelVision 2 was converted to a void-safe library (currently in experimental mode only) and no changes were made to the existing library. To use the void-safe library, some areas may need to be rewritten, these changes are described [[Converting existing software to void-safety| here]] + + +'''Void-safety Interface modifications''' + +*'''EV_ANY''' +** Added 'create_interface_objects' so that attached types may be created before the bridge pattern is set, these attached types are then initialized via 'initialize' + + +==EiffelStudio 6.3== + +'''Interface modifications''' + +* '''EV_APPLICATION''' +**Added 'add_idle_action_kamikaze' as a synonym for 'do_once_on_idle' as this matches better with 'add_idle_action' + +'''Bug Fixes''' + +*'''Platform Independent''' +** '''EV_GRID''' +***Optimized rendering of items during addition/removal of large number of rows/items. +***Fixed item selection handling to correctly handle the Alt key +***Fixed certain graphical glitches and a crash when inserting new subrows in to existing structures +***Optimized 'remove_rows' to not redraw the grid 'during' each call, now scrollbars are updated on idle + +*'''Windows''' +** '''EV_ACCELERATOR''' +***Reimplemented accelerator handling so that they work with dialog windows. + +*'''Solaris/Linux''' +** '''EV_PIXEL_BUFFER''' +***Now correctly resetting item data after creation, before pixel buffer memory was random +***Fixed 'draw_pixel_buffer' to correctly composite the data instead of blindly copying it over. +**'''EV_DRAWABLE''' +*** Optimized clipping to prevent overdraw when blitting pixmaps offscreen. + + + +==EiffelStudio 6.2== + +'''Interface modifications''' +* '''EV_WINDOW''' - Added hide actions. + +'''Bug fixes''' +* '''Platform independent''' +** '''EV_GRID''' +*** Fixed crashes when rendering child tree nodes + + + +==EiffelStudio 6.1== + +'''Interface modifications''' +* '''EV_APPLICATION''' - Added 'is_display_remote' for determining whether the graphical display is on the same machine as the running system. +* '''EV_POINTER_STYLE_CONSTANTS''' - Added hyperlink_cursor constant so that hyperlink cursors may be used in applications +* '''EV_POINTER_STYLE''' - Now pointer style objects may be twinned correctly to match the capability of pixmaps and cursor objects. +* '''EV_DRAWABLE''' - Added 'draw_sub_pixel_buffer' so that pixel buffer data may be rendered to a drawable. +* '''EV_PIXEL_BUFFER''' - Added 'draw_pixel_buffer_with_x_y'. +* '''EV_STOCK_PIXMAPS''' - Now pixel buffers are used for stock icons; this allows for alpha transparency information to be retained. + +'''Bug fixes''' +* '''Platform independent''' +** '''EV_GRID''' +*** Fixed certain crashes when recomputing offsets + + +* '''Windows''' +** '''EV_STOCK_PIXMAPS''' +*** Now alpha information is correctly extracted for stock icons + + +* '''Linux/Solaris''' +** '''EV_COMBO_BOX''' +*** Fixed calling of change_actions when items are selected via the drop down + +** '''EV_POINTER_STYLE''' +*** Fixed issue when converting to a cursor object then reverting back would render a white square instead of the requested cursor + +** '''EV_WINDOW''' +*** Fixed issues when calling disable/enable user resize in certain states + + + +==EiffelStudio 6.0== + +'''Interface modifications''' +* '''EV_PICK_AND_DROPABLE''' - Added context menu capabilities with 'set_configurable_target_menu_mode', 'set_configurable_target_menu_handler' and 'show_configurable_target_menu' that can be used to override the existing Pick and Drop mechanism. +* '''EV_ACTION_SEQUENCE''' - Now event_data is defined with named tuples for easier reading of the action sequence parameters. +* '''EV_APPLICATION_ACTION_SEQUENCES''' +** Added 'file_drop_actions' for OS based file drag and drop from exterior applications to a EiffelVision 2 application. +** Made 'idle_actions' obsolete as it is not thread-safe +** Now a full garbage collection occurs if the application has been idle for 30 seconds + +* '''EV_APPLICATION''' +** Added 'transport_in_progress' for querying if a pebble transport is currently taking place. +** Added caps_lock_on for querying if the caps lock key is currently toggled +** `process_events` will now call idle actions when no more events are left in the pending queue + +* '''EV_FONT''' - Added 'line_height' to retrieve an appropriate text editor line height in pixels for a font. +* '''EV_PIXEL_BUFFER''' - Added conversion to/from EV_PIXMAP and added 'save_to_named_file' for saving buffer to disk. +* '''EV_POINTER_STYLE_CONSTANTS''' - Added header_sizewe cursor +* '''EV_FIXED''' - Added extend_with_size_and_position and set_with_size_and_position for flicker free update of fixed children. +* '''EV_GRID''' - Added `visible_row_count` for querying the number of currently visible rows. +* '''EV_TEXT_FIELD''' - Added inheritance from EV_TEXT_ALIGNABLE +* '''EV_POPUP_WINDOW''' - Added 'make_with_shadow' creation procedure to create a popup window with an alpha shadow (on platforms that support it). + +'''Bug fixes''' +* '''Platform independent''' +** '''EV_GRID''' +*** Fixed refresh issues and certain crashes when removing items from grid +*** Fixed navigation and selection handling for trees + +** '''EV_PICK_AND_DROPABLE''' - Fixed 'memory leak' when calling 'pebble_function'. + +* '''Windows''' +** Raised compatibility bar to Windows 2000 or greater. No more support for Windows 98 or NT 4.0. +** '''EV_DIALOG''' +*** Fixed resizing bug that led to a difference in behavior from regular EV_WINDOW descendents +*** Corrected calling of cancel actions when closing via the Cross which previously was broken for modeless and modal dialogs + +** '''EV_PIXMAP''' +*** Now correctly copying all agents over when the pixmap implementation internally changes state, previously some agents were being lost after certain operations on a pixmap +*** Now mask is correctly queried when saving pixmap + + +* '''Linux/Solaris''' +** '''EV_ACCELERATOR''' - Reimplemented accelerator implementation so that it works with all key combinations that were previously being unprocessed by gtk +** Completely reimplemented and optimized event handling for faster response, scaled down use of agents for event connection for decreased memory consumption + + +==EiffelStudio 5.7== + +'''Interface modifications''' +* '''STRING_GENERAL''' - All string operations now take STRING_GENERAL instead of STRING, this allows for mixing and matching of 8 and 32-bit string objects and allows for 32bit Unicode values, the return value is always STRING_32 +* '''EV_APPLICATION''' +** Added action sequences for querying global user events such as pointer clicks and motion +** EiffelVision 2 is now thread-aware with the addition of thread-safe 'add_idle_action' and 'do_once_on_idle' that allow threads to add agents to update the main GUI thread in a safe manner + +* '''EV_POINTER_STYLE''' - Added new pointer style class for setting the style of the mouse pointer, EV_CURSOR will be made obsolete, in the future animated cursors and transparency will be available +* '''EV_PIXEL_BUFFER''' - New class for loading/querying and setting RGBA values from disk +* '''EV_FIXED''' - Now item positions may be set to negative values within the fixed widget +* '''EV_BITMAP''' - New class for setting 1 bit masks on EV_PIXMAP via set_mask +* '''EV_TEXT''' - Added 'scroll_to_end' to scroll down so that the last line is visible +* '''EV_WIDGET''' +** Added 'refresh_now' that allows for immediate redraw of a widget without having to wait for the event loop to repaint it. A useful example of this is when calling 'set_text' on EV_LABEL during heavy computation. +** Added ability to ignore the default key action on widgets. + +* '''EV_GRID''' +** Changed semantic of `move_row` and `move_rows` so that destination position is now an insertion index before a row instead of placing as the row index itself. This allows for easier insertion of rows. Any code using these features will need to be rechecked as this is a breaking change for rows that are moved down the grid +** Altered `move_rows` so that it will now unparent the top level nodes from the first row being moved whilst keeping any subtree structure +** Added `move_rows_to_parent` that allows moving a block of parented rows from one parent to another +** Added `insert_new_rows` and `insert_new_rows_parented` which permit you to add insert multiple rows at once. This is far quicker than adding rows individually. +** Added `remove_rows` which permits you to remove multiple rows at once. This is far quicker than removing each row individually. +** Fixed `enable_capture` and disable_capture' which previously captured an internally hidden component of the grid, so no events were ever received during capture. +** Previously, `set_default_colors` did not work. +** Fixed bug in `pointer_enter_actions` and `pointer_leave_actions` of EV_GRID_ITEM which were not always fired when the mouse pointer entered or left the grid. +** Corrected `not_row_height_variable_and_vertical_scrolling_per_pixel` precondition of `enable_partial_dynamic_content`. +** Fixed bug which caused an internal exception within the grid when `is_tree_enabled` and `is_content_partially_dynamic`. +** Strengthened preconditions of `insert_new_row_parented` to prevent you inserting a new row at an index within a subtree structure of one of the existing subrows, as in that case, it is impossible for the parent to be the desired row. +** Added capability to hide rows in the grid +** Added ability for locking the position of rows and columns in the grid + +* '''EV_GRID_ROW''' - Added `insert_subrows` for the quick addition of multiple subrows at once. +* '''EV_WINDOW''' - Added `is_border_enabled`, `enable_border` and `disable_border`. This lets you turn on/off the border as required. +* '''EV_HEADER_ITEM''' - Added `user_can_resize` which enables you to prevent a user from resizing the item. Also added `minimum_width` and `maximum_width` which permit you to restrict the resizing of the item within a particular range. +* '''EV_MESSAGE_DIALOG''' - All message dialogs now use their associated message icon as the icon pixmap displayed in the title bar, instead of the standard EiffelVision 2 icon. +* '''EV_DYNAMIC_TREE_ITEM''' - The `subtree_function` is now only executed when you expand the item. In the previous version, querying the contents of the item caused the subtree function to be executed, filling the children. +* '''EV_COMBO_BOX''' - Added `is_list_shown`, `list_hidden_actions` and renamed `drop_down_actions` to `list_shown_actions`. +* '''EV_APPLICATION''' - Added `pointer_motion_actions`, `pointer_button_press_actions`, `pointer_button_release_actions`, `pointer_double_press_actions`, `mouse_wheel_actions`, `key_press_actions`, `key_press_string_actions` and `key_release_actions`. Each of these action sequences pass the applicable widget as part of the event data. + +'''Bug fixes''' +* '''Platform independent''' +** '''EV_GRID''' - Fixed refresh issues and certain crashes when removing items from grid + +* '''Windows''' +** '''EV_WINDOW''' - The default state is now `user_can_resize`. Although this was previously specified within `is_in_default_state`, the window was not actually resizeable. +** '''EV_DIALOG''' +*** Calling `enable_user_resize` or `disable_user_resize` on a dialog that is shown relative to another window no longer looses the relative state of the dialog. +*** Fixed failure of a "check" statement within EiffelVision when showing a dialog with a `default_cancel_button` relative or modal to another window. + +** '''EV_FONT_DIALOG''' - Fixed issue where displayed font did not take into account font specified through call to `set_font`. +** '''EV_RICH_TEXT''' - Fixed calling of `change_actions` which were never called in the previous version. +** '''EV_PIXMAP''' - If a pixmap was parented directly within a container and Windows XP themes were enabled, the background theme of the parent container was not applied to the pixmap. This was especially noticeable when using EV_NOTEBOOK as a parent container. +** '''EV_WIDGET''' - Fixed bug in theme handling on Windows XP. Previously, any widgets that were created before the first window was created did not draw correctly when displayed. +** '''EV_COMBO_BOX''' - Fixed bug in `key_press_actions` which were called twice when you pressed the up or down arrow keys. +** '''EV_TITLED_WINDOW''' +*** `title` was returning `Void` if you had not explicitly set a `title`. +*** Fixed raise to work when process is not in the foreground, the window will now flash in the window selector + +** '''EV_MENU''' - A menu with an ampersand (i.e. menu.set_text ("Test && Verify")) could be truncated when displayed (i.e. the `y` could be missing). +** '''EV_PIXMAP''' - Fixed a memory corruption while loading PNG images. +** Fixed resizing issue which would happen if too many widgets are nested in each other, those nested widgets would not resize properly. + +* '''Gtk''' +** '''EV_DIALOG''' - Fixed modal dialogs so that they behave the same as on Windows so that show_modal_to_window is indeed only modal to the parent window +** - Mouse events now only go to the widget that the mouse is currently interacting with +** '''EV_FONT''' - Fixed bug where font names were being matched on substring, meaning that Sans would match with San Serif +** '''EV_TEXT''' - Fixed and optimized calls relating to display lines versus actual lines +** - Fixed potential instability due to signal marshal calls being made during object dispose +** - Completely overhauled event handling implementation to use less resources and be much more optimal +** '''EV_POPUP_WINDOW'''Completely rewrote popup window implementation to be not dependent on the window manager, this means that they will work in all scenarios with WM intervention +** '''EV_ACCELERATOR''' - Fixed crashes caused by certain accelerator combinations +** '''EV_TOOL_BAR_BUTTON''' - Toolbar buttons are now accepted as Pick and Drop targets + + +==EiffelStudio 5.6== + +'''Interface modifications''' +* '''EV_POPUP_WINDOW''' - A new window type which inherits EV_WINDOW with two differences: It does not display a border of any sorts and is not displayed in the task bar. This is especially useful for simulating tooltips and other such pop-ups. +* '''EV_APPLICATION''' - Added 'uncaught_exception_actions' which is called whenever an action sequence called from the underlying toolkit fails to deal with any exceptions raised. +* '''EV_CLIPBOARD''' - Added 'has_text' so that the clipboard can be queried without retrieving the entire contents. +* '''EV_CHECKABLE_TREE''' - A new widget that inherits EV_TREE, providing similar functionality but for each item contained a check box is displayed. +* '''EV_NOTEBOOK''' +** Added `pointed_tab_index` which returns the index of the tab beneath the mouse pointer or 0 if none. +** Added EV_NOTEBOOK_TAB which may be queried via the new query `item_tab`. The object represented by this new class provides the ability to set both the text and a pixmap for the tab item. +** Now inherits EV_ITEM_PIXMAP_SCALER as the tabs support pixmaps through the use of EV_NOTEBOOK_TAB. + +* '''EV_COMBO_BOX''' - Added `drop_down_actions`, fired as the list is dropped down which permits dynamic filling of the combo box as its contents are displayed. +* '''EV_WIDGET''' - Removed postcondition `has_focus` from `set_focus` since in most cases it does not hold. Indeed between the time you set the focus and the time you check if you still have the focus something could have happen that would remove the focus. +* '''EV_PIXMAP''' - Added `sub_pixmap`, this allows a pixmap to be created from a region of another +* '''EV_RICH_TEXT''' - Corrected postcondition of `buffered_format` which restricted the end position to `text_length` instead of `text_length` + 1. +* '''EV_FILE_OPEN_DIALOG''' - Added features for retrieving multiple file names. The following additional features are now available: 'enable_multiple_selection', `disable_multiple_selection`, `multiple_selection_enabled` and `file_names`. +* '''EV_TEXT_COMPONENT''' - Removed `is_editable` precondition of `set_caret_position`. + +'''Bug fixes''' +* '''Platform independent''' +** '''EV_DIALOG_I''' - Fixed consistency of `default_push_button`, before we could get some assertions violations from the implementation classes. +** '''EV_ANY''' - Added protection for multiple calls of `destroy` which previously caused crashes in some situations, now `destroy` calls a `safe_destroy` intermediary which checks if the implementation has not already been destroyed +** '''EV_GAUGE''' - Fixed bug in `make_with_value_range` which did not adjust `value` to `lower`, thereby putting the gauge in an invalid state. + +* '''Windows''' +** Fixed resizing issue: when a widget is inserted in a hidden window and that the minimum size of the window does not change, the widget would not appear on the window when shown. One had to manually resize the window to make it appear. Now it will appear properly. +** Fixed a crash which could occur when using the tab or arrows keys to navigate between the primitive of a window. It would happen when trying to set the focus on a widget which was previously parented but is not anymore. +** Improved appearance of applications running on Windows XP with manifest files. +** '''EV_RADIO_BUTTON''' - Enabled better navigation between radio buttons of a group using the arrow keys. +** '''EV_SPIN_BUTTON''' +*** When it gets the focus, we set the focus to the associated text field. Before one would loose the focus until one use the mouse to set it to the text field part. +*** Fixed bug which restricted the maximum values permitted to approx. 16,000. Attempting to manipulate the spin button with values greater than this caused precondition violations internally. + +** '''EV_SCREEN''' +*** `widget_at_position` returns an instance of EV_COMBO_BOX when cursor is on top of the text part of the combo box, before it would return Void. +*** `set_pointer_position` was not setting the position accurately and it may have actually been set to one of the adjacent positions. + +** '''EV_COMBO_BOX''' +*** `focus_out_actions` are only called once when loosing focus. Before they would be called twice and even called when the combo box was getting the focus. +*** Fixed `has_focus` to return True when either the combo or the text field when it exists has the focus. +*** Fixed call on Void target when calling `set_foreground_color` on a displayed combo box which is not editable. +*** Fixed invariant violation with a non editable combo box. +*** Fixed `caret_position` which was failing if you attempted to set a caret position to a value greater than approx 65,000. +*** Fixed `set_focus` which failed if the combo box was non-editable. +*** Fixed handling of escape and enter keys while list was dropped down. If the combo box was contained within a dialog, the default cancel and default push button actions were fired as a result of pressing these keys. These keys are no longer propagated to the dialog in this fashion. + +** '''EV_MULTI_COLUMN_LIST''' - Calling `column_width` after calling `resize_column_to_content` did not return the correct result but instead the previously set column width. +** '''EV_NOTEBOOK''' +*** Fixed resizing issue of notebook when it is included in a hidden pane of another notebook, resulting in an assertion violation in the resizing code. +*** Fixed class invariant which failed when calling `destroy`. + +** '''EV_WINDOW''' +*** Fixed `screen_x` and `screen_y` so that they return the same value as `x_position` and `y_position`. +*** Fixed issue where `move_actions` were called with incorrect positions (before the given positions were the one from the child of the window, not the window itself). + +** '''EV_DIALOG''' +*** Calling `show`, moving the window and then subsequently calling `show_relative_to_window` or `show_modal_to_window` caused the dialog to move from its current position. Now the window no longer moves which mirrors the behavior in the opposite case where `show_relative_to_window` or `show_modal_to_window` is called before `show`. +*** Fixed bug which caused processing of particular keys in widgets contained within the dialog to be processed by the dialog preventing the `key_press_actions` from being fired and causing miscellaneous keyboard navigational issues. +*** Proper handling of `remove_default_push_button` and `set_default_push_button`. Before the internal state would be messed up, resulting in calling the `select_actions` of the the `default_push_button` even though the `default_push_button` did not have focus. +*** Better navigation using keys +*** Fixed bug where modal and modeless dialogs were not centered to parent + +** '''EV_TREE_NODE''' - Fixed bug which caused a crash if you performed the following: pruned a node from it's parent, pruned an empty node from this just pruned node and then attempted to insert a node within the empty node. +** '''EV_DIRECTORY_DIALOG''' - Fixed bug in which the dialog always reported that "ok" has been selected even if the "cancel" button had been selected. This occurred if the dialog had been shown more than once with "ok" already selected. +** '''EV_PIXMAP''' +*** Fixed color displayed around a pixmap while parented in a container. Previously, gray was always displayed but now we use the `background_color` of the `parent`. +*** Fixed masking blitting in draw_sub_pixmap. Previously the mask wasn't being blitted correctly discoloring the source image +*** Fixed mask handling with PNG loading. Previously if the source image pixels under the mask were not black then masking for icons and cursors didnt work correctly, now any color can be used underneath the mask and it will still be masked correctly + +** '''EV_TOOL_BAR''' +*** Fixed `is_show_requested` which was still returning `True` after a call to `hide`. +*** Improved resizing of tool bar buttons. A tool bar button with a text and no associated pixmap used to display an empty area where the pixmap would be displayed if set. Now, in this case, the button is just large enough to display its text. + +** '''EV_FONT''' - Fixed bug in `is_equal` which occasionally failed due to rounding errors between `height` and `height_in_points`. Now, `is_equal` compares `height_in_points` for the font which is more accurate and prevents this issue. +** '''EV_APPLICATION''' - `cancel_actions` were not always called when they should have been. If you cancelled a pick and drop by right clicking on a target that does not accept the `pebble`, the `cancel_actions` were not fired. +** '''EV_RICH_TEXT''' +*** Fixed bug in `buffered_format` which corrupted the current text upon calling `flush_buffer` if the text contained any RTF reserved characters such as '/', '{' or '}'. +*** Fixed `set_background_color` which was not changing the background color +*** Fixed bug in `disable_word_wrapping` which had a side effect that limited the maximum number of characters to 64000. + +** '''EV_TOOL_BAR_BUTTON''' - Fixed bug in handling of enabled/disabled state during a pick and drop transport. The pick and drop mechanism disables tool bar buttons automatically that are not valid targets. If you called `enable_sensitive` or `disable_sensitive` during a pick and drop, this state was not reflected at the end of the pick and drop and the buttons were always restored to their original state. Now the buttons are restored to their last set state. +** '''EV_TITLED_WINDOW''' - Fixed issue with `raise` where in addition of bringing the window to the front it was changing the previously focused widget within that window. Now it preserves the previously focused widget. +** '''EV_PRIMITIVE''' - Fixed bug which affected all primitives that hold items. Calling `destroy` on the primitive and then calling `destroy` on one of the items caused precondition violations internally. The bug was that the call to `destroy` on the primitive did not call `wipe_out` to remove all of the contents and the item was still attempting to access its `parent` which should have been `Void`. +** '''EV_WIDGET''' +*** Fixed two bugs with `key_press_string_actions`. The first was that the action sequence was fired when Escape or Backspace was pressed. As these are not displayable characters, the `key_press_string_actions` are no longer fired for these keys. The second is that pressing Enter was passing the the string "%R" which is the Windows specific newline character. We now pass "%N" when the Enter key is pressed. +*** Fixed bug in `pointer_motion_actions`. In some uncommon situations, it was possible to receive the motion event multiple times with the same position. +*** The `key_press_string_actions` are no longer fired by the "delete" key ( ASCII 127). + +** '''EV_TEXT''' - Fixed bug where `caret_position` was returning an incorrect value if it the text had word wrapping enabled and one or more lines in the text were currently word wrapped. +** '''EV_FONT_DIALOG''' - Fixed bug where `name` of `font` returned was incorrect. +** '''EV_SPLIT_AREA''' - Split areas now have a completely flat appearance. + +* '''Gtk''' +** '''EV_CURSOR''' - Now the default X-Cursors are used where applicable instead of pixmapped representations of them, this allows for animated cursors if available on the X-server +** '''EV_VIEWPORT''' - Fixed issue where offsets where not being updated right away so querying back to the viewport from an expose caused by the viewport for the values would be incorrect +** '''EV_TEXTABLE''' - Now UTF8 strings from different language locales are displayed correctly and not cut-off +** '''EV_CLIPBOARD''' - Now UTF8 strings from different language locales are handled correctly for copying and pasting +** '''EV_DRAWING_AREA''' - +*** Fixed `flush` to instantly call any pending expose events +*** Fixed issue where drawing area was not being focused when clicked upon by default + +** '''EV_FONT''' +*** Fixed memory leaks in font lookup +*** Now all resources get freed on disposal of font +*** Now precalculating `ascent` and `descent` to improve drawing performance +*** Added better default font handling, now if the default font gets passed in, it will be treated as such by the Gtk theme engine + +** '''EV_TOOL_BAR_BUTTON''' - Improve appearance of text and pixmap when `disable_vertical_button_style` is called +** '''EV_FONTABLE''' - Improved font handling with theme manager, all default fonts now relate to the Application font chosen from the Gtk theme manager +** '''EV_DRAWABLE''' +*** Corrected font placement with `draw_text` using fonts of the same height that have varying ascent values +*** Corrected `draw_arc` to handle all radian angles for both start_angle and aperture values +*** Fixed mask handling for `draw_sub_pixmap` to work with non-zero 'area' coordinates + +** '''EV_MULTI_COLUMN_LIST''' - Fixed memory leak when setting string values +** '''EV_TREE_NODE''' +*** Fixed `remove_pixmap` to remove pixmap from tree model +*** Fixed crash when removing nodes from parent nodes not present in a tree widget + +** '''EV_RICH_TEXT''' +*** Now `paste` uses the EiffelVision 2 clipboard directly and so all clipboard assertions are fulfilled +*** Fixed `buffered_format` to not wipe out the text buffer of the widget and therefore stop other EV_TEXT features from functioning correctly +*** Now `buffered_append` doesn't wipe out the screen contents of the rich text control + +** '''EV_ACCELERATOR''' - Now the key accelerator is checked if valid before proceeding, in some circumstances when a key is not present in the key mapping table adding an accelerator would crash the system, now if the accelerator is not valid for the current key mapping then nothing is done +** '''EV_WINDOW''' +*** Now setting and querying focus works in all circumstances with all window types + +** '''EV_PIXMAP''' - Improved pixmap 'stretch' for smaller images +** '''EV_WIDGET''' +*** Optimized motion event handling so that current motion events only get requested when the previous one has been processed +*** Fixed theme managed handling in all widgets so that fonts when changed outside of the application by the theme manager get reflected in the EiffelVision 2 application + +** '''EV_DIALOG''' +*** Fixed bug where modal and modeless dialogs were not centered to parent + +** '''EV_FRAME''' - Corrected issue where changing alignment of text was resetting the vertical alignment +** '''EV_COMBO_BOX''' - Now the drop down box doesn't fire focus out actions when shown + + +==EiffelStudio 5.5== + +'''Interface modifications''' +* '''EV_TEXT''' +** Weakened a number of preconditions that required a non empty final line, which was unnecessary. Removed the obsolete feature `put_new_line` and made `last_line_not_empty` obsolete as it is unnecessary and can be queried via `line`. +** Added `line_number_from_position` which returns the line on which a particular caret position resides. + +* '''EV_ACTIVE_LIST''' - New class added which replaces all occurrences of ACTIVE_LIST within the interface. This prevents the EiffelVision implementation from being "unhooked" by user modification through the interface. The class is completely backwards compatible, and does not require any modifications to your code. Classes such as EV_ACCELERATOR_LIST and EV_FONT incorporate this change. +* '''EV_DOCKABLE_SOURCE''' - Added features `is_external_docking_relative`, `enable_external_docking_relative` and `disable_external_docking_relative`. This permits you to dock a source to an EV_DOCKABLE_DIALOG that is not displayed relative to the original top window. +* '''EV_RICH_TEXT''' - New class, providing a text control with support for character formatting and colors on a character by character basis. The following supporting classes have been added for use with EV_RICH_TEXT: EV_CHARACTER_FORMAT, EV_CHARACTER_FORMAT_EFFECTS, EV_PARAGRAPH_FORMAT, EV_CHARACTER_FORMAT_RANGE_INFORMATION, EV_PARAGRAPH_FORMAT_RANGE_INFORMATION and EV_PARAGRAPH_CONSTANTS. +* '''EV_ENVIRONMENT''' - Added `fonts` which returns a list of all fonts available on the system. +* '''EV_APPLICATION''' - Added `captured_widget` which returns the EV_WIDGET currently captured in the system, or `Void` if none. +* '''EV_SPLIT_AREA''' - Added `splitter_width` which returns the width of the splitter in pixels. +* '''EV_ANY_HANDLER''' - This is the only class to which `default_create` from EV_ANY is supposed to be exported. However, particular descendents were exporting `default_create` to ANY instead. This has now been fixed. +* '''EV_MESSAGE_DIALOG''' - `make_with_text_and_actions` has now been added to the list of creation procedures. +* '''EV_SCREEN''' - Added `horizontal_resolution` and `vertical_resolution` which return the number of pixels per inch. +* '''EV_FILE_DIALOG''' - Added support for multiple file extensions through the addition of `filters` which provides support for setting both a filter and an associated comment. The existing features `filter` and `set_filter` have been made obsolete. +* '''EV_FONT''' +** Modified return type of `string_size` from TUPLE [INTEGER, INTEGER] to TUPLE [INTEGER, INTEGER, INTEGER, INTEGER]. This does not break any existing code, but provides additional `left_offset` and `right_offset` queries (items 3, 4). Items 1, 2 still return the width and height of the string, but this is only the dimensions to be used when placing multiple strings next to each other. Some characters on more exotic fonts may still extend past this boundary, and the rectangle that fully encloses the string is given by adding the left and right offsets to the width. +** Added `height_in_points` and `set_height_in_points` for setting the height of a font in points (1/72 of an inch). This may be used to ensure that your fonts occupy the same height on screens with varying resolutions. + + +'''Bug fixes''' +* '''Platform independent''' +** '''EV_DRAWABLE''' - `draw_text` and `draw_text_top_left` now both support text containing new line characters. +** '''EV_APPLICATION''' - `focused_widget` had a side effect which may modify the index of some containers. +** '''EV_DYNAMIC_TREE_ITEM''' - fixed `count` which was not executing the subtree function as necessary when called. +** '''EV_TREE''' - Fixed bug in `has_recursively` which failed if there were one or more dynamic tree items contained. +** '''EV_MULTI_COLUMN_LIST''' - Fixed bug in `set_column_alignments` which crashed if you called it with an empty list after having previously called it with a non empty list. +** '''EV_FIGURE_TEXT''' - Fixed bounding size issues which would cause the `width` and `height` to be returned incorrectly, causing them to be not correctly cleared when moved in a figure world. +** '''EV_FIGURE_GROUP''' - Fixed both `append` and `make_from_array` which were not setting the `group` of each item inserted. + +* '''Windows''' +** '''EV_WINDOW''' +*** `move_actions` was always passing positive values for the x and y coordinates of the window, even if they should have been negative. +*** Showing two or more dialogs relative to a window and then hiding the focused relative dialog could cause the window to move being the next window in the Z order. This has now been fixed. + +** '''EV_FONT''' +*** Fixed bug when using `preferred_families` after creating a font via `make_with_values`. The family that was specified was previously ignored. +*** Fixed bug in `copy` which in certain cases could lead to a copied font not exhibiting the typeface as the original, even though no assertions were violated. + +** '''EV_SCROLL_BAR''' - Fixed handling of scroll bars with upper values greater than 32,000. Previously, dragging the bar of a scroll bar past this limit, corrupted the position of the bar and the `value`. +** '''EV_TEXT''' +*** Corrected `last_position_from_line_number` which was returning an incorrect position when there were multiple lines of text contained, and you queried the final line. +*** Modified `insert_text` so that the control is no longer scrolled to the top as a result. The original position is now maintained wherever possible. +*** Corrected handling of selection for caret positions greater than 64,000 characters. The following features were broken when using caret positions greater than 64,000: `caret_position`, `has_selection`, `selection_start` and `selection_end` + +** '''EV_SPIN_BUTTON''' +*** Corrected positioning in parent container. In many situations, the spin button mis-behaved and would be moved to the 0x0 pixel position in the parent. +*** Fixed tooltips which were never displayed. + +** '''EV_LIST_ITEM''' - Setting a pixmap to an item that was already displayed in a list and had a text would cause the end of the text to be cut off. This is now fixed. +** '''EV_COMBO_BOX''' - Fixed tooltips which were never displayed. +** '''EV_TOOL_BAR''' - Fixed a number of serious GDI leaks, the worst of which occurred when items that had a pixmap were removed from a tool bar. +** '''EV_PROGRESS_BAR''' - Fixed bug which was limiting values in the range 0 to 65535. +** '''EV_TEXT_FIELD''' - calling `set_font` now updates the `minimum_height` of the text field so that it is large enough to completely display the font. + +* '''Gtk''' +** '''GTK 2.4''' EiffelVision 2 has been completely upgraded from gtk 1.2 to version 2.4 and provides completely new implementations for EV_LIST, EV_COMBO_BOX, EV_FILE_DIALOG, EV_MULTI_COLUMN_LIST, EV_CLIPBOARD, EV_MENU, EV_TREE, EV_FONT, EV_PIXMAP using the latest gtk widget set +** '''EV_WIDGET''' Fixed a screen positioning for all widgets +** '''EV_GAUGE''' Fixed bounds setting +** '''EV_DIALOG''' Now key presses work whilst in Pick and Drop +** '''EV_WIDGET''' Now motion events pass x and y coordinates relative to the captured widget + + +==EiffelStudio 5.4== + +'''Interface modifications''' +* '''EV_ITEM_PIXMAP_SCALER''' - New class added which provides no new functionality, but is a clean abstraction of `pixmaps_width`, `pixmaps_height` and `set_pixmaps_size` which were all defined independently in EV_TREE, EV_LIST, EV_MULTI_COLUMN_LIST and EV_COMBO_BOX. Your code will not be affected by this change. +* '''EV_TOOL_BAR''' - Added three new features `has_vertical_button_style`, `enable_vertical_button_style` and `disable_vertical_button_style`. The default style for buttons is vertical and was the only style previously available, in which the `pixmap` is displayed above `text`. When vertical style is disabled, the `pixmap` of a button will be displayed to the left of its `text`. +* '''EV_TREE ''' - No longer inherits EV_TREE_NODE_CONTAINER which is now obsolete. Made `selected` obsolete, use selected_item /= Void instead. +* '''EV_TREE_NODE''' - Now inherits EV_TREE_NODE_LIST instead of EV_TREE_NODE_CONTAINER. This provides more functionality at the level of the node, but does not change the features available in non deferred descendents, as they all previously inherited EV_TREE_NODE_LIST. Changed type of `parent` to EV_TREE_NODE_LIST from EV_TREE_NODE_CONTAINER. Removed three obsolete features - `align_text_left`, align_text_center' and `align_text_right`. +* '''EV_TREE_ITEM''' - Strengthened `is_expandable` so that it checks `parent_tree` is not Void, this brings it into line with the preconditions of `expand`. +* '''EV_DYNAMIC_TREE_ITEM''' - Strengthened `is_expandable` to check `parent_tree`, in line with preconditions of `expand`. Added "valid_operands" precondition to `set_subtree_function` which ensures that you only pass a function with valid operands. +* '''EV_TREE_NODE_CONTAINER''' - Now obsolete, you should use EV_TREE_NODE_LIST instead. +* '''EV_MULTI_COLUMN_LIST''' - Added missing postconditions to `align_text_left`, `align_text_right`, `align_text_center` and other miscellaneous features that were missing relevant postconditions. +* '''EV_MENU''' - Tightened preconditions of `show` and `show_at` to ensure that the menu is not parented. +* '''EV_TEXT''' Added `has_word_wrapping`, `enable_word_wrapping` and `disable_word_wrapping`. These features allow you to switch between horizontal word wrapping, in which lines too long to be displayed will be wrapped, and no word wrapping, in which horizontal scroll bars will be displayed, allowing you to view the complete contents of each line. Previously EV_TEXT would always wrap lines, and the default behavior is `has_word_wrapping` as it was before these changes. +* '''EV_TEXT_COMPONENT''' - Added `has_selection` precondition to `selected_text` which requires that `has_selection` must be True for you to call `selected_text`. +* '''EV_FILE_DIALOG''' - Added `valid_file_title` for validation of a file name excluding the path. +* '''EV_STANDARD_DIALOG''' - Corrected postcondition of `make_with_text` which was checking that `text` was the same object as the STRING passed as an argument. This was incorrect, as `text` is cloned during the creation. +* '''EV_WIDGET''' - Added `remove_real_target` which ensures that `real_target` is Void. +* '''EV_WIDGET_ACTION_SEQUENCES''' - Added `mouse_wheel_actions`, fired each time that the mouse wheel is scrolled. +* '''EV_NOTEBOOK''' - Now inherits EV_FONTABLE permitting a font to be applied to the item texts. +* '''EV_ENVIRONMENT''' +** Added `mouse_wheel_scroll_lines` which returns an INTEGER corresponding to the number of lines that should be scrolled in response to each mouse wheel scroll event received. +** Added `has_printer` which returns `True` if at least one printer is installed. + +* '''EV_PRINT_CONTEXT''' - Added `horizontal_resolution` and `vertical_resolution` which return the page size in pixels of the page type selected from an EV_PRINT_DIALOG. This permits you to adjust the figure world you are printing to an EV_PRINT_PROJECTOR based on the limits of the page, as determined by `horizontal_resolution` and `vertical_resolution` in pixels. +* '''EV_APPLICATION''' - Added `process_events_until_stopped` and `stop_processing`, similar to `process_events`, except the processing is executed until `stop_processing` is called. +* '''EV_PRINT_PROJECTOR''' - Added `has_printer` check to `make_with_context`, ensuring that if you are to print to a printer, at least one printer is available. +* '''EV_PRINT_CONTEXT''' - `default_create` now initializes a set of standard values, permitting the printing to the default printer, using US letter size. +* '''EV_RELATIVE_POINT''' - The features `set_x_abs`, `set_y_abs`, `set_angle_abs`, `set_scale_x_abs` and `set_scale_y_abs` now all have a precondition ensuring that you may only call them while `being_positioned` is True, which is only the case during execution of a custom positioning agent. Previously, if they were called at other times, the values set would be overridden. +* '''EV_FIGURE''' - `accept_cursor` and `deny_cursor` are now available as queries. +* '''EV_ABSTRACT_PICK_AND_DROPABLE''' - `set_accept_cursor` and `set_deny_cursor` no longer accept `Void` arguments. +* '''EV_FIGURE_MATH ''' - 'line_angle' now correctly returns the angle in radians relative to world. +* '''EV_ARROWED_FIGURE''' - 'start_angle' and 'end_angle' now work in all circumstances +* '''EV_FIGURE_STAR''' - First line generated is now created from 'point_b' +* '''EV_FIGURE_EQUILATERAL''' - First point generated is now based upon 'point_b' + +'''Breaking changes''' +* '''EV_TREE_NODE_CONTAINER''' - This class is no longer used in EiffelVision 2, and if you were relying on it, you should use EV_TREE_NODE_LIST instead. The type of `parent` for tree nodes has been changed from EV_TREE_NODE_CONTAINER to EV_TREE_NODE_LIST, so if you retrieve the `parent` and then attempt to iterate, you may have declared an instance of EV_TREE_NODE_CONTAINER. In this situation, you should simply change the definition to EV_TREE_NODE_LIST instead. + +'''Bug fixes''' +* '''Platform independent''' +** '''EV_DYNAMIC_TREE_ITEM''' - No longer crashes if your `subtree_function` returns Void. In this situation, it will now behave as if the `Result` was empty. +** '''EV_BOX''' - Attempting to dock from an EV_DOCKABLE_SOURCE while the box was empty would not work. This has now been fixed. +** '''EV_TEXT_COMPONENT''' - Calling `append_text`, `prepend_text` or `insert_text` while `is_editable` is False caused a precondition failure in the implementation which is now fixed. +** '''EV_DOCKABLE_SOURCE''' +*** It was previously not possible to dock to an empty window, as the target was ignored in error. +*** Fixed bug which caused a crash if a dock was attempted to an empty box. + +** '''EV_CHECKABLE_LIST''' - Corrected postcondition of `checked_items` which was checking `selected_items` in error, and therefore almost always failing. +** '''EV_APPLICATION''' - Querying `focused_widget` if the window with the focus was empty caused a crash. This has now been fixed, and in this situation, the window itself is returned. +** '''EV_FIGURE_TEXT''' - Fixed handling of `preferred_fonts` from the `font`, which was not taken into account. Previously, the default font was always used. +** '''EV_DYNAMIC_LIST''' - Fixed `retrieve_item_by_data` and `retrieve_items_by_data` which were always performing object comparison, even when reference comparison was selected by passing `False` as the second argument. +** '''EV_TREE_NODE_LIST''' - Fixed `retrieve_item_recursively_by_data` and `retrieve_items_recursively_by_data` which were always performing object comparison, even when reference comparison was selected by passing `False` as the second argument. +** '''EV_CONTAINER''' - Fixed bug in `unmerge_radio_button_groups` which would crash if the container had no radio buttons. + +* '''Windows''' +** '''EV_TEXT_COMPONENT''' - fixed bug in `select_region` which would fail if `start_pos` was greater than `end_pos`. +** '''EV_PIXMAP''' +*** `expose_actions` previously had a feature contained related to the implementation, and calling `wipe_out` on `expose_actions` would stop the image from being redrawn. There are now no side effects related to `expose_actions`. +*** Calling `copy` on a pixmap that was parented in an EV_CONTAINER, and therefore displayed on screen had no visual effect until the window was re-painted. The image is now updated immediately. Also, using `copy` on a pixmap in a similar situation that was originally set with a masked icon, and passing a pixmap created from a bitmap file would cause a crash. +*** Fixed display error in handling of pixmaps created from a PNG with a transparent color, using `set_with_named_file`. The background would be garbled and partially black. + +** '''EV_LIST''' +*** Calling `disable_sensitive` when already non sensitive would loose the original selection, and calling `enable_sensitive` when already sensitive would alter the selected item. The features will no longer alter the selection if called twice. +*** Fixed result of `background_color` which was returning gray instead of white before a color was assigned +'''EV_CELL''' - If you removed the item, the minimum size was not updated to reflect this, thereby retaining the minimum size as constrained by the minimum size of the now removed item. +** '''EV_TREE_ITEM'''/ '''EV_TREE''' - A call to `disable_select` on an EV_TREE_ITEM will now actually remove the selection from the tree. Previously, the style of the item was changed, but a call to `selected_item` on the tree would still return the item. +** '''EV_FILE_DIALOG''' - Fixed precondition violation when you calling `set_file_name` which was rejecting directory separators. +** '''EV_DIALOG''' - Fixed a bug when you had two dialogs displayed modally, with the second modal to the first. If you had a text field within the second dialog whose `return_actions` contained an agent which would destroy the second dialog, the `select_actions` of the `default_push_button` in the lower dialog would be subsequently fired. +** '''EV_LABEL''' - If a label was disabled through the disabling of a container in which it was contained, it would sometimes not be grayed out. This has now been fixed. +** '''EV_PICK_AND_DROPABLE''' +*** `mode_is_target_menu` did not work for a pick and drop source whose `pebble` was generated by a `pebble_function`. +*** Fixed bug where drag and drop was not working as it was attempting to perform docking instead. If both are enabled, docking has priority. + +** '''EV_COMBO_BOX_IMP''' +*** Fixed `set_foreground_color` and `set_background_color` which previously did nothing. +*** Fixed bug in selection. If during execution of the `select_actions` of an item contained, you called `enable_select` on another item within the combo box, subsequently selecting the originally selected item would no longer fire its `select_actions`. +*** `enable_edit` and `disable_edit` were both causing the pixmaps of any items contained to be no longer displayed. + +** '''EV_PRINT_DIALOG''' - Querying `print_context` from a print dialog if a user selected "Cancel" would previously crash. +** '''EV_TREE''' and '''EV_MULTI_COLUMN_LIST''' - Fixed result of `background_color` which was returning gray instead of white before a color was assigned +** '''EV_SCREEN''' - `widget_at_pointer_position` now returns the combo box if the mouse pointer is held above the drop down list button of a combo box. Previously, `Void` was returned. + +* '''Gtk''' +** '''EV_TREE_NODE''' - Now expansion state remains the same when 'set_pixmap' is called. +** '''EV_DIALOG''' - Fixed bug where 100 percent of CPU time was being used when dialog was shown modally. +** '''EV_WINDOW''' - Now sizing invariants are fulfilled when widget is destroyed, preventing segmentation violation. +** '''EV_COMBO_BOX''' +*** Fixed bug where reselecting an item within the combo box list was in fact deselecting it. +*** Now first item remains selected when items are added. + +** '''EV_WINDOW''' - Fixed querying of positioning which never changes if previously set by user. +** '''EV_APPLICATION''' - Priority of `idle_actions` has been changed so that gtk will recalculate widgets sizes before calling its idle handler, this means that all resizing is done before idle actions are called. +** '''EV_WINDOW ''' - Now windows correctly shrink when requested size is smaller than current size +** '''EV_PICK_AND_DROPABLE''' - Fixed bug where if both drag and drop and docking were enabled, both would be executed, now docking overrides drag and drop if both are enabled. +** '''EV_TIMEOUT ''' - Now timeouts correctly unregister themselves on dispose preventing segmentation violation. +** '''EV_PIXMAP ''' - Pixmap stretching now works as expected. +** '''EV_WINDOW''' - Now all window specific events work as expected +** '''EV_TITLED_WINDOW''' - Now is_displayed returns false when window is minimized. +** '''EV_TREE_NODE''' - Insertion of children at specific rows now displays as expected. +** '''EV_WINDOW''' - Now windows have a border and are resizable to match Win32 behavior +** '''EV_SPLIT_AREA''' - Now 'split position' honors request when widget resize is pending +** '''EV_DRAWING_AREA ''' - Fixed full size optimization so that all expose actions are handled correctly +** '''EV_TEXT_COMPONENT - ''' Fixed issue where up and down arrow keys caused widget to lose focus unnecessarily +** '''EV_FONT''' - Now preferred families are taken in to account when no style is set +** '''EV_STANDARD_DIALOG '''- Now all file handling dialogs are resizable + + +==EiffelStudio 5.3== + +'''Interface modifications''' +* '''EV_TITLED_WINDOW_ACTION_SEQUENCES''' added which is inherited only by EV_TITLED_WINDOW and provides three new action sequences :- `minimize_actions`, `maximize_actions` and `restore_actions`. +* '''EV_TITLED_WINDOW''' +** You may now only call `maximize` and `minimize` if `is_show_requested`. +** When minimized, `is_displayed` now returns False. + +* '''EV_BUTTON''' now inherits EV_FONTABLE, allowing you to modify the font displayed. +* '''EV_DYNAMIC_LIST_ITEM''' - Corrected `off` which was using the version inherited from EV_TREE_NODE when it should have been using the version from EV_TREE_NODE_LIST instead. +* '''EV_RECTANGLE''' - Added precondition to `intersects` which stops a Void rectangle being passed as an argument. +* '''EV_TOOL_BAR_SEPARATOR''' - Now export many inherited features to {ANY} instead of {NONE}, including `parent`. +* '''EV_ENVIRONMENT''' - Added `supported_image_formats` which returns a LINEAR [STRING] containing all valid formats by their three letter extension. +* '''EV_CHECKABLE_LIST''' - New class added which behaves as an EV_LIST, except that for each EV_LIST_ITEM contained, an associated check box is displayed. +* '''EV_MESSAGE_DIALOG''' - No longer deferred, and has two creation procedures `default_create` and `make_with_text`. +* '''EV_STANDARD_DIALOG''' - All descendents now have `make_with_text` as a creation procedure'. +* '''EV_TABLE''' - Now inherits CHAIN instead of ARRAY. This is a breaking change, and may require some modification to your code. The inheritance from ARRAY was seriously flawed. For example, if you were to call `extend` on an EV_CONTAINER object that was currently referencing an EV_TABLE, then this would fail. Now that we inherit CHAIN, this problem, among others of a similar nature are fixed. Another advantage of inheriting CHAIN, is that the table may now be iterated which allows for greater flexibility.
+
+The following list details some of the breaking changes, and how to fix them: +** '''item''' - If you were using `item`, you should change this to `item_at_position`. A call to `item` will now return the current item. +** '''put''' - If you were using `put`, you must now replace this with `put_at_position`. +** '''extend''' and '''replace''' - These are now both exported, as before, they were exported to {NONE}. +** features inherited from '''ARRAY''' - These are no longer available but you may use the feature `to_array`, which returns the contents of the table represented as an ARRAY [EV_WIDGET]. This feature is marked as obsolete, as it is temporary, to simplify the transition to the new inheritance structure of EV_TABLE. +** '''count''' - The previous version of `count` was the one from ARRAY, which returned the number of available (not empty) cells in the table. We now use the version of `count` inherited from EV_CONTAINER which returns the number of widgets currently contained. Previously, the feature `widget_count` was used to return the number of items, but this feature has now been made obsolete. Therefore, if you were previously using `count`, replace this with `rows` * `columns`, and if you were using `widget_count`, replace this with a call to `count`. +** '''item_list''' - This is now obsolete. You may use `linear_representation` to retrieve the contents of the table, or simply traverse the table. + +* '''EV_FIXED''' - No longer inherits DOUBLE_MATH. +* '''EV_VIEWPORT''' - No longer inherits DOUBLE_MATH. +* '''EV_TEXT''' - `line_count` now returns the number of lines actually displayed, and not just the newline characters, as an EV_TEXT will wrap the text when necessary. The postcondition of `linecount` has been updated to reflect this change. +* '''EV_FILE_DIALOG''' Added "valid_file_name" precondition to `set_file_name` and a new feature `valid_file_name` which checks that a file name is valid on the current platform. + +'''Bug fixes''' +* '''Platform independent''' +** '''EV_WIDGET''' - `pointer_style` now correctly returns the Ibeam cursor for textable widgets. +** '''EV_FIGURE_RECTANGLE''' +*** Corrected `bounding_box` which was previously computed incorrectly when the rectangle was rotated. +*** Fixed `width` and `height` which were always returning one less pixel than they should have. + + +* '''Windows''' +** '''EV_PIXMAP''' - Setting a tile with `set_tile` followed by a call to a fill routine would crash the implementation. +** '''EV_COMBO_BOX''' - Implemented pick and drop. +** '''EV_TEXT_FIELD''' - Implemented pick and drop. +** '''EV_PASSWORD_FIELD''' - Implemented pick and drop. +** '''EV_TEXT''' +*** Implemented pick and drop. +*** If not `is_editable` and a `background_color` had been set, it was only used on lines containing text. The `background_color` is now correctly displayed throughout the whole control when not `is_editable`. +*** Fixed `select_region` which was selecting an incorrect region starting on any line except the first, when the `text` spanned multiple lines. +*** Fixed `selection_start` and `selection_end` which were incorrect when the selection was not completely contained on the first line. +*** Fixed `first_position_from_line_number` and `last_position_from_line_number` which were returning incorrect values when the text was wrapped. +*** Fixed `caret_position` and `set_caret_position` which were incorrect when the text spanned multiple lines, and the caret was not on the first line. +*** `line_count` now returns the number of lines actually displayed, and not simply the number of newline characters. To query the number of new line characters do :- text.occurrences ('%N') +*** Fixed bug in `search` which was returning -1 instead of 0 when the text was not found. + +** '''EV_DRAWABLE''' - Fixed bug when you performed the following: drew a filled shape, called `set_tile` and then drew another filled shape. The tile would not be used on the second fill. +** '''EV_COLOR_DIALOG''' - Querying `color` after a user had canceled the dialog would previously crash a system, if `set_color` had never been called. +** '''EV_COLOR''' - Fixed `set_rgb_with_24_bit` which would fail when called. +** '''EV_BUTTON, EV_TOGGLE_BUTTON''' - The buttons now correctly display a text, pixmap and background color simultaneously. Previously, the background color was never displayed, and either the pixmap or text would be displayed, not both. +** '''EV_PRINT_DIALOG''' - Fixed `set_from_page` and `set_to_page` which were previously not implemented. +** '''EV_LIST''' +*** Fixed a graphical glitch when using `wipe_out` when items were contained that required the horizontal scroll bar to be visible. The scroll bar was not hidden, even though there were no longer any items in the list. +*** Changing the selection behavior between multiple and single selection would cause the scroll bars to become hidden, even if they were necessary. Changing this status will no longer hide the scroll bars if they are required. + +** '''EV_TOOL_BAR''' +*** Items that were disabled would sometimes become enabled when other properties of the item were set. For example, performing "my_tool_bar_button.disable_sensitive" followed by "my_tool_bar_button.set_text ("Disabled")" while the button was parented, would result in a sensitive tool bar button. This is now fixed. +*** If you changed the `text` of a tool bar toggle button during the firing of the `select_actions` of the toggle button, the button would become unchecked as a result. This is now fixed, and changing the text will not stop the button from becoming selected. + +** '''EV_MULTI_COLUMN_LIST''' - Changing the selection behavior between multiple and single selection would cause the scroll bars to become hidden, even if they were necessary. Changing this status will no longer hide the scroll bars if they are required. +** '''EV_DYNAMIC_TREE_ITEM''' - Calling `set_tooltip` failed and has now been fixed. +** '''EV_TIMEOUT''' - Calling `destroy` more than once on a timeout, caused the implementation to crash, and has now been fixed. +** '''EV_TOOLTIPABLE''' - Tooltips on primitives were not supporting multiple lines and this has now been fixed. Use %N for a line break. + +* '''Gtk''' +** '''EV_SCROLLABLE_AREA''' - Items smaller than the area are now positioned correctly. +** '''EV_VIEWPORT''' +*** Widget now works correctly with negative offset values +*** Item position is now handled correctly on item resize. + +** '''EV_PIXMAP''' - All drawing routines now flush immediately to screen. +** '''EV_DIALOG''' - Canceling via Enter key is now handled correctly. +** '''EV_LIST''' - Fixed selection of selected item when changing from multiple selection to single selection. +** '''EV_MULTI_COLUMN_LIST''' +*** Row height now incorporates spacing pixel to match the implementation of Windows. +*** Default row height is now slightly larger to be more aesthetically pleasing with smaller fonts sizes. + +** '''EV_CONTAINER''' +*** `set_background_pixmap` now works with repeated parenting. +*** Radio group unmerging is now handled correctly. + +** '''EV_TEXT_FIELD ''' - Now vertical alignment is identical to that on Windows, including that for text field descendants. +** '''EV_RANGE ''' - Now motions events are passing consistent pointer values instead of sometimes skewed ones. +** '''EV_DRAWING_AREA''' - Now `focus_in_actions` are called in all circumstances. +** '''EV_TEXT''' +*** `scroll_to_line` is now implemented. +*** `line_count` and `current_line_number` now handle lines in text widget and not the text itself. + +** '''EV_FIXED''' - Now item sizing is correctly handled in all circumstances. +** '''EV_NOTEBOOK''' - Now tabs are more aesthetically pleasing. +** '''EV_MENU_SEPARATOR ''' - Menu Separators are now more prominent. +** '''EV_TOOLBAR_SEPARATOR - '''Toolbar Separators are now more prominent. + + + + +==EiffelStudio 5.2== + +'''Interface modifications''' +* '''EV_TEXTABLE''' - `align_text_left`, `align_text_right` and `align_text_center` have been extracted into a new class, EV_TEXT_ALIGNABLE which inherits EV_TEXTABLE. All previous descendents of EV_TEXTABLE now inherit EV_TEXT_ALIGNABLE, except EV_TREE_NODE, EV_MENU_ITEM, EV_LIST_ITEM and EV_TOOL_BAR_BUTTON +* '''EV_TEXT_COMPONENT''' - Now inherits EV_TEXTABLE. +* '''EV_TEXT_ALIGNMENT_CONSTANTS''' - New class added to support EV_TEXT_ALIGNABLE. +* '''EV_MENU_ITEM_LIST''' - `parent` is now of type EV_ANY, instead of EV_MENU_ITEM_LIST as it did not hold for EV_MENU_BAR. The renaming of `parent` to `old_parent` in EV_MENU_BAR has now been removed. +* '''EV_VIEWPORT''' - added `set_item_width`, `set_item_height` and `set_item_size`. +* '''EV_TABLE''' +** redefined `prunable` to `True` and implemented `prune`. +** Added the following features - `set_item_span`, `set_item_position`, `set_item_span_and_position`, `area_clear_excluding_widget`, `item_row_span`, `item_column_span`, `item_row_position` and `item_column_position`. + +* '''EV_WIDGET''' - Changed type of `focus_in_actions` and `focus_out_actions` from EV_FOCUS_ACTION_SEQUENCE to EV_NOTIFY_ACTION_SEQUENCE. `is_parent_recursive` is no longer available. It has been moved to EV_CONTAINER. This was necessary to fix a catcall encountered using EiffelVision 2 under .NET. The problem manifested with widgets that held items. +* '''EV_FIGURE''' - `proximity_in_actions` and `proximity_out_actions` are now obsolete. +* '''EV_FONTABLE''' - `set_font` now sets a copy of the font internally. +* '''EV_TREE''' - `ensure_item_visible` and `has_recursively` now take an EV_TREE_NODE as arguments, instead of an EV_TREE_ITEM. +* '''EV_TEXT''' - `put_new_line` is now obsolete. Use `set_text ("%N") instead." +* '''EV_APPLICATION_ACTION_SEQUENCES''' - Added `cancel_actions`, fired when a pick and drop is canceled, and `pnd_motion_actions` fired while the pointer moves during a pick and drop. +* '''EV_TREE_NODE_LIST''' +** `find_item_recursively_by_data`, `has_recursively` and `recursive_do_all` are now implemented in this class, instead of both EV_TREE and EV_TREE_NODE which are descendents. +** Added `retrive_items_recursively_by_data` and `retrieve_item_recursively_by_data` which allow you to specify a comparison criterion, and due to this addition, `find_item_recursively_by_data` has now been made obsolete. + +* '''EV_DYNAMIC_LIST''' - Added `retrieve_item_by_data` and `retrieve_items_by_data`. +* '''EV_ITEM_LIST''' - Made `item_by_data` obsolete, as you should now use `retrieve_item_by_data` added in EV_DYNAMIC_LIST. +* '''EV_DIALOG''' - Added `is_relative` and defined `is_modal` in this class, instead of inheriting it from EV_WINDOW. + +'''Bug fixes''' +* '''Platform independent''' +** '''EV_FIGURE_POLYLINE''' - Fixed `start_angle` and `end_angle` so that they are computed relative to the first and last polyline segments. This also fixes the start and end arrows, so that when displayed, they now actually point in the direction of their respective line segments. +** '''EV_TREE and EV_TREE_NODE''' - Fixed `find_item_recursively_by_data` which failed on the `index_not_changed` postcondition. Note that these features are now defined in EV_TREE_NODE_LIST. +** '''EV_DYNAMIC_TREE_ITEM''' - Fixed invariant violation from EV_ITEM_LIST, when created with `default_create`. + +* '''Windows''' +** '''EV_RADIO_BUTTON''' - The default minimum height after `default_create` is now enough to display the widget correctly. +** '''EV_CHECK_BUTTON''' - The default minimum height after `default_create` is now enough to display the widget correctly. +** '''EV_NOTEBOOK''' - When removing a widget from a notebook, it is now visible. Previously, the widget would be hidden. +** '''EV_LIST, EV_MULTI_COLUMN_LIST, EV_TREE''' - Fixed `set_foreground_color` and `set_background_color`. Previously, calling these features did nothing. +** '''EV_BOX''' - If a widget was not`is_item_expanded', then adding a new widget to the box before that widget would sometimes cause a different widget to become `is_item_expanded`. +** '''EV_TOOL_BAR_RADIO_BUTTON''' - The currently selected button in `peers` was unselected when the button was pressed, and not when it was really selected. This bug made it possible to make `selected_peer` Void, which caused an invariant to fail. +** '''EV_LIST_ITEM''' - Calling `enable_select` when parented in an EV_LIST now also sets the item as focused in the parent. This corrects bugs in keyboard navigation when selecting an item programatically. +** '''EV_FIXED''' - The minimum size is constrained by the positions and sizes of the children (They must be completely displayed), although when the positions of the children were reduced, the minimum allowable size was not recomputed. This meant that the widget would be enlarged when the positions of the children increased, but could never be reduced in size when the positions of the children were decreased. +** '''EV_MENU and EV_MENU_ITEM''' - `set_pixmap` has been implemented as previously, it did nothing. +** '''EV_TABLE''' - re-implemented resizing calculations to fix numerous problems when children had minimum sizes. The minimum size now also includes the border width when empty. +** '''EV_NOTEBOOK''' - `selection_actions` were called when you selected an item through `select_item`, even if the item was already selected. `selection_actions` are now only fired when the selection changes. +** '''EV_TREE_ITEM''' - calling `set_pixmap` twice successively with the same EV_PIXMAP caused a postcondition failure. +** '''EV_TEXT''' - Fixed `put_new_line`, although it has been made obsolete, as you should just use `append_text ("%N") instead. +** '''EV_SPLIT_AREA''' - Fixed crash reproducable by inserting an EV_PIXMAP directly into the split area. +** '''EV_CONTAINER''' - Fixed `propagate_foreground_color` and `propagate_background_color` which failed when one of the children was a descendent of EV_CELL. +** '''EV_APPLICATION_ACTION_SEQUENCES''' - `drop_actions` was being fired even when the pick and drop was canceled. +** '''EV_PIXMAP''' - Previously, if you were to add an agent to an action sequence of the pixmap, before it was parented, the agent would be removed during the parenting. +** '''EV_MENU''' +*** Pruning an EV_MENU_SEPARATOR when one or more EV_RADIO_MENU_ITEM were still contained in the menu would cause occasional crashes. +*** Previously, when adding an EV_MENU_SEPARATOR, followed by multiple EV_RADIO_MENU_ITEMS, all the items were being selected. +*** Fixed bug in `destroy` which was causing postcondition failures. + +** '''EV_TITLED_WINDOW''' - Fixed a GDI leak, manifesting when a window was destroyed. +** '''EV_DIALOG''' +*** Fixed `is_modal` which was previously always returned `False`. +*** Fixed bug with `background_color` and `foreground_color` which was not taken into account if the dialog was shown relative or modally to another window. +*** If a dialog with a default cancel button was displayed using `show`, then minimizing the dialog would cause the system to fail internally. +*** Fix bug in `show_relative_to_window` which would cause any associated menus to be removed. +*** Fixed bug in `show`, as if the dialog had already been shown modelessly to a window, then calling `show` did not show it independently, but still modelessly. +*** Fixed bug with `show_actions` which would be wiped out if you called `show_modal_to_window` and then `hide`. +*** `set_pixmap` will now actually display the pixmap, whereas before, no pixmap was displayed. + +** '''EV_TEXT_COMPONENT''' - Fixed `text_length` which was returning incorrect value for all descendents. +** '''EV_TEXT''' - Fixed `line_count` which was previously returning the correct result + 1. +** '''EV_SCROLLABLE_AREA''' - Fixed crash which occurred when you attempted to use `set_x_offset` or `set_y_offset` before the area had been parented or displayed. +** '''EV_FONTABLE''' - Fixed bug when `font` was queried, `preferred_families` was not returned correctly, and would always be empty. +** '''EV_CONTAINER''' - `set_background_pixmap` was not correctly cloning the image of the pixmap, and the displayed image could then be modified after setting, by changing the image of the original pixmap. + +* '''Gtk''' +** Remaining EV_WIDGET memory leaks have been fixed. +** '''EV_WIDGET'''- Focus in/out actions are now correctly called for widgets that do not occupy their entire space allocation such as EV_TEXT_FIELD. +** '''EV_DRAWABLE_IMP''' - Polylines now display correctly on big-endian machines (Sparc, PowerPC). +** '''EV_KEY''' +*** `out` is now correct for all keys (previously Quote and Backquote were incorrect). +*** The events for all keys are now fired when Shift is held down. + +** '''EV_STOCK_PIXMAPS''' - Warning and error pixmaps have been updated. +** '''EV_WINDOW''' - `remove_title now` works will all Window Managers. +** '''EV_TITLED_WINDOW''' +*** `propagate_foreground_color` is now fixed in use with pixmaps as children. +*** `set_maximum_size` now works as expected +*** `set_minimum_width` now has no effect on Window height. +*** calls on `minimize` before `launch` now satisfies all assertions +*** calling `destroy` twice now doesn't fail on precondition. +*** `set_position` now satisfies post-condition in all situations. +*** `resize_actions` are now passed the correct values. +*** `move_actions` are now called correctly. + +** '''EV_NOTEBOOK''' - now satisfies invariants when empty. +** '''EV_DIALOG''' +*** Destroy now satisfies all invariants. +*** Reported memory leaks now fixed. + +** '''EV_LABEL''' - Size is now taken from default gtk style size instead of hard coded 10 +** '''EV_FONT''' - Font caching is now vastly improved in terms of speed. +** '''EV_DRAWABLE''' - Calls to `set_font` are now also vastly speeded up. +** '''EV_TABLE''' +*** Memory management is now correct on item removal. +*** Now setting child's parent correctly + +** '''EV_TREE_NODE''' +*** Fixed all reported issues regarding item insertion and removal. + +** '''EV_CONTAINER''' - Fixed remaining issues with radio grouping and merging. +** '''EV_PICK_AND_DROPABLE''' - Now drop_actions may destroy `Current` without crash. +** '''EV_TEXT_FIELD''' +*** Now default `minimum_width` is reasonable (before 148, now same as Windows being 4 characters wide) +*** Fixed `caret_position` when queried in change actions + + + +==EiffelStudio 5.1== + +'''Interface modifications''' +* '''EV_TEXTABLE and EV_TEXT_COMPONENT''' - `text` no longer returns Void when empty. +* '''EV_WINDOW''' - `title` no longer returns `Void` when empty. +* '''EV_TOOLTIPABLE''' - `tooltip` no longer returns `Void` when empty. If empty, no tooltip is displayed. +* '''EV_TITLED_WINDOW''' - `icon_name` no longer returns `Void` when empty. +* '''EV_CLIPBOARD''' - `text` no longer returns `Void` when empty. +* '''EV_MESSAGE_DIALOG''' - `text` no longer returns `Void` when empty. +* '''EV_FILE_DIALOG''' - `file_name` no longer returns `Void` when the "Cancel" button was pressed, `Result` is empty instead. +* '''EV_DIRECTORY_DIALOG''' - `directory` no longer returns `Void when the "Cancel" button was pressed, `Result` is empty instead. +* '''EV_CONTAINER''' - has three new features `set_background_pixmap`, `background_pixmap` and `remove_background_pixmap`. `background_pixmap` will be tessellated to cover complete background area. +* '''EV_TREE and EV_TREE_NODE''' - Added `recursively_do_all`. +* '''EV_STANDARD_DIALOGS''' +** `ok_actions` have been renamed in descendents where appropriate. e.g. in EV_PRINT_DIALOG, they are renamed to `print_actions` to match the texts of the associated buttons. Where renamed, `ok_actions` are still available but obsolete. +** Selected button now also returns the correct text of the button (Previously it was always "Ok"). + +* '''EV_DIALOG_CONSTANTS''' - Added new constants required for the above change to EV_STANDARD_DIALOGS. +* '''EV_DRAWABLE''' - `draw_straight_line` now has a precondition to ensure the points are not identical. +* '''EV_SPLIT_AREA''' - separated `put` from `extend`. They were defined as synonyms, but have different behavior. +* '''EV_DYNAMIC_TREE_ITEM''' - Added `remove_subtree_function`. Item now only shows as expandable if there is a subtree function. +* '''EV_WINDOW''' - Added `maximum_dimension` which is the greatest value allowed for `width` and `height`. This is also the default value for `width` and `height`. +* '''EV_OPTION_BUTTON''' - This class has been made obsolete. It will be removed at the next release. +* '''EV_PICK_AND_DROPABLE_ACTION_SEQUENCES''' - Added `pick_ended_actions` which are called when a pick ends. +* '''EV_WIDGET''' - `set_minimum_height`, `set_minimum_width` and `set_minimum_size` now all allow 0 as an argument. Previously, 1 was the minimum valid dimension. +* '''EV_MULTI_COLUMN_LIST''' - `clear_selection` is now obsolete. Use `remove_selection` instead. + +'''Bug fixes''' +* '''Platform independent''' +** '''EV_FIXED''' - Corrected `set_item_height`, which was failing. +** '''EV_SELECTABLE''' - Corrected postcondition of `is_selected`. +** '''EV_PND_ACTION_SEQUENCE''' -- `veto_pebble_function` is now only called when its argument conforms to the transported pebble. + +* '''Windows''' +** '''EV_RANGE''' - The `maximum_value` could not be set greater than 32,000. The full range of an INTEGER may now be set. +** '''`focused_widget' from `EV_APPLICATION`''' - was incorrect if an EV_CONTAINER had just received the focus. +** '''EV_PICK_AND_DROPABLE''' +*** Ending a pick and drop on an EV_TOOL_BAR_BUTTON which has a non `void` pebble no longer starts a transport from the button. +*** Reduced flicker on cursor when picking from an EV_TREE_ITEM or EV_LIST_ITEM. +*** `pebble_function` would previously be called twice during a pick and drop. + +** '''EV_FIXED''' - Items contained are now drawn correctly dependent on their z order. +** '''EV_DRAWABLE''' +*** `Remove_clip_area` did not remove the clip_area correctly, but set it to the current size. This meant that if you then enlarged the widget, clipping would be applied. +*** Fixed problems with ordering of calls to certain features which would cause postcondition violations in the implementation. +*** `draw_pie_slice`, `fill_pie_slice` and `draw_arc` now have divide by 0 protection in the implementation. + +** '''EV_TEXT''' - `set_background_color` now correctly sets the color of the whole background. Previously only the area containing text was modified. +** '''EV_CLIPBOARD''' - Our implementation would sometimes query `text` when not allowed by Windows, thus causing postcondition failures. +** '''EV_BUTTON''' - The result of `text_alignment` after default_create was incorrect. + +* '''Gtk''' +** Gtk version of Studio released (including EiffelVision 2), so no fixes from 5.0 + diff --git a/documentation/18.11/solutions/gui-building/index.wiki b/documentation/18.11/solutions/gui-building/index.wiki new file mode 100644 index 00000000..f2e4df70 --- /dev/null +++ b/documentation/18.11/solutions/gui-building/index.wiki @@ -0,0 +1,12 @@ +[[Property:link_title|Graphics]] +[[Property:title|Graphics]] +[[Property:weight|-14]] +[[Property:uuid|19E0CFF0-C2B2-4BA7-ADBA-1DDD0DE32212]] +== Graphical user interface building solutions == + +Eiffel provides platform-independent graphical user interface (GUI) facilities, particularly: + +*EiffelVision 2, a class library for building GUI applications. + +*EiffelBuild, a GUI-builder, letting you devise your interfaces interactively and generating the corresponding calls to EiffelVision 2 mechanisms. + diff --git a/documentation/18.11/solutions/index.wiki b/documentation/18.11/solutions/index.wiki new file mode 100644 index 00000000..58d85ba2 --- /dev/null +++ b/documentation/18.11/solutions/index.wiki @@ -0,0 +1,14 @@ +[[Property:title|Solutions]] +[[Property:description|Eiffel Solutions, Technologies, and Class Libraries]] +[[Property:weight|3]] +[[Property:uuid|0f0913fe-d71c-43d3-6c22-706c8ed5d4ad]] +== Eiffel Solutions, Technologies, and Class Libraries == + +In this book you will find information about the facilities provided by Eiffel for satisfying many software development needs. + +This includes: +* The documentation for the Eiffel class libraries +** Tutorials and/or user guides +** Class references -- the library, cluster, and class views +* Other special instructions for handling commonly need tasks + diff --git a/documentation/18.11/solutions/iron-eiffel-package-repository.wiki b/documentation/18.11/solutions/iron-eiffel-package-repository.wiki new file mode 100644 index 00000000..c704d47e --- /dev/null +++ b/documentation/18.11/solutions/iron-eiffel-package-repository.wiki @@ -0,0 +1,460 @@ +[[Property:title|IRON: Eiffel package repository]] +[[Property:link_title|IRON packages]] +[[Property:weight|0]] +[[Property:uuid|393EFF7D-49DF-472C-89CE-7E0970F1A96A]] +{{ReviewRequested}} + +=Purpose= + +IRON provides an easy-to-use facility for using and sharing packages of quality Eiffel components, automating many of the tasks involved. +Most often a package is a library or a set of libraries, but it could also other resources such as tools. + +{{definition|IRON|a package management solution based on repositories.}} + + +=Package Repository vs Library Repository= + +Certainly the IRON repository is a repository of Eiffel libraries. However, sometimes libraries are used together, or cross reference one another, and thus are appropriate to be delivered together as a unit. +Such unit can also include other types of files, such as external .c files that may need to be compiled on the local platform to make .LIB or .OBJ files available to the linker (.a or .o on Unix and Linux systems), scripts or executable that need to be run as part of the installation process (e.g. to generate other files required by the library, install environment variables, generate source code from LEX files), or tool kits that are part of, or needed by, the library. +Since the IRON repository permits programmers to install software components in "units", and since sometimes those units can contain more than one library, as well as other types of files, a new term was required to convey this concept: package. + +{{Definition|package|a downloadable unit of software from an IRON repository that contains one or more Eiffel libraries and their related files.}} + + +=Application to .ecf files= +: Empowering Teams of Developers + +To configure Eiffel projects, programmers uses "ECFs" (Eiffel Configuration Files -- Microsoft Visual Studio users can think of "solution files"). + +One application of ECFs is to reference libraries installed in different locations. Without IRON, the usual solution is to use relative or absolute path, and generally using environment variables such as ISE_LIBRARY or EIFFEL_LIBRARY, and a few package specific variables such as GOBO, ... + +Typical library references without IRON in ECF: + + + + + + + +As projects grow and multiply, the number of these variables adds up quickly. A dozen or more such environment variables per system is (prior to IRON) not uncommon. Coordinating their use and evolution among a team of programmers can become a challenge. + +IRON has made it possible to simplify this scenario dramatically. For any commonly used library, it suffices to: +* Install the related package from an IRON repository. +* And for any project that uses the library, include an IRON uri in the related ECF. +** an IRON uri has the form: iron:package-name:relative-path-to-file.ecf +** as you can see, no more environment variable, and only a relative path from the root of the package. This simplifies a lot the referencing, and package/library management. No need to know where are located the installed files on the local machine. + +That's all! In the above example, the location of the libraries, in the project, then become something like: + + + + + + +There is no more need for a set of environment variables. + +IRON and EiffelStudio take care of the remaining details. And all developers on a project simply share the same ECF file with no further worry about where the libraries are. + +However, to get information about IRON location, use the command: iron path ... +:{| class="wikitable" +|- +! Command +! Result +! Example +|- +| iron path +| Base directory of IRON (~ IRON_PATH variable) +| C:\Users\jfiat\Documents\Eiffel User Files\14.05\iron +|- +| iron path base +| location of installed package base +| C:\Users\jfiat\Documents\Eiffel User Files\14.05\iron\packages\base +|- +| iron path xml +| location of installed package xml +| C:\Users\jfiat\Documents\Eiffel User Files\14.05\iron\packages\xml +|} + +Notes: +* It is possible to override the default location of IRON installation directory, by setting the environment variable IRON_PATH or ISE_IRON_PATH. +* In the scope of the .ecf file, the IRON_PATH variable is always set: to default path or to the value of environment variable IRON_PATH. +* In addition to the IRON way to reference library, it is also possible to use the absolute URL in the repository, see advanced usage for more details. + +https://iron.eiffel.com/14.05/com.eiffel/library/base/base.ecf +https://iron.eiffel.com/14.05/com.eiffel/library/text/parser/xml/parser/xml_parser.ecf +https://iron.eiffel.com/14.05/others/dummy/src/foo/bar.ecf + + +But this implies putting the version in the url (i.e 14.05), or you could set ISE_LIBRARY to https://iron.eiffel.com/14.05/com.eiffel + += IRON client tool = +The '''iron''' client executable is a facility that permits Eiffel programmers to easily install, remove, update, list, examine, search and share Eiffel packages. +Additionally, it permits easy maintenance of a local list of IRON repositories. + +A default IRON server is provided and a default repository is added automatically by the iron executable, based on the version of EiffelStudio that installed the iron executable (example: https://iron.eiffel.com/14.05 ). + +The IRON facility consists of three parts: + +* A default repository at https://iron.eiffel.com/14.05 (provides the web API and web interface for the repositories that are stored there; you can add other IRON servers as they become available). + +* The '''iron''' executable utility on the local machine (installed with EiffelStudio, the program that interacts with the repositories). + +* Within EiffelStudio and the Eiffel compiler, is the ability to read and use IRON references from the Eiffel Configuration File (.ecf). The '''Project settings''' tool, and '''Add Library' dialog also provides support for IRON packages. + +=How to Use IRON= +== Install wanted Eiffel packages == +Using the EiffelStudio command prompt (installed with EiffelStudio), execute the IRON command to install the packages you want to use: + + iron install + +Note that the compilation of an Eiffel project that depends on uninstalled Eiffel package(s) will suggest and propose to the user to install the missing packages (this is currently supported with '''ec''' in command line mode, and graphical mode. + +== Add reference to install package libraries == +Simply add the library with IRON uri iron:package-name:relative-path-to-file.ecf, as you would have previously for local libraries. This can be done directly by editing the .ecf file, or using the EiffelStudio '''Project Settings''' tool from Eiffel Studio: + + Project Settings -> -> Groups -> Libraries + +right-click Libraries and add a library. This will popup the '''Add Library''' dialog, that expects a name and a location, simply select the available library from the grid. +Note that you have an easy way to install, remove IRON packages from the '''Iron''' tab of the "Add Library" dialog. + +* The default and recommended location for a IRON package library is the IRON uri: + iron:package-name:relative-path-to-file.ecf + +* It is also possible to use the absolute URL in the IRON repository such as: + https://iron.eiffel.com/14.05/com.eiffel/library/base/base.ecf + +* And an other solution, would be to use the IRON_PATH environment variable to locate the install libraries, such as: + $IRON_PATH\packages\base\base.ecf + +This latter method, while it works, is not recommended simply because it defeats some of the advantages of using the IRON repository in the first place. + +== External dependencies == +If the package has some other way of linking it with your Eiffel projects, e.g. to an external '''.dll''' or '''.so''' , then instructions for this should be provided within the package. + +== Optional == +If you do not define one of these environment variables, the location used is: +By default the base directory for IRON is under //iron , but it is possible to overwrite this value by setting the environment variable IRON_PATH (or ISE_IRON_PATH). Note that if the physical location does not exists, the local '''iron''' executable will create it. + +Setting IRON_PATH, can be a way to setup different development environments (with different registered repositories, ...) + +=How to Get Information About IRON Packages= +At the website provided by a particular IRON server, you can get information about available packages in a number of ways. You can start by simply visiting the server's base address: https://iron.eiffel.com/ . + +* This page lists the repository versions available. +* Select the version that matches the version of EiffelStudio you have installed. +Example: clicking on version 14.05 takes you to https://iron.eiffel.com/repository/14.05/ where you can list existing packages, or add a new package if you have an account on the server. + +If you click the "Package list" or "All packages" link, it takes you to a list of packages available under that version. + +== Search/filter== +To filter this list, you can use the search window. You can specify search criteria in this format :criterion:search_string + +Criteria available: + +:{| class="wikitable" +|- +! Criterion +! Meaning +|- +| name +| string is contained in package name (wildcards are supported) +|- +| title +| string is contained in title +|- +| tag +| package contains search_string in its tags (i.e. keywords) +|- +| downloads +| has at least N downloads, e.g. downloads:25 +|} +If a criterion is omitted, '''name''' is used by default. +'''Operators available''': or, and, not (example: name:er and not name:parser) + +Finally, when you have found the package you want, click on its title, and the page displayed will contain detailed information about the package. + +== Associated paths == +Part of the information is a portion of the URI which you can use to define the path to the package. +For the '''base''' library (title: EiffelBase), these URIs look like this: + +/14.05/com.eiffel/library/base +/14.05/com.eiffel/library/data_structure/adt/base + + +Given that the server's HTTP address is (in this example) https://iron.eiffel.com/, you can compose full paths from this, and use them in your Eiffel project. In this case, you can include the EiffelBase library in your project by specifying either: + +https://iron.eiffel.com/14.05/com.eiffel/library/base/base.ecf +or https://iron.eiffel.com/14.05/com.eiffel/library/data_structure/adt/base/base.ecf + + +Both will cause your project to compile with the same EiffelBase library provided by this IRON repository, provided you previously issued the following command on your system: + +> iron install base +or +> iron install https://iron.eiffel.com/14.05/com.eiffel/library/base + + +'''IMPORTANT''': those associated URIs may be deprecated soon with the use of IRON uri iron:base:base.ecf. + +=Using IRON from the Command Line= +The "iron" executable is used to perform various operations such as search, install, remove, update and share. This executable is installed with EiffelStudio in $ISE_EIFFEL/tools/spec/$ISE_PLATFORM/bin/. + +==Quick Help from the Command Line== +*iron help +:lists the actions that are available. + +*iron --help +:displays detailed usage syntax for the action specified. Note that most of the actions have a -v (verbose) option that will display additional helpful information about the action performed, including (when relevant) the local path to the package. + +==Action Summary== + +:{| class="wikitable" +|- +! Action +! Meaning +|- +| update +| updates cached package information +|- +| list +| displays a list of available packages, and whether they are installed +|- +| search +| searches for a specified packages +|- +| info +| displays information about a specified packages +|- +| install +| installs specified packages +|- +| remove +| removes specified packages +|- +| repository +| manages repository list +|- +| share +| share and manage your packages (an account on the IRON server is required) +|} + + +==Examples== + +===Update cached iron repository information=== + iron update + + +===Display information about package=== +:For instance for the '''api_wrapper''' package: + iron info api_wrapper + +:If the package is installed, the installation path will also be displayed. + +===Search for a package by name, ID or URI=== +:(package IDs and URIs are displayed by the "info" action) (future releases will enable searching by other criteria as well, such as by tags [i.e. keywords]): + iron search base + + +===List available packages=== + iron list + + +===List installed packages=== + iron list --installed + + +===Install a package=== + iron install base + +(or iron install https://iron.eiffel.com/14.05/com.eiffel/library/base) + +:(This latter form is useful in resolving name conflicts when, for instance, you have multiple IRON repositories registered on your system, and two or more contain a packaged called "base".) + +===Uninstall a package=== + iron remove base + + +===Install all available packages=== + iron install --all + + +===Uninstall all installed packages=== + iron remove --all + + +=Advanced Usage= +==Managing Multiple Repositories== + +It is possible to have more than one IRON repository server registered. +Examples: + +iron repository --list +iron repository --add https://iron.eiffel.com/14.05 +iron repository --add https://custom.example.com/14.05 +iron repository --add C:\eiffel\my_repository +iron repository --remove https://custom.example.com/14.05 + + +===Multiple-Repository Name Conflict Resolution=== + +If you have more than one IRON repository registered on your system, it is possible that the same package name may exist on more than one repository. If this is the case, and you attempt to perform operations using that name only, the repository that will be used will be the first repository in the list that contains a package with that name. If you need the package with that name from a different repository, then use the "id" "uri" form of the identifying the package you want. + +If the sequence of repositories is not to your liking, you can change it in three ways: + +:* use the iron executable to remove and add repositories to re-sequence them, or +:* delete the repositories.conf file and use the iron executable to add them again in the sequence you want them. +:* edit the file repositories.conf with a plain text editor in the directory indicated by your IRON_PATH (or ISE_IRON_PATH) environment variable (or //iron/ if one of these environment variables are not defined on your system). (Note that this latter method, while possible, is not recommended, since the syntax of that file can change with new releases.) + +==Building a package== +An IRON package has to provide, at its root, a file package.iron. This file describes the package with name, description, and various other information. +See for instance, the package.iron for Eiffel Base package: + +package base + +project + base_safe = "base-safe.ecf" + base = "base.ecf" + base_testing = "testing/testing-safe.ecf" + base_testing = "testing/testing.ecf" + +note + title: Eiffel Base + description: "Eiffel Base: kernel library classes, data structure, Input and Output" + + tags: base,kernel,structure,io + license: Eiffel Forum License v2 + copyright: 1984-2013 Eiffel Software and others + link[doc]: "Documentation" http://eiffelroom.com/ + link[source]: "Subversion" https://svn.eiffel.com/eiffelstudio/trunk/Src/library/base + link[license]: http://www.eiffel.com/licensing/forum.txt + maps: /com.eiffel/library/data_structure/adt/base + +end + + +Note: The package iron file for the Eiffel Base package is available online at https://svn.eiffel.com/eiffelstudio/trunk/Src/library/base/package.iron . + +Current status: +* only the '''name of the package is required''' +* the section "project" list the various available .ecf projects +* the section "note" contains title, description, tags, ... informations. The formation is similar to Eiffel indexing note, and in addition it supports bracket in the name of note, such as in ''link[doc]''. +** The "link" declaration: link[category]: "Optional Title" associated-url +* The following notes have semantic that are processed by Iron: '''title, description, tags, link[..], and maps''', for now mostly on the Iron server. +* It is possible to use any note name. Currently they are simply stored and never displayed. In the future, Iron may support additional semantic for those notes. + +A few packages may require '''post installation operations''', such as compiling C code, or others. +For that, use the section '''setup''', and in particular the '''compile_library''' information. +During installation, '''iron''' will launch the compile_library tool delivered with EiffelStudio on the provided directory. + +Example at https://svn.eiffel.com/eiffelstudio/trunk/Src/library/cURL/package.iron : + +package cURL + +setup + compile_library = Clib +... + + +This compile_library tool relies on finish_freezing -library and thus process the Makefile-win.SH or Makefile.SH. + +==Using your own IRON packages locally== +There are various ways to use your own Eiffel package libraries: +* Using local location as it was currently done before 14.05 (i.e relative or absolute path, and eventually using an environment variable...). +* Sharing the package on an IRON server, and then install it from that server: +** The default https://iron.eiffel.com/ is the recommended server +** But it is possible to host your own server easily. (server how-to documentation will be provided soon). +* And there is another solution: local repository. + +Local repositories rely heavily on the package.iron files. So if a folder is registered as iron repository, internally iron will search this folder recursively for package.iron files. + +Example on Windows: +iron repository --add %ISE_LIBRARY%\library + +It should find and list all the official ISE IRON packages. +Now if you want to install the '''time''' package from it, just do + +> iron install time +Searching [time] +-> several packages for name [time]! + 1) time (https://iron.eiffel.com/14.05) "EiffelTime" + 2) time (file:///C:/EiffelDev/Src/library) + > Select a package [1] (q=cancel): 2 +-> Install time (file:///C:/EiffelDev/Src/library) +Installing [time (file:///C:/EiffelDev/Src/library)] -> successfully installed. + + +To make development easier, you may want to edit/update the repositories.conf file, in order to put that file://... local repository on the top. + +> iron path +C:\Users\jfiat\Documents\Eiffel User Files\14.05\iron +and then edit "C:\Users\jfiat\Documents\Eiffel User Files\14.05\iron\repositories.conf" + + +*However, unless you are using the iron tool in batch mode ( --batch flag ), you will be asked to choose which package you want to install. +*You can also use the EiffelStudio "Add Library" dialog via the "Iron" tab, to install, uninstall the various packages. +*And last solution, you can use the full url as: + > iron install file:///C:/EiffelDev/Src/library/time + +Of course, do not forget that local repository should be used only for code in progress, otherwise you should share that library and use it as a simple user. One of the goal of IRON is to encourage people sharing their libraries with other Eiffel users. + +==Sharing Your Packages== +To build and share your own packages on an IRON server, you will need a user account on that IRON server which will host your packages. +Please visit https://iron.eiffel.com/repository/account/?register to create a new account. + +As usual, to see the available options, use: + iron share --help + +Example: + +To build the '''gps_nmea''' package from your library c:\eiffel\library\gps_nmea\ : + + +iron share create --username --password + --repository https://iron.eiffel.com/14.05 + --package "c:\eiffel\library\gps_nmea\package.iron" --package-name "gps_nmea" + + +This command will: +* create a new package named '''gps_nmea''' on iron repository '''https://iron.eiffel.com/14.05''', +* using the local package '''c:\eiffel\library\gps_nmea''' (i.e: you need to provide the package.iron file) + +Note: +* the --package-name is for now required, even if the package.iron already provides such information. +* see the iron share --help for advanced usage (such as --index, --package-archive-source, ...). + +After adding such a package to the library, it is recommended that you go to the website, double check that the package was created they way you wanted it to be, and you can edit its information. +Then, using the iron executable, install the package on your system, and go through the steps of using it in an Eiffel project, and correct any problems discovered, to verify that end users will be able to productively use your package. + +It is also '''''strongly''''' encouraged to include (or provide a link to) documentation that orients the user to its use, and answers basic questions such as: What is the package? What motivated you to create it? What problem(s) does it address? Under what circumstances can the package be productively used? Under what circumstances should it ''not'' be used (if applicable)? And some basic examples of its use. If the package is complex, it can be very helpful to include a well-commented application that demonstrates intended reuse of the package in software. + +Important note: having clear documentation that enables end users to easily learn how to use your package is a VITAL link in the ability to reuse software components as is so aptly described in ''[[uuid:496983ef-b86e-772e-16b9-39b37ef80e37|Object‑Oriented Software Construction, 2nd Edition]]'', in the Modular Understand-ability criterion: + +:''''' "A method favors Modular Understand-ability if it helps produce software in which a human reader can understand each module without having to know the others, or, at worst, by having to examine only a few of the others." ''''' + +and the Self-Documentation Principle: + +:''''' "The designer of a module should strive to make all information about the module part of the module itself." ''''' + +The point: reuse is only possible when end users can easily and quickly learn how to reuse software components available to them. + +=Origin of the Name IRON= + +As many readers will know, the name "Eiffel" was chosen to reflect the elegance and soundness of constructing large, complex software systems, with '''simple, individual components, each of which is a unit by itself and has its own existence, and can be tested for integrity as a separate unit, but its role in the larger scheme of things is to be used as a "building block"''' for constructing high-integrity software systems. The picture on the front of the book ''[[uuid:496983ef-b86e-772e-16b9-39b37ef80e37|Object‑Oriented Software Construction, 2nd Edition]]'' illustrates this. + +This of course is intentionally meant as a direct parallel to the famous structure built by the architect and civil engineer Alexandre Gustave Eiffel. This structure was constructed with '''simple, individual components, each of which is a unit by itself and has its own existence, and can be tested for integrity as a separate unit, but its role in the larger scheme of things is to be used as a "building block"''' for constructing a high-integrity structure: the Eiffel Tower. + +As a parallel to this, "IRON", as a name, was chosen to reflect the fact that the individual building blocks were themselves made from iron. In the Eiffel world, constructing a large complex software system is done with libraries of high-quality reusable components. Thus, the "building blocks" are made from iron, and software systems are made from those building blocks. Hence, IRON provides the "raw material" from which complex Eiffel systems are developed. + +=Planned Enhancements= +This documentation describes the version of iron released with EiffelStudio 14.05. +More features are planned or are already under development: +:* the ability to analyze the contents of the package, to extract information related to its .ECF file(s) +:* a way of ensuring that the package compiles under the specified version of EiffelStudio +:* support for test suite +:* detection and actions related to package dependencies +:* package version +:* ability to upgrade of packages already installed +:* extended post-installation operations +:* more features that users may request or suggest. + diff --git a/documentation/18.11/solutions/networking/eiffelnet/eiffelnet-class-reference.wiki b/documentation/18.11/solutions/networking/eiffelnet/eiffelnet-class-reference.wiki new file mode 100644 index 00000000..8bb6f404 --- /dev/null +++ b/documentation/18.11/solutions/networking/eiffelnet/eiffelnet-class-reference.wiki @@ -0,0 +1,5 @@ +[[Property:title|EiffelNet Class Reference]] +[[Property:weight|1]] +[[Property:uuid|25ab1fde-b4bc-2f45-1ec2-6dd109bdfc39]] +==View the [[ref:libraries/net/reference/index|EiffelNet Class Reference]]== + diff --git a/documentation/18.11/solutions/networking/eiffelnet/eiffelnet-samples/advanced.wiki b/documentation/18.11/solutions/networking/eiffelnet/eiffelnet-samples/advanced.wiki new file mode 100644 index 00000000..7da22e1f --- /dev/null +++ b/documentation/18.11/solutions/networking/eiffelnet/eiffelnet-samples/advanced.wiki @@ -0,0 +1,29 @@ +[[Property:title|Advanced]] +[[Property:weight|0]] +[[Property:uuid|9229e5c1-165e-add7-6ce2-355dec4544f1]] +==Compiling== + +To compile the example, you must compile two projects: ''chat'' and ''join''. + +To compile the ''chat ''project: +* Launch EiffelStudio. +* Click '''Add project''' +* Browse to ''$ISE_EIFFEL\examples\net\advanced\chat\''. +* Choose ''chat.ecf'' +* Choose the location where the project will be compiled, by default the same directory containing the configuration file. +* Click '''OK'''. + +To compile the ''join ''project: +* Launch EiffelStudio. +* Click '''Add project''' +* Browse to ''$ISE_EIFFEL\examples\net\advanced\join\''. +* Choose ''join.ecf'' +* Choose the location where the project will be compiled, by default the same directory containing the configuration file. +* Click '''OK'''. + + + + + + + diff --git a/documentation/18.11/solutions/networking/eiffelnet/eiffelnet-samples/index.wiki b/documentation/18.11/solutions/networking/eiffelnet/eiffelnet-samples/index.wiki new file mode 100644 index 00000000..1126a995 --- /dev/null +++ b/documentation/18.11/solutions/networking/eiffelnet/eiffelnet-samples/index.wiki @@ -0,0 +1,7 @@ +[[Property:title|EiffelNet Samples]] +[[Property:weight|2]] +[[Property:uuid|c9c0fe01-a80f-5834-8503-aad1063e1503]] +=Description= + +Here is a set of five examples written to show some basic applications using the EiffelNet library . Two of them (Advanced and Same Machine) rely on specific code to Unix Operating systems and consequently cannot be run under Windows. + diff --git a/documentation/18.11/solutions/networking/eiffelnet/eiffelnet-samples/polling.wiki b/documentation/18.11/solutions/networking/eiffelnet/eiffelnet-samples/polling.wiki new file mode 100644 index 00000000..e73b581d --- /dev/null +++ b/documentation/18.11/solutions/networking/eiffelnet/eiffelnet-samples/polling.wiki @@ -0,0 +1,26 @@ +[[Property:title|Polling]] +[[Property:weight|1]] +[[Property:uuid|3bdc742f-2214-c5fb-2336-bc613b721c0d]] +==Compiling== + +To compile the example, you must compile two projects: ''client'' and ''server.'' + +To compile the ''client'' project: +* Launch EiffelStudio. +* Click '''Add project''' +* Browse to ''$ISE_EIFFEL\examples\net\polling\client\''. +* Choose ''polling_client.ecf'' +* Choose the location where the project will be compiled, by default the same directory containing the configuration file. +* Click '''OK'''. + +To compile the ''server'' project: +* Launch EiffelStudio. +* Click '''Add project''' +* Browse to ''$ISE_EIFFEL\examples\net\polling\server\''. +* Choose ''polling_server.ecf'' +* Choose the location where the project will be compiled, by default the same directory containing the configuration file. +* Click '''OK'''. + + + + diff --git a/documentation/18.11/solutions/networking/eiffelnet/eiffelnet-samples/predef.wiki b/documentation/18.11/solutions/networking/eiffelnet/eiffelnet-samples/predef.wiki new file mode 100644 index 00000000..95e15f27 --- /dev/null +++ b/documentation/18.11/solutions/networking/eiffelnet/eiffelnet-samples/predef.wiki @@ -0,0 +1,26 @@ +[[Property:title|Predef]] +[[Property:weight|2]] +[[Property:uuid|d9851197-ae39-5e73-9bf3-51d7cb9fa23c]] +==Compiling== + +To compile the example, you must compile two projects: ''client'' and ''server.'' + +To compile the ''client'' project: +* Launch EiffelStudio. +* Click '''Add project''' +* Browse to ''$ISE_EIFFEL\examples\net\predef\client\''. +* Choose ''our_client.ecf'' +* Choose the location where the project will be compiled, by default the same directory containing the configuration file. +* Click '''OK'''. + +To compile the ''server'' project: +* Launch EiffelStudio. +* Click '''Add project''' +* Browse to ''$ISE_EIFFEL\examples\net\predef\server\''. +* Choose ''our_server.ecf'' +* Choose the location where the project will be compiled, by default the same directory containing the configuration file. +* Click '''OK'''. + + + + diff --git a/documentation/18.11/solutions/networking/eiffelnet/eiffelnet-samples/same-machine.wiki b/documentation/18.11/solutions/networking/eiffelnet/eiffelnet-samples/same-machine.wiki new file mode 100644 index 00000000..77df8f93 --- /dev/null +++ b/documentation/18.11/solutions/networking/eiffelnet/eiffelnet-samples/same-machine.wiki @@ -0,0 +1,26 @@ +[[Property:title|Same Machine]] +[[Property:weight|3]] +[[Property:uuid|d10e1e4b-94c1-2725-f465-79da88730196]] +==Compiling== + +To compile the example, you must compile two projects: ''client'' and ''server.'' + +To compile the ''client'' project: +* Launch EiffelStudio. +* Click '''Add project''' +* Browse to ''$ISE_EIFFEL\examples\net\same_mach\client\''. +* Choose ''our_client.ecf'' +* Choose the location where the project will be compiled, by default the same directory containing the configuration file. +* Click '''OK'''. + +To compile the ''server'' project: +* Launch EiffelStudio. +* Click '''Add project''' +* Browse to ''$ISE_EIFFEL\examples\net\same_mach\server\''. +* Choose ''our_server.ecf'' +* Choose the location where the project will be compiled, by default the same directory containing the configuration file. +* Click '''OK'''. + + + + diff --git a/documentation/18.11/solutions/networking/eiffelnet/eiffelnet-samples/two-machines.wiki b/documentation/18.11/solutions/networking/eiffelnet/eiffelnet-samples/two-machines.wiki new file mode 100644 index 00000000..568ae9d2 --- /dev/null +++ b/documentation/18.11/solutions/networking/eiffelnet/eiffelnet-samples/two-machines.wiki @@ -0,0 +1,27 @@ +[[Property:title|Two Machines]] +[[Property:weight|4]] +[[Property:uuid|52307bfe-116d-f5c4-ccf1-98f330ef82e5]] +==Compiling== + +To compile the example, you must compile two projects: ''client'' and ''server.'' + +To compile the ''client'' project: +* Launch EiffelStudio. +* Click '''Add project''' +* Browse to ''$ISE_EIFFEL\examples\net\two_mach\client\''. +* Choose ''our_client.ecf'' +* Choose the location where the project will be compiled, by default the same directory containing the configuration file. +* Click '''OK'''. + +To compile the ''server'' project: +* Launch EiffelStudio. +* Click '''Add project''' +* Browse to ''$ISE_EIFFEL\examples\net\two_mach\server\''. +* Choose ''our_server.ecf'' +* Choose the location where the project will be compiled, by default the same directory containing the configuration file. +* Click '''OK'''. + + + + + diff --git a/documentation/18.11/solutions/networking/eiffelnet/eiffelnet-tutorial/bibliography.wiki b/documentation/18.11/solutions/networking/eiffelnet/eiffelnet-tutorial/bibliography.wiki new file mode 100644 index 00000000..07a3ed15 --- /dev/null +++ b/documentation/18.11/solutions/networking/eiffelnet/eiffelnet-tutorial/bibliography.wiki @@ -0,0 +1,16 @@ +[[Property:title|Bibliography]] +[[Property:weight|10]] +[[Property:uuid|739d59a6-c0b0-899f-24cf-5a17655a5512]] +[1] Bertrand Meyer: [[Eiffel: The Language]], Prentice Hall, 1992. (Available from Eiffel Software.) + + +[2] Bertrand Meyer: [http://www.eiffel.com/services/training/books.html Reusable Software: The Base Object-Oriented Component Libraries], Prentice Hall, 1994. (Available from Eiffel Software.) + + +[3] W. Richard Stevens: ''Unix Network Programming'', Prentice Hall, 1990. + + + + + + diff --git a/documentation/18.11/solutions/networking/eiffelnet/eiffelnet-tutorial/clients-and-servers.wiki b/documentation/18.11/solutions/networking/eiffelnet/eiffelnet-tutorial/clients-and-servers.wiki new file mode 100644 index 00000000..b91e1308 --- /dev/null +++ b/documentation/18.11/solutions/networking/eiffelnet/eiffelnet-tutorial/clients-and-servers.wiki @@ -0,0 +1,19 @@ +[[Property:title|Clients and servers]] +[[Property:weight|1]] +[[Property:uuid|3c1711f8-3aa0-9f3b-c1ce-0cd9324b3e00]] +In the client-server model of computing, a number of software systems, the clients, may require general-purpose services provided by other systems, the servers. Clients and servers run concurrently, on the same machine or, more generally, on different machines connected through a network. + +Typically, the clients are systems, for example systems that provide useful facilities for human users; the servers take care of operations that clients could not perform on their own (or would perform less efficiently), and of operations that are common to several clients. Example of servers include: +* '''Computation servers''', which take care of heavy or specialized computations not appropriate for the clients, assuming the servers' processors are more powerful. +* '''File servers''' and '''database servers''', providing access to persistent data that different clients may need to access. + +The client-server relation is usually many-to-many: each client application, in the course of performing its duties, may successively require services from different servers; and each server may cater to different clients. This second aspect, illustrated by the following figure, is particularly important; it allows a single server to communicate with as many clients as appropriate. + [[Image:fig-1]] +Although communication occurs both ways - clients sending objects to servers and conversely - the situation in such a scheme is usually not symmetric. Whereas a client requesting a certain service will need to know beforehand what server provides that service, the server, for its part, will not in general name its clients in advance; it will simply stand ready to provide its services to whatever suitable client happens to request them. + +This dissymmetry appears clearly in EiffelNet and in the examples of this manual. It means in particular that clients and servers act differently at the '''beginning''' of their client-server lifecycle. The party that initiates the communication is the client; in this operation it will identify the desired server (through a local file name for communication on the same machine, or though a machine name for network communication). The server simply makes itself ready for possible connections by starting to "listen" on the communication channels - relying for this on an EiffelNet procedure that is indeed called ''listen''. + + + + + diff --git a/documentation/18.11/solutions/networking/eiffelnet/eiffelnet-tutorial/event-driven-command-execution.wiki b/documentation/18.11/solutions/networking/eiffelnet/eiffelnet-tutorial/event-driven-command-execution.wiki new file mode 100644 index 00000000..d9ef0d3e --- /dev/null +++ b/documentation/18.11/solutions/networking/eiffelnet/eiffelnet-tutorial/event-driven-command-execution.wiki @@ -0,0 +1,207 @@ +[[Property:title|Event-driven command execution]] +[[Property:weight|8]] +[[Property:uuid|66036773-3e41-2877-7fa4-e0601558fc7c]] +{{note|The example classes discussed in this section appear in the subdirectory ''polling ''of the example directory.}} + + +===9.1 Commands and events=== + +In the preceding examples each participant in a communication had to get ready to send or receive at specific stages of its life. Although this did not preclude asynchronous communication, it is sometimes desirable to make the scheme even more asynchronous, and control more decentralized, by letting each system simply specify certain communication events that it wants to monitor, and certain commands to be executed on occurrence of the specified events. + +The commands are objects, instances of a general-purpose class COMMAND or its proper descendants. Class COMMAND has, among its features, a procedure execute which executes the current command; some commands are undoable and have an undo procedure. + +In EiffelNet the possible events associated with a socket will be of three kind: a read event; a write event; or a special event (out of bounds operation). The command classes will be descendants of [[ref:libraries/net/reference/poll_command_chart|POLL_COMMAND]], an heir of COMMAND. + +===9.2 Command classes=== + +The example uses three command classes: DATAGRAM_READER, used by both clients and servers, and specialized versions of a datagram writer: one for clients, CLIENT_DATAGRAM_WRITER, and one for servers, SERVER_DATAGRAM_WRITER. These classes model operations that must be triggered in the case of a read event and a write event. + +Here is the common reader command: + +class + DATAGRAM_READER + +inherit + + POLL_COMMAND + redefine + active_medium + end + +create + + make + +feature + + active_medium: NETWORK_DATAGRAM_SOCKET + + execute (arg: ANY) + local + rec_pack: PACKET + datagram: DATAGRAM_PACKET + i: INTEGER + do + rec_pack := active_medium.received (10, 0) + create datagram.make_from_managed_pointer (rec_pack.data) + io.putint (datagram.packet_number) + io.new_line + from i := 0 until i > 9 loop + io.putchar (datagram.element (i)) + i := i + 1 + end + io.new_line + end + +end -- class DATAGRAM_READER + + + +The execute procedure reads a packet of ten characters and prints these characters. Its counterpart in the writing command will produce these ten packets: + +class + CLIENT_DATAGRAM_WRITER + +inherit + + POLL_COMMAND + redefine + active_medium + end + +create + + make + +feature + + active_medium: NETWORK_DATAGRAM_SOCKET + + execute (arg: ANY) + local + sen_pack: DATAGRAM_PACKET + char: CHARACTER + do + -- Make packet with characters `a' to `j' in successive positions + create sen_pack.make (10) + from char := 'a' until char > 'j' loop + sen_pack.put_element (char, char |-| 'a') + char := char.next + end + sen_pack.set_packet_number (1) + active_medium.send (sen_pack, 0) + end + +end -- class CLIENT_DATAGRAM_WRITER + + +===9.3 The server and the client=== + +Once the commands have been defined, it suffices for the server and the client to associate instances of these commands with the appropriate. + +The abstraction needed for this purpose is provided by class MEDIUM_POLLER. An instance of this class knows about a number of commands, each associated with a certain socket in read, write or special event mode. By applying procedure execute to such a medium poller, you direct it to monitor these sockets for the corresponding events and to execute the command associated with each event that will be received. Procedure execute takes two integer arguments: the maximum number of sockets to monitor, and the timeout in milliseconds. + +Here is the server built with this mechanism: + +class + POLLING_SERVER + +create + + make + +feature + + make (argv: ARRAY [STRING]) + local + soc: detachable NETWORK_DATAGRAM_SOCKET + ps: MEDIUM_POLLER + readcomm: DATAGRAM_READER + writecomm: SERVER_DATAGRAM_WRITER + do + if argv.count /= 2 then + io.error.putstring ("Usage: ") + io.error.putstring (argv.item (0)) + io.error.putstring (" portnumber%N") + else + create soc.make_bound (argv.item (1).to_integer) + create ps.make_read_only + create readcomm.make (soc) + ps.put_read_command (readcomm) + create writecomm.make (soc) + ps.put_write_command (writecomm) + ps.execute (15, 20000) + ps.make_write_only + ps.execute (15, 20000) + soc.close + end + rescue + if soc /= Void and then not soc.is_closed then + soc.close + end + end + +end -- POLLING_SERVER + + + +Procedure make creates three objects: a socket, which it associates with a specific port; a poller; and a read command (an instance of DATAGRAM_READER), which it attaches to the socket. It then enters the read command into the poller, and does the same thing with a write command. It sets up the poller to accept read commands only and then executes the poller; this will enable the server to get the read event triggered by the client's write command (as it appears below in the text of class POLLING_CLIENT). Then the server reverses the poller's set-up to write-only, and calls execute again. + +The client follows the same scheme, reversing the order of read and write operations: + +class + POLLING_CLIENT + +create + + make + +feature + + make (argv: ARRAY [STRING]) + local + soc: detachable NETWORK_DATAGRAM_SOCKET + ps: MEDIUM_POLLER + readcomm: DATAGRAM_READER + writecomm: CLIENT_DATAGRAM_WRITER + do + if argv.count /= 3 then + io.error.putstring ("Usage: ") + io.error.putstring (argv.item (0)) + io.error.putstring (" hostname portnumber%N") + else + create soc.make_targeted (argv.item (1), argv.item (2).to_integer) + create ps.make_write_only + create readcomm.make (soc) + ps.put_read_command (readcomm) + create writecomm.make (soc) + ps.put_write_command (writecomm) + ps.execute (15, 20000) + ps.make_read_only + ps.execute (15, 20000) + soc.close + end + rescue + if soc /= Void and then not soc.is_closed then + soc.close + end + end + +end + + + +===9.4 A less deterministic scheme=== + +Although the example uses the event-driven mechanisms of EiffelNet, it is still relatively deterministic in that it follows a precise protocol defined by a strict sequence of read and write operations on both sides. This is why every call to execute is preceded by a call to either make_read_only or make_write_only to set up the poller in the appropriate mode. + +A less deterministic scheme may often be desirable, where you simply enter a number of commands (read, write, out of bounds processing) into a poller and then wait for arbitrary events to occur and trigger commands. There is no need with this scheme to know in advance the order in which events may occur: a read event will trigger the command entered into the poller through put_read_command; a write event will trigger the command entered through put_write_command. + +To achieve this behavior, simply create the poller using make as creation procedure. This will set up the poller so as to accept all socket events, and enter into event-driven command execution by calling execute on the poller. + + + + + + + diff --git a/documentation/18.11/solutions/networking/eiffelnet/eiffelnet-tutorial/index.wiki b/documentation/18.11/solutions/networking/eiffelnet/eiffelnet-tutorial/index.wiki new file mode 100644 index 00000000..b758d087 --- /dev/null +++ b/documentation/18.11/solutions/networking/eiffelnet/eiffelnet-tutorial/index.wiki @@ -0,0 +1,5 @@ +[[Property:title|EiffelNet Tutorial]] +[[Property:weight|0]] +[[Property:uuid|09679e98-4d5c-d2af-439b-00b28c6cfe4b]] + + diff --git a/documentation/18.11/solutions/networking/eiffelnet/eiffelnet-tutorial/introduction-examples.wiki b/documentation/18.11/solutions/networking/eiffelnet/eiffelnet-tutorial/introduction-examples.wiki new file mode 100644 index 00000000..fa73d4b2 --- /dev/null +++ b/documentation/18.11/solutions/networking/eiffelnet/eiffelnet-tutorial/introduction-examples.wiki @@ -0,0 +1,40 @@ +[[Property:title|Introduction to the examples]] +[[Property:weight|4]] +[[Property:uuid|3d9d54ab-0324-d8d4-ae32-f5379f2fc721]] +The following sections describe a set of examples showing how to use EiffelNet to build client-server applications. + +The examples start with the most simple uses involving high-level classes covering common cases and shielding developers from details of the mechanism. Subsequent examples will reveal some of these details, useful for more advanced or specific applications of EiffelNet. + +All the examples discussed here appear in the directory ''$ISE_EIFFEL/examples/net'' of the Eiffel distribution. + +===Object structures=== + +As noted above, it is possible with sockets, as any other IO_MEDIUM, to send and receive simple objects such as integers. But for this first example we are already more ambitious and want to exchange entire linked lists of strings. The structures that we will exchange are described by the following class: + +class + OUR_MESSAGE + +inherit + + LINKED_LIST [STRING] + + STORABLE + undefine + is_equal, copy + end + +create + make + +end + + +Note that to make use of the storage and retrieval facilities the objects to be exchanged must be instances of a class which, as here, is a descendant of STORABLE. + + + +{{caution|On Windows, the examples `advanced` and the `same_mach` are nonfunctional. This is because these examples use code specific to Unix Operating systems. }} + + + + diff --git a/documentation/18.11/solutions/networking/eiffelnet/eiffelnet-tutorial/more-complex-example.wiki b/documentation/18.11/solutions/networking/eiffelnet/eiffelnet-tutorial/more-complex-example.wiki new file mode 100644 index 00000000..76edfdfc --- /dev/null +++ b/documentation/18.11/solutions/networking/eiffelnet/eiffelnet-tutorial/more-complex-example.wiki @@ -0,0 +1,17 @@ +[[Property:title|A more complex example]] +[[Property:weight|9]] +[[Property:uuid|a57bbf5b-d877-8a50-1bca-92848868bdec]] +{{note|The example classes discussed in this section appear in the subdirectory ''advanced ''of the example directory.}} + + +The last example exercises most of EiffelNet's major facilities. It consists of a server that allows an arbitrary number of clients to connect to it. Each time the user of one of the client systems types a line on the keyboard, the client sends this character to the server, which then broadcasts it to all the clients (including the original sender). This scheme allows several people to talk together, hence the names chosen: the server class is called CHAT, and the client is called JOIN. + +The example uses the network mode of communication, based on the [[ref:libraries/net/reference/network_client_chart|NETWORK_CLIENT]] and [[ref:libraries/net/reference/network_server_chart|NETWORK_SERVER ]] classes. It uses automatic polling through [[ref:libraries/net/reference/medium_poller_chart|MEDIUM_POLLER]] as in the previous example; the relevant command is given by class CONNECTION, an heir of [[ref:libraries/net/reference/poll_command_chart|POLL_COMMAND]] . The information exchanged between the server and its clients is described by class MESSAGE, an heir of [[ref:libraries/base/reference/linked_list_chart|LINKED_LIST]] [ [[ref:libraries/base/reference/string_8_chart|STRING]] ] similar to the earlier examples' OUR_MESSAGE (see [[Introduction to the examples]] ). Attributes include, the name client_name of the client that has sent this message, the boolean new indicating whether the current message is the first from a client that is trying to connect to the server, and over indicating that the message is the last sent by a client before disconnecting. + +The server maintains a list of the currently active connections. In the receive routine, it checks on the main socket for any client trying to connect. The socket is set to be non-blocking to enable the server to continue checking the already connected clients. If the connection is successful, the server sends to the new client the list of clients already connected and adds the new connection to its list. Then it polls the connections in the list, and processes the messages, if any. If the message is tagged new, the server sends a message to all the clients indicating that a new client has joined the server; if it is tagged over, it sends a message indicating that the client has opted out. + +Each client uses the [[ref:libraries/net/reference/medium_poller_chart|MEDIUM_POLLER]] to check any message coming from the server and immediately displays any such message. It also checks a special connection, created with io.input as a medium, to check what the user is typing and then send it to the server. If the user types ''bye'', the client terminates, sending a message tagged over to the server. + + + + diff --git a/documentation/18.11/solutions/networking/eiffelnet/eiffelnet-tutorial/obtaining-finer-degree-control.wiki b/documentation/18.11/solutions/networking/eiffelnet/eiffelnet-tutorial/obtaining-finer-degree-control.wiki new file mode 100644 index 00000000..0149e866 --- /dev/null +++ b/documentation/18.11/solutions/networking/eiffelnet/eiffelnet-tutorial/obtaining-finer-degree-control.wiki @@ -0,0 +1,253 @@ +[[Property:title|Obtaining a finer degree of control]] +[[Property:link_title|]] +[[Property:weight|6]] +[[Property:uuid|9e2de24b-8ae3-5b57-9797-e163defe83d9]] +Let us now take a more internal look at the workings of EiffelNet. The two examples that follow have the same behavior as the preceding one; since their text is less simple, they are only interesting as an illustration of the lower-level facilities that you may want to use in specific cases. If you are already familiar with socket programming, they will also give you a more precise idea of how EiffelNet encapsulates the basic socket mechanisms. + +As before, we have a client and a server class, still called OUR_CLIENT and OUR_SERVER, which are part of two different systems and will run concurrently. The communication uses streams rather than datagrams; the datagram form of communication will be examined in section [[Using datagram sockets|using datagram sockets]] . + +===A client and a server on the same machine=== + +{{note|The example classes discussed in this section appear in the subdirectory ''same_mach'' of the example directory }} + +First, let us assume that the client and server run on the same machine, so that we will use the UNIX_ versions of the classes (the next example will be multi-machine). The communication protocol is also the same as before: the client sends a list of strings, the server returns it extended. + +Here we will create and manipulate sockets directly. For that reason, both classes inherit from the EiffelNet class SOCKET_RESOURCES which introduces a number of constants and other useful socket-related features. + +The two sockets must be able to refer to a common address. For a communication within a single machine, as noted, this address is a path name, again ''/tmp/here'' for this example. The address will be an argument of the creation procedure used to obtain a socket soc1 on either side: + + create soc1.make_client ("/tmp/here") + create soc1.make_server ("/tmp/here") + +The make_ procedures take care of all the hassles of establishing a socket for a client or a server: creating an address object, setting it to the given path name, binding the socket to the address, and in the client case establishing the connection. For finer control, these procedures are still available: you can create a bare socket by using the basic creation procedure make (rather than the more sophisticated make_client +and make_server), then create a separate address object, associate the two, and call the bind and connect procedures. + +Because communication is bidirectional, the distinction between client and server is not between who sends and who receives, although here the server only sends messages of acknowledgment. The client is the party that initiates the communication; the server is the party which stands ready to accept the communication. This difference justifies the presence of two creation procedures make_client and make_server as illustrated above. To initiate the communication, the client will execute: + + soc1.connect + +To make itself ready for the communication, the server will execute: + + soc1.listen (n) + +where n is a positive integer indicating the maximum number of client connection attempts that may be queued. The value 5, used in the example, is typical for n. + +When you use the _SERVER classes of the predefined level, as in the earlier example, 5 is indeed the default; you can change the value to a positive integer n through the call set_queued (n) . + +Whenever the server needs to exchange objects with one of the clients, it obtains access to the socket through the following sequence: + + soc1.accept + soc2 := soc1.accepted + ... Storage and retrieval operations using soc2 (not soc1) ... + soc2.close + + +Procedure accept ensures synchronization with the client. When communication is established, accept creates a new socket which will be accessible through attribute accepted, whose value is here assigned to the local entity soc2. To receive objects, the server will use operations of the form introduced earlier ( [[An overview of EiffelNet Mechanisms|An overview of EiffelNet, sending and receiving object structures]] ): + + if attached {SOME_EXPECTED_TYPE} soc2.retrieved as l_temp then +-- soc2.retrieved was attached to an object of the expected type. Now that object is attached to `l_temp' +-- Proceed with normal computation, typically involving calls of the form l_temp.some_feature + else +-- soc2.retrieved was not attached to an object of the expected type. + end + + +applying to soc2, not soc1; this makes soc1 available to accept connections with other clients, a fundamental feature of client-server mechanisms. + +The operation soc2.close which terminates the above sequence closes the new socket. In principle this is not necessary, since garbage collection should eventually reclaim the socket object, and the dispose procedure of the corresponding socket class includes a call to close. But the risk exists that you run out of sockets before garbage collection reclaims all currently opened sockets, so it is preferable to include the close calls explicitly. + +At the end of the processing it is necessary to close the original socket soc1 but also to unlink it. The feature cleanup from class SOCKET takes care of both closing and unlinking. + +Here is the server class based on these principles. The actual processing has been put aside in a procedure process. + +class + OUR_SERVER +inherit + + SOCKET_RESOURCES + + STORABLE + +creation + make + +feature + + make + -- Accept communication with client and exchange messages + local + count: INTEGER + soc1: detachable UNIX_STREAM_SOCKET + do + create soc1.make_server ("/tmp/here") + from + soc1.listen (5) + count := 0 + until + count = 3 + loop + process (soc1) -- See below + count := count + 1 + end + soc1.cleanup + rescue + if soc1 /= Void then + soc1.cleanup + end + end + + process (soc1: UNIX_STREAM_SOCKET) + -- Receive a message, extend it, and send it back + do + soc1.accept + if attached soc1.accepted as l_soc2 then + if attached {OUR_MESSAGE} retrieved (l_soc2) as l_our_new_list then + across + l_our_new_list as it + loop + io.put_string (it.item) + io.new_line + end + l_our_new_list.extend ("%N I'm back.%N") + l_our_new_list.independent_store (l_soc2) + end + soc2.close + end + end + +end + + +Note that at the end the server should not only closes the original socket soc1 but also unlinks it. It is recommended to have a Rescue clause which, as here, ensures that the socket will be closed and unlinked if the system terminates abnormally before its term. +Here now is the client class: + +class + OUR_CLIENT + +inherit + + SOCKET_RESOURCES + +creation + make + +feature + + make + -- Establish communication with server, and exchange messages + local + soc1: detachable UNIX_STREAM_SOCKET + do + create soc1.make_client ("/tmp/here") + soc1.connect + process (soc1) -- See below + soc1.cleanup + rescue + if soc1 /= Void then + soc1.cleanup + end + end + + process (soc1: UNIX_STREAM_SOCKET) + -- Build a message to server, receive answer, build + -- modified message from that answer, and print it. + local + our_list: OUR_MESSAGE + do + create our_list.make + our_list.extend("This") + our_list.extend (" is") + our_list.extend (" our") + our_list.extend (" test") + our_list.independent_store (soc1) + if attached {OUR_MESSAGE} our_list.retrieved (soc1) as l_our_new_list then + across + l_our_new_list as it + loop + io.putstring (it.item) + end + io.new_line + end + end + +end + + +===Communication between two different machines=== +{{note|The example classes discussed in this section appear in the subdirectory ''two_mach'' of the example directory }} + + +Let us now assume that the client and the server will run on two separate machines. Instead of UNIX_ sockets, we must now use sockets of type NETWORK_STREAM_SOCKET. + +The available creation procedures are slightly different. The server will be set up so as to listen to clients from any machine; it designates a '''port''', identified by an integer, on which it will listen. The socket creation on the server side is then + + create soc1.make_server_port (2000) + +For the client, the creation will specify two elements of information: the port number and the server. The server argument, a string, identifies the machine used as a server; it may be the host name of that machine, for example ''"serverhost" ''as used in the example; or it can be the machine's internet address, made of a sequence of numbers separated by periods, such as ''"127.0.0.1"''. + +The rest of the classes is as before. + +class + OUR_SERVER + +inherit + + SOCKET_RESOURCES + + STORABLE + +creation + make + +feature + + soc1: detachable NETWORK_STREAM_SOCKET + + make + -- Accept communication with client and exchange messages. + do + create soc1.make_server_by_port (2000) + ... The rest as before... + end + + process + ... As before ... + end + +end + + +class + OUR_CLIENT + +inherit + + SOCKET_RESOURCES + +creation + make + +feature + + soc1: detachable NETWORK_STREAM_SOCKET + + make + do + create soc1.make_client_by_port (2000, "serverhost") + ... The rest as before ... + end + + process + ... As before ... + end + +end + + + + + + + + + diff --git a/documentation/18.11/solutions/networking/eiffelnet/eiffelnet-tutorial/overview-eiffelnet-mechanisms.wiki b/documentation/18.11/solutions/networking/eiffelnet/eiffelnet-tutorial/overview-eiffelnet-mechanisms.wiki new file mode 100644 index 00000000..8764a745 --- /dev/null +++ b/documentation/18.11/solutions/networking/eiffelnet/eiffelnet-tutorial/overview-eiffelnet-mechanisms.wiki @@ -0,0 +1,130 @@ +[[Property:title|An overview of EiffelNet Mechanisms]] +[[Property:weight|2]] +[[Property:uuid|08d7ca19-65e3-7f35-fbce-a50d0aedf626]] +{{UpdateNeeded}} + + + +To enable clients and servers to exchange objects, you will have to ensure that they can refer to a common '''address'''. At the predefined level this is really the only notion that you need to know, although it is useful to get the bigger picture, in particular the concept of '''socket '''(which enables systems to set up communication channels), the various forms of communication (single-machine versus multi-machine, stream versus datagram), the kinds of object structure that may be exchanged, the notion of packet, and how to associate commands with communication events. The following paragraphs review these ideas and the corresponding EiffelNet abstractions. + +===Establishing a common address=== + +When two systems need to communicate through sockets, they must establish a binding through some common point of reference, called an '''address'''. Predictably, the notion of address is one of the important internal abstractions of EiffelNet, although in most cases developers of applications using EiffelNet do not need to manipulate address objects directly. + +EiffelNet supports two modes of communication: single-machine and multi-machine. In the single-machine case, the two communicating systems are known to be running on the same machine. In the multi-machine case, also known as the '''network''' case, they may be running on different machines, and communication occurs through a network. These two modes clearly require a different binding mechanism. + +When a client and a server reside on the same machine, they both have access to that machine's file system. This provides a straightforward binding mechanism: the common address will simply be a "path name", the Unix terminology for the full name of a file in a hierarchically organized file system. In the examples below this file will be ''/tmp/here ''(file ''here'' in the ''/tmp'' directory, conventionally used for temporary files). This file must not exist prior to the communication; it will be created by the socket mechanisms and then removed. + +For the network style of communication, this simple device of using a path name is no longer applicable. To define a common address, we may use two elements of information: the name of a machine, and the indication of a '''port''' on that machine. More precisely: +* The port will be identified by an integer. In the examples below port ''2000'' will be used. +* The machine may be identified in either of two ways: its '''host name''' (the name assigned to the machine when the operating system was first installed on it) or its '''Internet address''', a sequence of numbers separated by periods, such as ''127.0.0.1''. EiffelNet routines that need an argument identifying a machine will indifferently take a host name or an Internet address, passed in either case as a string. In the examples below the identification will be a host name, given as the string ''"serverhost"''. + +In network-style client-server communication, the mechanism will be dissymmetric, reflecting the possibility (noted earlier) of a single server catering to many clients. The clients will state both the machine identification of their intended server and the port on which they will talk to that server. The server, however, will only specify the port; this means that it makes itself available to any client that cares to talk to it on that port. This provides some of the essential flexibility of client-server communication, where only one of the partners needs to state beforehand whom it wants to talk to. + +===Sockets and communication modes=== + +A software system will exchange objects with another by sending them to a socket. Although if you stay at the predefined level you will not need to manipulate sockets explicitly, it is useful to understand this concept and know about the corresponding EiffelNet classes. + +You may think of a socket as a communication port; by attaching sockets together you enable communication between the corresponding systems, for example a client and a server: + + +[[Image:fig-2]] + + +EiffelNet has been designed so that sockets look very much like files. You send objects to a socket in the same way that you write objects onto a file, and receive objects from a socket in the same way that you read objects from a file. This fundamental commonality is reflected in the inheritance hierarchy of the corresponding classes: + + +[[Image:fig-3]] + + +Note that the hierarchy as shown is not complete; in particular the full structure uses classes STREAM (of which the STREAM_ classes are heirs) and DATAGRAM for multiple inheritance ''. ''Only the classes below the dotted line are part of EiffelNet; the others are part of EiffelBase, the fundamental data structure and algorithm library of ISE Eiffel [ [[Bibliography|2]] ]. + +The most important property of this inheritance hierarchy is that it shows how sockets fit within the overall structure. Thanks to the common ancestor IO_MEDIUM, socket classes have most of their features in common with files. + +In normal usage, the only socket classes that you will need are four classes appearing at the bottom of the above figure. They correspond to two separate distinctions: single-machine versus multi-machine, and reliable versus unreliable. + +On the first distinction: +* If the communicating systems run on the same machine, you may use one of the UNIX_ classes. +* For systems that run on different machines, you must use one of the NETWORK_ classes. This will also work if the systems are on the same machine, but less efficiently since communication may go through the network. + +The use of the word UNIX_ does not mean that the machine must be running the Unix operating system; rather, it denotes a certain style of client-server communication, the Unix style. (This is comparable to the use of the name UNIX_FILE in EiffelBase, for a class describing files that behave in the Unix style even though they may be implemented on non-Unix machines.) + +The second distinction reflects two modes of socket communication: stream communication and datagram communication. Both of these modes support two-way communication between systems, but with different properties: +* A stream socket, as provided by the STREAM_ classes, provides sequenced communication without any loss or duplication of data. Stream communication is normally synchronous: the sending system waits until it has established a connection to the receiving system and transmitted the data. +* A datagram socket, as provided by the DATAGRAM_ classes, is asynchronous: the sending system emits its data and does not wait for an acknowledgment. Because the sender is not blocked, this mode is more efficient, but it does not guarantee sequencing, reliability or non-duplication. + +===Sending and receiving simple values=== + +IO_MEDIUM has all the basic input and output facilities applying to objects of basic types, as also offered in FILE(see the specification of FILE in reference [ [[Bibliography|2]] ]). So you can use sockets to send and receive characters, integers, real numbers in simple or double precision and strings. For example, if the type of +`my_socket' is one of the socket classes shown on the preceding figures, any of the following calls will be valid: + + my_socket.put_string ("Some text") + my_socket.read_integer_32 + my_last_integer := my_socket.last_integer_32 + + +Since sockets are bidirectional, these instructions may all appear as part of the same class provided you make sure to guarantee proper synchronization between senders and receivers. You may also prefer to specialize certain sockets for sending and others for receiving. + +===Sending and receiving object structures=== + +In many cases, what you will want to send and receive is not just simple values but non-basic objects (instances of arbitrary classes, having as many fields as needed) and, more generally, entire object structures. + +The basic mechanism enabling a system to send objects through EiffelNet is also the basic mechanism for storing objects into a file: class STORABLE from EiffelBase. + + +{{note|Although this discussion uses the class STORABLE, it should be noted that this class will in the future be made obsolete by the classes in the Serialization (SED) subcluster of EiffelBase. You will notice that the EiffelNet examples delivered with EiffelStudio use the classes from the Serialization cluster.}} + + +As documented in [ [[Bibliography|2]] ], STORABLE provides features to store and retrieve complete object structures. There are three storage procedures, called under the respective forms + + struct1.basic_store (iom1) + struct1.general_store (iom1) + struct1.independent_store (iom1) + + +Assuming that the type of ''iom1 ''is IO_MEDIUM or a conforming type such as [[ref:libraries/base/reference/file_chart|FILE]] or one of the _SOCKET classes, and that the type of ''struct1'' conforms to STORABLE. Note that reference [2] in its original version does not include ''independent_store'', and requires ''iom'' to be of type FILE rather than the more general IO_MEDIUM. The current version of EiffelBase, however, supports the more general properties described here. + +All three storage procedures have the effect of sending to ''iom1 ''(whether a file, a socket or some other IO-medium) a copy of the entire object structure starting at ''struc1''. Together with the retrieval routines seen below, they apply the principle of reference completeness stated in [ [[Bibliography|1]] ] and [ [[Bibliography|2]] ]: +{| border="1" +|- +| Whenever a routine of class STORABLE stores an object into an external file, it stores with it the dependents of that object. +| Whenever one of the associated retrieval routines retrieves a previously stored object, it also retrieves all its dependents. +|} + +For EiffelNet, of course, "storing" and "retrieving" mean sending and receiving. The rest of this section, which applies to sockets as well as to files, will continue to use the original terminology of storage and retrieval. + +The three storage procedures differ in their degree of generality: +* ''basic_store'' will only work if the sending and retrieving are performed by instances of the same system (the same executable module). +* ''general_store'' will work if the sender and retriever are different systems (using the same classes for the objects that they exchange), but these systems must run on machines of the same architecture, or at least of architectures that use the same data representation. +* ''independent_store'' will work in the most general case, with the sender and receiver possibly running on platforms using different data representations. + +The penalty for using more general representations is that the data representation (as stored into the file or sent to the socket) will have to include more information. So ''basic_store ''uses the most compact representation, and ''independent_store'' the most verbose. + +The scheme for accessing an object structure produced by one of these three procedures is the following, used in a descendant of class STORABLE: + + if attached {SOME_EXPECTED_TYPE} retrieved (iom2) as l_temp then +-- Retrieved object is of expected type and now attached to `l_temp' +-- Proceed with normal processing, typically involving calls of the form `l_temp.some_feature' + else +-- Retrieved was not attached to an object of SOME_EXPECTED_TYPE + end + + +Here ''iom2'' must be of a type conforming to IO_MEDIUM. The [[ET: Inheritance#Object test|object test]] using the "attached" syntax checks that the root object of the structure produced by the corresponding call to one of the ''_store'' procedures is of a type that conforms to the expected type. + +Although there are three separate storage procedures, there is only one retrieval routine, ''retrieved''; the algorithm for ''retrieved ''is able to figure out, from the format of the retrieved objects, whether they were produced in the basic, general or independent mode. + +===Packets=== + +The classes PACKET and DATAGRAM_PACKET are used to represent packets of data that can be sent to sockets. + +Their main use is for a system that relies on datagram communication. As noted above, this mode does not guarantee sequencing, making each system responsible for checking that packets arrive in the proper order. This is possible through feature ''number ''of class DATAGRAM_PACKET, which gives the number of the current packet. + +===Associating commands with events=== + +EiffelNet supports a highly asynchronous (and hence efficient) mode of operation by offering mechanisms through which you can specify that a certain action must be executed whenever a certain medium becomes available for reading, writing or handling of special cases (out of bounds). This facility is provided by a set of related classes: +* The actions are represented by class POLL_COMMAND, an heir of the EiffelBase class COMMAND with, in particular, the procedure ''execute''. +* Using MEDIUM_POLLER, you can specify that a certain command (an instance of POLL_COMMAND) must be executed whenever a certain medium becomes available for the appropriate operation (read, write, handling of out-of-bounds cases). +* Using POLL_MASK, you can set a mask to select the sockets or files on which your instance of MEDIUM_POLLER is working. + + diff --git a/documentation/18.11/solutions/networking/eiffelnet/eiffelnet-tutorial/using-datagram-sockets.wiki b/documentation/18.11/solutions/networking/eiffelnet/eiffelnet-tutorial/using-datagram-sockets.wiki new file mode 100644 index 00000000..54389a94 --- /dev/null +++ b/documentation/18.11/solutions/networking/eiffelnet/eiffelnet-tutorial/using-datagram-sockets.wiki @@ -0,0 +1,14 @@ +[[Property:title|Using datagram sockets]] +[[Property:weight|7]] +[[Property:uuid|ba27b7dd-77db-7f6f-9b8c-2a3111d9d432]] +{{note|The example classes discussed in this section appear in the subdirectory ''datagram'' of the example directory. }} + +Using datagram sockets implies a few differences from the preceding schemes. You create a [[ref:libraries/net/reference/network_datagram_socket_chart|NETWORK_DATAGRAM_SOCKET]] or a UNIX_DATAGRAM_SOCKET as before. You do not need to call listen, accept or connect. Once you have created your sockets using the make_client or make_server creation procedure, you can use the send and received routines, specifying the socket to which you want to send, or from which you want to receive. + +The command send takes an argument of type [[ref:libraries/net/reference/datagram_packet_chart|DATAGRAM_PACKET]] , and the query received returns a result of this type. [[ref:libraries/net/reference/datagram_packet_chart|DATAGRAM_PACKET]] is an heir of class [[ref:libraries/net/reference/packet_chart|PACKET]] , itself an heir of [[ref:libraries/base/reference/array_chart|ARRAY]] [ [[ref:libraries/base/reference/character_8_chart|CHARACTER]] ]. Class [[ref:libraries/net/reference/datagram_packet_chart|DATAGRAM_PACKET]] makes it possible, through the query number and the associated command set_number, to associate a packet number with each packet. This compensates for lack of guaranteed sequencing of datagram sockets: the sender can number packets through set_number, and the receiver can check that all packets have been received through number, asking the sender to re-emit missing objects. + +The text of this example is similar to what appears below (in a more general setting involving event-driven computation) for the next example. + + + + diff --git a/documentation/18.11/solutions/networking/eiffelnet/eiffelnet-tutorial/what-eiffelnet.wiki b/documentation/18.11/solutions/networking/eiffelnet/eiffelnet-tutorial/what-eiffelnet.wiki new file mode 100644 index 00000000..c11e732f --- /dev/null +++ b/documentation/18.11/solutions/networking/eiffelnet/eiffelnet-tutorial/what-eiffelnet.wiki @@ -0,0 +1,33 @@ +[[Property:title|What is EiffelNet]] +[[Property:weight|0]] +[[Property:uuid|bf6d5904-9df8-451a-2ef9-0eee1200b60f]] +===What is EiffelNet?=== + +The client-server model of computing is quickly gaining ground as a way of optimizing network resources and of building sophisticated and flexible transactional applications. + +The object-oriented method of software development, as embodied in Eiffel, potentially provides ideal support for developing client-server applications. The EiffelNet library described in this report makes this potential a reality by addressing one the crucial needs of client-server development: how to exchange objects between software systems. Systems using EiffelNet can exchange object structures with other systems running on the same machine or on different machines; in the case of different machines, the hardware architectures need not be the same. Objects are transmitted using sockets. + +Writing client-server applications, especially their communication aspects, is an arduous task; developers must master many tricky details of socket programming and other low-level mechanisms. EiffelNet hides this complexity by providing ready-made classes addressing the most common cases, so that developers only have to describe what is specific to their application, letting EiffelNet handle the whole process of communication and synchronization between clients and servers. This part of EiffelNet is known as the ''predefined level'' and for many uses this is the only one that you will need to learn about. For developments requiring a finer degree of control, all the major mechanisms of socket programming are still accessible in a convenient form through more specialized classes. + +In offering these varying levels of abstraction and control, EiffelNet follows the principles set by other libraries of the Eiffel environment (see for example the discussion of EiffelLex in reference [ [[Bibliography|2]] ]). Some users require a mechanism that will be very easy to learn and will hide all the details in common cases; other users (or the same at later stages of their work) need to access the whole array of facilities available at the level of the underlying hardware or software. The various components of the library should address all these needs. + +This manual describes how to use EiffelNet at its various levels of abstraction. + +===Background and prerequisites=== + +EiffelNet is a component of the Eiffel development environment. + +This manual assumes the following prerequisites: +* Familiarity with the basic Eiffel concepts: classes, inheritance, features, assertions, exception handling (see reference [ [[Bibliography|1]] ]). +* Experience of writing software with Eiffel. +* Basic knowledge of the EiffelBase libraries, as described in reference [ [[Bibliography|2]] ]. + +Familiarity with the basic concepts of client-server computing will also be helpful (see for example reference [ [[Bibliography|3]] ]; if you are new to this area, however, you will still be able to use EiffelNet, as this manual defines all the needed concepts. + +===Organization of this manual=== + +[[Clients and servers]] discusses the notion of client and server. [[An overview of EiffelNet Mechanisms]] presents an overview of EiffelNet's facilities. The sections titled [[Introduction to the examples]] through [[A more complex example]] describe the facilities in detail through a set of increasingly ambitious examples (whose texts may all be found in the directory '''$ISE_EIFFEL/examples/net''' of the Eiffel distribution). The final section is a short [[Bibliography]]. + + + + diff --git a/documentation/18.11/solutions/networking/eiffelnet/index.wiki b/documentation/18.11/solutions/networking/eiffelnet/index.wiki new file mode 100644 index 00000000..84d8357d --- /dev/null +++ b/documentation/18.11/solutions/networking/eiffelnet/index.wiki @@ -0,0 +1,10 @@ +[[Property:title|EiffelNet]] +[[Property:weight|4]] +[[Property:uuid|80fbd984-da52-b573-6282-33f499d67ab5]] +==EiffelNet Library== + +Type: Library
+Platform: Any + +A library providing classes that facilitate network communication through sockets. + diff --git a/documentation/18.11/solutions/networking/index.wiki b/documentation/18.11/solutions/networking/index.wiki new file mode 100644 index 00000000..c590b289 --- /dev/null +++ b/documentation/18.11/solutions/networking/index.wiki @@ -0,0 +1,33 @@ +[[Property:title|Networking]] +[[Property:weight|-9]] +[[Property:uuid|4ddb235c-fea6-ee00-05af-6493e2c652a7]] +==Network communication solutions== + +Many Eiffel applications take advantage of networking. The Eiffel solutions to support networking include the EiffelNet, ZeroMQ and http_client libraries. + +===Choosing the right libraries=== +The libraries serve different, and complementary, purposes: + +*EiffelNet enables Eiffel systems to use many Internet concepts and protocols: sockets, network address, IPV4, IPV6 and others. + +*ZeroMQ supports direct messaging. + +*http_client is a web client used to send HTTP requests (GET, POST, ...) and process the associated responses. + +===Using the libraries=== + +Here is how to take advantage of one or more of the above libraries in your Eiffel system: + + + +* '''EiffelNet''': +: manipulation of sockets, network addresses, IPv4, IPv6. But also basic limited implementation for a few protocols. $ISE_LIBRARY/library/net/net.ecf + +* '''ZeroMQ''': +: wrapping for the [http://zeromq.org/ ZeroMQ] Distributed Messaging . [https://svn.eiffel.com/eiffelstudio/trunk/Src/library/zeromq] + +* '''http_client''': +: simple web client to send http (GET, POST, ...) request and receive associated response. $ISE_LIBRARY/contrib/library/network/http_client/http_client.ecf + + + diff --git a/documentation/18.11/solutions/other-languages/cecil/cecil-interface-overview.wiki b/documentation/18.11/solutions/other-languages/cecil/cecil-interface-overview.wiki new file mode 100644 index 00000000..2812a2ed --- /dev/null +++ b/documentation/18.11/solutions/other-languages/cecil/cecil-interface-overview.wiki @@ -0,0 +1,581 @@ +[[Property:title|CECIL interface overview]] +[[Property:weight|3]] +[[Property:uuid|7d8b4785-6f05-02c9-ba1c-12bad3d4b331]] +==Eiffel basic types== +The EIFFEL include files define types for every EIFFEL types: +* An Eiffel INTEGER is an ''EIF_INTEGER'', +* An Eiffel CHARACTER is an ''EIF_CHARACTER'', +* An Eiffel REAL is an ''EIF_REAL'', +* An Eiffel DOUBLE is an ''EIF_DOUBLE'', +* Eiffel references (any Eiffel objects that are not from a basic type) are ''EIF_REFERENCE'' (not protected, and can be moved), +* An Eiffel POINTER is an ''EIF_POINTER,'' +* An Eiffel BOOLEAN is an ''EIF_BOOLEAN'', +* A Protected Eiffel object is an ''EIF_OBJECT'' (does not move, and should be accessed through eif_access. ). + +Generally, you should use these types when implementing external C functions bound to be used from Eiffel or when you want to manipulate Eiffel objects from the C side. EIF_REFERENCE, EIF_OBJECT, EIF_POINTER all correspond in C to a (char *), but their semantic remains different in Eiffel. + +{{note|In the following code samples, the class OBJECT is a placeholder for one of your type that you wish to use via CECIL.}} + +{{sample|Calling C external `foo` from Eiffel, which takes a pointer and an eiffel object of type OBJECT as arguments and returns an INTEGER. }} + + + c_foo (ptr: POINTER; obj: OBJECT): INTEGER + external + "C | %"your_file.h%"" + alias + "foo" + end + + + +In the C side, The C function `foo` is defined as follow: + + +EIF_INTEGER foo (EIF_POINTER ptr, EIF_OBJECT obj) + { + /* some code */ + } + + +In some cases, you may not be able to change the signature of a C function you want to use. In this case, you must describe its actual signature in the Eiffel code. On the C side, foo is already defined as below: + +int foo (void *arg1, char c, FILE *file) + { + /* some code */ + } + +To match the signature, you must declare it in Eiffel as: + + c_foo (arg1: POINTER; c: CHARACTER; file: POINTER): INTEGER + external + "C (void *, char, FILE *) : int | %""your_file.h%"" + alias + "foo" + end + +Not doing this would generally produce warnings during the C compilation, and it could crash with some C compilers. + +To perform the conversion, here is the actual Eiffel types mapping to C types: +* POINTER is compatible with any C pointer ( ''char *''). +* INTEGER is a long. +* CHARACTER is an ''unsigned char''. +* DOUBLE is a ''double''. +* REAL is a ''float''. +* BOOLEAN is an ''unsigned char (EIF_TRUE = '\01', EIF_FALSE = '\0')'' . + +These are the current correspondences but they may change. The definition of each Eiffel type is located in `$ISE_EIFFEL/bench/spec/$PLATFORM/include/eif_portable.h` . + +===More about EIF_OBJECT, EIF_REFERENCE, and basic expanded types=== +It is sometimes difficult to tell the difference between an ''EIF_OBJECT'' and an ''EIF_REFERENCE''. +An ''EIF_REFERENCE'' is an Eiffel reference. It corresponds to an Eiffel object in the Eiffel side. eif_attribute, eif_reference_function, eif_string, eif_wean all return ''EIF_REFERENCEs''. An ''EIF_REFERENCE'' can be used "as is" by the Eiffel run-time. eif_attribute, eif_xx_function take ''EIF_REFERENCEs'' as arguments, never ''EIF_OBJECTs''. The return value of a C external is to be an ''EIF_REFERENCE'', if it is not a basic expanded type. To protect an ''EIF_REFERENCE'', use eif_protect. + +An ''EIF_OBJECT'' is a safe and static indirection to an Eiffel reference. As the GC may move an Eiffel reference, this indirection is updated at every collection so that you do not need to know whether an Eiffel reference has moved or not. You must pass through this indirection to access the Eiffel reference (see eif_access). Not doing so is completely unsafe since an Eiffel reference may be obsolete after a collection. eif_create, eif_adopt, and eif_protect returns an ''EIF_OBJECT''. The argument of a C external (on the C side) , which is not a basic expanded type, is also an ''EIF_OBJECT''. The Eiffel run-time temporarily protects the Eiffel objects that are passed to a C external , that is why the signature of a C external has no ''EIF_REFERENCE'' in it, but ''EIF_OBJECT'' instead. After the C external call, the run-time unprotects the Eiffel object. If you intend to use in the C side an ''EIF_OBJECT'' given by a C external afterwards, you must protect it with eif_adopt. To unprotect an ''EIF_OBJECT'' , which is not a C external argument, use eif_wean. + +The basic expanded types are INTEGER, INTEGER_64, INTEGER_16, INTEGER_8, REAL, DOUBLE, CHARACTER, BOOLEAN, POINTER. They are passed to C externals by values. There is no need to protect instances of these types. When the POINTER is a pointer to an Eiffel object (ex: $my_object), then the direct Eiffel reference is passed to C, with no protection and this reference may move. Use eif_protect to manually protect it. To unprotect it, call eif_wean. + +==Protecting the Eiffel objects== +You can use the CECIL functions directly from a C program as well as from a C external called from Eiffel. If you encounter problems, they may be related to the handling of garbage collection. The programmer who uses CECIL has to be aware that all Eiffel objects can be moved or collected asynchronously by the Garbage Collector (GC). +The cecil library provides the user with numerous macros and functions, which relieve the programmer from these kinds of low-level considerations (most of them are declared in $ISE_EIFFEL/bench/spec/$PLATFORM/include/eif_cecil. h). + +===Eiffel objects passed in a C external=== +An Eiffel object which is passed as an argument of a C external is automatically protected: the value passed to C is not a direct Eiffel reference. In fact, it is a temporary indirection pointer, which is only valid until the C external returned. This indirection pointer is to be used to access the direct reference of the Eiffel object with ''eif_access (eiffel_object)'' where ''eiffel_object'' is the argument (an ''EIF_OBJECT)'' of the C external which corresponds to the Eiffel object. Only Eiffel objects passed to C is automatically protected. This excludes basic expanded types, since they cannot be moved. +===Accessing the direct reference to an Eiffel object: eif_access=== +'''# include "eif_hector. h"''' + + +'''EIF_REFERENCE eif_access (EIF_OBJECT object) /* Macro */''' + + +The GC moves the objects every time it runs a collection cycle. A collection cycle can only occur during an Eiffel call. This includes calls to Eiffel routines and calls to CECIL functions (other than ''eif_access''). Thus, it may be unsafe to access a "raw" reference to an Eiffel object, (of type ''EIF_REFERENCE'') "as is", since the latter can be obsolete after each collection. To avoid this, you must access a direct reference through a "protection", which is a safe, non-moving pointer (of type ''EIF_OBJECT''). Call the macro ''eif_access'' as follows: ''eif_access (protection)'' , where ''protection'' is either a value returned by eif_create, eif_adopt or eif_protect, or an Eiffel object which is an argument of a C external. + +Use ''eif_access'' to pass an Eiffel object to an Eiffel routine or to return the value of a C external. It is also unsafe to pass a direct Eiffel reference ( ''EIF_REFERENCE'') to a C function which is not an Eiffel routine. Pass a protected indirection instead ( ''EIF_OBJECT''). However, if you still intend to pass a direct reference, be very careful and make sure that you do not perform any Eiffel call after passing the reference to the C function and before reading it. + +'''For example, in the following external:''' + + + c_foo (ptr: POINTER; obj: OBJECT): INTEGER + external + "C | %""your_file.h%"" + alias + "foo" + end + + + +the Eiffel run-time will protect obj, which can asynchronously move, and give a static and safe indirection to C. + +'''Here is an example of how accessing obj: OBJECT:''' + +EIF_INTEGER foo (EIF_POINTER ptr, EIF_OBJECT obj); +{ + /* Print the Eiffel object `obj', with the feature `print' + * from ANY. (do not forget to put `visible' the class + * ANY in the project configuration file. + */ + + EIF_PROCEDURE ep; + EIF_TYPE_ID tid; + tid = eif_type_id ("ANY"); + ep = eif_procedure ("print", tid); + (ep) (eif_access(obj),eif_access(obj)); +} + + +'''Important rules when using eif_access:''' + +{{note|The first argument of ''(ep)'' is the target of the function (the eiffel object to which you want to apply the Eiffel feature ''(ep)'') and the second argument corresponds to the first argument of `print`. Any Eiffel object could have been the 1st argument of ''(ep)'' since all of them inherit ''ANY''. }} + + +* '''Never pre compute the value returned by eif_access. '''
+'''Example:'''
+Example:
+Instead of the code above, it would have been dangerous to write: + +EIF_REFERENCE e_ref = eif_access (obj); +... +(ep) (e_ref, e_ref); + + + +because e_ref is the direct reference to the Eiffel object when calling ''eif_access(). '' There is not guarantee that it will still be valid when the call to ''(ep)'' is done: meanwhile, e_ref may have been moved by the GC.
+ + +* '''Never use eif_access with encapsulated eiffel calls:'''
+(eif_access in not an eiffel call) +'''Example:''' + + +(ep) (eif_access (a), eif_string ("Hello world")); + /* eif_string is a macro returning a direct reference to an Eiffel string, + * which corresponds to the C string passed as its argument. + */ + +Nothing guarantees that the direct reference returned by `eif_access (a)` will be still valid when executing (ep): it may be obsolete after the Eiffel call eif_string ("Hello world"), which may invoke a collection cycle. + +The correct code is + + +EIF_REFERENCE my_string; +/* some code */ +my_string = eif_string ("Hello world"); +(ep) (eif_access (a), my_string); + + + +In this case, you do not need to protect `my_string` since the GC is not likely to be triggered after the call to ''eif_string'' and before `my_string` is given as argument in ''(ep). '' A collection is triggered only during Eiffel calls. If an Eiffel call had been performed, you would have had to use ''eif_protect'' (see paragraph 3. 2): + + +EIF_REFERENCE my_string; +EIF_OBJECT i_my_string; +/* some code */ +my_string = eif_string ("Hello world"); +i_my_string = eif_protect (my_string); /* Protect `my_string'. */ +/* Some eiffel calls */ +(ep) (eif_access (a), eif_access (i_my_string)); +eif_wean (i_my_string); /* Release protection. */ + + + + +===Keeping a reference from C after an external call: eif_adopt=== +'''# include "eif_hector. h"''' + + +EIF_OBJECT eif_adopt (EIF_OBJECT object) + + +When passing Eiffel objects to C, you may need to keep a reference to them after the C external is called. Since the Eiffel run-time automatically will unprotect the Eiffel object references passed to a C external after execution, if one of the Eiffel objects is not referenced any longer from Eiffel, then the garbage collector will collect it because it is not aware that you may still need to reference this object from the C side. + +Called within a C external, the function ''eif_adopt'' creates a user protection for the Eiffel object ''object'' passed to C ( ''object'' is a C external argument). This way, the GC cannot collect the Eiffel reference returned by ''eif_access(object)'' when the C external returned. It tells the GC to keep artificially a reference to this Eiffel reference from C. It returns the new indirection pointer (say ''returned_value'') that must be used afterwards to access this direct Eiffel reference with ''eif_access (return_value)''. It is important to note that ''eif_adopt'' already takes an indirection pointer as unique argument. This is a temporary protection pointer: you can access the direct Eiffel reference with ''eif_access (object)'' only within the code of the C external. When the C external returns, ''eif_access (object)'' is NULL but ''eif_access (returned_value)'' remains valid until you release it with eif_wean. + +'''Example:''' + +In Eiffel: + + + c_foo (ptr: POINTER; obj: OBJECT): INTEGER + external + "C | %"your_file.h%"" + alias + "foo" + end + c_display_and_release_obj + external + "C | %"your_file.h%"" + alias + "display_and_release_obj" + end + + + +On the C side: + + +EIF_OBJECT my_obj; /* Protection of the object of type OBJECT. */ +EIF_INTEGER foo (EIF_POINTER ptr, EIF_OBJECT obj) +{ + my_obj = eif_adopt (obj); /* Keeping a reference on it for + * for later use. + */ + /* some code */ +} +void display_and_release_obj (void) +{ + /* Display global object. */ + EIF_PROCEDURE ep; + EIF_TYPE_ID tid; + tid = eif_type_id ("OBJECT"); + ep = eif_procedure ("print", tid); + (ep) (eif_access(my_obj),eif_access(my_obj)); /* Print global object.*/ + eif_wean (my_obj); /* Remove the protection on global object.*/ +} + + + +Between the call of `c_foo` and `c_display_obj`, the global object `(eif_access (my_obj))` may not be referenced from Eiffel any longer. To prevent the GC from collecting it before the call to `c_display_and_release_obj`, you must protect it with `eif_adopt` in the C function `foo`. + +==Other CECIL functions:== + +===Creating Eiffel objects from C: eif_create=== +''' # include "eif_cecil. h"''' + + +EIF_OBJECT eif_create (EIF_TYPE_ID type_id) + + +All CECIL calls are not completed using C externals. It is possible to create and manipulate Eiffel objects from a C program and still reap benefits from the garbage collector and design by contract methodology provided by Eiffel (see also [[Compiling an Eiffel system for CECIL|How to run a CECIL program]] ). This function does not call any creation procedure. + +The CECIL function ''eif_create'' takes a type identifier ''type_id'' as argument (generally returned by eif_type_id). It returns a static indirection pointer which is to be used afterwards to access the newly created Eiffel object with ''eif_access (returned_value)'' where ''returned_value'' is the value returned by ''eif_create'' . This means that when creating an eiffel object from C, the eiffel object is automatically protected: there is no need to call eif_adopt or eif_protect on it. This function does not call any creation procedure. To do so, you need to explicitly call it with eif_procedure. The garbage collector will not collect the newly created object until you call eif_wean on it. + +'''Example:''' + +Creating an object of type "OBJECT": + + +#include eif_setup.h" /* for EIF_INITIALIZE and EIF_DISPOSE_ALL */ +#include "eif_eiffel.h" /* for other exported routines from the Eiffel run-time */ +main (int argc,char **argv,char **envp) +{ + EIF_TYPE_ID tid; + EIF_OBJECT my_obj; + EIF_INITIALIZE(failure) /* Initialization of Eiffel run-time. + * This is to be done before any CECIL call. + */ + + tid = eif_type_id ("OBJECT"); + if (tid == EIF_NO_TYPE) + eif_panic ("No type id."); + my_obj = eif_create (tid); /* Create eiffel object, returns an indirection. */ + /* some code */ + eif_wean (my_obj); /* We do not need it any more. */ + EIF_DISPOSE_ALL /* Reclaim memory allocated by Eiffel run-time. */ +} + + + +{{note|`eif_create` does not call any creation procedure. It just allocates memory and initializes an object. }} + +===Protecting the objects returned by Eiffel functions.=== + +'''# include "eif_hector. h"''' + + +''' EIF_OBJECT eif_protect (EIF_REFERENCE object)''' + + +This function is used to tell explicitly the GC that you want to keep a reference to an eiffel object from the C. It returns a static indirection pointer which is to be used afterwards to access the direct Eiffel reference object with eif_access (returned_value) where returned_value is the value returned by eif_protect . With this call, the GC artificially references object, so that it cannot collect it. It is unsafe to access directly (i.e without using eif_access) the Eiffel reference object, which may be obsolete after any collection cycle (the GC moves the objects). Ignore this rule, if you are sure that there is no Eiffel call after you pass the direct Eiffel reference to a C function and before you read it. + +To release this artificial reference, call eif_wean (returned_value) + +eif_protect is to be called on an EIF_REFERENCE returned by eif_attribute, eif_string, or the returned value of eif_reference_function. + +See also eif_adopt, eif_create, eif_wean, eif_access. + +'''Example:''' Assume that you want to access an attribute `tab` of type ARRAY [INTEGER] in the class OBJECT. + + +#include eif_setup.h" +#include "eif_eiffel.h" +main (int argc,char **argv,char **envp) +{ + EIF_TYPE_ID tid; + EIF_OBJECT my_obj; + EIF_PROCEDURE emake; /* Creation procedure of "OBJECT". */ + EIF_REFERENCE tab; /* direct reference to `tab' from "OBJECT". */ + EIF_OBJECT i_tab; /* Protected indirection to `tab'. */ + EIF_INITIALIZE(failure) + tid = eif_type_id ("OBJECT"); + if (tid == EIF_NO_TYPE) + eif_panic ("No type Id."); + my_obj = eif_create (tid); + emake = eif_procedure ("make", tid); /* On the eiffel side: make is do ... end.. */ + (emake) (eif_access (my_obj)); /* Call `make' on `eif_access(my_obj)'.*/ + tab = eif_attribute( eif_access (my_obj), "tab", EIF_REFERENCE, NULL); + /* Return the attribute `tab' of type EIF_REFERENCE + * of the object `eif_access (my_obj)'. + */ + i_tab = eif_protect (tab); /* Here, protect `tab'. */ + /* some code */ + eif_wean (my_obj); + eif_wean (i_tab); /* We do not need it any more. */ + EIF_DISPOSE_ALL /* Reclaim memory allocated by Eiffel run-time. */ +} + + + +{{note|Although you must protect Eiffel references returned by eif_attribute, you do not have to protect attributes of basic types - they are not Eiffel references and not supposed to move. }} + +===Getting the type id of an Eiffel type: eif_type_id=== +'''# include "eif_gen_conf. h"''' # include "eif_gen_conf. h" + + +EIF_TYPE_ID eif_type_id (char *type_string) + + +Return the type identifier corresponding to the type described in type_string. If the type does not exist, is not visible or an instance of it is not declared in the root class, it returns EIF_NO_TYPE. + +COMPATIBILITY: +eif_type_id is equivalent to eif_type_by_name. +'''Example:''' type_id of STD_FILES so as to call 'put_string'. + + +EIF_PROCEDURE p_put_string; /* 'put_string' from STD_FILES. */ +EIF_TYPE_ID tid; +EIF_REFERENCE_FUNCTION fn_io; /* once function `io' from ANY (and STD_FILES by inheritance). */ +EIF_REFERENCE o_io; /* Eiffel object `io' returned by once function*/ +EIF_REFERENCE o_str; /* Eiffel string */ +EIF_OBJECT i_io, i_str; /* safe indirection pointers to ``io' and Eiffel string. */ +tid = eif_type_id ("STD_FILES"); +if (tid == EIF_NO_TYPE) + eif_panic ("Type not in system."); +fn_io = eif_reference_function ("io", tid); +o_io = (fn_io) (root_obj); /* `root_obj' is the root object of the CECIL system + * automatically initialized in EIF_INITIALIZED + * if it does not exists */ +i_io = eif_protect (o_io); /* Protect `io' . */ +o_str = eif_string ("Hello World"); /* Create Eiffel string */ +i_str = eif_protect (o_str); /* Protect Eiffel string. */ +p_put_string = eif_procedure ("put_string", tid); +if (p_put_string == (EIF_PROCEDURE) 0) /* No routine found. */ + eif_panic ("put_string not visible"); /* Raised if "visible exception" disabled. */ +(p_put_string) (eif_access (i_io), eif_access (i_str)); + + + +eif_type_id is also used for returning the type identifier of generic types but you need to specify the generic parameter, otherwise it returns EIF_NO_TYPE. + +'''Example:''' + + +EIF_PROCEDURE p_make; /* 'make' from ARRAY [INTEGER] . */ +EIF_TYPE_ID tid; +tid = eif_type_id ("ARRAY[INTEGER]"); +p_make = eif_procedure ("make", tid); + + + +===Getting the type id of a generic type : eif_generic_type.=== +Obsolete: see eif_type_id. +===Raising an eiffel panic: eif_panic.=== +''' # include "eif_except. h"''' + + +void eif_panic(char *msg) + +# include "eif_threads. h" + +void eif_thr_panic (char *msg) + +Raise an Eiffel panic with Eiffel exception trace with message msg. In MT mode, use eif_thr_panic instead. + +===Releasing an Eiffel indirection pointer: eif_wean=== +'''# include "eif_hector. h"''' + + +EIF_REFERENCE eif_wean(EIF_OBJECT object) + + +Tell the GC to remove the artificial reference to the nested Eiffel reference returned by eif_access (object). Then, the GC will be able to collect this nested object, as soon as it is not referenced from Eiffel any longer. + +{{note|Object must have been previously created with eif_adopt, eif_protect or eif_create. }} +eif_wean (object) returns an Eiffel reference, which corresponds to eif_access (object). After a call to eif_wean (object), eif_access (object) is NULL, which does not mean that the nested Eiffel object is Void, but that the indirection pointer does not reference it any longer. It is possible to reuse object later on.
+Calling eif_wean (external_argument) where external_argument is an Eiffel object given by a C external can cause erratic behaviors. Indeed, external_argument is an indirection pointer, which is automatically deleted after the external call (not the nested Eiffel object), deleting it prematurely can corrupt the indirection pointers stack.
+See also eif_access. +'''Example:''' C external returning an Eiffel string. + +In Eiffel: + + foo : STRING + external + "C | %"a file.h%"" + end + + +In C: + +EIF_REFERENCE foo () { + EIF_REFERENCE str; + EIF_OBJECT i_str; + str = eif_string ("Hello world"); + i_str = eif_protect(str); + /* Some operations on `i_str' */ + return eif_wean (i_str); /* Returns direct reference to the Eiffel string. + * No need to keep an extra reference from the C. */ +} + + +===Getting the attribute from an Eiffel object: eif_attribute=== + +``` +# include "eif_cecil. h" + +EIFFEL_TYPE eif_attribute (EIF_REFERENCE object, char *name, EIFFEL_TYPE, int *status) +``` + +Return the attribute of an Eiffel object. + +The `eif_attribute` macro returns the attribute of object of name, which is of type EIFFEL_TYPE. + +EIFFEL_TYPE is the type of the Eiffel attribute. It can be: EIF_INTEGER, EIF_POINTER, EIF_CHARACTER, EIF_BOOLEAN, EIF_DOUBLE, EIF_REAL or EIF_REFERENCE. + +If status is NULL then no status is set. Otherwise the status of the function is put in *status: +*status = EIF_NO_ATTRIBUTE => no attribute found. +*status = EIF_CECIL_OK => attribute found. +*status = EIF_CECIL_ERROR => an undefined error occurred, object may be invalid. + +If the visible exception is enabled, then a visible exception is raised upon failure (EIF_NO_ATTRIBUTE, EIF_CECIL_ERROR). + +RETURN VALUE: +Upon failure, it returns (EIFFEL_TYPE) 0, otherwise, the attribute is returned. If the return value is not a basic type, you must protect it with eif_protect. + +COMPATIBILITY: +`eif_attribute (object, name, type, NULL)` is equivalent to `eif_field (object, name, type)`. + +{{tip|You cannot access a constant attribute, or the result of a function (once or not) with eif_attribute. Use eif_procedure or eif_xx_function instead. }} +
+{{tip|EIF_BOOLEAN attribute_exists (EIF_REFERENCE object, char *name) returns EIF_TRUE or EIF_FALSE depending if the attribute exists or not, is visible or not. }} + +===Getting the address of an Eiffel routine=== +``` +#include "eif_cecil. h" + +EIF_PROCEDURE eif_procedure (char *rout_name, EIF_TYPE_ID type_id) +EIF_REFERENCE_FUNCTION eif_reference_function (char *rout_name, EIF_TYPE_ID type_id) +EIF_INTEGER_FUNCTION eif_integer_function (char *rout_name, EIF_TYPE_ID type_id) +EIF_CHARACTER_FUNCTION eif_character_function (char *rout_name, EIF_TYPE_ID type_id) +EIF_REAL_FUNCTION eif_real_function (char *rout_name, EIF_TYPE_ID type_id) +EIF_DOUBLE_FUNCTION eif_double_function (char *rput_name, EIF_TYPE_ID type_id) +EIF_BIT_FUNCTION eif_bit_function (char *rout_name, EIF_TYPE_ID type_id) +EIF_BOOLEAN_FUNCTION eif_boolean_function (char *rout_name, EIF_TYPE_ID type_id) +EIF_POINTER_FUNCTION eif_pointer_function (char *rout_name, EIF_TYPE_ID type_id) +``` + +Return the address of the Eiffel routine by giving its name rout_name and the type id type_id of the class, in which it is declared. Returns a NULL pointer or raises a visible exception (if enabled) when there is no corresponding routine with name rout_name or the routine is not visible. The first argument of an Eiffel routine has to be the target of the Eiffel routine. + +The Eiffel object returned by an Eiffel function must be protected afterwards with `eif_protect` (this only applies for functions whose addresses are returned by `eif_reference_function`, since the other function types returns basic types, which are not Eiffel objects). + +{{note|The address returned by these functions must be called between parenthesis. }} + +{{caution|Be sure that the Eiffel routine is not a C External. In this case, you should call directly the C external instead of its Eiffel wrapper. }} + +===Enabling/Disabling the visible exception=== +``` +#include "eif_cecil. h" + +void eif_enable_visible_exception () +void eif_disable_visible_exception () +``` + +Respectively, enable and disable the visible exception. + +By default, the visible exception is disabled (since v4. 5). + +===Creating an Eiffel string: eif_string=== +``` +#include "eif_plug. h" + +EIF_REFERENCE eif_string (char *string) /* Macro */ +``` + +Return the direct reference to an Eiffel string by giving the corresponding C string . The result of eif_string does not reference the C string passed as argument: it copies it, before creating the Eiffel string. + +{{note|The return value must be protected with eif_protect for later use.
The C string must be manually freed by the user, if it has been dynamically allocated. }} + +COMPATIBILITY: + +`eif_string ("ABC")` is equivalent to `RTMS ("ABC")` and `eif_make_string ("ABC", strlen ("ABC"))`. + +===Getting the return-type of an attribute: eif_attribute_type=== +``` +#include "eif_cecil. h" + +int eif_attribute_type (char *attr_name, EIF_TYPE_ID tid) + +#define EIF_REFERENCE_TYPE 1 +#define EIF_CHARACTER_TYPE 2 +#define EIF_BOOLEAN_TYPE 3 +#define EIF_INTEGER_TYPE 4 +#define EIF_REAL_TYPE 5 +#define EIF_DOUBLE_TYPE 6 +#define EIF_EXPANDED_TYPE 7 +#define EIF_BIT_TYPE 8 +#define EIF_POINTER_TYPE 0 +#define EIF_NO_TYPE (-1) +``` + +Return the type of the attribute described by its name attr_name and the type identifier tid of the class where it is defined. The return type is an int (see above for correspondences). In case of failure, EIF_NO_TYPE is returned - not such given attribute name, routine name instead of attribute name, or so on. + +'''Example:''' Get the type of count from STRING + + +int i; +i = eif_attribute_type ("count", eif_type_id ("STRING"); +printf ("type is %d\n"); /* Should be EIF_INTEGER_TYPE since it returns an Eiffel Integer */ + + + +{{tip|*(EIFFEL_TYPE *) eif_attribute_safe (EIF_REFERENCE object, char *name, int type_int, int *status) can be used for debugging or type checking. It returns the attribute reference of name from the object of type type_int. status contains the status of the function call: it can be EIF_CECIL_OK, EIF_CECIL_ERROR, EIF_NO_ATTRIBUTE or EIF_WRONG_TYPE (type_int does not match with real type of object). }} + +===Getting the class name corresponding to a type id: eif_name=== +``` +#include "eif_cecil. h" + +char *eif_name (EIF_TYPE_ID tid) +``` + +Return the corresponding name (C string) of the Eiffel class, given a type identifier type_id. If the type identifier is a generic type identifier, no generic parameter type is given. Return NULL if an invalid type identifier is given. + +'''Example:''' + +`printf ("the class name with type id 1 is %s\n", eif_name (1); /* Should print "ANY" on most compiler versions */` + +COMPATIBILITY: + +`eif_name` is equivalent to `eif_name_by_tid`. + +===Getting the type id of an Eiffel object: eif_type, eif_type_by_reference.=== +``` +#include "eif_cecil. h" + + +EIF_TYPE_ID eif_type (EIF_OBJECT object) + +EIF_TYPE_ID eif_type_by_reference (EIF_REFERENCE reference) +``` + +`eif_type` returns the type identifier, given an indirection pointer to an Eiffel object. + +`eif_type_by_reference` returns the type identifier, given the direct reference to an Eiffel object reference. + +COMPATIBILITY: +`eif_type` is equivalent to `eif_type_by_object.eif_type (object)` is equivalent to `eif_type_by_reference (eif_access (object))`. + +===Converting a C array into an Eiffel array: eif_make_from_c.=== +``` +eif_make_from_c(eif_array, c_array, int nelts, int type) /* Macro */ +``` +(since 4. 5) + + +`eif_array` is an `EIF_REFERENCE`, `c_array` is a C array of type `(type *)`, `nelts is the number of elements in the array. + diff --git a/documentation/18.11/solutions/other-languages/cecil/cecil-reference/attribute-exists.wiki b/documentation/18.11/solutions/other-languages/cecil/cecil-reference/attribute-exists.wiki new file mode 100644 index 00000000..5b5f78f0 --- /dev/null +++ b/documentation/18.11/solutions/other-languages/cecil/cecil-reference/attribute-exists.wiki @@ -0,0 +1,24 @@ +[[Property:title|attribute_exists]] +[[Property:weight|-15]] +[[Property:uuid|7cdf93a7-6f63-869a-5443-b8908a086d18]] +==Overview== + +#include "eif_cecil.h" + +EIF_BOOLEAN attribute_exists (EIF_REFERENCE object, char * name); + + +==Description== +The attribute_exists() macro returns EIF_TRUE when the attribute of name name exists in the Eiffel object (reference) object. +==Return value== +EIF_TRUE or EIF_FALSE. +==Conformance== +ISE Eiffel 4.5 and later. + + +{{SeeAlso|
+[[eif_attribute]] }} + + + + diff --git a/documentation/18.11/solutions/other-languages/cecil/cecil-reference/eif-access.wiki b/documentation/18.11/solutions/other-languages/cecil/cecil-reference/eif-access.wiki new file mode 100644 index 00000000..25374076 --- /dev/null +++ b/documentation/18.11/solutions/other-languages/cecil/cecil-reference/eif-access.wiki @@ -0,0 +1,28 @@ +[[Property:title|eif_access]] +[[Property:weight|-14]] +[[Property:uuid|2f74eeb4-2508-bf32-adf2-87959cfb2593]] +==Synopsis== + +#include "eif_hector.h" + +EIF_REFERENCE eif_access (EIF_OBJECT obj); + + +==Description== +The eif_access macro accesses the Eiffel object obj. + +==Return value== +The Eiffel reference (EIF_REFERENCE) protected by obj which can be passed to Eiffel routines. + +==Conformance== +ISE Eiffel 4.1 and later. + + +{{SeeAlso|
+[[eif_wean]]
+[[eif_adopt]]
+[[eif_protect]] }} + + + + diff --git a/documentation/18.11/solutions/other-languages/cecil/cecil-reference/eif-adopt.wiki b/documentation/18.11/solutions/other-languages/cecil/cecil-reference/eif-adopt.wiki new file mode 100644 index 00000000..4933b1c4 --- /dev/null +++ b/documentation/18.11/solutions/other-languages/cecil/cecil-reference/eif-adopt.wiki @@ -0,0 +1,28 @@ +[[Property:title|eif_adopt]] +[[Property:weight|-13]] +[[Property:uuid|dc8ef8a9-7082-2a27-4e45-8f1d4472dbda]] +==Synopsis== + +#include "eif_hector.h" + +EIF_OBJECT eif_adopt (EIF_OBJECT obj); + + +==Description== +The eif_adopt function adopts obj. By adopting it, the user prevents obj from being unprotected automatically by the Eiffel run-time. The run-time protects automatically the Eiffel objects passed to a C external before entering the external and unprotects them after exiting the C external. To keep this protection later on, you must call eif_adopt. + +==Return value== +An EIF_OBJECT. This return value can be used later to access the nested, protected Eiffel reference with [[eif_access]]. + +==Conformance== +ISE Eiffel 4.1 and later. + + +{{SeeAlso|
+[[eif_access]]
+[[eif_protect]]
+[[eif_wean]] }} + + + + diff --git a/documentation/18.11/solutions/other-languages/cecil/cecil-reference/eif-attribute-type.wiki b/documentation/18.11/solutions/other-languages/cecil/cecil-reference/eif-attribute-type.wiki new file mode 100644 index 00000000..f5450227 --- /dev/null +++ b/documentation/18.11/solutions/other-languages/cecil/cecil-reference/eif-attribute-type.wiki @@ -0,0 +1,39 @@ +[[Property:title|eif_attribute_type]] +[[Property:weight|-11]] +[[Property:uuid|28b3840f-648f-dc4d-8c83-70532a5e8e63]] +==Synopsis== + +#include "eif_cecil.h" + +int eif_attribute_type (char *attr, EIF_TYPE_ID tid); + + +==Description== +The eif_attribute_type function returns the type of the attribute attr, from the Eiffel type, which type identifier is tid. + +==Return value== + +Sucessful: One of the following: +# EIF_INTEGER_TYPE +# EIF_CHARACTER_TYPE +# EIF_BOOLEAN_TYPE +# EIF_DOUBLE_TYPE +# EIF_REAL_TYPE +# EIF_REFERENCE_TYPE +# EIF_EXPANDED_TYPE +# EIF_BIT_TYPE + +Failing: EIF_NO_TYPE + +==Conformance== +ISE Eiffel 4.5 and later. + +{{SeeAlso|
+[[eif_protect]]
+[[attribute_exists]]
+[[eif_procedure]]
+[[eif_*_function]] }} + + + + diff --git a/documentation/18.11/solutions/other-languages/cecil/cecil-reference/eif-attribute.wiki b/documentation/18.11/solutions/other-languages/cecil/cecil-reference/eif-attribute.wiki new file mode 100644 index 00000000..0e3a4d15 --- /dev/null +++ b/documentation/18.11/solutions/other-languages/cecil/cecil-reference/eif-attribute.wiki @@ -0,0 +1,62 @@ +[[Property:title|eif_attribute]] +[[Property:weight|-12]] +[[Property:uuid|c843f272-8ac2-c30e-e71f-bd6c567e9de3]] +==Synopsis== + +#include "eif_cecil.h" + +EIFFEL_TYPE eif_attribute (EIF_REFERENCE object, char * name, EIFFEL_TYPE, int * status); + + +==Description== +The eif_attribute macro returns the attribute of name name, which is of type EIFFEL_TYPE. +EIFFEL_TYPE is the type of the Eiffel attribute. It can be one of the following: +# EIF_INTEGER +# EIF_CHARACTER +# EIF_BOOLEAN +# EIF_DOUBLE +# EIF_REAL +# EIF_REFERENCE + +If status is NULL then no status is set. Otherwise the status of the call is put into *status. Its value is one of the following: +# EIF_NO_ATTRIBUTE +# EIF_CECIL_OK + +If the visible exception is enabled, then a visible exception is raised upon failure (EIF_NO_ATTRIBUTE, EIF_CECIL_ERROR). + +==Return value== + +Successful: the Eiffel attribute. + +Failing: (EIFFEL_TYPE) 0 + +==Notes== + +If the return value is an EIF_REFERENCE, you must protect it with [[eif_protect]]. + +You cannot access a constant attribute, or the result of a once function with eif_attribute. + +==Conformance== + +ISE Eiffel 4.5 and later. + +==Compatibility== + +eif_attribute (object, name, type, NULL) + +is equivalent to: + +eif_field (object, name, type) + +which is deprecated. + + +{{SeeAlso|
+[[eif_protect]]
+[[attribute_exists]]
+[[eif_procedure]]
+[[eif_*_function]] }} + + + + diff --git a/documentation/18.11/solutions/other-languages/cecil/cecil-reference/eif-create.wiki b/documentation/18.11/solutions/other-languages/cecil/cecil-reference/eif-create.wiki new file mode 100644 index 00000000..bf55d814 --- /dev/null +++ b/documentation/18.11/solutions/other-languages/cecil/cecil-reference/eif-create.wiki @@ -0,0 +1,30 @@ +[[Property:title|eif_create]] +[[Property:weight|-7]] +[[Property:uuid|b928f4b9-2830-5723-6f02-57eac618b116]] +==Synopsis== + +#include "eif_cecil. h" + +EIF_OBJECT eif_create (EIF_TYPE_ID tid); + + +==Description== +The eif_create function creates an Eiffel object, which type identifier is tid. +==Return value== +It returns an Eiffel object, which is already protected. +==Notes== +You cannot pass the return value to Eiffel routines as is: you must call [[eif_access]] to pass it to Eiffel routine. + +To release the protection of an Eiffel object created with eif_create, call [[eif_wean]]. It will be collected during the next collection. + +==Conformance== + +ISE Eiffel 4.1 and later. + + +{{SeeAlso|
+[[eif_wean]]
+[[eif_type_id]] }} + + + diff --git a/documentation/18.11/solutions/other-languages/cecil/cecil-reference/eif-disable-visible-exception.wiki b/documentation/18.11/solutions/other-languages/cecil/cecil-reference/eif-disable-visible-exception.wiki new file mode 100644 index 00000000..e77da72f --- /dev/null +++ b/documentation/18.11/solutions/other-languages/cecil/cecil-reference/eif-disable-visible-exception.wiki @@ -0,0 +1,32 @@ +[[Property:title|eif_disable_visible_exception]] +[[Property:weight|-6]] +[[Property:uuid|6b8323d9-1963-c6b8-0198-f07895916c46]] +==Synopsis== + +#include "eif_cecil.h" + +void eif_enable_visible_exception (); +void eif_disable_visible_exception (); + + +==Description== +The [[eif_enable_visible_exception]] routine enables the visible exception, while [[eif_disable_visible_exception]] disables it. These routines can be used for debugging purpose. A visible exception is raised when the user tries to access to an Eiffel attribute or a Eiffel routine address which is not visible. + +The visible exception is disabled by default. + +==Conformance== + +ISE Eiffel 4.5 and later. + +==Compatibility== + +In ISE Eiffel 4.3 and 4.4, the visible exception is enabled by default. + + +{{SeeAlso|
+[[eif_attribute]]
+[[eif_procedure]]
+[[eif_*_function]] }} + + + diff --git a/documentation/18.11/solutions/other-languages/cecil/cecil-reference/eif-enable-visible-exception.wiki b/documentation/18.11/solutions/other-languages/cecil/cecil-reference/eif-enable-visible-exception.wiki new file mode 100644 index 00000000..386b3a6b --- /dev/null +++ b/documentation/18.11/solutions/other-languages/cecil/cecil-reference/eif-enable-visible-exception.wiki @@ -0,0 +1,33 @@ +[[Property:title|eif_enable_visible_exception]] +[[Property:weight|-4]] +[[Property:uuid|97b5a74c-d7ad-abf4-9390-59266b67c7c7]] +==Synopsis== + +#include "eif_cecil.h" + +void eif_enable_visible_exception (); +void eif_disable_visible_exception (); + + +==Description== +The [[eif_enable_visible_exception]] routine enables the visible exception, while [[eif_disable_visible_exception]] disables it. These routines can be used for debugging purpose. A visible exception is raised when the user tries to access to an Eiffel attribute or a Eiffel routine address which is not visible. + +The visible exception is disabled by default. + +==Conformance== + +ISE Eiffel 4.5 and later. + +==Compatibility== + +In ISE Eiffel 4.3 and 4.4, the visible exception is enabled by default. + + +{{SeeAlso|
+[[eif_attribute]]
+[[eif_procedure]]
+[[eif_*_function]] }} + + + + diff --git a/documentation/18.11/solutions/other-languages/cecil/cecil-reference/eif-function.wiki b/documentation/18.11/solutions/other-languages/cecil/cecil-reference/eif-function.wiki new file mode 100644 index 00000000..06ef73b4 --- /dev/null +++ b/documentation/18.11/solutions/other-languages/cecil/cecil-reference/eif-function.wiki @@ -0,0 +1,125 @@ +[[Property:title|eif_*_function]] +[[Property:weight|15]] +[[Property:uuid|643603a5-de12-1ffc-2da3-92c8475078e8]] +==Overview== + +This page documents all CECIL functions of the form eif_*_function where "*" is a supported type such as "integer", "bit", "character", "real", etc. + + +==Synopsis== + +#include "eif_cecil.h" + +EIF_REFERENCE_FUNCTION eif_reference_function (char * name, int * tid); + +EIF_INTEGER_FUNCTION eif_integer_function (char * name, int * tid); + +EIF_CHARACTER_FUNCTION eif_character_function (char * name, int * tid); + +EIF_REAL_FUNCTION eif_real_function (char * name, int * tid); + +EIF_DOUBLE_FUNCTION eif_double_function (char * name, int * tid); + +EIF_BOOLEAN_FUNCTION eif_boolean_function (char * name, int * tid); + +EIF_POINTER_FUNCTION eif_pointer_function (char * name, int * tid); + +EIF_BIT_FUNCTION eif_bit_function (char * name, int * tid); + + +==Description== + +These functions return the address of the Eiffel function of name name from the class, which type identifier is tid. + +{| border="1" +! Use this function !! For an Eiffel function returning +|- +| eif_reference_function +| Eiffel reference +|- +| eif_integer_function +| Eiffel integer +|- +| eif_character_function +| Eiffel character +|- +| eif_real_function +| Eiffel real +|- +| eif_double_function +| Eiffel double +|- +| eif_boolean_function +| Eiffel boolean +|- +| eif_pointer_function +| Eiffel pointer +|- +| eif_bit_function +| Eiffel bit +|} + + +If the visible exception is enabled, it raises an visible exception upon failure. + +==Return value== + +Successful: The address of the function. + +Failing: NULL (function does not exist or is not visible). + +==Notes== + +The Eiffel function cannot be a C external. In this case, you must directly call the C routine. + +The return value is an address: to use it as a routine, you must call it with arguments or at least with (). + +No argument type checking is done. You may cast the address of an Eiffel routine, obtained with these functions, when calling it with real arguments. + +If the function returns an Eiffel reference, you must protect it with [[eif_protect]]. + +==Conformance== +ISE Eiffel 4.4 and later. + +==Compatibility== + +Compatibility with deprecated functions is shown in this table. + + +{| border="1" +! Function name !! Equivalent deprecated function name +|- +| eif_reference_function +| eif_fn_ref +|- +| eif_integer_function +| eif_fn_int +|- +| eif_real_function +| eif_fn_float +|- +| eif_double_function +| eif_fn_double +|- +| eif_character_function +| eif_fn_char +|- +| eif_bit_function +| eif_fn_bit +|- +| eif_boolean_function +| eif_fn_bool +|- +| eif_pointer_function +| eif_fn_pointer +|} + + +{{SeeAlso|
+[[eif_type_id]]
+[[eif_protect]]
+[[eif_procedure]] }} + + + + diff --git a/documentation/18.11/solutions/other-languages/cecil/cecil-reference/eif-name-tid.wiki b/documentation/18.11/solutions/other-languages/cecil/cecil-reference/eif-name-tid.wiki new file mode 100644 index 00000000..15f973f0 --- /dev/null +++ b/documentation/18.11/solutions/other-languages/cecil/cecil-reference/eif-name-tid.wiki @@ -0,0 +1,35 @@ +[[Property:title|eif_name_by_tid]] +[[Property:weight|-1]] +[[Property:uuid|7ae34f4d-5eaf-0703-29f7-54dc4f0fd49d]] +==Synopsis== + + +#include "eif_cecil.h" + +char *eif_name_by_tid (EIF_TYPE_ID tid); + + +==Description== + +The eif_name_by_tid function returns the name of the class corresponding to tid. + +==Return value== + +A statically allocated C string which is the name of the class. If tid is invalid, it returns NULL. + +==Conformance== + +ISE Eiffel 4.4 and later. + +==Compatibility== + +[[eif_name_by_tid]] is equivalent to [[eif_name]]. + + +{{SeeAlso|
+[[eif_type]]
+[[eif_type_by_reference]]
+[[eif_type_id]] }} + + + diff --git a/documentation/18.11/solutions/other-languages/cecil/cecil-reference/eif-name.wiki b/documentation/18.11/solutions/other-languages/cecil/cecil-reference/eif-name.wiki new file mode 100644 index 00000000..1be441bc --- /dev/null +++ b/documentation/18.11/solutions/other-languages/cecil/cecil-reference/eif-name.wiki @@ -0,0 +1,35 @@ +[[Property:title|eif_name]] +[[Property:weight|-2]] +[[Property:uuid|2921b2ef-1f59-cd26-df50-5cb946eae84c]] +==Synopsis== + +#include "eif_cecil.h" + +char *eif_name (EIF_TYPE_ID tid); + + +==Description== + +The eif_name function returns the name of the class corresponding to tid. + +==Return value== + +A statically allocated C string which is the name of the class. If tid is invalid, it returns NULL. + +==Conformance== + +ISE Eiffel 4.4 and later. + +==Compatibility== + +[[eif_name]] is equivalent to [[eif_name_by_tid]]. + + +{{SeeAlso|
+[[eif_type]]
+[[eif_type_by_reference]]
+[[eif_type_id]] }} + + + + diff --git a/documentation/18.11/solutions/other-languages/cecil/cecil-reference/eif-procedure.wiki b/documentation/18.11/solutions/other-languages/cecil/cecil-reference/eif-procedure.wiki new file mode 100644 index 00000000..168ff880 --- /dev/null +++ b/documentation/18.11/solutions/other-languages/cecil/cecil-reference/eif-procedure.wiki @@ -0,0 +1,47 @@ +[[Property:title|eif_procedure]] +[[Property:weight|1]] +[[Property:uuid|3937f124-fffa-3244-d2e4-46ccfcec5fa8]] +==Synopsis== + + +#include "eif_cecil.h" + +EIF_PROCEDURE eif_procedure (char * name, int * tid); + + +==Description== + +The eif_procedure function returns the address of the Eiffel procedure of name name from the class, which type identifier is tid. + +If the visible exception is enabled, it raises an visible exception upon failure. + +==Return value== + +Successful: Address of the procedure. +Failing: NULL. (The procedure does not exist or is not visible). + +Otherwise, the address of the procedure is returned. + +==Notes== + +The Eiffel procedure cannot be a C external. In this case, you must directly call the C routine. + +The return value is an address: to use it as a routine, you must call it with arguments or at least with (). + +No argument type checking is done. You may cast the address of an Eiffel routine obtained with eif_procedure when calling it with real arguments. + +==Conformance== + +ISE Eiffel 4.4 and later. + +==Compatibility== + +eif_procedure is equivalent to eif_proc, which is deprecated. + + +{{SeeAlso|
+[[eif_type_id]]
+[[eif_*_function]] }} + + + diff --git a/documentation/18.11/solutions/other-languages/cecil/cecil-reference/eif-protect.wiki b/documentation/18.11/solutions/other-languages/cecil/cecil-reference/eif-protect.wiki new file mode 100644 index 00000000..3a3ca453 --- /dev/null +++ b/documentation/18.11/solutions/other-languages/cecil/cecil-reference/eif-protect.wiki @@ -0,0 +1,36 @@ +[[Property:title|eif_protect]] +[[Property:weight|2]] +[[Property:uuid|f335a229-93c4-4f3f-6fca-9c4c190745c4]] +==Synopsis== + + +#include "eif_hector.h" + +EIF_OBJECT eif_protect (EIF_REFERENCE ref); + + +==Description== + +The eif_protect function protects the Eiffel reference ref from the garbage collector. It keeps a reference on it so that the garbage collector does not collect it if it is not referenced from Eiffel any longer. + +==Return value== + +The eif_protect function returns an EIF_OBJECT. This EIF_OBJECT can be used later on to access ref with [[eif_access]]. + +==Conformance== + +ISE Eiffel 4.4 and later. + +==Compatibility== + +eif_protect is equivalent to henter, which is deprecated. + + +{{SeeAlso|
+[[eif_access]]
+[[eif_adopt]]
+[[eif_wean]] }} + + + + diff --git a/documentation/18.11/solutions/other-languages/cecil/cecil-reference/eif-string.wiki b/documentation/18.11/solutions/other-languages/cecil/cecil-reference/eif-string.wiki new file mode 100644 index 00000000..411ec896 --- /dev/null +++ b/documentation/18.11/solutions/other-languages/cecil/cecil-reference/eif-string.wiki @@ -0,0 +1,37 @@ +[[Property:title|eif_string]] +[[Property:weight|5]] +[[Property:uuid|d203c941-df82-495a-55f3-791652b0e9ef]] +==Synopsis== + + +#include "eif_plug.h" + +EIF_REFERENCE eif_string (char * string); + + +==Description== + +The eif_string macro returns an Eiffel string corresponding to the C string string. + +The return value does not reference string. + +==Notes== + +This function return an Eiffel reference, which must be protected with [[eif_protect]]. + +==Conformance== + +ISE Eiffel 4.5 and later. + +==Compatibility== + +eif_string is equivalent to RTMS, which is deprecated. + + +{{SeeAlso|
+[[eif_protect]]
+[[eif_create]] }} + + + + diff --git a/documentation/18.11/solutions/other-languages/cecil/cecil-reference/eif-type-id.wiki b/documentation/18.11/solutions/other-languages/cecil/cecil-reference/eif-type-id.wiki new file mode 100644 index 00000000..e7ab31a8 --- /dev/null +++ b/documentation/18.11/solutions/other-languages/cecil/cecil-reference/eif-type-id.wiki @@ -0,0 +1,45 @@ +[[Property:title|eif_type_id]] +[[Property:weight|9]] +[[Property:uuid|248182c3-5e89-4adc-097f-f03cb934eb63]] +==Synopsis== + + +#include "eif_gen_conf.h" + +EIF_TYPE_ID eif_type_id (char * type); + + +==Description== + +The eif_type_id function returns the type identifier corresponding to type, which is the name of the type. + +==Return value== + +The type identifier of type. + +==Notes== + +An error cannot be caught by a visible exception. + +The type is not necessary visible. + +==Conformance== + +ISE Eiffel 4.3 and later. + +==Compatibility== + +eif_type_id is equivalent to [[eif_type_by_name]]. + +With ISE Eiffel 4.2 and earlier, use eif_generic_type for generic types. + + +{{SeeAlso|
+[[eif_*_function]]
+[[eif_procedure]]
+[[eif_type]]
+[[eif_name]] }} + + + + diff --git a/documentation/18.11/solutions/other-languages/cecil/cecil-reference/eif-type-name.wiki b/documentation/18.11/solutions/other-languages/cecil/cecil-reference/eif-type-name.wiki new file mode 100644 index 00000000..fe5f795b --- /dev/null +++ b/documentation/18.11/solutions/other-languages/cecil/cecil-reference/eif-type-name.wiki @@ -0,0 +1,43 @@ +[[Property:title|eif_type_by_name]] +[[Property:weight|7]] +[[Property:uuid|51549b56-757c-f91f-6d27-5784a12181ac]] +==Synopsis== + + +#include "eif_gen_conf.h" + +EIF_TYPE_ID eif_type_by_name (char * type); + + +==Description== + +The eif_type_by_name function returns the type identifier corresponding to type, which is the name of the type. + +==Return value== + +The eif_type_by_name function returns the type. + +==Notes== + +An error cannot be caught by a visible exception. + +The type is not necessary visible. + +==Conformance== + +ISE Eiffel 4.3 and later. + +==Compatibility== + +eif_type_by_name is equivalent to [[eif_type_id]]. + + +{{SeeAlso|
+[[eif_*_function]]
+[[eif_procedure]]
+[[eif_type]]
+[[eif_name]] }} + + + + diff --git a/documentation/18.11/solutions/other-languages/cecil/cecil-reference/eif-type-reference.wiki b/documentation/18.11/solutions/other-languages/cecil/cecil-reference/eif-type-reference.wiki new file mode 100644 index 00000000..44572d11 --- /dev/null +++ b/documentation/18.11/solutions/other-languages/cecil/cecil-reference/eif-type-reference.wiki @@ -0,0 +1,33 @@ +[[Property:title|eif_type_by_reference]] +[[Property:weight|8]] +[[Property:uuid|1258584a-0aae-3246-0553-98817deda6e0]] +==Synopsis== + + +#include "eif_cecil.h" + +EIF_TYPE_ID eif_type_by_reference (EIF_REFERENCE reference); + + +==Description== + +The eif_type_by_reference function returns the type identifier corresponding to reference. + +==Return value== + +Type identifier of reference. + +The behavior is unpredictable if reference is not a valid Eiffel reference. + +==Conformance== + +ISE Eiffel 4.5 and later. + + +{{SeeAlso|
+[[eif_type]]
+[[eif_name]]
+[[eif_type_id]] }} + + + diff --git a/documentation/18.11/solutions/other-languages/cecil/cecil-reference/eif-type.wiki b/documentation/18.11/solutions/other-languages/cecil/cecil-reference/eif-type.wiki new file mode 100644 index 00000000..bc89a5ed --- /dev/null +++ b/documentation/18.11/solutions/other-languages/cecil/cecil-reference/eif-type.wiki @@ -0,0 +1,35 @@ +[[Property:title|eif_type]] +[[Property:weight|6]] +[[Property:uuid|8c200b03-cae1-bbcd-98b0-1767402744be]] +==Synopsis== + + +#include "eif_cecil.h" + +EIF_TYPE_ID eif_type (EIF_OBJECT object); + + +==Description== + +The eif_type function returns the type identifier corresponding to object. + +==Return value== + +Type identifier of object. The behavior is unpredictable if object is not a valid Eiffel object. + +==Conformance== + +ISE Eiffel 4.3 and later. + +==Compatibility== + +eif_type(object) is equivalent to eif_type_by_reference(eif_access(object)). + + +{{SeeAlso|
+[[eif_type_by_reference]]
+[[eif_type_id]] }} + + + + diff --git a/documentation/18.11/solutions/other-languages/cecil/cecil-reference/eif-wean.wiki b/documentation/18.11/solutions/other-languages/cecil/cecil-reference/eif-wean.wiki new file mode 100644 index 00000000..8e9a929e --- /dev/null +++ b/documentation/18.11/solutions/other-languages/cecil/cecil-reference/eif-wean.wiki @@ -0,0 +1,32 @@ +[[Property:title|eif_wean]] +[[Property:weight|10]] +[[Property:uuid|d94fdbce-8cbd-7714-ebfc-38e1f0526eaa]] +==Synopsis== + + +#include "eif_hector.h" + +EIF_REFERENCE eif_wean (EIF_OBJECT obj); + + +==Description== + +The eif_wean function releases the protection of the Eiffel reference, which is protected by the Eiffel object obj. + +==Return value== + +The Eiffel reference previously protected by obj. + +==Conformance== + +ISE Eiffel 4.1 and later. + + +{{SeeAlso|
+[[eif_access]]
+[[eif_adopt]]
+[[eif_protect]] }} + + + + diff --git a/documentation/18.11/solutions/other-languages/cecil/cecil-reference/index.wiki b/documentation/18.11/solutions/other-languages/cecil/cecil-reference/index.wiki new file mode 100644 index 00000000..2e13ce2c --- /dev/null +++ b/documentation/18.11/solutions/other-languages/cecil/cecil-reference/index.wiki @@ -0,0 +1,5 @@ +[[Property:title|CECIL Reference]] +[[Property:weight|4]] +[[Property:uuid|20ca6ef1-0d26-a556-955c-96bed93dfdfb]] +References for CECIL features + diff --git a/documentation/18.11/solutions/other-languages/cecil/cecil-samples/cecil-basic-sample.wiki b/documentation/18.11/solutions/other-languages/cecil/cecil-samples/cecil-basic-sample.wiki new file mode 100644 index 00000000..3ce6d43a --- /dev/null +++ b/documentation/18.11/solutions/other-languages/cecil/cecil-samples/cecil-basic-sample.wiki @@ -0,0 +1,76 @@ +[[Property:title|CECIL - Basic sample]] +[[Property:weight|2]] +[[Property:uuid|ed699d37-f480-0cef-817f-9f4a857c1691]] +==cecil-test== + +After you have done the appropriate steps to compile the example, you will get a `cecil.exe` on windows, or `cecil` on Unix. + +This example performs some basic tests of CECIL from C to Eiffel and Eiffel to C. You can: +* choose to raise an exception when a routine is not visible +* create an Eiffel string +* choose to raise a precondition violation from C. + + + +A typical output will be: + +$ cecil +Do you want to enable the visible exception? (y-yes, n-no):n +Disable visible exception + +====== In eiffel_call ====== + Eiffel type id = 9 + Eiffel procedure make 0x100546b4 + Eiffel object = 0x30068030 +Testing linked_list... +12345 +test_linked_list OK +Testing memory... +Give string length (enter a high number for raising an Eiffel exception) +234 +Memory OK +Testing if string void ... +Enter a string: (press enter if you want to raise an Eiffel exception) +wefsd +wefsdTesting precondition...By default it is true + +====== Done ====== + +====== In eiffel_call ====== + Eiffel type id = 9 + Eiffel procedure test_linked_list 0x10054ebc + Eiffel object = 0x30068030 +Testing linked_list... +12345 +test_linked_list OK + +====== Done ====== + +====== In eiffel_call_1_arg ====== + Eiffel type id = 9 + Eiffel procedure print 0x1004e0a8 + Eiffel object = 0x30068030 + Eiffel object = 0x30068030 +Execute the Eiffel code `print (linked_list)' from the C side: +MAIN [0x30068030] + linked_list: LINKED_LIST [0x30068C40] + +====== Done ====== + +====== In cecil_test ====== + protected indirection of 30068c40 is 300311bc + Eiffel type id of STRING = 198 + Eiffel type id of LINKED_LIST [STRING] = 224 + Linked List forth: 10222fbc + Linked list object = 0x30068c40 +Do you want to test the visibility of an Eiffel routine? (y-yes, n-no): +n +Do you want raise a precondition violation? (y-yes, n-no): +n + +====== Done ====== + + + + + diff --git a/documentation/18.11/solutions/other-languages/cecil/cecil-samples/cecil-c-eiffel.wiki b/documentation/18.11/solutions/other-languages/cecil/cecil-samples/cecil-c-eiffel.wiki new file mode 100644 index 00000000..075b365a --- /dev/null +++ b/documentation/18.11/solutions/other-languages/cecil/cecil-samples/cecil-c-eiffel.wiki @@ -0,0 +1,46 @@ +[[Property:title|CECIL - C to Eiffel]] +[[Property:weight|0]] +[[Property:uuid|c3b64ef2-28b2-920e-44fb-4cff2320c099]] +==array== +This example shows how to create an Eiffel array from an existing C array. After you have done the appropriate steps to compile the example, you will get a `cecil.exe` on windows, or `cecil` on Unix. Launch the program and you will be prompted for 10 integers that will be inserted in a C array, it will then initialize the Eiffel array and calls display from the MY_ARRAY class. A typical output will be: + +$ ./cecil +Enter 10 integers: +Enter element 1: 1 +Enter element 2: 2 +Enter element 3: 3 +Enter element 4: 4 +Enter element 5: 5 +Enter element 6: 6 +Enter element 7: 7 +Enter element 8: 8 +Enter element 9: 9 +Enter element 10: 10 + +Display an Eiffel Array: +@1 = 1 +@2 = 2 +@3 = 3 +@4 = 4 +@5 = 5 +@6 = 6 +@7 = 7 +@8 = 8 +@9 = 9 +@10 = 10 + + +==string== +This example shows how to create an Eiffel string from an existing C string. After you have done the appropriate steps to compile the example, you will get a `cecil.exe` on windows, or `cecil` on Unix. Launch the program and you will be prompted for a string, it will then initialize the Eiffel string and calls io. put_string from the STD_FILES class. A typical output will be: + +$ ./cecil +Enter a string to convert in Eiffel string: +Hello World! +Now printing the Eiffel string from Eiffel + +Hello World! + + + + + diff --git a/documentation/18.11/solutions/other-languages/cecil/cecil-samples/cecil-eiffel-c.wiki b/documentation/18.11/solutions/other-languages/cecil/cecil-samples/cecil-eiffel-c.wiki new file mode 100644 index 00000000..6a310b95 --- /dev/null +++ b/documentation/18.11/solutions/other-languages/cecil/cecil-samples/cecil-eiffel-c.wiki @@ -0,0 +1,96 @@ +[[Property:title|CECIL - Eiffel to C]] +[[Property:weight|1]] +[[Property:uuid|3d1df3fe-2ac8-1ba3-c846-8329ea8a3772]] +==array== + +This example shows how to create a C array from an existing Eiffel array. + +After you have done the appropriate steps to compile the example, you will get a `cecil.exe` on windows, or `cecil` on Unix. + +Launch the program and you will be prompted for 10 integers that will be inserted in an Eiffel array, it will then initialize the C array and display it. + +A typical output will be: + +$ ./cecil +This example create n array on the Eiffel side and print it on the C side +Enter 10 integers: +1 +2 +3 +4 +5 +6 +7 +8 +9 +10 + +Displaying from C +@1 = 1 +@2 = 2 +@3 = 3 +@4 = 4 +@5 = 5 +@6 = 6 +@7 = 7 +@8 = 8 +@9 = 9 +@10 = 10 + + +==object== +This example shows the Eiffel memory management and all issues when passing an Eiffel object reference to C. In the example, you can edit the file `root_class.e` to modify the example: + +--give_to_c (o1) +give_to_c_by_pointer ($o1) -- Choose the way you pass it + +When you choose the first possibility (commented by default), give_to_c will use the CECIL API eif_adopt to keep a reference on the Eiffel object. When you choose the second possibility, give_to_c_by_pointer will use the CECIL API eif_protect to keep a reference on the Eiffel object. Until forget_from_c is called from the C side, the object o1 will not be collected since we have protected it through the call to give_to_c or give_to_c_by_pointer. At the end after the object o1 is collected, we try to perform an operation on it which will fail with a call on void target exception. A typical output will be: + +$ cecil +Creating o1 +Object string is o1 +Give it to C +Losing reference to initial o1 from Eiffel +Collecting... +Display new o1: +Object string is o2 +Display o1 given to C: +Object string is o1 +Losing reference from C +Losing reference from Eiffel +Collecting... +An Eiffel object of type OBJECT is collected +Old o1 forgot from both C and Eiffel: +Raise a Void exception.. + +cecil: system execution failed. +Following is the set of recorded exceptions: +------------------------------------------------------------------------------- +Class / Object Routine Nature of exception Effect +------------------------------------------------------------------------------- +ROOT_CLASS make @26 display: +<30068030> Feature call on void target. Fail +------------------------------------------------------------------------------- +ROOT_CLASS make @26 +<30068030> Routine failure. Fail +------------------------------------------------------------------------------- +ROOT_CLASS root's creation +<30068030> Routine failure. Exit +------------------------------------------------------------------------------- +An Eiffel object of type OBJECT is collected + + +==string== +This example shows how to create a C string from an existing Eiffel string. After you have done the appropriate steps to compile the example, you will get a `cecil.exe` on windows, or `cecil` on Unix. Launch the program and you will be prompted for a string from Eiffel and a C string will be created and display. A typical output will be: + +$ cecil +Enter a string to convert into a C string: +Hello World! + +Here is the C string: +Hello World! + + + + + diff --git a/documentation/18.11/solutions/other-languages/cecil/cecil-samples/cecil-how-compile-samples.wiki b/documentation/18.11/solutions/other-languages/cecil/cecil-samples/cecil-how-compile-samples.wiki new file mode 100644 index 00000000..95b18e96 --- /dev/null +++ b/documentation/18.11/solutions/other-languages/cecil/cecil-samples/cecil-how-compile-samples.wiki @@ -0,0 +1,41 @@ +[[Property:title|CECIL - How to compile the samples?]] +[[Property:weight|4]] +[[Property:uuid|3548e1b4-9488-10d5-561e-f817c15d6ff0]] +==Compiling for Windows== + +Depending on your C compiler different steps have to be done, but do not forget to do the following before starting the C compiler specific part in a DOS console: +set ISE_EIFFEL=XXX + +where XXX is the EiffelStudio installation directory. + +===With Borland C++:=== + +By default, Borland C++ is not in your path, so you will have to first set your path correctly by typing: +set PATH=%ISE_EIFFEL%\BCC55\bin;%PATH% + +If the file `Makefile. win' is present, then you can launch the compilation with: +make -f Makefile. win + +Otherwise launch the compilation with: +make -f Makefile. bcb + +===With Microsoft Visual C++:=== + +By default, the command line tools of Visual C++ should be available from the command line. + +If the file `Makefile. win' is present, then you can launch the compilation with: +nmake -f Makefile. win + +Otherwise launch the compilation with: +nmake -f Makefile. msc + +==Compiling for UNIX== + +Then, make sure that your path to the EiffelStudio executables are properly configured before launching the command below. + +To compile and execute from scratch type: +finish_freezing -library + + + + diff --git a/documentation/18.11/solutions/other-languages/cecil/cecil-samples/cecil-threads.wiki b/documentation/18.11/solutions/other-languages/cecil/cecil-samples/cecil-threads.wiki new file mode 100644 index 00000000..dd22abe7 --- /dev/null +++ b/documentation/18.11/solutions/other-languages/cecil/cecil-samples/cecil-threads.wiki @@ -0,0 +1,70 @@ +[[Property:title|CECIL - Threads]] +[[Property:weight|3]] +[[Property:uuid|44f2ee31-8634-6e54-f45a-8b36f780f888]] +==bank_account== + +After you have done the appropriate steps to compile the example, you will get a `bank_account.exe` on windows, or `bank_account` on Unix. + +This program launches two types of threads: +* the spenders withdraw some money from a shared bank account +* the savers make some deposits on it. + +The Eiffel Threads are launched from C. The synchronization is done from Eiffel. The shared bank account is a C structure, and is updated by the Eiffel Threads using some C externals. + +
+In main. c:
+LISTSZ size of bank account history.
+DEPOSITORS numbers of savers.
+WITHDRAWERS numbers of spenders. +
+ + + +A typical output will be: + +$ bank_account +**** Bank account report: +Thread 0x30036350 DEPOSIT 161 +Thread 0x30036350 DEPOSIT 614 +Thread 0x30036350 DEPOSIT 626 +Thread 0x30036350 DEPOSIT 880 +Thread 0x30036350 DEPOSIT 601 +Thread 0x30036350 DEPOSIT 480 +Thread 0x30036350 DEPOSIT 177 +Thread 0x30036350 DEPOSIT 451 +Thread 0x30036350 DEPOSIT 96 +Thread 0x30036350 DEPOSIT 219 +*** BALANCE: 5305 +Do you want to continue? (y/n) +y +**** Bank account report: +Thread 0x3003fcf0 DEPOSIT 161 +Thread 0x3004f088 DEPOSIT 161 +Thread 0x300567a0 WITHDRAWAL 161 +Thread 0x3005e1f0 WITHDRAWAL 161 +Thread 0x30036350 DEPOSIT 531 +Thread 0x3003fcf0 DEPOSIT 614 +Thread 0x3004f088 DEPOSIT 614 +Thread 0x300567a0 WITHDRAWAL 614 +Thread 0x30036350 DEPOSIT 409 +Thread 0x3003fcf0 DEPOSIT 626 +*** BALANCE: 7485 +Do you want to continue? (y/n) +y +**** Bank account report: +Thread 0x3004f088 DEPOSIT 626 +Thread 0x30036350 DEPOSIT 799 +Thread 0x300567a0 WITHDRAWAL 626 +Thread 0x3005e1f0 WITHDRAWAL 614 +Thread 0x3003fcf0 DEPOSIT 880 +Thread 0x30036350 DEPOSIT 860 +Thread 0x3004f088 DEPOSIT 880 +Thread 0x300567a0 WITHDRAWAL 880 +Thread 0x30036350 DEPOSIT 307 +Thread 0x3004f088 DEPOSIT 601 +*** BALANCE: 10318 + + + + + diff --git a/documentation/18.11/solutions/other-languages/cecil/cecil-samples/index.wiki b/documentation/18.11/solutions/other-languages/cecil/cecil-samples/index.wiki new file mode 100644 index 00000000..95353be7 --- /dev/null +++ b/documentation/18.11/solutions/other-languages/cecil/cecil-samples/index.wiki @@ -0,0 +1,14 @@ +[[Property:title|CECIL samples]] +[[Property:weight|5]] +[[Property:uuid|dab15073-3970-7e47-a2d8-c926faa50ade]] +Before trying the examples, please take a moment and look at the [[CECIL - How to compile the samples?|description]] that will explain how to compile the CECIL samples. + +Available samples include: +* [[CECIL - C to Eiffel|C to Eiffel]] +* [[CECIL - Eiffel to C|Eiffel to C]] +* [[CECIL - Basic sample|Basic CECIL sample]] +* [[CECIL - Threads|Threads]] + + + + diff --git a/documentation/18.11/solutions/other-languages/cecil/compiling-eiffel-system-cecil.wiki b/documentation/18.11/solutions/other-languages/cecil/compiling-eiffel-system-cecil.wiki new file mode 100644 index 00000000..a2bada7e --- /dev/null +++ b/documentation/18.11/solutions/other-languages/cecil/compiling-eiffel-system-cecil.wiki @@ -0,0 +1,35 @@ +[[Property:title|Compiling an Eiffel system for CECIL]] +[[Property:weight|1]] +[[Property:uuid|94a549df-1919-9dcd-82b3-1cd82e064a03]] +==Compiling your Eiffel system for CECIL== +It is very simple to "Cecilize" your Eiffel system, that is to say make its features available from the outside through CECIL. You will compile it as you normally would - either freeze it or finalize it. The only supplementary precaution is to make the features and classes that will be used by CECIL [[Group Options|visible]]. + +==Building a CECIL archive== +The EiffelStudio compiler produces both C code and a "Makefile". The Makefile compiles and links that C code in a subdirectory one level below the EIFGENs directory of a project. For frozen/melted code, the Makefile is located in the W_code subdirectory. For finalized code, it is in the F_code subdirectory. +To produce a CECIL library, you must: open a shell (unix) or the MS-DOS prompt (Windows), go to the subdirectory that contains the Makefile, and then type: + + + make cecil (on unix and on windows with Borland) + nmake cecil (on windows with VC++) + +This generates a CECIL archive whose name derived from the name system name of the Eiffel system, as follows: + + + lib.a (on unix) + lib.lib (on Windows) + + +For example, the corresponding archive for an Eiffel system called "test", would be called either "libtest.a" (Unix) or "libtest.lib" (Windows). +Note that through CECIL you can use an Eiffel system compiled in any of the Eiffel compilation modes: +* Finalized C code. +* Workbench (melted/frozen) code, usually for development purposes. In this case you must copy the ''.melted'' file ( where '''' is the name of your system) located in EIFGENs\\W_code to the directory where you intend to execute your C application from. + +{{note|each time you melt the Eiffel system, the ''. melted'' file is updated. }} + +{{caution|In the second case (workbench mode), it is not possible to call through the CECIL interface any routine that has been melted in the last compilation; this would raise the run-time exception:
+''' $ applied to melted routine'''
+The solution is simply to refreeze the system. }} + + + + diff --git a/documentation/18.11/solutions/other-languages/cecil/index.wiki b/documentation/18.11/solutions/other-languages/cecil/index.wiki new file mode 100644 index 00000000..7423bfd1 --- /dev/null +++ b/documentation/18.11/solutions/other-languages/cecil/index.wiki @@ -0,0 +1,19 @@ +[[Property:title|CECIL]] +[[Property:weight|3]] +[[Property:uuid|c03112b8-578e-cc1a-ee13-c6928b787529]] +This document provides an overview of the C-Eiffel Call-In Library (CECIL) as defined in Eiffel: The Language (ETL). The first section addresses how to compile and run a CECIL program, on the [[Compiling an Eiffel system for CECIL|Eiffel side]] and on the [[Using a CECIL archive|C side]] . The [[CECIL interface overview|second part]] contains a more precise description of the Eiffel types, the protection mechanism as well as how to write and use C externals. + +CECIL, designed by Eiffel Software , is the C library that permits C and C++ applications (as well as applications written in other languages) to take advantage of almost all Eiffel facilities: create Eiffel objects, apply features to them. The basics of CECIL are described in chapter 24 of the reference book on Eiffel, Eiffel: The Language, which covers interfaces between Eiffel and other languages. Important material can also be found in the Eiffel Software manual Eiffel: The Environment. + +The CECIL documentation, man pages and examples are part of the standard delivery of EiffelStudio 5.0 and higher. + +The present document complements the descriptions of Eiffel: The Language. Note that CECIL has been revised and improved since that book was published, so the explanations below have precedence over those in the book. + +This document is intended for both Windows and Unix users. Only a few of the sections, clearly marked, are platform-specific. +To access Eiffel mechanisms from C or other external languages: +* Compile your Eiffel system so as to generate "Cecilized" code, that is to say code callable from the outside. See [[Compiling an Eiffel system for CECIL|Compiling your Eiffel system for CECIL]] . +* In writing the external code that will use the facilities of the Eiffel system, use the CECIL functions as specified in chapter 24 of ''Eiffel: The Language''. See also [[CECIL interface overview|The CECIL interface overview]] . +* C-compile and link that code. See [[Using a CECIL archive|Building a C system using CECIL]] . + +For feature by feature specification, please have a look at [[CECIL Reference|the man pages]] . + diff --git a/documentation/18.11/solutions/other-languages/cecil/using-cecil-archive.wiki b/documentation/18.11/solutions/other-languages/cecil/using-cecil-archive.wiki new file mode 100644 index 00000000..57767959 --- /dev/null +++ b/documentation/18.11/solutions/other-languages/cecil/using-cecil-archive.wiki @@ -0,0 +1,97 @@ +[[Property:title|Using a CECIL archive]] +[[Property:weight|2]] +[[Property:uuid|e8438c9b-65ae-368f-6559-a0d5b28db4b7]] +==Linking the CECIL archive into a program== +The CECIL archive already incorporates the Eiffel run-time. To use the functions provided in the CECIL archive, simply write the C programs according to the CECIL specifications of ETL, and then include the CECIL archive in the link line of your C application. + + +On Unix/linux, this line looks like this: + + +ld -o [name of your CECIL executable] [your C object files and archives]lib.a -lm + + +{{note|On Unix, linking with "-lm" is required since the Eiffel run-time uses the standard math libraries. You may need to link with other libraries (for example, on linux: with "-lbsd", in MT mode with "-lpthread" (posix threads) or "-lthread" (solaris)). }} + + +on Windows, with MS VC++: + + +link [your link flags] -OUT:[name of your cecil executable] [your C object files and archives] lib.lib [other Windows libraries] + + + +on Windows with Borland: + + +ilink32 -ap -c -Tpe main.obj c0w32.obj, [name of your cecil executable],,EIFGENs\target_name\W_code\lib.lib CW32 IMPORT32 OLE2w32,, + + + +===Notes for compiling CECIL C files:=== +The CECIL library is built automatically, which is unfortunately not the case of the corresponding object files of the cecil program you wrote.
+The C flags to use are usually the same as the ones needed during the compilation of the generated C-code plus those which are relevant to your own C-code. + +Typically, you will compile with your flags as below (if you are using gcc): + + +gcc -c -O -I$ISE_EIFFEL/studio/spec/$PLATFORM/include -I -D your_file.c + + +or , if you are on Windows using MS VC++: + + +cl -c -nologo -Ox -I$ISE_EIFFEL\studio\spec\windows\include -I -D your_file.c + + +or, if you are on Windows using Borland: + + +bcc32 -c -I$ISE_EIFFEL\studio\spec\windows\include -I -D your_file.c + + +{{note|if you want to use the multithreaded facilities of Eiffel, you should define the EIFFEL MT flags by adding "-DEIF_THREADS" to the command line and follow the instructions of your C compiler and platform to find out which additional flags you may need. For example, on Solaris you need to add "-DSOLARIS_THREADS -D_REENTRANT". }} + + +You can specify a Makefile in your configuration file, so that your C files will be compiled automatically after the Eiffel compilation and before the final linking. See [[Externals Options|the manipulation of external]] in the project settings to add $PATH_TO_MAKEFILE/your_makefile. + + +This makefile will be run from the $/EIFGENs/target_name/W_code or $/EIFGENs/target_name/F_code directory. You should not give the CECIL executable the same name as your system, because it will be replaced by the Eiffel executable when you run another compilation. + + +==Initializing the Eiffel run-time== +Even though the main thread of control resides in the "C side" of the program, the Eiffel run-time must be initialized correctly before it can use CECIL facilities to communicate with the Eiffel world. +In the C file containing the "main" C function, you must add the following line to include the header file "eif_setup. h" provided with this example: + + + +#include "eif_setup.h" /* Macros EIF_INITIALIZE and EIF_DISPOSE_ALL */ +#include "eif_eiffel.h" /* Exported functions of the Eiffel run-time */ + + +Your "main" function must have the three standard arguments of the C "main" function: "argc", "argv" and "envp" and include the following macros that are defined in "eif_setup. h": + + + +int main(int argc, char **argv, char **envp) + /* Please respect this signature: 'argc', 'argv' and 'envp' are used * in EIF_INITIALIZE. */ +{ + /* declarations of variables */ + /* Initialize the Eiffel run-time. */ + EIF_INITIALIZE(failure) + +/* body of your "main" function */ + + /* Reclaim the memory allocated by the Eiffel run-time. */ +EIF_DISPOSE_ALL +} + + +{{note|The above mentioned macros must imperatively be in the body of the "main" function for the Eiffel exception handling mechanism to work correctly. You also need to add the Eiffel run time directory to the list of directories in which the C compiler searches for include files. You can do so by using the "-I" option of your C compiler. You can only link one CECIL library into your C applications at a time. }} + + +{{caution|Even though external object files and archives are correctly specified in the "object" clause of the configuration file, you will need to explicitly link them to your C application. }} + + + + diff --git a/documentation/18.11/solutions/other-languages/eiffel-external-mechanism/index.wiki b/documentation/18.11/solutions/other-languages/eiffel-external-mechanism/index.wiki new file mode 100644 index 00000000..88899949 --- /dev/null +++ b/documentation/18.11/solutions/other-languages/eiffel-external-mechanism/index.wiki @@ -0,0 +1,17 @@ +[[Property:title|Eiffel "external" mechanism]] +[[Property:weight|0]] +[[Property:uuid|b6ea568d-a9d3-3220-7957-d9c81620e885]] +{{UnderConstruction}} + + +The Eiffel mechanism for interfacing with other languages, as defined by the [[ECMA Standard 367|Eiffel standard (8.31)]] uses a syntax for '''external''' features, that is, features that are in languages or libraries external to Eiffel. + +Additionally, there is a notion of such external languages being either '''registered''' or '''unregistered'''. A language is registered if every Eiffel implementation must support the external interface to this language as defined by the standard. So the names of all registered languages appear in the Eiffel standard. And the details of the specific external mechanisms for those languages also appear in the standard. Registered languages included in the June 2006 edition of the standard are '''"C"''', '''"C++"''', and '''"dll"'''. + +The case of unregistered languages is simply that there is no guarantee that such a language is supported by any particular Eiffel compiler. So, a the name of an unregistered language might appear as '''"Cobol"''' or '''"Ada"'''. These names may be meaningful to particular Eiffel compilers, but from the standpoint of the standard they are arbitrary manifest strings. + + + + + + diff --git a/documentation/18.11/solutions/other-languages/eiffel-external-mechanism/interfacing-c-and-c.wiki b/documentation/18.11/solutions/other-languages/eiffel-external-mechanism/interfacing-c-and-c.wiki new file mode 100644 index 00000000..93383c7c --- /dev/null +++ b/documentation/18.11/solutions/other-languages/eiffel-external-mechanism/interfacing-c-and-c.wiki @@ -0,0 +1,132 @@ +[[Property:modification_date|Mon, 03 Sep 2018 08:31:04 GMT]] +[[Property:publication_date|Mon, 03 Sep 2018 08:28:15 GMT]] +[[Property:title|Interfacing with C and C++]] +[[Property:weight|0]] +[[Property:uuid|dcc4e216-307b-46ec-1bc1-a15da8b99469]] +{{UnderConstruction}} + + +Interfacing with C and C++ are similar enough that both can be covered together. There are two basic mechanisms available. The first and simpler of the two uses an existing routine and is available only to C externals. Using this approach you simply specify the '''signature''' of an existing C function along with where the function can be found. The second mechanism allows you to write C or C++ code inline. The second option is always recognizable by the presence of the word "'''inline'''" in the external specification. Again, the '''inline''' option is the only one allowed for C++ externals. + +==Using an existing C function== + +Here is an example of an external targeting an existing C function. In this case it's the floor function from the C library. + + + floor (v: DOUBLE): DOUBLE + -- Floor of `v' + external + "C signature (double): double use " + end + + +The Eiffel external function floor now gives Eiffel code access to the C library function of the same name. + +Here external is an Eiffel keyword that introduces the external specification that appears in the quoted string that follows. (The quoted string is actually an Eiffel [[ET: Other mechanisms|manifest string]], so it could actually be a simple quoted string or a [[ET: Other mechanisms|verbatim string]].) Within the quoted string we find first the registered language designator, in this case "C", followed by the function's signature, followed by the location in which the C function can be found. The terms "signature" and "use" within the quoted string are technically not Eiffel language keywords, but are keywords used in the specification of externals. There is one other similar keyword "inline" which can be used, but we will address it later. + +The "signature" consists of the types of the arguments to C function as well as the function's return type. The argument types are separated by commas in a list enclosed in parentheses. A colon precedes the function type. In cases in which the target function takes no arguments, it is not necessary to include a set of empty parentheses in the signature. However, for compatibility purposes, the empty parentheses are allowed. + +The "use" part denotes provides a file name or list of file names. File names can be either "user" file names or "system" file names. In the case of our example, a system file name "" is used. System files are those that should be found by the system with no additional information. System file names are enclosed in angle brackets. User file names are included in a quoted string. User file names will be passed as written to the operating system. Remember that when coding a user file name, that because it already occurs within a quoted string, you must use the percent sign to code the quotation marks inside a quoted string, for example: + + + "C signature (double): double use %"my_c_header.h%"" + + +Alternatively, you could code the external as a verbatim string. This would make the percent signs unnecessary. + +There's one more thing to note about using existing C functions. In the floor example above, the Eiffel function has the same name as the C function it targets. But that may not always be the case. It's possible that the C function name might conflict with a name already established in your class, or might conflict with Eiffel naming conventions. Suppose you wanted to call the Eiffel routine my_floor instead of floor. You could use the alias part of the external specification to state that the actual C function name differs from the Eiffel name, as shown below. + + + my_floor (v: DOUBLE): DOUBLE + -- Floor of `v' + external + "C signature (double): double use " + alias + "floor" + end + + + +==Inline externals== + +In addition to using an existing C function, you can, for both C and C++, create an '''inline''' external. The idea here is that you write the necessary C or C++ language within the definition of the external. In the case of inline externals the alias part is used to contain the inline code rather than a function name. Your inline C and C++ code can access the arguments of the external feature. Let's look at my_floor written as an inline external: + + + my_floor (v: DOUBLE): DOUBLE + -- Floor of `v' + external + "C inline use " + alias + "return floor($v)" + end + + +In the alias part you see a line of C code calling the library function floor and returning the result. The argument to the call to floor needs to be the argument to the Eiffel function my_floor. To do this in the inline C code, the dollar sign ('$') precedes the argument name "v". So, the convention in inline externals is to use the dollar sign in C or C++ code to reference an argument of the Eiffel function. + +The example below is a C++ example that involves more complex processing in the alias part. + + + c_height (a_framework: POINTER): INTEGER + -- Get ribbon height + require + a_framework_exists: a_framework /= default_pointer + external + "C++ inline use " + alias + "{ + UINT32 val; + HRESULT hr = S_OK; + + IUIRibbon* pRibbon = NULL; + if (SUCCEEDED(((IUIFramework *) $a_framework)->GetView(0, IID_IUIRIBBON, (void **) &pRibbon))) { + hr = pRibbon->GetHeight(&val); + pRibbon->Release(); + } + return (EIF_INTEGER) val; + }" + end + + + +==Rules for C and C++ externals== + +===C external validity=== + +A C external is valid if it satisfies the following conditions: + +# It specifies either an external signature or an inline routine. +# If it specifies an inline routine, then +## The C text of the routine follows the alias keyword. +## For any occurrence, within the C text, of an identifier following a dollar sign ('$'), the identifier must be the name of an argument of the external routine. + + +===C++ external validity=== + +A C++ external is valid if it satisfies the following conditions: + +# It specifies an inline routine with the C++ text of the routine occurring after the alias keyword. +# For any occurrence, within the C++ text, of an identifier following a dollar sign ('$'), the identifier must be the name of an argument of the external routine. + + +===External file name validity=== + +An external file name appearing after the "use" is valid if it satisfies the following conditions: + +# It denotes a file when interpreted according to the conventions of the underlying operating system. +# The file is accessible for reading. +# The file contains content valid in the target language. + +The first condition means that user file names must conform to the path and file names of the target environment. Such file names will be passed on to the operating system as they appear. And for system file names, those enclosed in angle brackets, this means that they must be found where the operating system would expect such system files to reside. + +Some parts of the validity of external file names may not be able to be determined by an Eiffel compiler and thus ultimately depend upon the evaluation of an external compiler. For example, the Eiffel compiler might not be able to determine whether a particular C file contains valid content. + + +==Related pages or articles== +{{seealso|
+- [https://www.eiffel.org/doc/solutions/Eiffel_%22external%22_mechanism]
+- [https://www.eiffel.org/article/protecting_objects]
+- [https://www.eiffel.org/article/using_externals_in_multithreaded_applications]
+- [https://www.eiffel.org/article/c_c_calls_and_callbacks]
+ +}} + diff --git a/documentation/18.11/solutions/other-languages/eiffel-external-mechanism/interfacing-dlls.wiki b/documentation/18.11/solutions/other-languages/eiffel-external-mechanism/interfacing-dlls.wiki new file mode 100644 index 00000000..d8e38895 --- /dev/null +++ b/documentation/18.11/solutions/other-languages/eiffel-external-mechanism/interfacing-dlls.wiki @@ -0,0 +1,29 @@ +[[Property:title|Interfacing with DLLs]] +[[Property:weight|0]] +[[Property:uuid|4ad177dd-13ec-c237-99b3-efc9851995a5]] +Using EiffelStudio, there are two different ways to call C routines exported in DLLs. This is because on the Windows platform, there are two frequently-used calling conventions for C routines found in DLLs: + +* _cdecl: referred to as the standard calling convention +* __stdcall referred to as the Pascal calling convention + +Calling conventions define 1) how arguments are placed on the stack, and 2) which entity (the caller, or the callee) is responsible for returning the call stack to its previous state when the routine has completed. These two methods are NOT compatible. Therefore if you have a routine in a DLL you wish to call, one of the first things to find out about it is which calling convention it expects. DLL routines that use the `_cdecl` calling convention require the use of the '''dll32''' sub-language option. For `__stdcall`, use the '''dllwin32''' sub-language option. Here is an example: + + + my_cdecl_routine (a: INTEGER): POINTER + -- Encapsulation of a dll function with the `_cdecl' call mechanism. + external + "C [dll32 %"my_cdecl_dll.dll%"] (int): EIF_POINTER" + end + + my_stdcall_routine (a: INTEGER): POINTER + -- Encapsulation of a dll function with the `_stdcall' call mechanism. + external + "C [dllwin32 %"my_stdcall_dll.dll%"] (int): EIF_POINTER" + end + + +{{note|Most OS services provided by the Win32 API use the __stdcall calling convention.}} + +{{warning|Getting '''dll32''' and '''dllwin32''' reversed will cause your application's call stack to be corrupted. This will cause your application to malfunction, can cause it to crash, and can potentially crash your whole system. So getting this right is crucial to smooth implementation of external DLL calls. For more information please consult your C compiler documentation.}} + + diff --git a/documentation/18.11/solutions/other-languages/eiffel-external-mechanism/obsolete-external-interfaces/c-externals-0.wiki b/documentation/18.11/solutions/other-languages/eiffel-external-mechanism/obsolete-external-interfaces/c-externals-0.wiki new file mode 100644 index 00000000..456d7c9d --- /dev/null +++ b/documentation/18.11/solutions/other-languages/eiffel-external-mechanism/obsolete-external-interfaces/c-externals-0.wiki @@ -0,0 +1,302 @@ +[[Property:title|C++ Externals]] +[[Property:weight|2]] +[[Property:uuid|e74e2661-5d7f-2f08-5279-1c24fd16a532]] +==Introduction== + +Before making C++ calls in EiffelStudio, you may want to learn the basics of making [[C externals|C calls]] , since these basics are not repeated here but they might be useful for C++ users as well and are necessary to fully benefit from this document. + +==Overview== + +Eiffel software must interact with software written in other languages. In this document you will learn about how to incorporate C++ classes in your Eiffel software. + +The C++/Eiffel interface offers the following mechanisms: +* You can create instances of C++ classes from Eiffel, using the C++ "constructor" of your choice. +* You can apply to these objects all the corresponding operations from the C++ class: executing functions ("methods"), accessing data members, executing destructors. +* On Windows, you can use the Legacy++ tool to produce an Eiffel "wrapper class" encapsulating all the features of a C++ class, so that the result will look to the rest of the Eiffel software as if it had been written in Eiffel. + +The discussion concentrates on using C++ software from Eiffel. In the other direction, you can use [[CECIL|the Cecil library (C-Eiffel Call-In Library)]] . + +==Syntax specification== + +In the following specification, the syntax for External and External_name is retained unchanged from ''Eiffel: The Language'', where Language_name is defined simply as Manifest_string; the rest covers the additional facilities. + +External == external Language_name [External_name] + +Language_name == + '"' + Basic_language_name + [Special_external_declaration] + [Signature] + [Include_files] + '"' + +Basic_language_name == "C" | "C++" + +Special_external_declaration == "[" Special_feature "]" + +Special_feature == Special_C_feature | Special_C++_feature + +Special_C_feature == -- .... See appendix E of Eiffel: The Language... + +Special_C++_feature == + Member_function_call| + Static_function_call | + Object_creation | + Object_deletion | + Data_member_access | + +Member_function_call == C++_Class + +C++_Class == Class_name File_name + +Class_name == Identifier + +Static_function_call == static C++_Class + +Object_creation == new C++_Class + +Object_deletion == delete C++_Class + +Data_member_access == data_member C++_Class + + -- The remaining elements are repeated + -- from the C interface specification (page 291 in Eiffel: The Environment). + +File_name == User_file_name | System_file_name + +User_file_name == '%"' Manifest string '%"' + +System_file_name == "<" Manifest_string ">" + +Signature == "(" Type_list ")" [Result_type] + +Type_list == {Type "," ...} + +Result_type == ":" Type + +Include_files == "|" File_list + +File_list == {File_name "," ...} + +External_name == alias Manifest_string + + + +As with the C extensions of the previous appendix, the syntax description conventions are those of ''Eiffel: The Language''. == means "is defined as". The vertical bar | separates alternative choices, such as the three possibilities for Special_feature. The brackets [...] enclose optional components; for example a Language_name is made of required quotes, a required Basic_language_name and three further components, any or all of which may be absent. The notation {Element Separator ...} means: 0 or more occurrences ("specimens") of Element separated, if more than one, by Separator. + +Several of the symbols of the syntax notation, such as the brackets or the vertical bar, also appear in the language; to avoid any confusion they are given in double quotes. For example the specification for Include_files begins with "|" to indicate that an Include_files part starts with a vertical bar. Single quotes may be used instead of double quotes when one of the quoted characters is itself a double quote; for example '%"' appearing in the production for User_file_name denotes the percent character followed by the double quote character. Special words such as '''static''' in bold italics stand for themselves, unquoted. + +==Available possibilities== + +===Processing C++ features=== + +A Special_C++_feature, if present, indicates one of the following, all illustrated by examples in the next sections: +* If the special feature's declaration simply starts with a C++ class name, followed by the associated file name, it indicates that the Eiffel feature will call a C++ member function (also known as a "method") from that class. The name of the member function is by default the same as the name of the Eiffel feature; as usual, you can specify a different name through the alias clause of the external declaration. +* If the declaration starts with static, it indicates a call to a C++ static function. +* If the declaration starts with new, it indicates a call to one of the constructors in the C++ class, which will create a new instance of that class and apply to it the corresponding constructor function. +* If the declaration starts with delete, it indicates a call to a destructor from the C++ class. In this case the Eiffel class may inherit [[ref:libraries/base/reference/memory_chart|MEMORY]] and redefine the dispose procedure to execute the destructor operations whenever the Eiffel objects are garbage-collected. +* If the declaration starts with data_member, it indicates access to a data member (attribute in Eiffel terminology) from the C++ class. + +The rest of the possible components are the same as in the C interface: Signature to specify types for arguments and results; possible Include file. + +===Extra argument=== + +For a non-static C++ member function or destructor, the corresponding Eiffel feature should include an extra argument of type POINTER, at the first position. This argument represents the C++ object to which the function will be applied. + +For example, a C++ function +void add(int new_int); + +should have the Eiffel counterpart + + cpp_add (obj: POINTER; new_int: INTEGER) + -- Encapsulation of member function add. + external + "C++ [IntArray %"intarray.h%"] (IntArray *, int)" + end + +This scheme, however, is often inconvenient because it forces the Eiffel side to work on objects in a non-object-oriented way. (The object-oriented way treats the current object, within a class, as implicit.) A better approach, used by Legacy++, is to make a feature such as cpp_add secret, and to export a feature whose signature corresponds to that of the original C++ function, with no extra object argument; that feature will use a secret attribute object_ptr to access the object. In the example this will give the feature + + add (new_int: INTEGER) + -- Encapsulation of member function add. + do + cpp_add (object_ptr, new_int) + end + + +where ''object_ptr'' is a secret attribute of type POINTER, initialized by the creation procedures of the class. To the Eiffel developer, add looks like a normal object-oriented feature, which takes only the expected argument. Further examples appear below. This technique only works of course when the C++ object is implicit in the context of the Eiffel class. + +There is no need for an extra argument in the case of static member functions and constructors. + +==Wrapping C++ classes: Legacy++== + +Before taking a look at examples of the various facilities mentioned, it is useful to consider the tool that will help you, in many cases, avoid worrying about their details. + +===The role of Legacy++=== + +Often you will want to provide an Eiffel encapsulation of all the facilities -- member functions, static functions, constructors, destructors, data members -- of a C++ class. This means producing an Eiffel class that will provide an Eiffel feature for each one of these C++ facilities, using external declarations based on the mechanisms listed in the preceding section. + +Rather than writing these external declarations and the class structure manually, you can use the Legacy++ tool to produce the Eiffel class automatically from the C++ class. + +===Calling Legacy++=== + +Legacy++ is called with an argument denoting a ''.h'' file that must contain C++ code: one or more classes and structure declarations. It will translate these declarations into Eiffel wrapper classes. Legacy++ is only available on Windows. It is located in the $ISE_EIFFEL\studio\spec\windows\bin directory, under the name legacy.exe. + +The following options are available: +* '''-E''': apply the C preprocessor to the file, so that it will process #include, #define, #ifdef and other preprocessor directives. This is in fact the default, so that you do not need to specify -E explicitly (see next option). +* '''-NE''': do not apply the C preprocessor to the file. +* '''-p''' ''directories'': use ''directories'' as include path. +* '''-c''' ''compiler'': use ''compiler'' as the C++ compiler. +* '''-g''': treat the C++ code as being intended for the GNU C++ compiler. + +===Result of applying Legacy++=== + +Running Legacy++ on a C++ file will produce the corresponding Eiffel classes. Legacy++ processes not only C++ classes but also C++ "structs"; in both cases it will generate an Eiffel class. + +Legacy++ knows about default specifiers: public for structs, private for classes. + +Legacy++ will generate Eiffel features for member functions (static or not). + +It will also handle any constructors and destructors given in the C++ code, yielding the corresponding Eiffel creation procedures. If there is no explicit constructor, it will produce a creation procedure with no arguments and an empty body. + +For any non-static member function or destructor, Legacy++ will generate a secret feature with an extra argument representing the object, as explained in the preceding section in this page. It will also produce a public feature with the same number of arguments as the C++ function, relying on a call to the secret feature, as illustrated for add and cpp_add above. + +The char* type is translated into STRING. Pointer types, as well as reference types corresponding to classes and types that Legacy++ has processed, will be translated into POINTER. Other types will yield the type UNRESOLVED_TYPE. + +===Legacy++ limitations=== + +It is up to you to supply Eiffel equivalents of all the needed types. If Legacy++ encounters the name of a C++ class or type that it does not know -- i.e. it is neither a predefined type nor a previously translated class -- it will use the Eiffel type name UNRESOLVED_TYPE. If you do not change that type in the generated class, the Eiffel compiler will produce an error (unknown class) at degree 5. + +Legacy++ does not handle inline function declarations. + +Legacy++ does not handle C++ templates. + +Legacy++ makes no effort to understand the C++ inheritance structure. + +More generally, given the differences in the semantic models of C++ and Eiffel, Legacy++ can only perform the basic Eiffel wrapping of a C++ class, rather than a full translation. You should always inspect the result and be prepared to adapt it manually. + +Legacy++'s contribution is to take care of the bulk of the work, in particular the tedious and repetitive parts. The final details are left to the Eiffel software developer. + +Legacy++ is only supported on the windows platform. + +==Example== + +Consider the following C++ class, which has an example of every kind of facility that one may wish to access from the Eiffel side: + +class IntArray { + public: + IntArray(int size); + ~IntArray(); + void output(); + void add(int new_int); + static char * type(); + + protected: + int *_integers; +}; + + +Here is the result of applying Legacy++ to that class, which will serve as an illustration of both the C++ interface mechanisms and Legacy++: + +note + description: "Eiffel encapsulation of C++ class IntArray"; + date: "$Date: 2006-10-12 03:18:50 +0200 (Thu, 12 Oct 2006) $"; + revision: "$Revision: 64319 $" + +class + INTARRAY + +inherit + MEMORY + redefine + dispose + end + +create + make + +feature -- Initialization + + make (size: INTEGER) + -- Create Eiffel and C++ objects. + do + object_ptr := cpp_new (size) + end + +feature-- Removal + + dispose + -- Delete C++ object. + do + cpp_delete (object_ptr) + end + +feature + + output + -- Call C++ counterpart. + do + cpp_output (object_ptr) + end + + add (new_int: INTEGER) + -- Call C++ counterpart. + do + cpp_add (object_ptr, new_int) + end + +feature {INTARRAY} + + underscore_integers: POINTER + -- Value of corresponding C++ data member. + do + Result := underscore_integers (object_ptr) + end + +feature {NONE} -- Externals + + cpp_new (size: INTEGER): POINTER + -- Call single constructor of C++ class. + external + "C++ [new IntArray %"INTARRAY.H%"] (EIF_INTEGER)" + end + + cpp_delete (cpp_obj: POINTER) + -- Call C++ destructor on C++ object. + external + "C++ [delete IntArray %"INTARRAY.H%"] ()" + end + + cpp_output (cpp_obj: POINTER) + -- Call C++ member function. + external + "C++ [IntArray %"INTARRAY.H%"] ()" + alias + "output" + end + + cpp_add (cpp_obj: POINTER; new_int: INTEGER) + -- Call C++ member function. + external + "C++ [IntArray %"INTARRAY.H%"] (EIF_INTEGER)" + alias + "add" + end + + cpp_underscore_integers (cpp_obj: POINTER): POINTER + -- Value of C++ data member + external + "C++ [data_member IntArray %"INTARRAY.H%"]: EIF_POINTER" + alias + "_integers" + end + +feature {NONE} -- Implementation + + object_ptr: POINTER + +end -- class INTARRAY + + + + + diff --git a/documentation/18.11/solutions/other-languages/eiffel-external-mechanism/obsolete-external-interfaces/c-externals.wiki b/documentation/18.11/solutions/other-languages/eiffel-external-mechanism/obsolete-external-interfaces/c-externals.wiki new file mode 100644 index 00000000..43ed03ad --- /dev/null +++ b/documentation/18.11/solutions/other-languages/eiffel-external-mechanism/obsolete-external-interfaces/c-externals.wiki @@ -0,0 +1,224 @@ +[[Property:title|C externals]] +[[Property:weight|1]] +[[Property:uuid|f6a5ce2d-882b-27a2-ad6e-2e4c36027528]] +==General consideration== + +As Eiffel Software's technology relies heavily on the use of a C/C++ ANSI compiler, you have to be sure to always put the correct signature of an external C/C++ routine. If it was not the case, the C compilation of your system could fail. Most of the time a C compiler is more comprehensive than a C++ compiler and most type errors won't cause you any harm, but C++ compilers are not as lax as C compilers and they will mostly generate errors. + +The sections concerning [[#macros|Macros]] and [[#structs|Structs]] are also available for C++ if the macro or the struct is defined in a C++ header file. + + + +==C routines== + +You can encapsulate routines that are defined in a C header file. We will take some examples and will show you how to write wrappers in Eiffel. + +If in a header file called `my_header.h`, you have the following declaration: + + /* Routine with no parameter */ +extern void no_param(void); + + /* Routine with one parameter */ +extern void one_param(int j); + + /* Routine returning a value with no parameter */ +extern size_t no_param_return(void); + + /* Routine returning a value with one parameter */ +extern size_t one_param_return(FILE *f); + + +Here is the corresponding Eiffel code: + + c_no_param + -- Encapsulation of a C routine with no parameter. + external + "C | %"my_header.h%"" + alias + "no_param" + end + + c_one_param (i: INTEGER) + -- Encapsulation of a C routine with one parameter. + external + "C (int) | %"my_header.h%"" + alias + "one_param" + end + + c_no_param_return: INTEGER + -- Encapsulation of a C routine with no parameter + -- returning an INTEGER + external + "C (): EIF_INTEGER| %"my_header.h%"" + alias + "no_param_return" + end + + c_one_param_return (p: POINTER): INTEGER + -- Encapsulation of a C routine with one parameter + -- returning an INTEGER + external + "C (FILE *): EIF_INTEGER| %"my_header.h%"" + alias + "one_param_return" + end + + + +==Macros== + +If in a header file called `my_header.h`, you have the following declaration: + + /* Predefined constants */ +#define ID_MENU 128 +#define ID_MENU_CHARACTER 'c' + + /* Access the 'i'-th element of 'a' where 'a' * is an array of EIF_INTEGER */ +#define i_th(a,i)((a) + (i)*sizeof(EIF_INTEGER)) + + +Then, the corresponding Eiffel code will look like: + + + + menu_id: INTEGER + -- `ID_MENU' C encapsulation. + external + "C [macro %"my_header.h%"] : EIF_INTEGER" + alias + "ID_MENU" + end + + menu_id_character: CHARACTER + -- `ID_MENU_CHARACTER' C encapsulation. + external + "C [macro %"my_header.h%"] : EIF_CHARACTER" + alias + "ID_MENU_CHARACTER" + end + + i_th (p: POINTER; i: INTEGER): INTEGER + -- Access the `i'-th element of `p', array of C EIF_INTEGER. + external + "C [macro %"my_header.h%"] (EIF_INTEGER *, EIF_INTEGER): EIF_INTEGER" + alias + "i_th" + end + + + +==Structs== + +The struct encapsulation enables you to wrap C/C++ structures easily without having to write any additional code in a C header file as it was the case until Eiffel Software introduced this new keyword in the external specification with the 4.5 release of the Eiffel Software environment. With the struct encapsulation you can set and retrieve the value of a certain field of a struct. + +If in a header file called `my_header.h`, you have the following declaration of the `Point` structure whose `x` and `y` fields we want to access and set: + + + + /* Definition of `Point' */ +typdef struct point { + int x; + int y; +} Point; + + +Then, the corresponding Eiffel code will look like: + + x (p: POINTER): INTEGER + -- Access field x of struct pointed by `p'. + external + "C [struct %"my_header.h%"] (Point): EIF_INTEGER" + alias + "x" + end + + y (p: POINTER): INTEGER + -- Access field y of struct pointed by `p'. + external + "C [struct %"my_header.h%"] (Point): EIF_INTEGER" + alias + "y" + end + + set_x (p: POINTER; v: INTEGER) + -- Set field x of struct pointed by `p'. + external + "C [struct %"my_header.h%"] (Point, int)" + alias + "x" + end + + set_y (p: POINTER: v: INTEGER) + -- Set field y of struct pointed by `p' with `v'. + external + "C [struct %"my_header.h%"] (Point, int)" + alias + "y" + end + + + +==Windows externals== + +===DLLs=== + +With EiffelStudio you now have two different ways to call C routines exported in a DLL. Why two, because Windows provides two ways to call a C routine in a DLL: +* _cdecl: referred to as the standard way +* __stdcall referred to as the Pascal way + +Therefore if you want to call an external routine defined in a DLL supposed to be called using the `_cdecl` method, you have to use the '''dll32''' sub-language option. For `__stdcall` you need to use the '''dllwin32''' sub-language option. Here is an example: + + + + my_cdecl_routine (a: INTEGER): POINTER + -- Encapsulation of a dll function with the `_cdecl' call mechanism. + external + "C [dll32 %"my_dll.dll%"] (int): EIF_POINTER" + end + + my_stdcall_routine (a: INTEGER): POINTER + -- Encapsulation of a dll function with the `_stdcall' call mechanism. + external + "C [dllwin32 %"my_dll.dll%"] (int): EIF_POINTER" + end + + +{{warning|Using '''dll32''' in cases calling for '''dllwin32''' and vice versa will cause your system to crash, because the C call stack will be corrupted. For more information please read your C compiler documentation. }} + + +===Windows API=== + +As described in the previous section concerning routines exported in a DLL, the Windows API is using the `__stdcall` convention. As a consequence, you cannot use the standard external mechanism to wrap them because it is using the `_cdecl` convention. However, you can easily wrap those function by using the '''macro''' sub-language. + +Here is an example that has been taken from WEL, the Windows Eiffel Library, to encapsulate the Windows `SendMessage` function: +Windows defined SendMessage as: + + +LRESULT SendMessage( + HWND hWnd, // handle to destination window + UINT Msg, // message + WPARAM wParam, // first message parameter + LPARAM lParam // second message parameter +); + + +In WEL, the encapsulation is written as: + + + + cwin_send_message (hwnd: POINTER; msg, wparam, param: INTEGER) + -- SDK SendMessage (without the result) + external + "C [macro %"wel.h%"] (HWND, UINT, WPARAM, LPARAM)" + alias + "SendMessage" + end + + +{{seealso|
+[[C++ Externals|C++ externals]] }} + + + + diff --git a/documentation/18.11/solutions/other-languages/eiffel-external-mechanism/obsolete-external-interfaces/index.wiki b/documentation/18.11/solutions/other-languages/eiffel-external-mechanism/obsolete-external-interfaces/index.wiki new file mode 100644 index 00000000..135bc2fe --- /dev/null +++ b/documentation/18.11/solutions/other-languages/eiffel-external-mechanism/obsolete-external-interfaces/index.wiki @@ -0,0 +1,11 @@ +[[Property:title|Obsolete "external" interfaces]] +[[Property:weight|0]] +[[Property:uuid|1b72d727-711e-2cab-8010-d62842e5230a]] + +{{UnderConstruction}} + + +The interface mechanisms for C and C++ on the following pages are now been superseded in favor of the mechanism described in the Eiffel standard. + + + diff --git a/documentation/18.11/solutions/other-languages/eiffel2java/eiffel2java-class-reference.wiki b/documentation/18.11/solutions/other-languages/eiffel2java/eiffel2java-class-reference.wiki new file mode 100644 index 00000000..4ba267b2 --- /dev/null +++ b/documentation/18.11/solutions/other-languages/eiffel2java/eiffel2java-class-reference.wiki @@ -0,0 +1,5 @@ +[[Property:title|Eiffel2Java class reference]] +[[Property:weight|0]] +[[Property:uuid|2cc96a02-8e55-3663-d0d5-0f2ec3ed4403]] +==View the [[ref:libraries/eiffel2java/reference/index|Eiffel2Java class reference]]== + diff --git a/documentation/18.11/solutions/other-languages/eiffel2java/eiffel2java-sample.wiki b/documentation/18.11/solutions/other-languages/eiffel2java/eiffel2java-sample.wiki new file mode 100644 index 00000000..da840240 --- /dev/null +++ b/documentation/18.11/solutions/other-languages/eiffel2java/eiffel2java-sample.wiki @@ -0,0 +1,104 @@ +[[Property:title|Eiffel2Java Sample]] +[[Property:weight|1]] +[[Property:uuid|90ef17d4-8e23-34dd-1cb8-488533561dd4]] +This example shows how to create an instance of the Java Virtual Machine and the creation of an object of type test, a java class reproduced below: + +(Java Code) + +class test +{ + test () + { + my_integer = 10; + } + + public int my_integer; + public static int my_static_integer; + public void my_method (int arg_int, String arg_string) + { + my_static_integer = arg_int; + my_integer = arg_int; + } +} + + +In order to run properly you need to read [[Eiffel2Java|the library requirement]] . + +===Compiling the example=== + +Since the example is using the `test.java` class, the first step is to compile the java class using the `javac` command line utility from the JDK. Once it is done, copy the `test.class` either into $ISE_EIFFEL\examples\Eiffel2Java\EIFGENs\classic\W_code or else into $ISE_EIFFEL\examples\Eiffel2Java\EIFGENs\classic\F_code, depending on your compilation mode (freezing vs. finalizing). + +===Running the example=== + +Once the example is compiled, you can run it and here is the expected output: + +$ sample +Creating instance of class `test' +Value of `my_integer' is 10 +Value of `my_static_integer' is 0 +Calling `my_method' with (2, "String test") +Value of `my_integer' after call to `my_method' is 2 + + +===Code description=== +(Eiffel Code) + +class + EIFFEL_TO_JAVA +inherit + SHARED_JNI_ENVIRONMENT + +create + make + +feature -- Creation + + make + local + class_test: JAVA_CLASS + instance_of_class_test: JAVA_OBJECT + fid: POINTER + value: INTEGER + j_args: JAVA_ARGS + do + --| Creation of the Java object + class_test := jni.find_class ("test") + create instance_of_class_test.create_instance (class_test, "()V", Void) + + --| Access to a public attribute + fid := instance_of_class_test.field_id ("my_integer", "I") + + -- 'fid' contains the id of the field 'my_integer' + -- 'value' contains the value of the field referenced + -- by 'fid' + + value := instance_of_class_test.integer_attribute (fid) + + --| Access to a static attribute using directly the JAVA_CLASS + fid := class_test.field_id ("my_static_integer", "I") + value := class_test.integer_attribute (fid) + + + --| Access to a static attribute using the attribute 'jclass' + fid := instance_of_class_test.jclass.field_id ("my_static_integer", "I") + value := instance_of_class_test.jclass.integer_attribute (fid) + + --| Access to the method 'my_method' + -- Get the id of 'my_method' + fid := instance_of_class_test.method_id ("my_method", "(ILjava/lang/String;)V") + + -- Create the set of arguments for 'my_method' + create j_args.make(2) + j_args.push_int (2) + j_args.push_string("String test") + + -- Create the set of arguments for 'my_method' + -- Call to the void method referenced by 'fid' + instance_of_class_test.void_method (fid, j_args) + end -- make + +end -- class EIFFEL_TO_JAVA + + + + diff --git a/documentation/18.11/solutions/other-languages/eiffel2java/eiffel2java-tutorial.wiki b/documentation/18.11/solutions/other-languages/eiffel2java/eiffel2java-tutorial.wiki new file mode 100644 index 00000000..fd54efea --- /dev/null +++ b/documentation/18.11/solutions/other-languages/eiffel2java/eiffel2java-tutorial.wiki @@ -0,0 +1,159 @@ +[[Property:title|Eiffel2Java Tutorial]] +[[Property:weight|0]] +[[Property:uuid|2d0fc62b-90e9-650b-2896-d92db66899c9]] +==Introduction== + +The Java interface allows you to call Java routines or attributes from your Eiffel code. It uses the Java Native Interface (JNI) provided by the Java Development Kit (JDK). You can get more information about the JNI at: + +[http://java.sun.com/j2se/1.5.0/docs/guide/jni/ http://java.sun.com/j2se/1.5.0/docs/guide/jni/] + +===Requirements=== +* JDK 1.1.8 or newer should be correctly set up (download it at [http://java.sun.com/javase/downloads/index.jsp http://java.sun.com/javase/downloads/index.jsp] ) +* The environment variable CLASSPATH should defined (check with the JDK documentation on how to do so) and that it contains the Java classes you want to access. +* The environment variables should be setup correctly. See $ISE_EIFFEL\library\Eiffel2Java\README.txt for information how to do this. + +===Limitations=== +* In this version, you can only use one JNI environment. +* Only one thread can interact with the Java Virtual Machine (JVM). +* It is not possible to call Eiffel features from Java program. +* The Eiffel feature `destroy_vm` of `JAVA_VM` calls a C function of the Java NativeInterface that is not fully implemented in jdk 1.1.8. This function, called DestroyJavaVM, always returns -1 in jdk 1.1.8. For further information, go on the JNI pages at the address above. + +==Interface classes== + +===JNI_ENVIRONMENT=== + +Holds information about JNI environment. Potentially many JNI environments can exists at once, but more than one was never tested. This class provide the facilities to interact with the JVM: +* creation of instances of Java Classes +* exceptions mechanism +* destruction of the JVM + +===SHARED_JNI_ENVIRONMENT=== + +Shared JNI environment. Since one JNI is needed per thread we limit Eiffel to having one thread that deals with Java. The class that calls Java routines or attributes must inherit from this class. + +===JAVA_VM=== + +This class is used to initially load the JVM into the running program. This is the Eiffel representation of the JVM. + +===JAVA_CLASS=== + +Access to Java classes. Static methods and attributes are accessed via this class.This is the Eiffel representation of a Java Class. + +===JAVA_OBJECT=== + +This class gives Eiffel access to Java objects. You can use it directly or inherit from to and create a more convenient Eiffel class that makes the Java object look like an Eiffel object. The Eiffel representation of a Java Object. + +{{warning|to access the static fields or routines of a Java Class, you have to use the features of a JAVA_CLASS instance!! }} + +===JAVA_EXTERNALS=== + +JNI external declarations. Don't use this class directly. + +===JAVA_***_ARRAY=== + +Access to Java array of "***". "***" can be all the usual types of Java (byte, short, int, float, double, char, boolean) or object if it is an array of Java Object (a String is considered as an object) + +===JAVA_ARGS=== + +Class representing the arguments that can be passed to a Java method. See below about the signature of the methods + +===JAVA_OBJECT_TABLE=== + +This class provides a mapping between Java and Eiffel objects + +'''Mapping the Eiffel classes and the Java types:''' +The following table describes the mapping of Java primitive types and classes to Eiffel classes. +{| +|- +| '''Java type/class''' +| '''Eiffel class''' +|- +| boolean +| BOOLEAN +|- +| char, byte +| CHARACTER +|- +| short, int +| INTEGER +|- +| long +| INTEGER_64 +|- +| float +| REAL +|- +| double +| DOUBLE +|- +| String +| STRING +|- +| void +| Void +|} + +The interface does the mapping automatically. For example, if you call a Java method that returns a 'float', by using float_method you will get a REAL. + +'''The signature of Java methods and attributes:''' + +When you want to call a Java method or access a field, you need to specify its signature.The Eiffel to Java interface follows the JNI specifications. The table below summarizes the encoding for the Java type signatures: +{| +|- +| '''Signature''' +| '''Java Type''' +|- +| Z +| boolean +|- +| B +| byte +|- +| C +| char +|- +| S +| short +|- +| I +| int +|- +| J +| long +|- +| F +| float +|- +| D +| double +|- +| V +| void +|- +| [type +| type [] +|} + +The signature for a Java class has the following form: + +L fully-qualified-class; + +For example, class String: + +Ljava/lang/String; + + +The signature for a method has the following form: + +(arguments-types) returned-types + +For example, the signature of a method that takes as arguments an integer and a string and return void is: + +(ILjava/lang/String;)V + + + + + + + diff --git a/documentation/18.11/solutions/other-languages/eiffel2java/index.wiki b/documentation/18.11/solutions/other-languages/eiffel2java/index.wiki new file mode 100644 index 00000000..0e38347f --- /dev/null +++ b/documentation/18.11/solutions/other-languages/eiffel2java/index.wiki @@ -0,0 +1,8 @@ +[[Property:title|Eiffel2Java]] +[[Property:weight|4]] +[[Property:uuid|009ed581-1141-7db0-74bb-a9cbca15b904]] +==The Eiffel2Java Library== + +Type: Library
+Platform: Any + diff --git a/documentation/18.11/solutions/other-languages/index.wiki b/documentation/18.11/solutions/other-languages/index.wiki new file mode 100644 index 00000000..55c5a282 --- /dev/null +++ b/documentation/18.11/solutions/other-languages/index.wiki @@ -0,0 +1,14 @@ +[[Property:link_title|With other languages]] +[[Property:title|Including other languages]] +[[Property:weight|-12]] +[[Property:uuid|6029d6d9-bb73-5c74-02f6-70d202a65ceb]] +== Interacting with software in other languages == + +===C, C++, and Java=== +With EiffelStudio you can encapsulate routines written in C , C++ and Java. This makes it possible to use powerful libraries written in other languages while still benefiting from the use of Eiffel for the overall design of your system. + +It is also possible to make Eiffel routines available to be called by these languages. So, you can augment existing systems written in other languages with extensions built with Eiffel. + +===Microsoft COM and .NET=== +In addition to C, C++, and Java, you may find it valuable to use Eiffel with other technologies like Microsoft COM and the multiple languages of Microsoft .NET. You will find information about interacting with these technologies in our documentation specific to [[Microsoft Windows|support for Microsoft Windows]]. + diff --git a/documentation/18.11/solutions/platform-specifics/index.wiki b/documentation/18.11/solutions/platform-specifics/index.wiki new file mode 100644 index 00000000..41481a3a --- /dev/null +++ b/documentation/18.11/solutions/platform-specifics/index.wiki @@ -0,0 +1,6 @@ +[[Property:title|Platform specifics]] +[[Property:description|Eiffel's facilities, tools, and libraries that are targeted to specific operation systems]] +[[Property:weight|12]] +[[Property:uuid|fe9cb24b-3f0f-cb79-8ef0-27c34c851dfe]] +Although the majority of Eiffel is completely platform independent, Eiffel does provide solutions for some development needs that are strictly related to the capabilities of specific operating systems. This book documents Eiffel's facilities, tools, and libraries that are targeted to specific operation systems. + diff --git a/documentation/18.11/solutions/platform-specifics/microsoft-windows/com/eiffelcom-library/eiffelcom-class-reference.wiki b/documentation/18.11/solutions/platform-specifics/microsoft-windows/com/eiffelcom-library/eiffelcom-class-reference.wiki new file mode 100644 index 00000000..19571af0 --- /dev/null +++ b/documentation/18.11/solutions/platform-specifics/microsoft-windows/com/eiffelcom-library/eiffelcom-class-reference.wiki @@ -0,0 +1,5 @@ +[[Property:title|EiffelCOM Class Reference]] +[[Property:weight|0]] +[[Property:uuid|476f2bc7-9afa-125e-0b68-3e4fc30e97f4]] +==View the [[ref:libraries/com/reference/index|EiffelCOM Class Reference]] == + diff --git a/documentation/18.11/solutions/platform-specifics/microsoft-windows/com/eiffelcom-library/eiffelcom-interface-content/index.wiki b/documentation/18.11/solutions/platform-specifics/microsoft-windows/com/eiffelcom-library/eiffelcom-interface-content/index.wiki new file mode 100644 index 00000000..06629f80 --- /dev/null +++ b/documentation/18.11/solutions/platform-specifics/microsoft-windows/com/eiffelcom-library/eiffelcom-interface-content/index.wiki @@ -0,0 +1,17 @@ +[[Property:title|EiffelCOM Interface Content]] +[[Property:weight|-2]] +[[Property:uuid|a6543000-6009-970e-8a68-a6f3b18c1fc6]] +The EiffelCOM library includes the following clusters: +* A [[ref:libraries/com/reference/index|Constants]] cluster provides standard COM constants and enumerations. +* A [[Interfaces|Interfaces]] cluster includes wrappers for standard interfaces that the EiffelCOM wizard does not generate and deferred classes: [[ref:libraries/com/reference/ecom_interface_chart|ECOM_INTERFACE]] , [[ref:libraries/com/reference/ecom_queriable_chart|ECOM_QUERIABLE]] , and [[ref:libraries/com/reference/ecom_stub_chart|ECOM_STUB]] . +* A [[Structures|Structures]] cluster includes wrappers for COM structures and additional data structures. +* A [[ref:libraries/com/reference/index|Support]] cluster provides access to helper classes. + +{{seealso|
+[[COM and Eiffel]]
+[[EiffelCOM Wizard|EiffelCOM wizard]] }} + + + + + diff --git a/documentation/18.11/solutions/platform-specifics/microsoft-windows/com/eiffelcom-library/eiffelcom-interface-content/interfaces.wiki b/documentation/18.11/solutions/platform-specifics/microsoft-windows/com/eiffelcom-library/eiffelcom-interface-content/interfaces.wiki new file mode 100644 index 00000000..f22c2aab --- /dev/null +++ b/documentation/18.11/solutions/platform-specifics/microsoft-windows/com/eiffelcom-library/eiffelcom-interface-content/interfaces.wiki @@ -0,0 +1,23 @@ +[[Property:title|Interfaces]] +[[Property:weight|0]] +[[Property:uuid|7f65c561-cac3-6870-5d1c-6f73beeed872]] +COM interfaces have several facets. First, an interface is a deferred class ("abstract class" in C++ terms). This means that an interface is a specification of a type. Second, an interface pointer represents a COM object, which is callable by a client application. An object can expose several interfaces, or represent several types. + +==ECOM_INTERFACE== + +For each interface listed in a type library, the EiffelCOM wizard generates a deferred class and two effective classes: a proxy of an interface pointer, or a client side class, and a stub of an interface pointer, or a server side class. The deferred interface class inherits from [[ref:libraries/com/reference/ecom_interface_chart|ECOM_INTERFACE]] and has one deferred feature for each interface function. Both effective classes, or implemented interfaces, inherit from the deferred class and implement its functions. The functions of the interface proxy calls the underlying C layer, which in turn calls the COM component while the functions of the interface stub implement the component functionality. + +[[ref:libraries/com/reference/ecom_interface_chart|ECOM_INTERFACE]] holds a pointer to the underlying COM interface. + +==ECOM_QUERIABLE== + +Different languages handle type coercion or type narrowing in different ways. C uses type cast; C++ introduces several type casting mechanisms; Eiffel uses [[ET: Inheritance#Object test|object test]], etc. Every COM interface exposes the QueryInterface function which allows clients to query the COM component for a pointer to another interface. Querying a component for an interface pointer is analogous to using an object test in Eiffel. To accomplish this, EiffelCOM introduces a library class [[ref:libraries/com/reference/ecom_queriable_chart|ECOM_QUERIABLE]], which has the creation routine + + make_from_other (other: ECOM_INTERFACE) + +which queries a COM component internally. Every interface proxy class inherits from [[ref:libraries/com/reference/ecom_queriable_chart|ECOM_QUERIABLE]]. An important difference between this mechanism and using an object test is that if the creation routine fails to initialize a new [[ref:libraries/com/reference/ecom_queriable_chart|ECOM_QUERIABLE]] object, an exception will be raised, whereas, the attached syntax of the object test will merely produce a False result in the case in which no object of the desired type is available. + +==ECOM_STUB== + +[[ref:libraries/com/reference/ecom_stub_chart|ECOM_STUB]] inherits from [[ref:libraries/com/reference/ecom_interface_chart|ECOM_INTERFACE]], and exposes the feature [[ref:libraries/com/reference/ecom_stub_chart|create_item]] which allows creating the underlying COM object. + diff --git a/documentation/18.11/solutions/platform-specifics/microsoft-windows/com/eiffelcom-library/eiffelcom-interface-content/structures.wiki b/documentation/18.11/solutions/platform-specifics/microsoft-windows/com/eiffelcom-library/eiffelcom-interface-content/structures.wiki new file mode 100644 index 00000000..be49ad26 --- /dev/null +++ b/documentation/18.11/solutions/platform-specifics/microsoft-windows/com/eiffelcom-library/eiffelcom-interface-content/structures.wiki @@ -0,0 +1,116 @@ +[[Property:title|Structures]] +[[Property:weight|1]] +[[Property:uuid|fc2071f0-213c-cc88-4914-833b598ceb83]] +The [[ref:libraries/com/reference/index|Structures]] cluster includes wrappers for data structures useful when using the COM technology. + +==ECOM_ARRAY== + +ECOM_ARRAY is a multidimensional, resizable array. It is converted to SAFEARRAY at the COM runtime level. Most languages only support SAFEARRAYs of OLE automation types. + +==ECOM_EXCEPTION== + +ECOM_EXCEPTION provides support for triggering and catching exceptions. According to the COM specification, every feature of a COM interface should return a status code of type HRESULT. HRESULT is a 32 bit integer. The COM specification defines possible exception codes and corresponding human-readable descriptions. + +The status code is mapped by the EiffelCOM runtime to Eiffel exceptions. To raise COM-specific exceptions, the class ECOM_EXCEPTION provides the feature trigger: + + trigger (code: INTEGER) + -- Raise exception with code `code'. + -- See class ECOM_EXCEPTION_CODES for possible values. + + +The class also has several features that help analyzing exceptions and error codes received from the COM runtime. + + hresult: INTEGER + -- Original HRESULT. + require + applicable: is_developer_exception + + hresult_code: INTEGER + -- Status code. + require + applicable: is_developer_exception + + hresult_facility: INTEGER + -- Facility code. + require + applicable: is_developer_exception + + hresult_message: STRING + -- Error message. + require + applicable: is_developer_exception + + +Every call to COM should be wrapped into a rescue clause as follows: + + some_feature + local + retried: BOOLEAN + ... + do + if not retried then + -- Call to COM. + end + rescue + if is_developer_exception then + -- Compare `hresult' to some predefined value + -- and handle various cases, + -- or display a dialog box with an error message + -- `hresult_message'. + end + retried := True + retry + end + + +==ECOM_STRUCTURE== + +ECOM_STRUCTURE is a deferred class which inherits from WEL_STRUCTURE. All wrappers of COM structures inherit from ECOM_STRUCTURE. + +==ECOM_VARIANT== + +ECOM_VARIANT is a wrapper of the VARIANT structure. VARIANT is the Visual Basic equivalent to Eiffel's ANY. In Visual Basic all variable types conform to VARIANT. Since the semantics and runtime architecture of Visual Basic are different from those of Eiffel, there is no simple way to map VARIANT to ANY. Instead, EiffelCOM provides an Eiffel wrapper around the VARIANT structure. + +This wrapper exposes the feature + + variable_type: INTEGER + -- Variable type. See class ECOM_VAR_TYPE for possible values. + + +which specifies the actual type of the variant. The class has multiple features for typed access and setting of variables. + +==ECOM_VARIANT_ACCESS== + +ECOM_VARIANT_ACCESS provides the feature: + + missing: ECOM_VARIANT + -- Value representing the default value of a COM optional argument. + -- Equivalent to an omitted VB argument, or C++ vtMissing, or .NET System.Reflection.Missing. + + +Many COM Automation servers have routines that take arguments with default values. This is very common, for example, in Microsoft Office applications such as Excel and Word. In Visual Basic, such arguments are optional and, when omitted, the server uses the default value. In languages that cannot omit arguments, a special VARIANT value representing the omitted argument must be passed. EiffelCOM applications can pass missing for this purpose. + +For example, the following adds a new workbook to Excel. The default argument tells Excel to decide for itself how many worksheets to put in the new workbook: + +class + MY_EXCEL_APPLICATION + +inherit + APPLICATION_PROXY + + + ECOM_VARIANT_ACCESS + +feature + + add_workbook + local + workbook: WORKBOOK_PROXY + do + workbook := workbooks.add (missing, 0) + end + + + + + diff --git a/documentation/18.11/solutions/platform-specifics/microsoft-windows/com/eiffelcom-library/index.wiki b/documentation/18.11/solutions/platform-specifics/microsoft-windows/com/eiffelcom-library/index.wiki new file mode 100644 index 00000000..5c84bfb0 --- /dev/null +++ b/documentation/18.11/solutions/platform-specifics/microsoft-windows/com/eiffelcom-library/index.wiki @@ -0,0 +1,15 @@ +[[Property:title|EiffelCOM Library]] +[[Property:weight|8]] +[[Property:uuid|b5c66d71-515f-3c73-9c67-c50e4a8d6685]] +Type: Library
+Platform: Windows
+ +==EiffelCOM Library== + +The EiffelCOM library provides support classes for the code generated by the EiffelCOM wizard. It has wrappings for standard COM data types such as VARIANT, SAFEARRAY, CURRENCY, DECIMAL, IUnknown, IDispatch, etc. + +{{seealso|
+[[EiffelCOM Wizard|EiffelCOM wizard]] }} + + + diff --git a/documentation/18.11/solutions/platform-specifics/microsoft-windows/com/eiffelcom-wizard/com-and-eiffel/access-type.wiki b/documentation/18.11/solutions/platform-specifics/microsoft-windows/com/eiffelcom-wizard/com-and-eiffel/access-type.wiki new file mode 100644 index 00000000..24d56299 --- /dev/null +++ b/documentation/18.11/solutions/platform-specifics/microsoft-windows/com/eiffelcom-wizard/com-and-eiffel/access-type.wiki @@ -0,0 +1,241 @@ +[[Property:title|Access Type]] +[[Property:weight|5]] +[[Property:uuid|0d049617-9737-7cc8-810a-9f6f9ca603ec]] +Regardless of its location, a COM components can be accessed either through OLE '''Automation''' or '''directly''' through the interface's virtual table. + +==Automation== + +Accessing a COM component through Automation means using a well-known interface called '''IDispatch''' to access to a group of methods and properties. This interface includes the method invoke that allows calling a method, setting or getting a property on the Automation server. + +One advantage of this approach is that the interface has a known virtual table layout. As a result, Windows can include a built-in marshaler for that interface (See [[Deeper into COM]] for information on marshalers). The supported types (known as Automation types) and their Eiffel equivalents are listed in the following table: + +{| +|- +| +COM Type + +| +Eiffel equivalent + +| +Description + +|- +| +VARIANT_BOOL + +| +BOOLEAN + +| +Standard boolean + +|- +| +unsigned char + +| +CHARACTER + +| +Standard character + +|- +| +double + +| +DOUBLE + +| +Standard double + +|- +| +float + +| +REAL + +| +4-byte real value + +|- +| +int + +| +INTEGER + +| +Standard integer + +|- +| +long + +| +INTEGER + +| +Standard integer + +|- +| +short + +| +INTEGER + +| +2-byte integer + +|- +| +BSTR + +| +STRING + +| +Standard string + +|- +| +CURRENCY + +| +ECOM_CURRENCY + +| +Currency value + +|- +| +DATE + +| +DATE_TIME + +| +Standard date + +|- +| +SCODE + +| +INTEGER + +| +Return status + +|- +| +Interface IDispatch * + +| +ECOM_INTERFACE + +| +Automation interface + +|- +| +Interface IUnknown * + +| +ECOM_INTERFACE + +| +Generic interface + +|- +| +dispinterface + +| +ECOM_INTERFACE + +| +Automation interface + +|- +| +Coclass Typename + +| +TYPE_NAME + +| +Component main class + +|- +| +SAFEARRAY(TypeName) + +| +ECOM_ARRAY [TypeName] + +| +Array + +|- +| +TypeName* + +| +CELL [TypeName] + +| +Pointer to type + +|- +| VARIANT +| ECOM_VARIANT +| Variant value +|- +| enum +| INTEGER +| Enumeration +|- +| +Decimal + +| +ECOM_DECIMAL + +| +Decimal value + +|} + +Another advantage is a more dynamic discovery of the methods and properties of a component at runtime. Indeed the IDispatch interface also includes methods to determine whether or not a method or property is available and, in the case that it is available, get its identifier. This process is called late binding and allows component to discover at runtime the availability of functionality on other components. + +This approach has also a lot of drawbacks. First, late binding is not an efficient way of calling a function on an interface. This is because first its identifier must be requested, and then the function called. That's two round trips which can be expensive in a distributed environment. Second, since the marshaler is built-in, it has to know in advance all the possible types that a function can accept to be able to marshal the corresponding data. Consequently, there is a limitation on the number of types that one can use in signatures of functions on an Automation compatible interface. The set of available types is called '''Variant''' and cover most of the standard types. It does not allow however the passing of complex user defined data types. + +For these reasons Automation is mostly used in scripting environments (where speed is not an important factor) to accomplish simple tasks. + +==Direct Access== + +Direct interface access is the preferred way to access remote servers where speed becomes a concern and data types are specific to the application. The first interface pointer on the component is obtained through the class object (see [[Coclass|Class Object]] ). Other interfaces on the component are obtained by calling the '''QueryInterface''' function. + +Because information on any interface cannot be accessed dynamically, the description of the interfaces must be provided to tools that need to handle the components such as the EiffelCOM wizard. The official way of describing components and interfaces is through Interface Definition Language (IDL). Once an IDL file has been written to describe a component it can be compiled with MIDL (the Microsoft IDL compiler) to generate both a type library and the code for the marshaler specific to that interface. + +==EiffelCOM== + +One idea behind EiffelCOM is that the details of how a component is accessed should be of no concern to an EiffelCOM programmer. Of course the programmer should be able to choose which kind of access he or she wants to use, but this choice should have no impact on the design of the Eiffel system itself. For that reason, the Eiffel code generated by the wizard follows the same architecture independently of the choice made for interface access and marshaling. The differences in access are handled in the EiffelCOM runtime library where the actual calls to the components are implemented. + + +{{seealso|
+[[EiffelCOM Library|EiffelCOM library]]
+[[EiffelCOM: Introduction|Introduction]]
+[[COM Concepts|COM Concepts]]
+[[COM Interfaces|COM Interfaces]]
+[[Coclass|Coclasses]]
+[[The Component Location|Component Location]]
+[[Deeper into COM|Deeper into COM]] }} + + + + diff --git a/documentation/18.11/solutions/platform-specifics/microsoft-windows/com/eiffelcom-wizard/com-and-eiffel/coclass.wiki b/documentation/18.11/solutions/platform-specifics/microsoft-windows/com/eiffelcom-wizard/com-and-eiffel/coclass.wiki new file mode 100644 index 00000000..3af18e3d --- /dev/null +++ b/documentation/18.11/solutions/platform-specifics/microsoft-windows/com/eiffelcom-wizard/com-and-eiffel/coclass.wiki @@ -0,0 +1,28 @@ +[[Property:title|Coclass]] +[[Property:weight|3]] +[[Property:uuid|7f91f9ce-e042-1d48-9d01-f9b794269ec4]] +We saw earlier that [[COM Interfaces]] can be perceived as views of a component. This conceptual representation actually maps the implementation of an EiffelCOM component. This is because the coclass inherits from the interfaces and implements their [[uuid:b8c10baa-4f50-adfe-a6f8-9cb56a8f1917#Deferred feature|deferred features]]. Indeed, interfaces are [[uuid:b8c10baa-4f50-adfe-a6f8-9cb56a8f1917#Deferred class|deferred classes]] with all features deferred that are accessible by [[uuid:b8c10baa-4f50-adfe-a6f8-9cb56a8f1917#Client|clients]]. The coclass is an Eiffel class that inherits from these interfaces and implements all the features. This design is not specific to Eiffel though, and can be found in other languages as well. The coclass defines the behavior of the interface functions.
+ +==Class Object== +Also, we have seen that interfaces are accessed through interface pointers. But how does a client obtain one of these? +The answer lies in the class object. The name of this module should really be coclass factory since its goal is to spawn instances of the coclass on request. Class objects are accessed by COM whenever a client requests a new instance of the associated component. COM loads the class object and asks it to provide the interface pointer requested by the client. + +The way a class object is loaded in memory (this process is called activation) depends on the location of the component (See [[The Component Location|Location]] for a description of the possible locations of a component). If the component is an in-process server, then the class object is called directly through the functions exported from the DLL. If the component is an out-of-process server, then it provides COM with a pointer to the class object. In both cases, once the component is loaded, COM has access to the class object and can call it, should a client request a new instance of a component. + +[[Image:com-1|Component Creation]] + +The code for the class object is generated by the EiffelCOM wizard so that Eiffel programmers will not have to worry about it. + +{{seealso| +[[EiffelCOM Wizard|EiffelCOM wizard]]
+[[EiffelCOM Library|EiffelCOM library]]
+[[EiffelCOM: Introduction|Introduction]]
+[[COM Concepts|COM Concepts]]
+[[COM Interfaces|COM Interfaces]]
+[[The Component Location|Component Location]]
+[[Access Type|Access Type]]
+[[Deeper into COM|Deeper into COM]] }} + + + + diff --git a/documentation/18.11/solutions/platform-specifics/microsoft-windows/com/eiffelcom-wizard/com-and-eiffel/com-concepts.wiki b/documentation/18.11/solutions/platform-specifics/microsoft-windows/com/eiffelcom-wizard/com-and-eiffel/com-concepts.wiki new file mode 100644 index 00000000..b590cb7d --- /dev/null +++ b/documentation/18.11/solutions/platform-specifics/microsoft-windows/com/eiffelcom-wizard/com-and-eiffel/com-concepts.wiki @@ -0,0 +1,29 @@ +[[Property:title|COM Concepts]] +[[Property:weight|1]] +[[Property:uuid|9cb19fc1-3d26-5752-6232-ea23f2668c32]] +This page defines some concepts that are fundamental to the entire technology of COM. + +==The COM Standard== +COM is a standard that describes how a binary component can communicate with the outside world. + +==Interfaces== +The component communicates through well-defined interfaces. Each interface is a specification of a group of properties and methods. It is important that the interface does not contain the implementation of the properties and methods, only their specifications (signatures). + +==Coclasses== +The actual implementation lies in the [[Coclass|'''coclass''']]. There can be different implementations of the same interface in different coclasses. + +==Class Objects or Class Factories== +Finally, each coclass can be instantiated using a class object or class factory. + + +These notions will be discussed further in the upcoming sections. + +{{seealso|
+[[EiffelCOM Library| EiffelCOM library]]
+[[EiffelCOM: Introduction|Introduction]]
+[[COM Interfaces|COM Interfaces]]
+[[Coclass|Coclasses]]
+[[The Component Location| Component Location]]
+[[Access Type|Access Type]]
+[[Deeper into COM|Deeper into COM]] }} + diff --git a/documentation/18.11/solutions/platform-specifics/microsoft-windows/com/eiffelcom-wizard/com-and-eiffel/com-interfaces.wiki b/documentation/18.11/solutions/platform-specifics/microsoft-windows/com/eiffelcom-wizard/com-and-eiffel/com-interfaces.wiki new file mode 100644 index 00000000..67872f2d --- /dev/null +++ b/documentation/18.11/solutions/platform-specifics/microsoft-windows/com/eiffelcom-wizard/com-and-eiffel/com-interfaces.wiki @@ -0,0 +1,22 @@ +[[Property:title|COM Interfaces]] +[[Property:weight|2]] +[[Property:uuid|1dbc3fb2-cf0b-b129-1102-ba01e26d8f74]] +Interfaces are at the heart of any COM component. Interfaces are described in the definition file of a component. They consist of a group of semantically related functions that can be accessed by the clients of the component. Although they are a specification, they also have a physical representation. A client can request a pointer on an interface and access the component functions through that pointer. Interfaces are the only possible way to access functions from a component. They enforce information hiding by ensuring that clients can access only the component's public functions. + +Interfaces also define the type of a component. Each interface corresponds to a specific view of the component. In a way, this can be compared to polymorphism in the object-oriented world. Whenever an interface from a component is requested, only the functions defined on that interface are accessible, as if the component were polymorphically cast into an object of that type. + +The COM specification requires that any interface provide access to all interfaces on the same component. All interfaces should include a specific function called '''QueryInterface''' that will provide a pointer on any other interface of the component. Interfaces are identified with a globally unique identifier (GUID) guaranteed to be unique in time and space. Since this function has to be on every interface, it has been abstracted into a specific interface called '''IUnknown''' from which all other interfaces must inherit. + +The two other functions exposed by '''IUnknown''' are '''AddRef''' and '''Release'''. These functions should be called when a client gets a reference to an interface and when it discards that reference, respectively. These two functions define the life-cycle of a component at runtime by implementing reference counting—a common way of determining when a component can be removed from memory: when the reference count reaches zero, this signifies that there are no more clients are using that component. You might worry that this business of reference counting will the source of problems such as memory leaks. You would be right, should you choose a low-level language in which to implement your components, since it requires strict discipline on the part of the programmers. Fortunately, you will never have to implement or use these functions in Eiffel: all the processing related to IUnknown is provided by the EiffelCOM runtime. Calls to '''QueryInterface''' are done "behind the scene" and only when needed. The component life-cycle (i.e. calls to '''AddRef''' and '''Release''') is also taken care of by the EiffelCOM runtime. + +{{seealso|
+[[EiffelCOM Library|EiffelCOM library]]
+[[EiffelCOM: Introduction|Introduction]]
+[[COM Concepts|COM Concepts]]
+[[Coclass|Coclasses]]
+[[The Component Location|Component Location]]
+[[Access Type|Access Type]]
+[[Deeper into COM|Deeper into COM]] }} + + + diff --git a/documentation/18.11/solutions/platform-specifics/microsoft-windows/com/eiffelcom-wizard/com-and-eiffel/component-location.wiki b/documentation/18.11/solutions/platform-specifics/microsoft-windows/com/eiffelcom-wizard/com-and-eiffel/component-location.wiki new file mode 100644 index 00000000..cd88ebae --- /dev/null +++ b/documentation/18.11/solutions/platform-specifics/microsoft-windows/com/eiffelcom-wizard/com-and-eiffel/component-location.wiki @@ -0,0 +1,28 @@ +[[Property:title|The Component Location]] +[[Property:weight|4]] +[[Property:uuid|083c0120-2eda-9353-ceae-f63e7f407341]] + +==Types of Components== +Certainly you've heard of ActiveX, DirectX, OCX, COM+, ADO+, ASP, and other Microsoft technologies. These are all technologies that use the COM standard. This section focuses on categorizing COM components according to their properties as well as the context in which they are used. The categorization will define how the EiffelCOM wizard should be used to wrap or create a component. The first criterion that defines the type of component is its location at run time: will the component be loaded in the client process (in-process) or will the component be a remote server for a distributed application (out-of-process)? In the former case, the component is compiled as a Dynamic Link Libraries (DLL) while in the latter case it is a standard executable. + +==In-process Components== + +Typical instances of DLL components are found in technologies such as OCX, ActiveX, or ASP. These are small, downloadable binaries that will be loaded and executed in a container. The container acts as a client of the component. The EiffelCOM wizard provides the ability to wrap such a component by providing access to its interface to any Eiffel container. It is also possible to create a new In-process component in Eiffel. +One main difference with out-of-process components (other than the nature of the module, DLL versus executable) is the way in-process components are activated. In the case of out-of-process components, the component will specify COM when it is ready to receive calls from client. In the case of an in-process server the call is coming directly from COM: COM first loads the DLL into the client process and then calls the exported function DllGetClassObject to access the component class object. The other three exported functions of an in-process component are DllRegister to register the component in the Windows registry, DllUnregister to unregister the component from the registry and finally DllCanUnloadNow which gets called by COM whenever it tries to unload the component from memory. These four functions must be accessible from outside the DLL for the in-process component to work properly. + +==Out-of-process Components== +These components are standard executable acting as servers that can be accessed locally or over a network. Typically used in a three tier client server architecture, the major difference with in-process servers (other than the module type - executable instead of DLL) is their lifetime. In-process components are typically loaded to achieve a specific task and unloaded just after the task is complete. Out-of-process components are servers, intended to run continuously. The EiffelCOM wizard allows to build clients for such servers in Eiffel. It also provides the ability to create such servers. + + +{{seealso|
+[[EiffelCOM Library|EiffelCOM library]]
+[[EiffelCOM: Introduction|Introduction]]
+[[COM Concepts|COM Concepts]]
+[[COM Interfaces|COM Interfaces]]
+[[Coclass|Coclasses]]
+[[Access Type|Access Type]]
+[[Deeper into COM|Deeper into COM]] }} + + + + diff --git a/documentation/18.11/solutions/platform-specifics/microsoft-windows/com/eiffelcom-wizard/com-and-eiffel/deeper-com.wiki b/documentation/18.11/solutions/platform-specifics/microsoft-windows/com/eiffelcom-wizard/com-and-eiffel/deeper-com.wiki new file mode 100644 index 00000000..c9591cd3 --- /dev/null +++ b/documentation/18.11/solutions/platform-specifics/microsoft-windows/com/eiffelcom-wizard/com-and-eiffel/deeper-com.wiki @@ -0,0 +1,48 @@ +[[Property:title|Deeper into COM]] +[[Property:weight|6]] +[[Property:uuid|f28ee911-1b15-260c-a290-540b9531113a]] +'''Apartment models''' and '''Marshalling''' are two more interesting areas of COM internals. It is not necessary to understand these details to use the EiffelCOM wizard, but the knowledge could improve decision making when designing new EiffelCOM components. + +==Apartment models== + +The first interesting subject that warrants more in-depth coverage is the execution context of a component. Components can run in the same process as the client, but can also run in a separate process, even on a different machine. But this only takes processes into account. What happens if a component uses multithreading to achieve it tasks? In the case of remote servers, this is a very real possibility. The problem is that a server does not (and should not) know in advance the nature of its clients. It cannot assume that the client will be able to take advantage of its multithreading capabilities. Conversely a multithreaded client should not rely on the server's ability to handle concurrent access. + +The solution chosen in the COM specification is to define an additional execution context called an '''apartment'''. When COM loads a component it creates the apartment in which the component will run. Multiple instances of a multithreaded component will coexist in the same apartment since asynchronous calls will be handled correctly and there is no need to add any synchronization layer. On the other hand, single threaded components will be alone in their apartments and any concurrent calls coming from clients will be first synchronized before entering the apartment. These two behaviors define two different kinds of apartments: '''Multi Threaded Apartments''' (MTA) and '''Single Threaded Apartments''' (STA). + + +[[Image:com-2|Apartments]] + + +Apartments solve the problem of concurrency by removing the necessity of knowing the multithreaded capability of a component and its clients. Multithreaded clients can always make asynchronous calls and depending on whether the component handles concurrent access or not, they will be forwarded directly or synchronized first. There can be multiple instances of an STA running in one process, while there can be at most one MTA. + +==Marshalling== + +COM calls can "cross" apartment boundaries. Components from an STA can make calls to components running in an MTA and vice versa. These apartments might be running in different processes or even on different machines. The approach chosen in the COM specification for cross-apartment calls involves a pattern of '''proxies''' and '''stubs'''. + +The idea is to "trick" the client of an interface by providing an interface proxy in its apartment. The proxy includes exactly the same functions as the interface itself but the implementations will merely forward the call to the actual interface. The client's behavior is the same whether it is dealing the actual interface or just a proxy. A point of interest in this approach is that the client implementation is independent from the location of the component. + +But this is not quite the whole story. The call that goes to a proxy will not be forwarded to the actual interface but to its stub. The stub is the counterpart of the proxy—it represents the client for the interface. The interface's behavior is the same whether it is communicating with the actual client or a stub. Although it is not totally true that the component implementation is independent from the location of the client, the stub pattern still helps keep code identical for the implementation of the interface themselves. The implementation of a component will still be different between an in-process or out-of-process component, since it will have to be a DLL in one case and a executable in the other. The design of the interfaces might also differ since out-of-process servers will tend to avoid too many round trips. + + +[[Image:com-3|Cross Apartment Calls]] + + +There is one proxy/stub pair per interface. The proxy or the stub is loaded dynamically only when needed. This proxy/stub pair constitute the '''marshaller'''. The reason for having a single name for two different things comes from how MIDL generates its code. MIDL will produce files for one DLL in which both the proxy and the stub will be included. This DLL is the marshaller. + +==Summary== + +This brief introduction to the Component Object Model should be enough to get started with the EiffelCOM wizard. It specifies the main characteristics that define the type of a component and that need to be given to the wizard along with the definition file. + + +{{seealso|
+[[EiffelCOM Library|EiffelCOM library]]
+[[COM Concepts|COM Concepts]]
+[[Deeper into COM|Deeper into COM]]
+[[COM Interfaces|COM Interfaces]]
+[[Coclass|Coclasses]]
+[[The Component Location|Component Location]]
+[[Access Type|Access Type]] }} + + + + diff --git a/documentation/18.11/solutions/platform-specifics/microsoft-windows/com/eiffelcom-wizard/com-and-eiffel/eiffelcom-introduction.wiki b/documentation/18.11/solutions/platform-specifics/microsoft-windows/com/eiffelcom-wizard/com-and-eiffel/eiffelcom-introduction.wiki new file mode 100644 index 00000000..170e2962 --- /dev/null +++ b/documentation/18.11/solutions/platform-specifics/microsoft-windows/com/eiffelcom-wizard/com-and-eiffel/eiffelcom-introduction.wiki @@ -0,0 +1,22 @@ +[[Property:title|EiffelCOM: Introduction]] +[[Property:weight|0]] +[[Property:uuid|adadc51d-3dec-320a-9405-0842eacca4f7]] +This chapter attempts to cover enough information about COM for Eiffel developers to use the EiffelCOM wizard in an effective way. It does not cover all of COM ... that would (and does) require volumes. Still, this chapter presents the main concepts needed to understand how to build an EiffelCOM system. + +Briefly stated, the Component Object Model is a Microsoft binary standard that establishes how two binary units can access each other at runtime. Such binary units can run in the same process, in different processes on the same machine, or even on different machines. Components can be implemented in any language as long as the compiler produces binaries compliant with the COM standard. + +The advantages of such an approach include an increased reusability (binary reuse), a better version management (COM standard implies that new component versions are compatible with the older ones), and a built-in runtime environment. The binary reuse aspect of COM, augmented with the software quality of Eiffel, offers the developer a platform for increased productivity. + + +{{seealso|
+[[EiffelCOM Library| EiffelCOM library]]
+[[COM Concepts|COM Concepts]]
+[[COM Interfaces| COM Interfaces]]
+[[Coclass| Coclasses]]
+[[The Component Location|Component Location]]
+[[Access Type|Access Type]]
+[[Deeper into COM|Deeper into COM]] }} + + + + diff --git a/documentation/18.11/solutions/platform-specifics/microsoft-windows/com/eiffelcom-wizard/com-and-eiffel/index.wiki b/documentation/18.11/solutions/platform-specifics/microsoft-windows/com/eiffelcom-wizard/com-and-eiffel/index.wiki new file mode 100644 index 00000000..908c2653 --- /dev/null +++ b/documentation/18.11/solutions/platform-specifics/microsoft-windows/com/eiffelcom-wizard/com-and-eiffel/index.wiki @@ -0,0 +1,9 @@ +[[Property:title|COM and Eiffel]] +[[Property:weight|-15]] +[[Property:uuid|32e79152-1e8f-43cd-e014-a83aab18e440]] +==About COM and Eiffel== + +{{seealso|[[EiffelCOM Library| EiffelCOM library]] }} + + + diff --git a/documentation/18.11/solutions/platform-specifics/microsoft-windows/com/eiffelcom-wizard/eiffelcom-wizard-guided-tour/accessing-com-component.wiki b/documentation/18.11/solutions/platform-specifics/microsoft-windows/com/eiffelcom-wizard/eiffelcom-wizard-guided-tour/accessing-com-component.wiki new file mode 100644 index 00000000..19e138aa --- /dev/null +++ b/documentation/18.11/solutions/platform-specifics/microsoft-windows/com/eiffelcom-wizard/eiffelcom-wizard-guided-tour/accessing-com-component.wiki @@ -0,0 +1,58 @@ +[[Property:title|Accessing a COM Component]] +[[Property:weight|2]] +[[Property:uuid|d27be959-8f8e-a6f0-cd20-12f6ce71307f]] +This third tutorial describes how to access a COM component. It will build a client of the StringManipulator component built in the first tutorial. + +==Step by step instructions== +# Launch the EiffelCOM Wizard. Note: if you are running Windows 7, you will need to right-click "EiffelCOM Wizard" in the start menu and select "Run as administrator". +# In '''Project''', in the '''Current project''' input field, type in ''string_manipulator_client'' and press '''Enter'''. +# In '''Project Type''', choose ''Access an existing COM component''. +# In '''Component Information''', click the browse button (the button with '''...''') and open the file ''$ISE_EIFFEL\examples\com\wizard\string_manipulator\string_manipulator.idl'' where ''$ISE_EIFFEL'' represents the path to the EiffelStudio installation directory. +# Click '''Next'''. +# In '''Component Type''', choose ''In-process (*.dll)''. +# In '''Generation Options''', click the browse button and select the directory where the project should be created (which we will later refer to as the ''destination folder''). Choose ''$ISE_EIFFEL\examples\com\wizard\string_manipulator\generated\client'' where ''$ISE_EIFFEL'' represents the path to the EiffelStudio directory. +# Make sure both '''Compile C code''' and '''Compile Eiffel code''' are checked. +# Select '''Overwrite existing files'''. +# Click '''Generate'''. +# Wait until the wizard is done. + +==Temporary Work-Around== +Note that because Eiffel as a language has evolved somewhat since the '''EiffelCOM Wizard''' was last released, the compile will fail on the last (Eiffel) portion of the compile. However, in this case, it is not sufficient to simply launch EiffelStudio, change the configuration, and finish the compile. The reason is that the EiffelCOM Wizard WOULD HAVE built a pre-compiled library from the C and Eiffel files just generated, and this is important because later steps in this Guided Tour depend upon that library to be there. Thus, to navigate this, you will need to execute the steps below. + +# Let the EiffelCOM Wizard compilation proceed until it fails due to a Eiffel syntax error. Leave the EiffelCOM Wizard running. We will need it below. +# Click the EiffelStudio button to launch EiffelStudio on the project file that was generated above. +# The first window presented is the "Choose Your Directory" dialog box. UNCHECK the "Compile project" checkbox. Then click '''OK'''. +# Once EiffelStudio is open, click the ''Change Project Settings'' toolbar button, and navigate to ''Target: default'' in the navigation pane. +# Set the "Void safety" setting to "No", and set the "Syntax" setting to "Transitional syntax". +# Click '''OK''' in the Project Settings dialog box. +# DO NOT COMPILE, but exit EiffelStudio. +# Copy the .ECF file just modified to a safe location. In Windows Explorer, navigate to the ...\string_manipulator\generated\client\Client\ folder. Copy the .ECF file (string_manipulator_idl_client.ecf) outside the project directory temporarily (for example, to the ...\string_manipulator\generated\client\ folder. This .ECF file has the settings that will permit the EiffelCOM Wizard compilation to succeed. +# Place this safe copy of the modified .ECF file on the clipboard, ready to copy. Navigate to the folder where you made a copy of the above .ECF file, and in Windows Explorer, while the .ECF file is selected, from the Edit menu, select ''Copy'' (or hit Ctrl-C on the keyboard to make a copy of the file on the Windows clipboard). +# In Windows Explorer, navigate back to the ...\string_manipulator\generated\client\Client\ folder, but don't do anything yet. +# Quickly execute the following 2 steps: A) in the EiffelCOM Wizard, click the '''Generate''' button. B) After about 2 seconds, after the files have been generated and the C/C++ compilations have started, return to the Windows Explorer window in the ...\string_manipulator\generated\client\Client\ folder, and hit Ctrl-V on the keyboard to PASTE the saved .ECF file into the folder. Confirm when it prompts you whether to replace the .ECF file that was just generated (in Windows 7, this will be a "Copy and Replace" choice). +# Watch the EiffelCOM Wizard Output window as it completes successfully this time. +# With Windows Explorer, navigate to the ...\string_manipulator\generated\client\Client\EIFGENs\default\W_code\msc\ folder and confirm there is a file there named precomp.lib . + +Now you are ready to continue with the Guided Tour. + + +==First Look at the Generated Code== +At the end of the processing the '''EiffelStudio''' button becomes enabled. Click on it. This will automatically start EiffelStudio with the generated project so you can more easily navigate through the created Eiffel classes. + +{{note|When accessing a COM component the EiffelCOM Wizard will generate a precompiled library which includes all the generated classes. This allows for easy browsing of the generated classes, however a precompilation project is read-only, so you need to start another EiffelStudio to reuse the generated classes. The interesting classes are all related to the coclass proxy STRING_MANIPULATOR_PROXY. The proxy is the Eiffel class that gives access to the component. Each feature on the proxy calls the corresponding interface function on the component. You can use the EiffelStudio opened by the wizard to browse through the generated classes and study the class hierarchy.}} + +==Implementing a Client== +To implement a client of the StringManipulator component open a new EiffelStudio. Create the project in ''$ISE_EIFFEL\examples\com\wizard\string_manipulator\client'' using the ecf file found in that directory. Freeze and run the project. You are now accessing the previously built component and calling functions on its interfaces! The class MY_STRING_MANIPULATOR inherits from the generated STRING_MANIPULATOR_PROXY and redefines the feature ''replace_substring_user_precondition''. The generated interfaces include contracts for each exposed function. You can redefine the ''user_precondition'' features to implement your own preconditions. + +{{note|If a COM component should be added to an existing client, the generated ecf file can be added as a library. }} + +==Contracts== +Contracts can be broken directly on the proxy in which case you will get a standard contract violation in the client. If contracts are broken on the server then the exception will be forwarded by the EiffelCOM runtime to the client. The feature replace_substring_user_precondition in MY_STRING_MANIPULATOR includes has some assertions. Comment them out. Now the contract of the [[ref:libraries/base/reference/string_8_chart|replace_substring ]] feature is wrong and erroneous calls can be made. Quick melt the changes and run the client. Enter some invalid numbers in the fields used to call this feature. After you click '''Replace''' you will see an error message box warning you that a precondition was violated on the server side. This demonstrates contracts `over the wire'. The precondition was violated in the server; this exception was caught by the EiffelCOM runtime and sent back to the client. +{{seealso|
+[[Creating a New COM Component|Creating a New COM Component]]
+[[Creating a new component from an Eiffel project|Creating a new component from an Eiffel Project]] }} + + + + + diff --git a/documentation/18.11/solutions/platform-specifics/microsoft-windows/com/eiffelcom-wizard/eiffelcom-wizard-guided-tour/creating-new-com-component.wiki b/documentation/18.11/solutions/platform-specifics/microsoft-windows/com/eiffelcom-wizard/eiffelcom-wizard-guided-tour/creating-new-com-component.wiki new file mode 100644 index 00000000..8aba4cb7 --- /dev/null +++ b/documentation/18.11/solutions/platform-specifics/microsoft-windows/com/eiffelcom-wizard/eiffelcom-wizard-guided-tour/creating-new-com-component.wiki @@ -0,0 +1,52 @@ +[[Property:title|Creating a New COM Component]] +[[Property:weight|0]] +[[Property:uuid|f8298b7d-c1a4-c8cc-1821-066f90e7e6e0]] +This first tutorial describes creating a COM component from a COM definition file that is either an IDL file or a Type Library. The tutorial focuses on creating an in-process (DLL) component, called StringManipulator. The component exposes one interface IString that includes the functions ReplaceSubstring and PruneAll corresponding respectively to the features [[ref:libraries/base/reference/string_8_chart|replace_substring]] and [[ref:libraries/base/reference/string_8_chart|prune_all]] of the class [[ref:libraries/base/reference/string_8_chart|STRING]] from the EiffelBase library. IString also exposes the property String which represents the manipulated string. The property can be set or read. + +==Step by Step Instructions== +# Launch EiffelCOM Wizard. Note: if you are running Windows 7, you will need to right-click "EiffelCOM Wizard" in the start menu and select "Run as administrator". +# In the '''Current project''' input field, type in ''string_manipulator_server'' and press '''enter'''. +# In '''Project Type''', choose ''Create a new COM component''. +# In '''Component Information''', click the browse button (the button with '''...''') and open the file ''$ISE_EIFFEL\examples\com\wizard\string_manipulator\string_manipulator.idl'' where ''$ISE_EIFFEL'' represents the path to the EiffelStudio installation directory. +# Make sure '''Generate and use marshaller DLL''' is not checked. +# Click '''Next'''. +# In '''Component Type''', choose ''In-process (*.dll)''. +# In '''Generation Options''', click the browse button and select the directory where the project should be created (which we will later refer to as the ''destination folder''). Choose ''$ISE_EIFFEL\examples\com\wizard\string_manipulator\generated\component'' where ''$ISE_EIFFEL'' represents the path to the EiffelStudio installation directory. +# Make sure both '''Compile C code''' and '''Compile Eiffel code''' are checked. +# Make sure '''Clean destination folder prior to generation''' is selected. +# Click '''Generate'''. +# Wait until the wizard is done. + +{{note|Because Eiffel as a language has evolved somewhat since the '''EiffelCOM Wizard''' was last released, you will need to go into the project file under the "Server" subdirectory (string_manipulator_idl.ecf, preferrably from within EiffelStudio) and change the following settings for this example to compile: Select "Target" in the navigator pane, then change the "Void safety" setting to "No", and "Syntax" to "Transitional syntax". Click '''OK''' in the Project Settings dialog box. Now you can finish the compile from within EiffelStudio. Note that there will be a few warnings about obsolete calls. These can be ignored for now.}} + + +==First Look at the Generated Code== + +At the end of the processing the '''EiffelStudio''' button becomes enabled. Click on it. This will automatically start EiffelStudio with the generated project so you can navigate more easily through the created Eiffel classes. You can save the processing output by clicking the '''Save''' button. + +The deferred class STRING_MANIPULATOR_COCLASS represents the component and exposes all its functionality. It inherits from ISTRING_INTERFACE which corresponds to the '''IString''' interface and has one heir STRING_MANIPULATOR_COCLASS_IMP which implements all the deferred features. The default implementation in the heir is empty. + +==Implementing the Component== +To do something more interesting than merely returning an error to the client, edit the implementation of the STRING_MANIPULATOR_COCLASS_IMP class. There is an implementation of the class in ''$ISE_EIFFEL\examples\com\wizard\string_manipulator\server''\. Copy this file over to ''$ISE_EIFFEL\examples\com\wizard\string_manipulator\generated\component\server\component'' and freeze the project. Voila! You have your first EiffelCOM component up and running. + +==Running the Component== +The component needs to be registered prior to being loaded. Register an out-of-process component using the following syntax: + +system_name.exe -Regserver +where ''system_name'' is the name of the component executable file. Register an in-process component using the ''regsvr32'' utility using the following syntax: + +regsvr32 system_name.dll +where ''system_name'' is the name of the dll (e.g. string_manipulator). So to register the StringManipulator component, run: + +cd $ISE_EIFFEL\examples\com\wizard\string_manipulator\generated\component\server\EIFGENs\default\W_code +regsvr32 string_manipulator_idl.dll +Once registered, follow the steps described in [[Accessing a COM Component|Accessing a COM Component]] to build the component's client. + + +{{seealso|
+[[Creating a new component from an Eiffel project|Creating a new component from an Eiffel Project]]
+[[Accessing a COM Component|Accessing a COM Component.]] }} + + + + diff --git a/documentation/18.11/solutions/platform-specifics/microsoft-windows/com/eiffelcom-wizard/eiffelcom-wizard-guided-tour/creating-new-component-eiffel-project.wiki b/documentation/18.11/solutions/platform-specifics/microsoft-windows/com/eiffelcom-wizard/eiffelcom-wizard-guided-tour/creating-new-component-eiffel-project.wiki new file mode 100644 index 00000000..226e455f --- /dev/null +++ b/documentation/18.11/solutions/platform-specifics/microsoft-windows/com/eiffelcom-wizard/eiffelcom-wizard-guided-tour/creating-new-component-eiffel-project.wiki @@ -0,0 +1,46 @@ +[[Property:title|Creating a new component from an Eiffel project]] +[[Property:weight|1]] +[[Property:uuid|f1f6711a-989b-f182-377d-89dd827401d5]] +The second tutorial describes creating a COM component from an Eiffel system. The tutorial example String is almost identical to StringManipulator of the previous tutorial. In the StringManipulator example the wizard starts from an IDL file and builds an Eiffel System; in contrast, the String example takes an Eiffel system and generates an IDL file and the required plumbing code to make the Eiffel project accessible to COM. + +==Step by step instructions== +# Create a new Eiffel project in the directory ''$ISE_EIFFEL\examples\com\wizard\e2idl\eproject'' where $ISE_EIFFEL represents the path to the EiffelStudio installation directory. +# Select the ECF file located in the same directory and compile. +# Start the EiffelCOM Wizard +# In '''Project''', in the '''Current project''' input field, type in ''string'' and press '''enter'''. +# In '''Project Type''', choose ''Add a COM interface to an existing Eiffel project''. +# In the field under '''Path to Eiffel project location''' enter ''$ISE_EIFFEL\examples\com\wizard\e2idl\eproject''. +# Click the browse button under '''Path to system's configuration file (*.ecf)''' and open the file ''$ISE_EIFFEL\examples\com\wizard\e2idl\eproject\string.ecf''. +# In the text field under '''Target to use''', enter: ''string''. +# In the text field under '''Name of Eiffel facade class''', enter: string_manipulator. +# In the text field under '''Name of Eiffel facade class cluster''', enter: root_cluster. +# Click '''Next'''. +# In '''Component Type''', choose ''In-process (*.dll)''. +# In '''Generation Options''', click the browse button and select the directory where the project should be created. Choose ''$ISE_EIFFEL\examples\com\wizard\e2idl\generated''. +# Make sure both '''Compile C code''' and '''Compile Eiffel code''' are checked. +# Make sure '''Clean destination folder prior to generation''' is selected. +# Click '''Generate'''. +# Wait until the wizard is done. + +==First look at the generated code== + +The generated Eiffel classes include: +* ISTRING_MANIPULATOR_INTERFACE: This class represents the only interface exposed by the COM component. +* STRING_MANIPULATOR_PROXY_IMP: This class implements the coclass, it inherits from the interface and implements its members. +* ECOM_STRING_REGISTRATION: This class contains the code required to register the component. +You do not need to modify or implement any classes. The wizard produces a ready-to-use component. + + +{{tip|
+In most Eiffel systems functionality is spread out throughout the system. No single class exposes the full functionality of the system and can serve as a Facade to the outside world. Running the wizard on any such class would not be practical. Before starting the wizard write an Eiffel class that acts as a Facade and forwards client calls to the appropriate subsystems. Enter the Facade class name into '''Name of Eiffel facade class''' field. The wizard generates an IDL file from this class. }} + + +{{seealso|
+[[Creating a New COM Component|Creating a New COM Component]]
+[[Accessing a COM Component|Accessing a COM Component.]] }} + + + + + + diff --git a/documentation/18.11/solutions/platform-specifics/microsoft-windows/com/eiffelcom-wizard/eiffelcom-wizard-guided-tour/index.wiki b/documentation/18.11/solutions/platform-specifics/microsoft-windows/com/eiffelcom-wizard/eiffelcom-wizard-guided-tour/index.wiki new file mode 100644 index 00000000..6aed17b1 --- /dev/null +++ b/documentation/18.11/solutions/platform-specifics/microsoft-windows/com/eiffelcom-wizard/eiffelcom-wizard-guided-tour/index.wiki @@ -0,0 +1,21 @@ +[[Property:title|EiffelCOM Wizard Guided Tour]] +[[Property:weight|-13]] +[[Property:uuid|b0973926-aaac-0131-ae60-d1db6ecf6f38]] +This section provides a working example of how to use the EiffelCOM wizard to create COM components and to access existing COM components.
+* [[Creating a New COM Component|Creating a New COM Component]] . +* [[Creating a new component from an Eiffel project|Creating a new component from an Eiffel Project.]] +* [[Accessing a COM Component|Accessing a COM Component.]] + + +{{Caution|EiffelCOM currently requires the use of the Microsoft C compiler (available with Visual Studio or the Microsoft Windows SDK). EiffelCOM will not work at this time with the MinGW C compiler.}} + + +{{seealso| '''See Also'''
+[[EiffelCOM Wizard Introduction|Introduction]]
+[[EiffelCOM Wizard Reference|EiffelCOM wizard reference]] }} + + + + + + diff --git a/documentation/18.11/solutions/platform-specifics/microsoft-windows/com/eiffelcom-wizard/eiffelcom-wizard-introduction.wiki b/documentation/18.11/solutions/platform-specifics/microsoft-windows/com/eiffelcom-wizard/eiffelcom-wizard-introduction.wiki new file mode 100644 index 00000000..c55cf12d --- /dev/null +++ b/documentation/18.11/solutions/platform-specifics/microsoft-windows/com/eiffelcom-wizard/eiffelcom-wizard-introduction.wiki @@ -0,0 +1,31 @@ +[[Property:title|EiffelCOM Wizard Introduction]] +[[Property:weight|-14]] +[[Property:uuid|b73bc137-55ce-5404-e178-d88565cb6b62]] +The COM standard allows software components written in different languages to communicate with each other. However, building COM compliant applications requires the development of a large amount of "plumbing" code dedicated to supporting the technology. The EiffelCOM wizard was designed to free Eiffel developers from having to write the plumbing code. + +The '''EiffelCOM Wizard''' is a powerful tool that enables both the rapid development of COM components in Eiffel and the access of COM components from Eiffel systems. The wizard consists of a series of input fields, in which you describe the component's characteristics. The wizard uses data you enter to produce: +# An Eiffel system skeleton +# The code to access or create a component +# The component-specific runtime libraries. + +The wizard allows Eiffel developers with little COM knowledge to develop and reuse COM components. The design of the generated code follows the Eiffel standards and will look familiar to experienced Eiffel users. The only prerequisite to use the EiffelCOM wizard is an understanding of the '''Interface Definition Language'''. '''IDL''' describes a component's interface(s). Compilers can generate '''Type Libraries''' from IDL files. Tools that need information about a given component, such as the EiffelCOM wizard, Visual Basic, etc. will analyze the Type Libraries. The IDL syntax is very close to C so should be easy to learn for developers that are familiar with this language. + +The wizard generates code from a Type Library and additional information given by the user. The generated code consists of Eiffel classes, C/C++ files, and library files. The wizard automatically produces library files from generated C and C++ code. You do not need to modify generated C/C++ code to build your EiffelCOM system. + + +{{note|The '''EiffelCOM Wizard''' is delivered with EiffelStudio, but it is a '''standalone tool''' (i. e., not part of the EiffelStudio IDE). You can find the wizard by following the directory path: ''$ISE_EIFFEL\wizards\com''. The executable file ''com_wizard_launcher.exe'' will launch the GUI version of the wizard. The executable file ''com_wizard.exe'' is a command-line version of the wizard described [[Wizards: Command Line Options|here]].}} + + +==Code Generation Process== + +[[Image:introduction]] + + +The wizard can automatically compile the generated C and Eiffel code. To produce a Type Library corresponding to a given IDL file the wizard relies on '''MIDL''', the Microsoft IDL compiler (installed with the Windows Platform SDK). You may also provide the wizard with a Type Library directly. The wizard can also be used to add a COM interface to an existing Eiffel project. For the rest of the manual a '''COM Definition File''' will refer to the input file given to the wizard (either an IDL file, a Type Library or an Eiffel project file). + + +{{seealso|[[EiffelCOM Wizard Guided Tour|Guided Tour]] , [[EiffelCOM Wizard Reference|EiffelCOM wizard reference]] }} + + + + diff --git a/documentation/18.11/solutions/platform-specifics/microsoft-windows/com/eiffelcom-wizard/eiffelcom-wizard-reference/building-com-component.wiki b/documentation/18.11/solutions/platform-specifics/microsoft-windows/com/eiffelcom-wizard/eiffelcom-wizard-reference/building-com-component.wiki new file mode 100644 index 00000000..9fd448b0 --- /dev/null +++ b/documentation/18.11/solutions/platform-specifics/microsoft-windows/com/eiffelcom-wizard/eiffelcom-wizard-reference/building-com-component.wiki @@ -0,0 +1,73 @@ +[[Property:title|Building a COM Component]] +[[Property:weight|5]] +[[Property:uuid|eb299741-4570-c2f1-011a-69da3043c6eb]] +When building a COM component, the EiffelCOM wizard allows for the development of both in-process (DLLs) and out-of-process (EXEs) COM components in Eiffel. + +==Using the Generated Code== + +If the project consists of adding a COM interface to an existing Eiffel project then the wizard will generate (and optionally compile) everything required to implement the COM component. No extra work is required. + +If the project uses a COM definition file (either an IDL file or a type library), the EiffelCOM Wizard generates empty features in the classes corresponding to the component's coclasses. The implementation can then be added into these empty features. + +{{warning|Depending on the project settings, the EiffelCOM Wizard may overwrite the files containing the classes corresponding to the component's colasses if the project is re-generated thereby replacing the implemented features with empty ones. Make sure the destination folder is different from the folder where the classes have been implemented prior to re-generating the project. }} + +Unlike the code generated to access an existing component, the code generated to implement a new COM component will differ for an in-process or an out-of-process component. The difference lies in the component activation code in the class ECOM__REGISTRATION. If the component is in-process then this class includes the four functions that need to be exported from an in-process COM component ( DllRegisterServer, DllUnregisterServer, DllGetClassObject, and DllCanUnloadNow). If the component is out-of-process then the registration class includes a feature initializing the component and its graphical user interface. + +The architecture of the generated code is similar to the one used by the code generated to access an existing component: classes corresponding to the component's coclasses inherit from classes corresponding to the component's interfaces and implement all the deferred features. There is however a major difference: the classes corresponding to the component's coclasses should '''not''' be inherited from. Instead their implementation should be completed. Putting the implementation in a heir class would cause a runtime failure since the EiffelCOM generated code will instantiate the class corresponding to the component's coclass when being called rather than any descendant that would actually contain the implementation. The classes corresponding to the component's coclasses are all suffixed with _COCLASS_IMP. + + +==Component's GUI== + +In the case of an out-of-process server, the component might need a Graphical User Interface. There are two different scenarios in which the component can be activated: either its user launched it explicitly (e.g. by double clicking the executable icon) or it was launched by the COM runtime to satisfy a client request. In some cases it might be required for the component to have a different behavior in these two cases (for example the GUI could only be necessary when the component was launched explicitly by the user but should be hidden when launched by the COM runtime). The generated registration class for an out-of-process server includes the feature: + + main_window: WEL_FRAME_WINDOW + +This feature is a once function that can return the class corresponding to the component window. By default, this window is displayed only if COM does not start the component. When COM loads an out-of-process component, it appends the command line parameter "-embedding" to the executable. The generated registration class looks for this option and if it is part of the process argument list then it sets the default window appearance to hidden. Of course this default implementation may be modified if needed. + + +==Exceptions== + +The COM standard specifies that each COM routine should return a status code to the client. The status code is encoded in a HRESULT value. Such behavior goes against the Command Query Separation Principle in Eiffel. The EiffelCOM generated system should use exceptions instead of returning HRESULT values to the client. By default the EiffelCOM runtime will always return S_OK meaning that the routine succeeded. To notify the client of a problem (e.g. invalid argument value), the EiffelCOM component should raise the corresponding exception from class ECOM_EXCEPTION using the feature trigger from the same class. The EiffelCOM runtime will catch the exception and send the corresponding HRESULT back to the client. Here is what the Eiffel code for a COM component should look like: + + +note + description: "Eiffel coclass server example" +class + ECOM_SERVER_COCLASS_IMP + +inherit + ECOM_SERVER_COCLASS -- Generated by the wizard + + ECOM_EXCEPTION + export + {NONE} all + end + +feature -- Basic Operations + + coclass_feature (an_argument: ARGUMENT_TYPE) + -- Example of a coclass feature + do + if not is_valid (an_argument) then + trigger (E_invalidargument) + else + -- Normal processing + end + end + +feature {NONE} -- Implementation + + is_valid (an_argument: ARGUMENT_TYPE): BOOLEAN + -- Is an_argument a valid argument? + do + -- Test of validity of an_argument + end + +end -- class ECOM_SERVER_COCLASS_IMP + + +This class inherits from the generated Eiffel coclass and from ECOM_EXCEPTION. It implements the deferred feature coclass_feature from the generated coclass. This feature is part of the interface functions that can be called by clients of the component. Its implementation uses the feature trigger from ECOM_EXCEPTION to raise exceptions in case the feature cannot be executed normally (invalid argument). The EiffelCOM runtime catches the exception and maps it into an HRESULT that is sent back to the client. + + +{{seealso|[[How the EiffelCOM Wizard works|How the EiffelCOM Wizard Works]] , [[Generated Files|Generated Files]] , [[Class Hierarchy|Class Hierarchy]] , [[Eiffel Project Processing|Adding a COM Interface to an Eiffel Project]] , [[Reusing a COM Component|Accessing a COM Component]] , [[Wizards: Command Line Options|Command Line Options]] }} + diff --git a/documentation/18.11/solutions/platform-specifics/microsoft-windows/com/eiffelcom-wizard/eiffelcom-wizard-reference/class-hierarchy.wiki b/documentation/18.11/solutions/platform-specifics/microsoft-windows/com/eiffelcom-wizard/eiffelcom-wizard-reference/class-hierarchy.wiki new file mode 100644 index 00000000..19c2a5f5 --- /dev/null +++ b/documentation/18.11/solutions/platform-specifics/microsoft-windows/com/eiffelcom-wizard/eiffelcom-wizard-reference/class-hierarchy.wiki @@ -0,0 +1,34 @@ +[[Property:title|Class Hierarchy]] +[[Property:weight|2]] +[[Property:uuid|3f78176c-179f-78a4-cf32-47ec548bbb16]] +The generated Eiffel code reflects the architecture of the component described in the definition file. Each interface corresponds to a deferred Eiffel class that includes one deferred feature per interface function. The deferred features are implemented in heirs of the interface class. Classes inheriting from these interfaces implement either a coclass or an implemented interface (that is an interface whose instance might be used as an argument on one of the component interfaces functions). + + +==Projects Accessing Existing COM Components== + +In a project accessing an existing component, the Eiffel classes corresponding to component coclasses inherit from the class [[ref:libraries/com/reference/ecom_queriable_chart| ECOM_QUERIABLE ]] , which is part of the EiffelCOM library. This class includes the feature make_from_other which allows initializing the component from another instance of [[ref:libraries/com/reference/ecom_interface_chart| ECOM_INTERFACE ]] . + +[[Image:interface-inheritance]] + + +==Projects Implementing New COM Components== + +In a project implementing a new component, the Eiffel classes corresponding to component coclasses inherit from the class [[ref:libraries/com/reference/ecom_stub_chart|ECOM_STUB]], which is part of the EiffelCOM library. This class includes the feature [[ref:libraries/com/reference/ecom_stub_chart|create_item]] which allows initializing the component. + +[[Image:interface-inheritance-server]] + + +The '''Interface_proxy''' folder includes Eiffel classes wrapping interfaces that may be returned by functions on other interfaces. These classes inherit from both the deferred interface class located in '''Common\Interfaces''' and [[ref:libraries/com/reference/ecom_queriable_chart| ECOM_QUERIABLE ]] . + +[[Image:implemented-interface]] + + +The '''Interface_stub''' folder includes Eiffel classes implementing interfaces that may be given to the component as an argument. These classes inherit from both the deferred interface class and [[ref:libraries/com/reference/ecom_stub_chart| ECOM_STUB ]] . + +[[Image:implemented-interface-server]] + +{{seealso|[[How the EiffelCOM Wizard works|How the EiffelCOM Wizard Works]] , [[Generated Files|Generated Files]] , [[Eiffel Project Processing|Adding a COM Interface to an Eiffel Project]] , [[Reusing a COM Component|Accessing a COM Component]] , [[Building a COM Component|Building a COM Component]] , [[Wizards: Command Line Options|Command Line Options]] }} + + + + diff --git a/documentation/18.11/solutions/platform-specifics/microsoft-windows/com/eiffelcom-wizard/eiffelcom-wizard-reference/eiffel-project-processing.wiki b/documentation/18.11/solutions/platform-specifics/microsoft-windows/com/eiffelcom-wizard/eiffelcom-wizard-reference/eiffel-project-processing.wiki new file mode 100644 index 00000000..ce44be5b --- /dev/null +++ b/documentation/18.11/solutions/platform-specifics/microsoft-windows/com/eiffelcom-wizard/eiffelcom-wizard-reference/eiffel-project-processing.wiki @@ -0,0 +1,25 @@ +[[Property:title|Eiffel Project Processing]] +[[Property:weight|3]] +[[Property:uuid|d94c4060-af70-930b-5023-1c2b2d069633]] +The EiffelCOM Wizard can be used to add a COM interface to an existing Eiffel project. The advantage of that approach is that it doesn't require any knowledge about IDL. The EiffelCOM Wizard will take care of generating the IDL from the Eiffel facade class. The generated IDL will define one coclass containing one interface that corresponds to the contract view of the facade class. + +==Designing the Facade Class== + +The facade class should be designed so that it exposes the functionality of the Eiffel system that needs to be accessed from clients of the component. Only the public routines will be exported to the IDL and thus to clients (the class should not have any public attributes, see the list of requirements below). + +There are some rules that the facade class must follow for the COM wizard to be able to generate correct IDL: + +* The facade class must have a creation procedure called make that does not take any argument. This is the procedure that will be called by the EiffelCOM runtime to initialize the Eiffel object when a COM call arrives from a client. + +* The arguments and objects returned by the public routines of the facade class must be of one of the following types: [[ref:libraries/base/reference/character_8_chart| CHARACTER_8 ]] , [[ref:libraries/base/reference/integer_32_chart| INTEGER_32 ]] , [[ref:libraries/base/reference/real_32_chart| REAL_32 ]] , [[ref:libraries/base/reference/real_64_chart| REAL_64 ]] , [[ref:libraries/base/reference/boolean_chart| BOOLEAN ]] , [[ref:libraries/base/reference/integer_32_ref_chart| INTEGER_32_REF ]] , [[ref:libraries/base/reference/boolean_ref_chart| BOOLEAN_REF ]] , [[ref:libraries/base/reference/real_32_ref_chart| REAL_32_REF ]] , [[ref:libraries/base/reference/character_8_ref_chart| CHARACTER_8_REF ]] , [[ref:libraries/base/reference/real_64_ref_chart| REAL_64_REF ]] , [[ref:libraries/base/reference/string_8_chart| STRING_8 ]] , [[ref:libraries/com/reference/ecom_currency_chart| ECOM_CURRENCY ]] , [[ref:libraries/com/reference/ecom_decimal_chart| ECOM_DECIMAL ]] , [[ref:libraries/com/reference/ecom_interface_chart| ECOM_INTERFACE]] , or [[ref:libraries/com/reference/ecom_array_chart| ECOM_ARRAY]] . Features with arguments or return objects that are of a type not in this list are excluded from the generated IDL file and are not accessible to clients. + +* The facade class should not contain any public attribute, only routines can be exported to COM clients. + +* The facade class must belong to a successfully compiled Eiffel project. + + +{{seealso|[[How the EiffelCOM Wizard works|How the EiffelCOM Wizard Works]] , [[Generated Files|Generated Files]] , [[Class Hierarchy|Class Hierarchy]] , [[Eiffel Project Processing|Adding a COM Interface to an Eiffel Project]] , [[Accessing a COM Component|Accessing a COM Component]] , [[Reusing a COM Component|Reusing a COM Component]] , [[Wizards: Command Line Options|Command Line Options]] }} + + + + diff --git a/documentation/18.11/solutions/platform-specifics/microsoft-windows/com/eiffelcom-wizard/eiffelcom-wizard-reference/generated-files.wiki b/documentation/18.11/solutions/platform-specifics/microsoft-windows/com/eiffelcom-wizard/eiffelcom-wizard-reference/generated-files.wiki new file mode 100644 index 00000000..b1477525 --- /dev/null +++ b/documentation/18.11/solutions/platform-specifics/microsoft-windows/com/eiffelcom-wizard/eiffelcom-wizard-reference/generated-files.wiki @@ -0,0 +1,17 @@ +[[Property:title|Generated Files]] +[[Property:weight|1]] +[[Property:uuid|808d49ba-132d-f847-2d8c-f49fe8c499b1]] +The EiffelCOM Wizard generates code into the specified destination folder. The file hierarchy is the following: + +[[Image:folders]] + +* The '''Client''' folder includes all the files used to access a COM component. The subfolders '''Clib''' and '''Include''' contain respectively the C++ source files and header files. If a COM Client was generated (as opposed to a COM Server), the subfolder '''Component''' contains the Eiffel class used to provide an interface to the component. Finally, if a COM Server was generated, the subfolder '''Interface_proxy''' contains classes wrapping interfaces that may be returned by functions of the component. These classes may be of interest for systems implementing a new COM component as well. The '''Client''' folder also contains an ECF file that can be used to precompile the generated Eiffel classes if the project consists of accessing an existing component. It is also possible to directly use the ECF file as a library in an existing project. +* The '''Common''' folder includes classes that are useful both when accessing and implementing a COM component. It includes the usual C++ folders as well as the '''Interfaces''' and '''Structures''' folders. The '''Interfaces''' folder contains Eiffel classes corresponding to COM interfaces. These are deferred classes that only define the signature of the COM interfaces members. The '''Structures''' folder contains Eiffel classes wrapping any structure defined in the COM definition file (IDL or type library). +* Optionally, the EiffelCOM Wizard may generate a '''idl''' folder which contains the IDL file generated from the Eiffel facade class if the project consists of adding a COM interface to an existing Eiffel project. +* The '''Server''' folder includes files used to implement a COM component. Apart from the usual C++ folders, it also includes a '''Component''' folder which contains Eiffel classes corresponding to the component's coclasses and a '''Interface_stub''' folder which contains Eiffel classes wrapping interfaces that may be given as an argument to the component. This last folder may also be useful when accessing a COM component. The '''Server''' folder also includes a ECF file which can be used to compile the generated system if the project consists of creating a new component. + +{{seealso|[[How the EiffelCOM Wizard works|How the EiffelCOM Wizard Works]] , [[Class Hierarchy|Class Hierarchy]] , [[Eiffel Project Processing|Adding a COM Interface to an Eiffel Project]] , [[Reusing a COM Component|Accessing a COM Component]] , [[Building a COM Component|Building a COM Component]] , [[Wizards: Command Line Options|Command Line Options]] }} + + + + diff --git a/documentation/18.11/solutions/platform-specifics/microsoft-windows/com/eiffelcom-wizard/eiffelcom-wizard-reference/how-eiffelcom-wizard-works.wiki b/documentation/18.11/solutions/platform-specifics/microsoft-windows/com/eiffelcom-wizard/eiffelcom-wizard-reference/how-eiffelcom-wizard-works.wiki new file mode 100644 index 00000000..f7be337d --- /dev/null +++ b/documentation/18.11/solutions/platform-specifics/microsoft-windows/com/eiffelcom-wizard/eiffelcom-wizard-reference/how-eiffelcom-wizard-works.wiki @@ -0,0 +1,21 @@ +[[Property:title|How the EiffelCOM Wizard works]] +[[Property:weight|0]] +[[Property:uuid|2cbfb8ef-d163-fb01-ab8f-5ab156ea36fd]] +Depending on the project settings there are between 2 and 6 major steps involved when generating the Eiffel system: +* '''IDL Generation''': If the project consists of adding a COM interface to an existing Eiffel project, the first step accomplished by the EiffelCOM Wizard consists of generating an IDL file from the specified facade class (see [[Eiffel Project Processing|Adding a COM interface to an Eiffel project]] for additional details). +* '''IDL Compilation''': If the project uses an IDL file (whether it was specified or the result of processing a facade class from an existing Eiffel project), the EiffelCOM Wizard then compiles it into a type library. +* '''Type Library Parsing''': The EiffelCOM Wizard then analyzes the type library (whether it was specified in the settings or is the result of an IDL file compilation) and stores the information it needs to generate the code into an internal representation. +* '''Code Generation''': The EiffelCOM wizard generates both the Eiffel and C/C++ code from the information gathered during the previous step (see [[Generated Files|Generated Files]] for a list of generated files) +* '''C/C++ Compilation''': If specified in the project settings, the EiffelCOM Wizard then compiles the generated C and C++ code into object files and libraries that will be linked into the Eiffel system. +* '''Eiffel Compilation''': If the project consists of accessing an existing component then the EiffelCOM Wizard compiles the generated Eiffel code into a precompiled library that contains all the generated classes. If the project consists of creating a new component then the EiffelCOM Wizard compiles the generated Eiffel code into a standard project using the registration class as the root class. + +Optionally, EiffelStudio can be opened on the generated system by clicking the corresponding button after the system has been compiled. + + +{{note|The EiffelStudio button will only be enabled if the Eiffel code was compiled. }} + +{{seealso|[[Generated Files|Generated Files]] , [[Class Hierarchy|Class Hierarchy]] , [[Eiffel Project Processing|Adding a COM Interface to an Eiffel Project]] , [[Reusing a COM Component|Accessing a COM Component]] , [[Building a COM Component|Building a COM Component]] , [[Wizards: Command Line Options|Command Line Options]] }} + + + + diff --git a/documentation/18.11/solutions/platform-specifics/microsoft-windows/com/eiffelcom-wizard/eiffelcom-wizard-reference/index.wiki b/documentation/18.11/solutions/platform-specifics/microsoft-windows/com/eiffelcom-wizard/eiffelcom-wizard-reference/index.wiki new file mode 100644 index 00000000..3ea03b4d --- /dev/null +++ b/documentation/18.11/solutions/platform-specifics/microsoft-windows/com/eiffelcom-wizard/eiffelcom-wizard-reference/index.wiki @@ -0,0 +1,20 @@ +[[Property:title|EiffelCOM Wizard Reference]] +[[Property:weight|-12]] +[[Property:uuid|d3564eb8-ef56-4ec1-599f-430b023fa7e8]] +The '''EiffelCOM Wizard''' is delivered with EiffelStudio, but it is a '''standalone tool''' (i. e., not part of the EiffelStudio IDE). You can find the wizard by following the directory path: $ISE_EIFFEL\wizards\com. The executable file com_wizard_launcher.exe will launch the GUI version of the wizard. The executable file com_wizard.exe is a command line version of the wizard described [[Wizards: Command Line Options|here]]. + +The EiffelCOM Wizard facilitates the creation of Eiffel projects implementing or reusing COM components. + +* [[How the EiffelCOM Wizard works|How the EiffelCOM Wizard works]] describes the steps followed by the wizard when creating the Eiffel project. +* [[Generated Files|Generated Files]] describes the list of generated files and their usage. +* [[Class Hierarchy|Class Hierarchy]] describes the class hierarchy of the generated Eiffel project. +* [[Eiffel Project Processing|Eiffel Project Processing]] covers how to add a COM interface to an existing EiffelStudio project. +* [[Reusing a COM Component|Accessing a COM Component]] describes how to reuse an existing COM component. +* [[Building a COM Component|Building a COM Component]] describes how to build a new COM component. +* [[Wizards: Command Line Options|Command Line Options]] describes using the wizard from the command line. + +{{seealso|
+[[EiffelCOM Wizard Introduction|Introduction]]
+[[EiffelCOM Wizard Guided Tour|Guided Tour]] }} + + diff --git a/documentation/18.11/solutions/platform-specifics/microsoft-windows/com/eiffelcom-wizard/eiffelcom-wizard-reference/reusing-com-component.wiki b/documentation/18.11/solutions/platform-specifics/microsoft-windows/com/eiffelcom-wizard/eiffelcom-wizard-reference/reusing-com-component.wiki new file mode 100644 index 00000000..bf407877 --- /dev/null +++ b/documentation/18.11/solutions/platform-specifics/microsoft-windows/com/eiffelcom-wizard/eiffelcom-wizard-reference/reusing-com-component.wiki @@ -0,0 +1,96 @@ +[[Property:title|Reusing a COM Component]] +[[Property:weight|4]] +[[Property:uuid|ae910c51-2264-4b65-2567-9dfc1873beca]] +When reusing an existing COM component, the wizard generates the necessary code to access it. The plumbing is already done so that instantiating an Eiffel class corresponding to one of the component's coclasses automatically calls the right COM initialization APIs. + +==Using the Generated Code== + +Calling a feature on an Eiffel class corresponding to one of the component's coclasses forwards the call to the member on the corresponding interface. The data types of the function arguments are either Eiffel types defined in Eiffel data structure libraries, standard data types defined in the EiffelCOM library, or custom data types declared in the COM definition file. For example, from the following IDL line: + +HRESULT Function ([in] int a, [out, retval] MyStruct * b) + +The wizard generates the following feature: + +function (a: INTEGER): MY_STRUCT_RECORD + +where MY_STRUCT_RECORD is a generated Eiffel wrapper around the IDL defined structure MyStruct. Structures represent one case of custom data types, interfaces represent another. So for the following IDL: + +HRESULT Function ([in] ISomething * pInterface) + +The wizard generates the following Eiffel feature: + +function (p_interface: ISOMETHING_INTERFACE) + +where ISOMETHING_INTERFACE is a generated deferred class corresponding to the ISomething interface. Calling function requires passing an instance of a type that implements ISOMETHING_INTERFACE. The '''stubs''' implementing such interfaces can be found in '''Server\Interfaces_stub'''. In our example the Eiffel class would be named ISOMETHING_IMPL_STUB. The default implementation of the stub is empty and should be completed to implement the wanted behavior. This is how callbacks can be implemented using EiffelCOM. + + +==Contracts== + +All the Eiffel classes corresponding to the component's interfaces are generated in '''Common\Interfaces'''. These deferred classes include one deferred feature per function defined in the interface. They are equipped with automatically generated assertions. However, the wizard cannot generate fully specified contracts since it has no domain specific knowledge. It can only generate contracts that are domain independent. Such contracts, although useful, are not enough to describe entirely the behavior of the component. Generated contracts include checking for Void Eiffel objects as well as null C pointers for wrappers. There might be a need for additional assertions. Invariants and postconditions can be added in an heir of the generated Eiffel coclass proxy. Preconditions, however, cannot be strengthened. A workaround provided by the wizard consists of generating a precondition function for each feature in the interface. The default implementation of these functions always returns True. They can be redefined to implement the correct behavior: + + function (a: INTEGER): MY_STRUCT + -- Example of a generated Eiffel coclass feature + require + function_user_precondition: function_user_precondition + do + ... + ensure + non_void_my_struct: Result /= Void + end + +So the complete class hierarchy for an Eiffel client coclass is the following: +[[Image:client-inheritance]] + + +==Exceptions== + +The COM standard requires that any interface function returns a status value (known as a HRESULT). This means that any function which adheres to the COM standard actually corresponds to a side effect feature which the Eiffel methodology tries to avoid according to the ''Command Query Separation Principle''. The workaround used in EiffelCOM systems consists in mapping these return values to Eiffel exceptions. So if the component returns an HRESULT corresponding to an error code, the EiffelCOM runtime raises an Eiffel exception that needs to be caught by the client. + +[[Image:exception-raising]] + +As a result, any feature in the client making calls to the Eiffel classes corresponding to the component's coclasses should include a rescue clause. The processing done in this clause might depend on the nature of the exception. All the standard COM exceptions can be found in the library class ECOM_EXCEPTION_CODES, which is inherited from by ECOM_EXCEPTION. The later also inherits from the kernel class EXCEPTIONS and can consequently be used by the coclass client to catch the exceptions. + +The following code snippet illustrates how a client can process exceptions raised by a call to an Eiffel class representing a component's coclass: + +note + description: "Eiffel coclass client example" + +class + COCLASS_CLIENT + +inherit + ECOM_EXCEPTION + export + {NONE} all + end + +feature -- Basic Operations + + coclass_feature_client + -- Example of a coclass feature caller + local + retried: BOOLEAN + coclass: EIFFEL_COCLASS_PROXY + do + if not retried then + create coclass.make + coclass.coclass_feature -- Actual call + end + rescue + if hresult = E_notimpl then + -- Process non implemented function error. + retried := True + retry + elseif hresult = E_invalidarg then + -- Process invalid argument error. + retried := True + retry + else + -- Forward exception to caller. + end + end + +end -- class COCLASS_CLIENT + +{{seealso|[[How the EiffelCOM Wizard works|How the EiffelCOM Wizard Works]] , [[Generated Files|Generated Files]] , [[Class Hierarchy|Class Hierarchy]] , [[Eiffel Project Processing|Adding a COM Interface to an Eiffel Project]] , [[Building a COM Component|Reusing a COM Component]] , [[Wizards: Command Line Options|Command Line Options]] }} + diff --git a/documentation/18.11/solutions/platform-specifics/microsoft-windows/com/eiffelcom-wizard/eiffelcom-wizard-reference/wizards-command-line-options.wiki b/documentation/18.11/solutions/platform-specifics/microsoft-windows/com/eiffelcom-wizard/eiffelcom-wizard-reference/wizards-command-line-options.wiki new file mode 100644 index 00000000..9887fc3d --- /dev/null +++ b/documentation/18.11/solutions/platform-specifics/microsoft-windows/com/eiffelcom-wizard/eiffelcom-wizard-reference/wizards-command-line-options.wiki @@ -0,0 +1,34 @@ +[[Property:title|Wizards: Command Line Options]] +[[Property:weight|6]] +[[Property:uuid|ca417e46-ad46-2d3f-e13e-a88366dc06b3]] +The EiffelCOM Wizard can be used from the command line for example in batch scripts. The command line utility is com_wizard.exe and is located in $ISE_EIFFEL\wizards\com. Each command line option has both a long and a short name. The long names are all prefixed with -- while the short names are all prefixed with -. Options that take an argument should have the argument directly following the option with a space or a = sign in between the option name and the argument as in: + +--ace="mysystem.ecf" +this option is equivalent to: + +-a "mysystem.ecf" + +The list of options is the following: +* '''--client, -c''' : Build client to access COM component described by . +* '''--server, -s''' : Build new COM component as described by . +* '''--eiffel, -e''' : Add COM interface to Eiffel project with project file (*.epr) . +* '''--ace, -a''' : Path to ecf file of Eiffel project to be added a COM interface. Use together with '--eiffel'. +* '''--facade, -f''' : Name of facade class to generate IDL from. Use together with '--eiffel'. +* '''--cluster, -u''' : Name of facade class cluster. Use together with '--eiffel'. +* '''--outofprocess, -o''': Access or build out of process component. By default access or build in-process component (DLL). +* '''--compilec, -i''': Compile generated C code. +* '''--compileeiffel, -l''': Compile generated Eiffel code. Implies '--compilec'. +* '''--marshaller, -m''': Build marshaller DLL, can only be used with '--server' and if definition file is an IDL file. +* '''--destination, -d''' : Generate files in folder. By default files are generated in current folder. +* '''--cleanup, -p''': Cleanup destination folder prior to generation. This option cannot be used together with '--backup'. +* '''--backup, -b''': Backup overriden files by adding extension '.bac'. This option cannot be used together with '--cleanup'. +* '''--graphical, -g''': Launch GUI, all other options are ignored. +* '''--nologo, -n''': Do not display copyright information. +* '''--version, -v''': Print version information. +* '''--help, -h''': Display help on how to use the EiffelCOM Wizard command line utility. + +{{seealso|[[How the EiffelCOM Wizard works|How the EiffelCOM Wizard Works]] , [[Generated Files|Generated Files]] , [[Class Hierarchy|Class Hierarchy]] , [[Eiffel Project Processing|Adding a COM Interface to an Eiffel Project]] , [[Reusing a COM Component|Accessing a COM Component]] , [[Building a COM Component|Building a COM Component]] }} + + + + diff --git a/documentation/18.11/solutions/platform-specifics/microsoft-windows/com/eiffelcom-wizard/index.wiki b/documentation/18.11/solutions/platform-specifics/microsoft-windows/com/eiffelcom-wizard/index.wiki new file mode 100644 index 00000000..9c318e6f --- /dev/null +++ b/documentation/18.11/solutions/platform-specifics/microsoft-windows/com/eiffelcom-wizard/index.wiki @@ -0,0 +1,12 @@ +[[Property:title|EiffelCOM Wizard]] +[[Property:weight|4]] +[[Property:uuid|49d5c1b9-14f8-5bea-6641-50e9cf6715cf]] +Type: Wizard
+Platform: Windows + +{{seealso|
+[[EiffelCOM Library|EiffelCOM library]] }} + + + + diff --git a/documentation/18.11/solutions/platform-specifics/microsoft-windows/com/index.wiki b/documentation/18.11/solutions/platform-specifics/microsoft-windows/com/index.wiki new file mode 100644 index 00000000..c567e2dd --- /dev/null +++ b/documentation/18.11/solutions/platform-specifics/microsoft-windows/com/index.wiki @@ -0,0 +1,16 @@ +[[Property:title|COM]] +[[Property:weight|0]] +[[Property:uuid|993f5778-97c1-e113-31d7-61ae81c559fb]] +Microsoft COM (Component Object Model) is a platform-independent, distributed, system for creating binary software components that can interact. COM is the foundation technology for Microsoft's OLE (compound documents) and ActiveX (Internet-enabled components) technologies. + +{{definition|Automation|Automation is a Microsoft Windows Platform term that means, when an application provides it, that that application exposes its unique features to scripting tools and other applications. Automation uses the Component Object Model (COM).}} + +:See also [http://msdn.microsoft.com/en-us/library/windows/desktop/ms221375%28v=vs.85%29.aspx Automation]. + + +There is a host of technologies and capabilities that are available to your Eiffel applications on the Microsoft Windows platform through COM interfaces. For instance, a number of Microsoft products (e.g. Microsoft Word, Excel, Visio, Outlook, etc.) can be enhanced or controlled by other software through Automation via a COM interface. It is not complicated to, for example, have your Eiffel application open Excel, open a worksheet, evaluate its contents, and make extensive changes, or in-depth queries into its contents, either on the screen or invisibly. At this writing, all Microsoft Office products offer extensive COM interfaces for such purposes. + +In addition, Eiffel supports the capability of making Eiffel applications into COM-compliant COM objects, thus exposing callable COM interfaces to other software for similar purposes. + +The EiffelCOM Wizard, EiffelCOM Runtime, and EiffelCOM Library are there to make this job easier. + diff --git a/documentation/18.11/solutions/platform-specifics/microsoft-windows/eiffelribbon/eiffelribbon-design-tool.wiki b/documentation/18.11/solutions/platform-specifics/microsoft-windows/eiffelribbon/eiffelribbon-design-tool.wiki new file mode 100644 index 00000000..62a5dbcc --- /dev/null +++ b/documentation/18.11/solutions/platform-specifics/microsoft-windows/eiffelribbon/eiffelribbon-design-tool.wiki @@ -0,0 +1,134 @@ +[[Property:title|EiffelRibbon Design Tool]] +[[Property:weight|0]] +[[Property:uuid|E0B7F3F8-F7B1-43C4-8B7E-D175BC9A7D9F]] +=Overview= + +The EiffelRibbon design tool allows you to design a ribbon graphically, then generate the ribbon markup file and the Eiffel classes necessary to implement your design. + + +[[Image:EiffelRibbon design tool 01|EiffelRibbon design tool]] + +Figure 1: An EiffelRibbon project open in the EiffelRibbon design tool. + + +The interface of the design tool mimics that of [[EiffelBuild|EiffelBuild]]. That is, the interface contains three panes that have counterparts in EiffelBuild: + +# Type selector: A list of all the elements available for use in a ribbon. +# Layout constructor: A structured view of the organization of the elements used in a particular ribbon design. +# Object editor: The properties of the ribbon element which is currently selected in the Layout constructor. + +So, if you've used EiffelBuild, the EiffelRibbon design tool should seem quite familiar to you. + +=Usage= + +The typical usage of the design tool is much like the typical usage of EiffelBuild. + +* Create a new project ( File -> New Project... ) and choose a location for your EiffelRibbon project. +* Configure the ribbon by adding elements, name the elements, and choose icons for buttons. +* Save the project. +* Generate the code. +* Use EiffelStudio to compile the generated code. + +==Size definitions and scaling policies== + +An important aspect of Microsoft's ribbon technology is called '''[http://msdn.microsoft.com/en-us/library/windows/desktop/dd316927(v=vs.85).aspx adaptive layout]'''. When the ribbon is resized by a user at runtime, the adaptive layout makes corresponding changes to the size, format, organization and scale of the ribbon controls within each group based on size definition templates and scaling policies associated with the group. Size definitions are patterns for the use of a certain number of ribbon controls such as buttons. For a particular group of controls in an instance of ribbon, you can associate a size definition which will control the layout of the controls. At runtime, when the window hosting the ribbon is resized, a scaling policy, also associated with the group, will control how the controls in the group are reorganized in response to the resizing. When a group is selected in the EiffelRibbon tool, the group's size definition and scaling policy can be selected. + +{{note|Not all size definitions support all scaling policy choices. So it is important to know which scaling policies are supported by a size definition that you wish to associate with a group before you set the scaling policy for the group.}} + +===Size definitions=== + +The ribbon framework provides a significant number of size definition templates (simply called '''size definitions'''), as shown in Figure 2 below. Size definitions are usually assigned names based on the number and type of controls included in the group. For example, the size definition ''"ThreeButtonsAndOneCheckBox"'' is a size definition for three buttons plus one checkbox. + + +[[Image:EiffelRibbon Choose Size Definition]] + +Figure 2. Choosing a size definition for a ribbon control group. + + +In addition to using the size definitions provided, it is possible to create your own custom size definitions. You do this with the '''Size Definition Editor'''. At the lower left of Figure 1 above you can see the tab representing the Size Definition Editor. When you expand the tab, the editor becomes visible, as in Figure 3, below. + + +[[Image:EiffelRibbon size definition editor|Size Definition Editor]] + +Figure 3. EiffelRibbon tool with the Size Definition Editor pinned open. + + +Use the Size Definition Editor to create custom size definitions for your ribbon designs. The '''Add button''' button will add a new button placeholder to a custom size definition. A selected button placeholder can be altered to show or hide its label and use its small or large size. + + +[[Image:Size Definition Editor 02|Button placeholders]] + +Figure 4. Three button placeholders in a custom size definition (highlighted in red rectangle); one is large, and two are small. The text is visible in all cases. (This is the arrangement used for the "medium" configuration (highlighted in green rectangle) for the ''ThreeButtonCustom'' size definition used in the scaling policy figures in the next section. Screenshots of specifying arrangements used for "large" "small" configurations for ThreeButtonCustom are not shown.) + + +Once a custom size definition has been designed, it can be named, saved, and used in a ribbon design. + + +[[Image:Size Definition Editor 03|Name field and Save button]] + +Figure 5. The Size Definition Editor naming field and '''Save''' button. + + +When you generate code which uses a custom size definition, the EiffelRibbon Design Tool generates the (XML) representation for your size definition and then invoke the Microsoft Ribbon Framework's User Interface Command Compiler (UICC.exe) to validate the generated size definition code. This process can result in [http://msdn.microsoft.com/en-us/library/windows/desktop/dd316918(v=VS.85).aspx certain types of errors]. + +User Interface Command Compiler errors will appear in the Output pane of the EiffelRibbon Design Tool. + + +===Scaling policy=== + +The notion of adaptive layout includes the ability to specify preferred sizes for elements of a group and a scaling policy that can influence how the group reacts to resizing. More detail on size definition and scaling policy is available in Microsoft's [http://msdn.microsoft.com/en-us/library/windows/desktop/dd316927(v=vs.85).aspx ribbon documentation]. + +The EiffelRibbon tool allows you to specify ideal sizes and scale policy for a groups elements through the '''Ideal sizes''' radio buttons and the '''Scale''' checkboxes, as shown in Figure 6 below. + + +[[Image:EiffelRibbon design tool 02|Scaling policy elements: "Ideal sizes" and "Scale"]] + +Figure 6. A group definition showing it's size definition and the scaling policy elements "Ideal sizes" and "Scale". + + +In Figure 6, none of the Scale checkboxes is checked. This means that no scaling policy is in effect for the group ''group_context_popups''. So in a running application, a window with this ribbon might be rendered as shown in Figure 7: + + +[[Image:EiffelRibbon scaling policy 01]] + +Figure 7. A ribbon with no scaling policy, but with enough room to display all groups. + + +If the user resized the window to a narrower form, the buttons in the ''group_context_popups'' group would become occluded because scaling is not in effect. This is shown in Figure 8. + + +[[Image:EiffelRibbon scaling policy 01a]] + +Figure 8. After resizing, some buttons of the group are no longer visible. + + +If all of the ''Scale'' checkboxes that are supported by the size definition are checked in the EiffelRibbon tool for the group ''group_context_popups'' as shown in Figure 9, then scaling is enabled. + + +[[Image:EiffelRibbon scaling policy 02|Scale checkboxes enable scaling policy.]] + +Figure 9. All supported scales are enabled for ''group_context_popups''. + + +In the running application again, the initial rendering looks the same as in Figure 7 (its ''Large'' configuration). But if the window is resized to a narrower form with scaling policy enabled, it will go through the various configurations supported by the size definition: ''Medium'', ''Small'', then ''Popup''. The different configurations for this particular ribbon and size definition are shown in Figures 10 through 12. + + +[[Image:EiffelRibbon scaling policy 03|Medium configuration]] + +Figure 10. Scaling policy at medium configuration (see Figure 4 above). + + + +[[Image:EiffelRibbon scaling policy 04|Small configuration]] + +Figure 11. Scaling policy at small configuration. + + + +[[Image:EiffelRibbon scaling policy 05|Popup configuration]] + +Figure 12. Scaling policy at popup configuration. + + + + diff --git a/documentation/18.11/solutions/platform-specifics/microsoft-windows/eiffelribbon/index.wiki b/documentation/18.11/solutions/platform-specifics/microsoft-windows/eiffelribbon/index.wiki new file mode 100644 index 00000000..73860cc8 --- /dev/null +++ b/documentation/18.11/solutions/platform-specifics/microsoft-windows/eiffelribbon/index.wiki @@ -0,0 +1,78 @@ +[[Property:title|EiffelRibbon]] +[[Property:weight|2]] +[[Property:uuid|2f24957c-7fdc-f918-8c0d-37a9ef525508]] +=Introduction= + +EiffelRibbon is a library of classes with an associated [[EiffelRibbon Design Tool|tool]] which allows the integration of the Microsoft Windows "Ribbon" into graphical user interfaces programmed with [[EiffelVision 2]] and targeted to Microsoft Windows. The ribbon is part of a [http://msdn.microsoft.com/en-us/library/aa338198.aspx#office2007uifordevelopers_detaileddesignofthenewuisystem revamped user interface approach] introduced by Microsoft with the 2007 release of the Microsoft Office applications. So you've experienced the ribbon if you've used Microsoft Word, PowerPoint, or Excel from 2007 or later. + + +{{note|''Although EiffelRibbon classes work with EiffelVision 2 which is multi-platform, systems using EiffelRibbon can be targeted only to the Microsoft Windows platform.''}} + + +[[Image:EiffelRibbon window 01|A ribbon on a window]] + +Figure 1: A ribbon at the top of a window. + + +The EiffelRibbon library contains the classes that are used to implement the ribbon facilities. The classes in the EiffelRibbon library all have class names beginning "EV_", the default prefix for EiffelVision 2 classes. So the EiffelRibbon classes can be seen as an extension to the EiffelVision 2 library. If you've used EiffelVision 2 to create applications with graphical user interfaces, then the EiffelRibbon class won't look unfamiliar to you. However, unlike other EiffelVision 2 classes, the EiffelRibbon classes only work in applications targeted to Microsoft Windows. + +To gain a detailed understanding of the goals of Microsoft's Ribbon technology including some guidelines on designing effective ribbons, see [http://msdn.microsoft.com/en-us/library/cc872782.aspx the '''Ribbons''' page] on Microsoft's MSDN site. + +The [[EiffelRibbon Design Tool|EiffelRibbon design tool]] helps you configure a ribbon in much the same way that [[EiffelBuild|EiffelBuild]] (ES Builder) helps you layout a GUI application. + + +=The EiffelRibbon Library= + +The EiffelRibbon library contains the classes necessary to add ribbons to EiffelVision 2 applications. As stated above, you won't really need to use the library directly. Rather, you use the EiffelRibbon tool to build an application that uses the library classes. + +Still you may find it interesting to browse the classes in the library. You'll see that as in the EiffelVision 2 library, many of the classes are there to provide support for the various elements that can be used in an application. Most of the class names for EiffelRibbon-specific elements begin with the prefix "EV_RIBBON". Some examples are: EV_RIBBON_BUTTON, EV_RIBBON_DROP_DOWN_GALLERY, and EV_RIBBON_COMBO_BOX_ITEM. Again, similar to EiffelVision 2, the class EV_RIBBON_COMBO_BOX_ITEM models an item for a EV_RIBBON_COMBO_BOX. + +So, here again, if you are familiar with EiffelVision 2, then EiffelRibbon should not seem very foreign to you. + + +=EiffelRibbon Applications= + +When you build an application with the [[EiffelRibbon Design Tool|EiffelRibbon tool]], it generates classes for you. These classes are often clients or heirs to classes in the EiffelRibbon library. The classes generated for the objects on your ribbon should look familiar to you as well. For example, as with EiffelBuild, for each ribbon object, say a button, there will be a class ending with the suffix "_IMP" which will get regenerated each time you request the EiffelRibbon tool to generate classes. Also generated is an heir to that class with a name that does not include the suffix. This class you are free to edit, as it will not be regenerated. It is in these editable classes that you provide the action sequences for your ribbon objects' behaviors. + +The class shown in the Edit pane of EiffelStudio in Figure 2 is a portion of a generated class BUTTON_CHANGE_SMALL_IMAGE, representing a ribbon button, from one of the EiffelRibbon examples. BUTTON_CHANGE_SMALL_IMAGE is a heir to BUTTON_CHANGE_SMALL_IMAGE_IMP. You can see that in the redefined version of create_interface_objects code has been added to add an agent to the select_actions for the ribbon button. In this case, it's an inline agent that will toggle the associated image back and forth between two different images. + + +[[Image:EiffelRibbon application 01|An EiffelRibbon application in EiffelStudio.]] + +Figure 2. + +==Project '''modes'''== + +EiffelRibbon projects can be built in one of two different '''project modes'''. The project mode is selected from the '''Project''' menu of the EiffelRibbon design tool. + +The default mode, called '''DLL mode''', is the most all encompassing project mode. It has the advantage that the full capabilities of EiffelRibbon are accessible. In DLL mode, a separate DLL is created to contain the generated code for each ribbon created for the project. + +The alternative to DLL mode is '''Application mode'''. Application mode allows almost all the capabilities of DLL mode, but includes all ribbon code in the project's executable image (.exe). For this reason, it is necessary to re-freeze the project after changes when using Application mode. Re-freezing is not necessary in DLL mode. + +Both modes allow multiple ribbons to be created for multiple windows. However certain restrictions apply in Application mode that do not apply in DLL mode. In DLL mode, different DLL's are created for each ribbon. These DLL's are separate and do not share data. However, in Application mode, a number of ribbon facilities, including the help button, the quick access toolbar, and the mini toolbar, are shared among all the ribbons defined. In DLL mode, these facilities are not shared and as such can be different for each ribbon. + +=Usage notes= + +==System requirements== + +To use the EiffelRibbon library and tools you must have: + +# Windows 7 +# The Microsoft C compiler provided with either: +## Windows SDK 7.0 or greater +## Visual Studio 2008 or greater + + +==Current state of development== + +Initial distribution: +* The EiffelRibbon library is not usable directly. The EiffelRibbon design tool allows you to design a ribbon and will generate code that relies on the EiffelRibbon library. +* A class EV_RIBBON_TITLED_WINDOW is provided with the library. EV_RIBBON_TITLED_WINDOW is a descendant of the standard EiffelVision 2 class EV_TITLED_WINDOW. The ribbon classes generated by EiffelRibbon tool can be added only to instances of EV_RIBBON_TITLED_WINDOW. + +==Known issues and limitations== + +Initial distribution: +* Resizing policy is not yet supported. +* When working in Application Mode, it is necessary to freeze the target system each time the EiffelRibbon code is regenerated. This is not necessary in DLL Mode. + + diff --git a/documentation/18.11/solutions/platform-specifics/microsoft-windows/index.wiki b/documentation/18.11/solutions/platform-specifics/microsoft-windows/index.wiki new file mode 100644 index 00000000..bdd6c6de --- /dev/null +++ b/documentation/18.11/solutions/platform-specifics/microsoft-windows/index.wiki @@ -0,0 +1,7 @@ +[[Property:title|Microsoft Windows]] +[[Property:weight|1]] +[[Property:uuid|b6513eee-a12c-1f9f-4257-b08d2e18cef4]] +== Eiffel with Microsoft Windows == + +The primary source for Eiffel platform specific support for Microsoft Windows. + diff --git a/documentation/18.11/solutions/platform-specifics/microsoft-windows/net/building-net-application.wiki b/documentation/18.11/solutions/platform-specifics/microsoft-windows/net/building-net-application.wiki new file mode 100644 index 00000000..88a90a65 --- /dev/null +++ b/documentation/18.11/solutions/platform-specifics/microsoft-windows/net/building-net-application.wiki @@ -0,0 +1,14 @@ +[[Property:title|Building a .NET application]] +[[Property:weight|1]] +[[Property:uuid|a44736cf-41df-1679-9c6d-7b56f31d5f9a]] +Eiffel for .NET has some specific functionality meant to leverage necessary aspects of the .NET Framework. + +For that reason, the [[EiffelStudio: Project settings window|project settings]] for Eiffel for .NET introduces new options. These options include: +* Specifying whether the generated assembly should be an EXE or a DLL. +* Choosing between generating verifiable or non verifiable IL code. Non verifiable IL code executes faster but requires high trust settings. + +The Eiffel for .NET compiler generates a single assembly whose name is the name of the system as given in the [[System Options|system options of the project settings]] . + + + + diff --git a/documentation/18.11/solutions/platform-specifics/microsoft-windows/net/eiffel-aspnet-documentation/eiffel-aspnet-tools-and-administration/eiffel-codedom-provider-manager.wiki b/documentation/18.11/solutions/platform-specifics/microsoft-windows/net/eiffel-aspnet-documentation/eiffel-aspnet-tools-and-administration/eiffel-codedom-provider-manager.wiki new file mode 100644 index 00000000..d03a9064 --- /dev/null +++ b/documentation/18.11/solutions/platform-specifics/microsoft-windows/net/eiffel-aspnet-documentation/eiffel-aspnet-tools-and-administration/eiffel-codedom-provider-manager.wiki @@ -0,0 +1,45 @@ +[[Property:title|Eiffel CodeDom Provider Manager]] +[[Property:weight|-1]] +[[Property:uuid|089e658f-4bd8-df8f-5647-0c176c00359b]] +The Eiffel Codedom Provider Manager allows graphical configuration of the Eiffel CodeDom Provider. There can be multiple configurations, each of them being associated with at least one application. + +{{note|The Eiffel for ASP.NET installation program will add a shortcut in the start menu to the Eiffel CodeDom Provider Manager. }} + +The main dialog of the Eiffel CodeDom Provider Manager is divided into two vertical panes. The left pane contains a list of available configurations while the right pane contains the settings corresponding to the currently selected configuration. Initially the only available configuration is the '''default''' configuration which applies to all applications. The configurable settings are listed below. +==General Settings== +* '''Fail on error''': Checking this box will force the Eiffel Codedom Provider to fail when an error occurs. By default the provider rescues the failure and logs an error but it might be easier for debugging to have the Eiffel CodeDom Provider stop and raise an exception. +* '''Log server''': Server where events should be logged. By default events are logged on the machine running the CodeDom Provider, the corresponding value is a dot ("."). Consult the [[Logging|Logging]] section for additional information on logging. +* '''Log level''': By default only errors are written to the log. It might be useful for debugging purposes to log additional information and/or warnings. This setting also allows to disable logging in case it is not required. Consult the [[Logging|Logging]] section for additional information on logging. + +==Compiler Settings== +* '''Default root class''': In the event where the CodeDom tree does not define an entry point, there still needs to be a root class for the Eiffel system to compile properly. If there is an entry point defined in the Codedom tree then this setting is ignored. +* '''Precompile ace file''': This setting, if set, gives the path to the ACE file of the precompile that the CodeDom compiler should use when compiling systems with this configuration. The CodeDom compiler will first check whether the precompile for that ACE file already exists in the precompile cache (See Precompile cache below). If it finds one then it will check whether the ACE file was modified since the precompile was created. If there isn't a corresponding precompile or if the ACE file was modified then the CodeDom compiler will create a new precompile in the precompile cache using the specified ace file. It will then compile the system using the precompile in the cache corresponding to the specified ACE file. + +{{note|If for any reason the precompilation fails then the CodeDom compiler will still compile the system but without using any precompile. }} + +* '''Metadata cache''': Both the Eiffel CodeDom Provider and the Eiffel compiler require reading from and writing to an Eiffel Metadata Cache. These caches contain information about mapping the .NET types and members names to valid Eiffel identifiers. Because read and write access are required, the application that uses the CodeDom Provider must have write access rights to the Eiffel Metadata Cache folder. +{{note|The Eiffel for ASP.NET installation program will grant write access rights to the Eiffel Metadata Cache folder to the ASPNET user and IIS_WPG group if they exist. ASPNET is the default user account used by the ASP.NET process (aspnet_wp.exe) under Windows XP while IIS_WPG is the default user account used by the ASP.NET process (w3wp.exe) under Windows 2003 Server. }} + +{{warning|Changing the Eiffel Metadata Cache folder path will force the Eiffel CodeDom Provider to regenerate the cache content during the next code generation or compilation. This process can take a long time and in particular can take more time than the default timeout for an ASP.NET page. If the Eiffel CodeDom Provider is used together with ASP.NET and if the Eiffel Metadata Cache path has been modified, it is recommended to change the default timeout for the first ASP.NET page containing Eiffel code to be loaded (this can be done by setting the ''HttpServerUtility.ScriptTimeout'' property). }} + +* '''Compiler metadata cache''': This cache is used by the Eiffel Codedom Provider Compiler to map .NET types and members names to valid Eiffel identifiers. Please consult '''Metadata cache''' for additional information (the same note and warning apply). +* '''Precompile cache''': If the configuration defines a precompile ace file then the Eiffel CodeDom Provider will create the precompile in the directory specified in this setting. Changing this value will force the Eiffel CodeDom Provider compiler to recreate the precompile in the new directory. + +==Assembly Prefixes== +This list associates .NET assemblies with the prefix that will be used for Eiffel class names corresponding to .NET types belonging to the assembly. For example the prefix for the assembly ''System.Xml.dll'' is ''XML_'', this means that the Eiffel class names of all the types in the assembly ''System.Xml.dll'' will all begin with ''XML_''. This is necessary because Eiffel doesn't have a notion of namespace. The default assembly prefixes cannot be modified but new assembly/prefix pairs can be added if necessary. +==Applications== +This last setting will only appear for configurations other than the default configuration. It lists the applications that will use the configuration when they load the Eiffel CodeDom Provider assembly. If an application is not listed in any configuration then it will use the default configuration. + +{{note|For a change in an existing configuration to take effect, the process that uses the modified configuration must be restarted. }} + +==New Configuration== +New configurations may be created by clicking the ''New'' button or the ''New'' entry in the ''File'' menu. The New Configuration dialog box asks for the name and the path of the configuration. It will create a file with the extension '''.ecd''' ('''E'''iffel '''C'''ode'''D'''om) with the specified name in the directory located at the specified path. Whenever one of the applications listed at the bottom of the New Configuration dialog loads the Eiffel CodeDom Provider, it will use this new configuration. +==Configuration Properties== +Double clicking on the configuration name in the configurations list, clicking the ''Properties'' button or choosing the ''Properties'' menu entry in the ''File'' menu will open the Configuration Properties dialog. This dialog gives the dates of creation and last modification of the configuration as well as the list of applications that use it if it's not the default configuration. + + +{{seealso|[[Configuration|Configuration]], [[Logging|Logging]] }} + + + + diff --git a/documentation/18.11/solutions/platform-specifics/microsoft-windows/net/eiffel-aspnet-documentation/eiffel-aspnet-tools-and-administration/esplitter.wiki b/documentation/18.11/solutions/platform-specifics/microsoft-windows/net/eiffel-aspnet-documentation/eiffel-aspnet-tools-and-administration/esplitter.wiki new file mode 100644 index 00000000..42a3e08f --- /dev/null +++ b/documentation/18.11/solutions/platform-specifics/microsoft-windows/net/eiffel-aspnet-documentation/eiffel-aspnet-tools-and-administration/esplitter.wiki @@ -0,0 +1,45 @@ +[[Property:title|eSplitter]] +[[Property:weight|0]] +[[Property:uuid|2cf7249c-fd1e-b8e0-08ab-c2995b2b8227]] +This tool comes in two flavors: a command line only utility ''esplit.exe'' and a graphical tool ''esplitter.exe''. Both applications achieve the same goal: to produce standard Eiffel source files ('''.e''' files) from Eiffel CodeDom Provider generated source files ('''.es''' files). +==Command Line Utility (esplit.exe)== +This utility is located in the ''Codedom\bin'' subfolder of the Eiffel for ASP.NET directory. The command line syntax is: + +Usage: esplit -f=FOLDER [-s -d=DESTINATION -v -h -m=REGEXP -n] + -d, --destination=DESTINATION + Folder where generated Eiffel class files should be created. + If not specified, creates Eiffel class files in same folder as + corresponding Eiffel multi-class file. + -f, --folder=FOLDER + Folder containing Eiffel multi-class files. + -h, --help + Help on using this program. + -m, --match=REGEXP + Regular expression that file name must match to be processed, by default matches all files with extension '.es'. + -n, --nologo + Do not display copyright notice. + -s, --subfolders + Also process files in subfolders. + -v, --version + Version information. +So running: + +esplit -f . +will generate Eiffel source files from all the files with extension '.es' in the current folder and running: + +esplit -f "source" -m "C.*\.es" -d "destination" -s +will generate Eiffel source files from all the files with extension '.es' and whose filename starts with a 'C' located in the 'source' folder and all its subfolders. The Eiffel source files will be generated in the 'destination' folder. +==Graphical Utility (esplitter.exe)== +The graphical utility includes two panes. The first pane allows setting different parameters: +* '''Folder containing Eiffel multi-class file(s)''': this field gives the path to the folder which contains the files to be processed. The button to the right of the field allows to browse for the folder. This field corresponds to the '-f' parameter of the command line utility. +* '''Only process files whose filename matches the following regular expression''': this field corresponds to the '-m' parameter of the command line utility. +* '''Also process files in subfolder''': if this check box is checked then the utility will search for files whose filenames match the regular expression in the destination folder as well as in its subfolders. This check box corresponds to the '-s' switch of the command line utility. +* '''Generate Eiffel class files in the same folder as the Eiffel multi-class files''': checking this radio button is equivalent to not providing a '-d' parameter to the command line utility. +* '''Generate Eiffel class files in the following folder''': The content of the field below this radio button corresponds to the '-d' parameter of the command line utility. +Clicking on the '''Generate''' button switches to the output pane and starts the Eiffel class file generation. The output pane contains the text output resulting from the execution of the tool. It also contains two buttons: +* '''Open Folder''': clicking on this button will open Windows Explorer in the folder where the Eiffel source files were generated. +* '''Exit''': clicking this button will close the application. + + + + diff --git a/documentation/18.11/solutions/platform-specifics/microsoft-windows/net/eiffel-aspnet-documentation/eiffel-aspnet-tools-and-administration/index.wiki b/documentation/18.11/solutions/platform-specifics/microsoft-windows/net/eiffel-aspnet-documentation/eiffel-aspnet-tools-and-administration/index.wiki new file mode 100644 index 00000000..bc8615ec --- /dev/null +++ b/documentation/18.11/solutions/platform-specifics/microsoft-windows/net/eiffel-aspnet-documentation/eiffel-aspnet-tools-and-administration/index.wiki @@ -0,0 +1,11 @@ +[[Property:title|Eiffel for ASP.NET Tools and Administration]] +[[Property:weight|2]] +[[Property:uuid|960d3d4b-33d0-327f-343d-ad9d5591f07a]] +The Eiffel for ASP.NET delivery comes together with several tools: +* [[Eiffel CodeDom Provider Manager|Eiffel CodeDom Provider Manager]] allows administering the Eiffel CodeDom Provider. +* [[eSplitter|ESplitter]] allows generating standard Eiffel source files ('''.e''' files) from Eiffel CodeDom Provider generated files ('''.es''') files. +* [[Name Mapper|Name Mapper]] allows retrieving the Eiffel identifier corresponding to a .NET type or type member. + + + + diff --git a/documentation/18.11/solutions/platform-specifics/microsoft-windows/net/eiffel-aspnet-documentation/eiffel-aspnet-tools-and-administration/name-mapper.wiki b/documentation/18.11/solutions/platform-specifics/microsoft-windows/net/eiffel-aspnet-documentation/eiffel-aspnet-tools-and-administration/name-mapper.wiki new file mode 100644 index 00000000..0113e3c5 --- /dev/null +++ b/documentation/18.11/solutions/platform-specifics/microsoft-windows/net/eiffel-aspnet-documentation/eiffel-aspnet-tools-and-administration/name-mapper.wiki @@ -0,0 +1,15 @@ +[[Property:title|Name Mapper]] +[[Property:weight|2]] +[[Property:uuid|82691c82-50a5-ed7f-b138-90946d094dae]] +The Name Mapper utility allows retrieving the Eiffel identifier corresponding to a .NET type name or a .NET member name. There are only two input fields in the interface: the .NET type name should be entered in the first one while the .NET member name should be entered in the second one. Once a valid .NET type name is entered in the type name input field, the tool starts searching for the corresponding Eiffel identifier. When the Name Mapper finds the corresponding Eiffel identifier, it automatically fills the .NET member name input combo box with all the member names of the corresponding type. This means that the .NET member type name can be chosen from the combo box entries or typed in (if it's typed in then the tool will autocomplete the member name). +The assemblies the tool will look into for the .NET type whose name was given in the .NET type name input field are listed below the input fields. It is possible to add new assemblies to the list by clicking the ''Add'' button. Assemblies that were added this way can be removed by clicking the ''Remove'' button after selecting the assembly from the list. +{{note|Assemblies that are listed by default cannot be removed. }} + +{{note|When adding an assembly and if the assembly has not been consumed (i.e. the XML names mapping files have not been generated in the Eiffel Metadata Cache) then the Name Mapper will consume the assembly, this may take a while. }} + + +{{seealso|[[Names Mappings|Names Mapping]] }} + + + + diff --git a/documentation/18.11/solutions/platform-specifics/microsoft-windows/net/eiffel-aspnet-documentation/eiffel-codedom-provider/about-code-document-object-model-codedom.wiki b/documentation/18.11/solutions/platform-specifics/microsoft-windows/net/eiffel-aspnet-documentation/eiffel-codedom-provider/about-code-document-object-model-codedom.wiki new file mode 100644 index 00000000..42b50945 --- /dev/null +++ b/documentation/18.11/solutions/platform-specifics/microsoft-windows/net/eiffel-aspnet-documentation/eiffel-codedom-provider/about-code-document-object-model-codedom.wiki @@ -0,0 +1,10 @@ +[[Property:title|About the Code Document Object Model (CodeDom)]] +[[Property:weight|0]] +[[Property:uuid|46136373-34bb-94b7-1f7b-934d584cf637]] +CodeDom stands for the '''Code Document Object Model'''. CodeDom allows for representing source code in an abstract data structure. Such a representation is called a '''CodeDom tree''' as the underlying data structure uses a tree paradigm. This abstract representation can then be generated into different programming languages. Each language vendor provides its implementation of the CodeDom interfaces, this implementation is called a '''CodeDom Provider'''. Programmers can then build tools that can work with many different languages without having to know about each one, instead they just delegate code generation to each CodeDom Provider. +The CodeDom interfaces also expose types and methods that allow for parsing source code and creating the corresponding CodeDom. The current implementation of the Eiffel CodeDom Provider does not support parsing. Code generation is a much more popular useage of the CodeDom and the current version focuses on this aspect of the technology. + + + + + diff --git a/documentation/18.11/solutions/platform-specifics/microsoft-windows/net/eiffel-aspnet-documentation/eiffel-codedom-provider/common-scenarios.wiki b/documentation/18.11/solutions/platform-specifics/microsoft-windows/net/eiffel-aspnet-documentation/eiffel-codedom-provider/common-scenarios.wiki new file mode 100644 index 00000000..e52b2ba8 --- /dev/null +++ b/documentation/18.11/solutions/platform-specifics/microsoft-windows/net/eiffel-aspnet-documentation/eiffel-codedom-provider/common-scenarios.wiki @@ -0,0 +1,19 @@ +[[Property:title|Common Scenarios]] +[[Property:weight|7]] +[[Property:uuid|15334d95-2ef5-6e1b-1754-051342bb7290]] +==ASP.NET== +Probably the most common use of the CodeDom technology is via Internet Information Services (IIS) and ASP.NET. The installation of the Eiffel for ASP.NET will configure the machine so ASP.NET pages can be written in Eiffel. Consult the [[Eiffel for ASP.NET Installation|Eiffel for ASP.NET documentation]] for details on how to write ASP.NET Eiffel pages. +==WSDL== +Another use of the CodeDom technology is via the WSDL utility. This utility is part of the .NET Framework SDK and is a common line application that can be used to automatically generate stub source code for any Web Service described by a Web Service Description Language (WSDL) file. It is possible to tell the utility which CodeDom Provider to use via the command line as follows: + +Wsdl /language:"EiffelSoftware.CodeDom.CodeDomProvider, EiffelSoftware.CodeDom, Version=2.0.1.1402, Culture=neutral, PublicKeyToken=def26f296efef469"
+http://api.google.com/GoogleSearch.wsdl + +{{note|The version number used above might differ depending on the version of the Eiffel CodeDom Provider dll installed on your system. }} + +{{note|The example above uses the Google web service, the corresponding URL is correct at the time of writing but there is no guarentee it won't change (or be removed) in the future. }} + +This will generate a file with the extension '''.es''' which contains multiple Eiffel class definitions. Compiling this file will require using the CodeDom compiler (programmatically via the CodeDom ICodeCompiler interface) or using the [[eSplitter|eSplitter]] tool to generate standard Eiffel source files ('''.e''' files) that can then be compiled by the standard Eiffel compiler. + + + diff --git a/documentation/18.11/solutions/platform-specifics/microsoft-windows/net/eiffel-aspnet-documentation/eiffel-codedom-provider/configuration.wiki b/documentation/18.11/solutions/platform-specifics/microsoft-windows/net/eiffel-aspnet-documentation/eiffel-codedom-provider/configuration.wiki new file mode 100644 index 00000000..22fcf22a --- /dev/null +++ b/documentation/18.11/solutions/platform-specifics/microsoft-windows/net/eiffel-aspnet-documentation/eiffel-codedom-provider/configuration.wiki @@ -0,0 +1,13 @@ +[[Property:title|Configuration]] +[[Property:weight|3]] +[[Property:uuid|2d885f05-adcc-d8da-6515-4568fc76bcf6]] +The Eiffel Codedom Provider uses XML configuration files that define additional settings specific to Eiffel. Such settings include whether to fail on error, what events to log, where to log them etc... Each application can define its own configuration to be used when it loads the Eiffel CodeDom Provider. If an application is not associated with a configuration file then a default configuration is used. +The association between applications and configurations as well as the actual settings the configuration defines can be set in the [[Eiffel CodeDom Provider Manager|Eiffel CodeDom Provider Manager]] . Run ''ecdpman.exe'' to start the manager. + +{{note|The Eiffel for ASP.NET installation program will add a shortcut in the start menu to the Eiffel CodeDom Provider Manager. }} + +{{seealso|[[Eiffel CodeDom Provider Manager|Eiffel CodeDom Provider Manager]] , [[Logging|Logging]] , [[Required Permissions|Required permissions]] }} + + + + diff --git a/documentation/18.11/solutions/platform-specifics/microsoft-windows/net/eiffel-aspnet-documentation/eiffel-codedom-provider/eiffel-implementation.wiki b/documentation/18.11/solutions/platform-specifics/microsoft-windows/net/eiffel-aspnet-documentation/eiffel-codedom-provider/eiffel-implementation.wiki new file mode 100644 index 00000000..eaa5bdd3 --- /dev/null +++ b/documentation/18.11/solutions/platform-specifics/microsoft-windows/net/eiffel-aspnet-documentation/eiffel-codedom-provider/eiffel-implementation.wiki @@ -0,0 +1,32 @@ +[[Property:title|Eiffel Implementation]] +[[Property:weight|7]] +[[Property:uuid|3f945c36-521e-cd71-fc7b-d549a6c05a04]] +There are a few topics specific to the implementation of the Eiffel CodeDom Provider that are worth mentioning. +==Multiple Classes File== +The Eiffel compiler expects that there is only one class per source file (file with extension '''.e'''), however the CodeDom interface specification requires multiple classes to be generated in the same file (actually in the same ''stream''). The Eiffel CodeDom Provider code generator generates files with the extension '''.es''' which may contain multiple class definitions. Each class definition is separated with a special marker that the Eiffel CodeDom Provider compiler will parse to create multiple '''.e''' files - each containing a single class definition - prior to calling the command line Eiffel compiler. + + +{{note|Only the Eiffel CodeDom Provider compiler knows how to handle '''.es''' files. The standard Eiffel compilers can only parse '''.e''' files. }} + +Eiffel for ASP.NET includes the [[eSplitter|eSplitter]] utility which can 'split' Eiffel multi-class files ('''.es''' files) into single class files ('''.e''' files). +==Inheritance Snippet== +Any type defined in a CodeDom tree to be consumed by the Eiffel CodeDom Provider may include one (and only one) snippet member that includes an inheritance clause declaration. This ''inheritance snippet'' must start with the keyword '''inherit''' and follows the Eiffel syntax for inheritance clauses. All the feature adaptations available in the Eiffel programming language may be used in such a snippet ('''rename''', '''export''', '''undefine''', '''redefine''', '''select'''). + + +{{note|The CodeDom tree itself might define additional inheritance clauses in which case the Eiffel CodeDom Provider will merge the snippet and the implicit clauses in the generated source file. }} + +==Indexing Snippet and Precompiled Libraries== +Another interesting snippet member is the ''indexing clause snippet'' which must start with the '''indexing''' keyword and follows the Eiffel syntax for indexing clauses. This snippet may include the indexing clause '''precompile_definition_file''' which can be used to specify the path to the precompiled library ACE file to be used by the Eiffel CodeDom Compiler. This is specially useful in ASP.NET pages where each page can specify which precompiled ACE file to use when compiling it. This path will be used instead of the path defined in the [[Configuration|configuration file]]. + + +{{note|Only one class per compile unit should define a path to the precompiled library ACE file. If more than one class contain a '''precompile_definition_file''' indexing clause then there is no guarentee on which one the Eiffel CodeDom Compiler will use. }} + +==Eiffel Configuration== +There are several Eiffel specific settings that can be set in the Eiffel CodeDom Provider which will affect the generated code as well as the CodeDom compiler behavior. These settings are covered in the [[Configuration|Configuration]] section. + + +{{seealso|[[eSplitter|eSplitter]], [[Configuration|Configuration]] }} + + + + diff --git a/documentation/18.11/solutions/platform-specifics/microsoft-windows/net/eiffel-aspnet-documentation/eiffel-codedom-provider/index.wiki b/documentation/18.11/solutions/platform-specifics/microsoft-windows/net/eiffel-aspnet-documentation/eiffel-codedom-provider/index.wiki new file mode 100644 index 00000000..76857f95 --- /dev/null +++ b/documentation/18.11/solutions/platform-specifics/microsoft-windows/net/eiffel-aspnet-documentation/eiffel-codedom-provider/index.wiki @@ -0,0 +1,5 @@ +[[Property:title|The Eiffel CodeDom Provider]] +[[Property:weight|0]] +[[Property:uuid|0b45f31f-83ea-6301-9017-7b78c6827772]] +The Eiffel CodeDom Provider provides an implementation of the CodeDom Provider generation and compilation interfaces defined in the System.CodeDom namespace of the .NET Framework. This documentation includes the following sections: + diff --git a/documentation/18.11/solutions/platform-specifics/microsoft-windows/net/eiffel-aspnet-documentation/eiffel-codedom-provider/installation.wiki b/documentation/18.11/solutions/platform-specifics/microsoft-windows/net/eiffel-aspnet-documentation/eiffel-codedom-provider/installation.wiki new file mode 100644 index 00000000..44d43397 --- /dev/null +++ b/documentation/18.11/solutions/platform-specifics/microsoft-windows/net/eiffel-aspnet-documentation/eiffel-codedom-provider/installation.wiki @@ -0,0 +1,19 @@ +[[Property:title|Installation]] +[[Property:weight|1]] +[[Property:uuid|b6197932-4bcb-c79b-afe2-1a8f36dbbd7c]] +For certain tools (including ASP.NET) to detect the availability of a CodeDom Provider, the corresponding assembly name must be listed in the .NET machine wide configuration file typically located in: + +%SYSTEM_DRIVE%\Windows\Microsoft.NET\Framework\vx.x.xxxx\CONFIG\machine.config +(where vx.x.xxxx corresponds to the .NET Framework version number). The available CodeDom Providers are listed under the '''' XML node. The Eiffel CodeDom Provider implements a.NET Installer class so that should you need to add the Eiffel CodeDom Provider to the machine configuration file, simply run the .NET SDK command line utility ''InstallUtil'' as follows: + +InstallUtil EiffelSoftware.Codedom.dll +Conversely, should the Eiffel Codedom Provider not be required anymore, running the following command line will remove it from the ''machine.config'' file: + +InstallUtil /u EiffelSoftware.Codedom.dll + +{{note|The '''Eiffel for ASP.NET''' installation program will take care of registering and unregistering the Eiffel CodeDom Provider properly. }} + + + + + diff --git a/documentation/18.11/solutions/platform-specifics/microsoft-windows/net/eiffel-aspnet-documentation/eiffel-codedom-provider/limitations.wiki b/documentation/18.11/solutions/platform-specifics/microsoft-windows/net/eiffel-aspnet-documentation/eiffel-codedom-provider/limitations.wiki new file mode 100644 index 00000000..af6647b5 --- /dev/null +++ b/documentation/18.11/solutions/platform-specifics/microsoft-windows/net/eiffel-aspnet-documentation/eiffel-codedom-provider/limitations.wiki @@ -0,0 +1,10 @@ +[[Property:title|Limitations]] +[[Property:weight|8]] +[[Property:uuid|6d8ab90d-f051-5010-55df-218a020d9cb5]] +==Generation Only== +The current implementation of the Eiffel CodeDom Provider does not support parsing Eiffel source code to produce a CodeDom tree. Only code generation and compilation are supported in the current release. +==Managed Code Only== +Only managed code can be generated or compiled by the Eiffel CodeDom Provider. This means that the CodeDom tree being compiled cannot include snippet members which use or define Eiffel external clauses. If the system requires access to external methods, they should be defined in a precompiled library (see [[Configuration|Configuration]] ). + + + diff --git a/documentation/18.11/solutions/platform-specifics/microsoft-windows/net/eiffel-aspnet-documentation/eiffel-codedom-provider/logging.wiki b/documentation/18.11/solutions/platform-specifics/microsoft-windows/net/eiffel-aspnet-documentation/eiffel-codedom-provider/logging.wiki new file mode 100644 index 00000000..78736ac1 --- /dev/null +++ b/documentation/18.11/solutions/platform-specifics/microsoft-windows/net/eiffel-aspnet-documentation/eiffel-codedom-provider/logging.wiki @@ -0,0 +1,21 @@ +[[Property:title|Logging]] +[[Property:weight|4]] +[[Property:uuid|d425684b-687c-aee6-25fa-650e5885e014]] +The Eiffel CodeDom Provider may be configured (via the [[Eiffel CodeDom Provider Manager|Eiffel Codedom Provider Manager]] ) to log information, warnings and/or errors in the Windows Event Log. Logging may be useful for a number of reasons, some of them are: +* To detect which CodeDom interface method is called and when it's called. This is particularly useful when the source code for the CodeDom consumer (e.g. ASP.NET) is not available. +* To locate the source of a problem when the code generated by the Eiffel CodeDom Provider is incomplete or incorrect. This may happen if the CodeDom tree given to the Eiffel CodeDom Provider uses one of the unsupported constructs as listed in the topic [[Supported Constructs|Supported Constructs]] . +* To detect a problem in a CodeDom tree. The logs will help in locating the location of the problem as they include contextual information on the node where the error occurred. + +==Log Details== +There are three types of events that can be logged: information events, warnings and errors: +* Information events include calls to CodeDom interface methods and other events that will not affect the execution of the Eiffel CodeDom Provider +* Warnings include events that will not prevent the CodeDom Provider from running but that may affect the results. For example if a CodeDom tree element references a .NET entity that the Eiffel CodeDom Provider cannot find then it will generate a default Eiffel name by running the default formatting algorithm. This may produce code that does not compile if the Eiffel name of the entity does not correspond to the formatted .NET name (for example if the entity is a type and the type's assembly has a non-empty prefix). +* Errors include events that will force the execution of the Eiffel CodeDom Provider to stop. By default the Eiffel CodeDom Provider simply stops and returns an error, it is possible however to configure it so that an exception is raised. + +==Log Location== +All the Eiffel CodeDom Provider events are logged into the Windows '''System''' Log. This log can be viewed via the Windows administrative tool ''Event Viewer''. The source for the events raised by the Eiffel CodeDom Provider is ''Eiffel CodeDom Provider''. By default all the events are logged on the machine running the Eiffel CodeDom Provider but it is possible to change its configuration so that the events are logged on a different machine (see [[Required Permissions|Required permissions]] ). +{{seealso|[[Eiffel CodeDom Provider Manager|Eiffel CodeDom Provider Manager]] , [[Supported Constructs|Supported constructs]] , [[Required Permissions|Required permissions]] }} + + + + diff --git a/documentation/18.11/solutions/platform-specifics/microsoft-windows/net/eiffel-aspnet-documentation/eiffel-codedom-provider/required-permissions.wiki b/documentation/18.11/solutions/platform-specifics/microsoft-windows/net/eiffel-aspnet-documentation/eiffel-codedom-provider/required-permissions.wiki new file mode 100644 index 00000000..7649965a --- /dev/null +++ b/documentation/18.11/solutions/platform-specifics/microsoft-windows/net/eiffel-aspnet-documentation/eiffel-codedom-provider/required-permissions.wiki @@ -0,0 +1,26 @@ +[[Property:title|Required Permissions]] +[[Property:weight|6]] +[[Property:uuid|f55af6a0-b896-12b7-fe4a-ebb1787731e5]] +The account running the Eiffel CodeDom Provider might have restricted permissions such as when used through ASP.NET. This section aims at defining the security permissions required for the execution of the Eiffel CodeDom Provider. +==Eiffel Metadata Cache== +Both when generating and compiling source code, the Eiffel CodeDom Provider needs to read and write from and to the Eiffel Metadata Cache. This repository stores the mapping information between .NET and Eiffel names for both types and their members. By default the Eiffel Metadata Cache is located in the ''Assemblies'' subfolder of the Eiffel CodeDom Provider directory. +{{note|The Eiffel for ASP.NET installation program will grant read and write access to the Eiffel Metadata Cache folder for the ''ASPNET'' (default ASP.NET worker process account on Windows XP Professional) and the ''IIS_WPG'' (default ASP.NET worker process account on Windows Server 2003) accounts. }} +The path to the Eiffel Metadata Cache folder might be changed via the [[Eiffel CodeDom Provider Manager|Eiffel CodeDom Provider Manager]] , make sure the new folder can be read from and written to by the account running the process that uses the Eiffel CodeDom Provider. +==Precompile Cache== +The same requirements apply to the Precompile Cache folder. By default the Precompile Cache folder is located in the ''Precompile'' subfolder of the Eiffel CodeDom directory. +{{note|The Eiffel for ASP.NET installation program will grant read and write access to the Precompile Cache folder for the ''ASPNET'' (default ASP.NET worker process account on Windows XP Professional) and the ''IIS_WPG'' (default ASP.NET worker process account on Windows Server 2003) accounts. }} +As with the Eiffel Metadata Cache folder, it is possible to change the location of the Precompile Cache folder but the process running the Eiffel CodeDom Provider must always have read and write access to the folder. +==Logging== +Logging requires registry read access as well as event log write access. By default, the ASP.NET worker process does not have these permissions. The easiest way to grant the required permissions to the ASP.NET worker process is by using ASP.NET impersonation. This mechanism allows the ASP.NET worker process to run under a different account. This is done by providing a ''web.config'' file in the root folder of the ASP.NET application. The content of the configuration file needs to include the following declaration: + + + + + + +where Username is the name of an account which has all the required permissions and Password the corresponding password. Refer to the .NET Framework SDK documentation for additional information on ASP.NET impersonation. +The solution described above might not be acceptable on a production web server. However, it is possible to configure the Eiffel CodeDom Provider to log events on a different machine (see [[Eiffel CodeDom Provider Manager|Eiffel CodeDom Provider Manager]] ). The log machine should grant the appropriate permissions to the impersonated account for logging and could only be accessible through the web server. This setting would avoid having to grant additional permissions to the ASP.NET worker process account on the web server while still enabling logging. + + + + diff --git a/documentation/18.11/solutions/platform-specifics/microsoft-windows/net/eiffel-aspnet-documentation/eiffel-codedom-provider/supported-constructs.wiki b/documentation/18.11/solutions/platform-specifics/microsoft-windows/net/eiffel-aspnet-documentation/eiffel-codedom-provider/supported-constructs.wiki new file mode 100644 index 00000000..ac9b927d --- /dev/null +++ b/documentation/18.11/solutions/platform-specifics/microsoft-windows/net/eiffel-aspnet-documentation/eiffel-codedom-provider/supported-constructs.wiki @@ -0,0 +1,37 @@ +[[Property:title|Supported Constructs]] +[[Property:weight|2]] +[[Property:uuid|99e15890-75a9-8b76-d0b6-b9be419be5ce]] +Since not every language might support all the constructs CodeDom can represent, there needs to be a way for the CodeDom Provider to specify which constructs are supported and which ones are not. This is done through the System.Codedom.Compiler.ICodeGenerator interface using method Supports.
+This method takes a flag corresponding to the CodeDom contruct the caller is interested in and returns a boolean value indicating whether or not the construct is supported. In the Eiffel CodeDom Provider implementation there is a third category of constructs which will be reported as supported since the provider will generate valid Eiffel code for them but that should be distinguished from other "truly" supported constructs as the generated code will not correspond to the .NET equivalent of the construct.
+Let's take an example: Enum declarations are supported by the Eiffel CodeDom Provider because the generated Eiffel code will correctly make use of the values defined in the enum. However there is no such thing as an enum type in Eiffel so there won't be a corresponding .NET enum type in the generated assembly. Such constructs are said to be "non-roundtripable" because even if the Eiffel CodeDom Provider supported parsing source code, the corresponding CodeDom tree would not include the constructs like the initial CodeDom did. +The lists of supported, supported without roundtrip and unsupported constructs for the Eiffel CodeDom Provider are as follows: + +'''Supported constructs''': +* Arrays of arrays +* Assembly attributes +* Complex expressions +* Declare value types +* Entry point method +* Multiple interface members +'''Supported constructs (no roundtrip)''': +* Declare enums +* Declare events +* Declare interfaces +* Nested types +* Public static members +* Reference parameters +* Try catch statements +'''Unsupported constructs''': +* Chained constructor arguments +* Declare delegates +* Goto statements +* Multidimensional arrays +* Parameter attributes +* Return type attributes +* Static constructors +* Win32 resources + + + + + diff --git a/documentation/18.11/solutions/platform-specifics/microsoft-windows/net/eiffel-aspnet-documentation/index.wiki b/documentation/18.11/solutions/platform-specifics/microsoft-windows/net/eiffel-aspnet-documentation/index.wiki new file mode 100644 index 00000000..5327087a --- /dev/null +++ b/documentation/18.11/solutions/platform-specifics/microsoft-windows/net/eiffel-aspnet-documentation/index.wiki @@ -0,0 +1,12 @@ +[[Property:title|Eiffel for ASP.NET Documentation]] +[[Property:weight|6]] +[[Property:uuid|158e298e-e4b3-3246-651c-557f2f630957]] +CodeDom is a Microsoft .NET technology which allows representing source code programatically so that it may be rendered in different languages. The Eiffel CodeDom Provider is installed through Eiffel for ASP.NET which is available for download for free on the Eiffel Software web site ( [http://www.eiffel.com http://www.eiffel.com] ).
+The following documents cover different aspects of the Eiffel CodeDom Provider: +* [[Writing ASP.NET pages in Eiffel|Writing ASP.NET pages in Eiffel]] covers topics related to writing Eiffel pages in ASP.NET. +* The [[The Eiffel CodeDom Provider|Eiffel CodeDom Provider]] documentation focuses on the Eiffel CodeDom Provider per se. Read this documentation if you intend on using the Eiffel CodeDom Provider via a different mean than ASP.NET (e.g. to generate Web Services stubs using Microsoft's WSDL utility). +* Finally, [[Eiffel for ASP.NET Tools and Administration|Eiffel for ASP.NET Tools and Administration]] covers the Eiffel CodeDom Provider Manager, the eSplitter and the Name Mapper tools that are included in the Eiffel for ASP.NET delivery. + + + + diff --git a/documentation/18.11/solutions/platform-specifics/microsoft-windows/net/eiffel-aspnet-documentation/writing-aspnet-pages-eiffel/codedom-getting-started.wiki b/documentation/18.11/solutions/platform-specifics/microsoft-windows/net/eiffel-aspnet-documentation/writing-aspnet-pages-eiffel/codedom-getting-started.wiki new file mode 100644 index 00000000..52772abf --- /dev/null +++ b/documentation/18.11/solutions/platform-specifics/microsoft-windows/net/eiffel-aspnet-documentation/writing-aspnet-pages-eiffel/codedom-getting-started.wiki @@ -0,0 +1,15 @@ +[[Property:title|CodeDom: Getting Started]] +[[Property:weight|0]] +[[Property:uuid|06e0c7ae-6d25-a0ef-81e6-2ee3c95fe4a1]] +== Prerequisites == +Before you start writing ASP.NET pages in Eiffel, you should be familiar with the ASP.NET technology itself. If you haven't already, it is strongly recommended that you follow the ASP.NET quickstarts available online at [http://samples.gotdotnet.com/quickstart/aspplus/ http://samples.gotdotnet.com/quickstart/aspplus/] . Apart from a few Eiffel specific points described in [[Using Eiffel (to write ASP.NET pages)|Using Eiffel]], writing ASP.NET pages in Eiffel follows the same rules as writing ASP.NET pages in any other language. +Writing ASP.NET pages in Eiffel also requires to be familiar with the Eiffel programming language itself. There are no changes in the language when using it to write ASP.NET pages: the same parser and compiler are used to parse and compile standard Eiffel source code and ASP.NET generated source code. Documentation on the Eiffel programming language can be found on the [http://docs.eiffel.com Eiffel documentation web site] . + +==Samples== +The '''Samples''' folder of the Eiffel for ASP.NET delivery includes ASP.NET pages written in Eiffel. To run the samples you can either click on the corresponding link in the ''Start'' menu or open the page [http://localhost/EiffelSample http://localhost/EiffelSample] in your internet browser. Each sample comes with an extensively commented source code. +{{note|The samples will only be available if IIS was installed prior to installing Eiffel for ASP.NET. }} + + + + + diff --git a/documentation/18.11/solutions/platform-specifics/microsoft-windows/net/eiffel-aspnet-documentation/writing-aspnet-pages-eiffel/eiffel-aspnet-installation.wiki b/documentation/18.11/solutions/platform-specifics/microsoft-windows/net/eiffel-aspnet-documentation/writing-aspnet-pages-eiffel/eiffel-aspnet-installation.wiki new file mode 100644 index 00000000..d9ca6060 --- /dev/null +++ b/documentation/18.11/solutions/platform-specifics/microsoft-windows/net/eiffel-aspnet-documentation/writing-aspnet-pages-eiffel/eiffel-aspnet-installation.wiki @@ -0,0 +1,17 @@ +[[Property:title|Eiffel for ASP.NET Installation]] +[[Property:weight|-1]] +[[Property:uuid|c9371a07-12fb-bdb2-b076-3da3c0ec8da6]] +Eiffel for ASP.NET is available for downloading for free at [http://www.eiffel.com http://www.eiffel.com] . Simply run the file and follow the installer instructions. It is recommended that Internet Information Services (IIS) be deployed on the machine prior to installing Eiffel for ASP.NET. If IIS is not deployed then the installation program will display a warning message box. Click '''ignore''' to keep installing the product. +Without IIS, ASP.NET pages cannot be loaded and thus the samples will not be installed. It might still be useful to install Eiffel for ASP.NET without IIS if the Eiffel CodeDom Provider is going to be used through other [[Common Scenarios|scenarios]]. If IIS is available then the installer will open an Eiffel ASP.NET page at the end of the installation process. This page contains links to the documentation and samples. The installer will also put links to these documents in the ''Start'' menu under 'Programs\Eiffel for ASP.NET x.x' where 'x.x' corresponds to the version number of Eiffel for ASP.NET. +==System Requirements== +* Windows 2000 Server or Advanced Server with Service Pack 2, Windows XP Professional or 64-Bit Edition, or one of the Windows Server 2003 family products. +* .NET Framework (1.0 or 1.1) +* Internet Information Services with ASP.NET (optional see above) + +==ASP.NET Installation== +Please consult the corresponding documentation (available online at [http://msdn.microsoft.com/asp.net/ http://msdn.microsoft.com/asp.net/] ) for configuring ASP.NET properly. In particular, be aware that by default ASP.NET is disabled on Windows 2003 Server. + + + + + diff --git a/documentation/18.11/solutions/platform-specifics/microsoft-windows/net/eiffel-aspnet-documentation/writing-aspnet-pages-eiffel/index.wiki b/documentation/18.11/solutions/platform-specifics/microsoft-windows/net/eiffel-aspnet-documentation/writing-aspnet-pages-eiffel/index.wiki new file mode 100644 index 00000000..f39d2f87 --- /dev/null +++ b/documentation/18.11/solutions/platform-specifics/microsoft-windows/net/eiffel-aspnet-documentation/writing-aspnet-pages-eiffel/index.wiki @@ -0,0 +1,5 @@ +[[Property:title|Writing ASP.NET pages in Eiffel]] +[[Property:weight|-1]] +[[Property:uuid|7027e7f3-38e1-5e26-c936-20aea0e0c205]] +Eiffel for ASP.NET allows running ASP.NET pages written in Eiffel. It should be installed on both the web server and the developer's machine. This documentation includes the following sections: + diff --git a/documentation/18.11/solutions/platform-specifics/microsoft-windows/net/eiffel-aspnet-documentation/writing-aspnet-pages-eiffel/names-mappings.wiki b/documentation/18.11/solutions/platform-specifics/microsoft-windows/net/eiffel-aspnet-documentation/writing-aspnet-pages-eiffel/names-mappings.wiki new file mode 100644 index 00000000..f349281b --- /dev/null +++ b/documentation/18.11/solutions/platform-specifics/microsoft-windows/net/eiffel-aspnet-documentation/writing-aspnet-pages-eiffel/names-mappings.wiki @@ -0,0 +1,34 @@ +[[Property:title|Names Mappings]] +[[Property:weight|4]] +[[Property:uuid|fa212869-ffb0-0a6a-cbd0-7a184b11491d]] +Maybe the most striking difference when writing pages in Eiffel comes from the name of the .NET types and methods. Because of different naming conventions, overloading and differences in identifier validity rules, .NET identifiers cannot be mapped directly to Eiffel identifiers. As a consequence, the Eiffel compiler creates XML mapping files in the ''Eiffel Metadata Cache''. These files are created only once for each referenced assembly. +{{note|The ASP.NET installation program pre-generates the Eiffel Metadata Cache for all assemblies required by ASP.NET by default. }} +The name mapping algorithm is quite complex but it is possible to guess the Eiffel identifier from the .NET identifier in most cases. The following simple steps can be followed to retrieve the Eiffel identifier corresponding to a .NET type: +# Only the simple type name is used, the namespace isn't used by the Eiffel identifier: +System.Xml.NameTable -> NameTable + +# Underscores are introduced in between words (prior to upper case letters other than the first character): +NameTable -> Name_Table + +# Eiffel class names are always upper case: +Name_Table -> NAME_TABLE + +# If the assembly containing the type is associated with a prefix in the Eiffel system then the prefix gets prepended to the name: +NAME_TABLE -> XML_NAME_TABLE + +The steps to follow to retrieve the Eiffel identifier corresponding to a .NET member are simpler: +# For property getters, the "get_" prefix is removed: +get_MaxOccursString -> MaxOccursString + +# Underscores are introduced in between words (prior to upper case letters other than the first character): +MaxOccursString -> Max_Occurs_String + +# Eiffel feature names are always lower case: +Max_Occurs_String -> max_occurs_string + +Although these simplified steps will work in most cases there are certain .NET identifiers that require additional manipulation to be translated into Eiffel. The [[Name Mapper|Name Mapper]] utility should be used when such cases arise. +{{seealso|[[Name Mapper|Name Mapper]] }} + + + + diff --git a/documentation/18.11/solutions/platform-specifics/microsoft-windows/net/eiffel-aspnet-documentation/writing-aspnet-pages-eiffel/using-eiffel-write-aspnet-pages.wiki b/documentation/18.11/solutions/platform-specifics/microsoft-windows/net/eiffel-aspnet-documentation/writing-aspnet-pages-eiffel/using-eiffel-write-aspnet-pages.wiki new file mode 100644 index 00000000..6ce435c5 --- /dev/null +++ b/documentation/18.11/solutions/platform-specifics/microsoft-windows/net/eiffel-aspnet-documentation/writing-aspnet-pages-eiffel/using-eiffel-write-aspnet-pages.wiki @@ -0,0 +1,21 @@ +[[Property:title|Using Eiffel (to write ASP.NET pages)]] +[[Property:weight|3]] +[[Property:uuid|c8e2ffa7-cfa8-0b4c-4b5e-e1f386b7ab11]] +==Inheritance== +Eiffel handles inheritance in a different way than most languages. In C# or VB.NET the behavior of a newly introduced member in a class hierarchy is defined as part of the member declaration itself (for example C# will precede the member declaration with the keyword ''override'' to accomplish the same result as an Eiffel ''redefine'' clause). In Eiffel, classes are equipped with an inheritance clause which centralizes all the feature adaptations. +As a result, Eiffel for ASP.NET introduces '''inheritance snippets'''. Each Eiffel ASP.NET page may include at most one inheritance snippet. Such a snippet must start with the '''inherit''' keyword and may then list any valid Eiffel feature adaptation. + +==String and Array Manifest Constants== +The Eiffel programming language supports using '''manifest constants''' in source code. The type of these constants is inferred by the Eiffel compiler. There are two manifest constant types that require special attention on .NET: string and array. Because the Eiffel and the .NET types differ, writing code using string or array manifest constants requires additional care. +* '''Strings''': Eiffel strings cannot be mapped directly to .NET strings because Eiffel strings are ''mutable'': an Eiffel string can be resized while the size of a .NET string is set for the lifetime of the object. However, the Eiffel class STRING defines conversion features that will automatically convert to and from a .NET string. So when the compiler expects an object of type ''System.String'' where an object of type STRING is used, it will automatically call the right conversion routine.
+However if an instance of STRING is passed as an argument to an overloaded .NET function that can accept both an instance of ''System.Object'' or an instance of ''System.String'' then the compiler will produce an error since it has no means to know which type the Eiffel object should be converted to (any Eiffel object converts to ''System.Object''). When this happens, the conversion function to_cil must be explicitely called. +* '''Arrays''': The exact same problem also arises with arrrays. Instances of the Eiffel class ARRAY are different from instances of NATIVE_ARRAY which correspond to the .NET array type. There are however features in ARRAY that will convert to and from .NET arrays. If an overloaded .NET function can take an argument of type ''System.Object'' or ''System.Array'', any instance of ARRAY given to it must first be converted explicitly to a .NET array by calling the to_cil function. + +==Compilation and Timeouts== +Eiffel compilations can take longer than the default timeouts set in ASP.NET. In particular ASP.NET will run batch compilations on the entire directory that is being accessed by IIS each time the time stamp of that directory changes. If the batch compilation takes longer than the ''batchTimeout'' property defined in the machine wide configuration file (''machine.config'') then ASP.NET will start another compilation just for the requested file. This can be quite resource intensive for the Web server and thus it might be beneficial to increase the default value of 15 seconds for ''batchTimeout''. + + + + + + diff --git a/documentation/18.11/solutions/platform-specifics/microsoft-windows/net/eiffel-net-language/conventions/constructors-and-creation-procedures.wiki b/documentation/18.11/solutions/platform-specifics/microsoft-windows/net/eiffel-net-language/conventions/constructors-and-creation-procedures.wiki new file mode 100644 index 00000000..3f85e9d4 --- /dev/null +++ b/documentation/18.11/solutions/platform-specifics/microsoft-windows/net/eiffel-net-language/conventions/constructors-and-creation-procedures.wiki @@ -0,0 +1,48 @@ +[[Property:title|Constructors and Creation Procedures]] +[[Property:weight|4]] +[[Property:uuid|f06eb414-c284-902b-0481-3f00da82d47e]] +This section deals with what happens when objects, that is runtime instances of types, get created and initialized. When a new instance is created, there is an opportunity to initialize the state of the instance. This is done with a constructor in .NET, and with a creation procedure in Eiffel. + +==Eiffel Creation Procedures== + +Eiffel creation procedures are features of a class which can be used to initialize instances. Classes can have more than one creation procedure available. However, each creation procedure must ensure that the class invariant holds when the procedure completes execution. In other words, the creation procedure is there to initialize a newly created instance, and the class invariant guarantees that a newly initialized instance is actually valid. + +There is nothing special about creation procedures themselves, they are just ordinary procedures (although by convention their names usually begin with the word "make"). What makes them creation procedures is the fact that their names are listed as creation procedures in the class text. + +In Eiffel, a creation procedure can be applied to an instance at any time (not just at object creation). This is done sometimes to reinitialize existing instances. + +==Constructors in .NET== + +Like creation procedures in Eiffel, .NET constructors are used to initialize new instances of types. Constructors manifest themselves differently depending upon which .NET language you use. In C#, constructors always appear as a method having the same name as the class on which they are implemented. In Visual Basic .NET, they always appear as a Sub with the name New. Once compiled into an assembly, the metadata labels constructors as . ctor. + +Constructors can have multiple versions by overloading. That is, each version would have a different set of argument types. + +Constructors can only be applied when a new instance is created. + +===Constructors as Eiffel Creation Procedures=== + +When types from .NET assemblies are made available to Eiffel systems, the constructors are presented as creation procedures. Just as constructors show up in the C# and VB.NET environments with names appropriate to those languages, so it is with Eiffel for .NET. Always, constructors will have feature names which begin with the word "make", the convention for creation procedure naming in Eiffel. + +If there is only one version of the constructor, that version will be mapped to a single feature named make. However, if there are overloaded versions of the constructor, then these versions given names starting with "make_from_" and then followed with the argument names from the assembly metadata separated with the conjunction "_and_". Let's look at an example. + +The .NET type System.Drawing.Sizehas an overloaded constructor with two versions. In the System.Drawing assembly metadata, these two constructor versions look like this: + +void .ctor(int32 width, int32 height) +void .ctor(System.Drawing.Point pt) + + +So the argument names for the first version are width and height. For the second version there is only one argument named pt. The constructor versions as presented to Eiffel programmers as creation procedures look like this: + +make_from_width_and_height (width: INTEGER; height: INTEGER) +make_from_pt (pt: DRAWING_POINT) + + +Presenting the names in this format handles the conflicts of overloading and provides reasonably intuitive names that comply with Eiffel naming conventions. + +===Eiffel Creation Procedures as Constructors?=== + +Eiffel creation procedures do not map to constructors when Eiffel classes are compiled into assemblies. Rather, they are actually manifested as functions on a factory class in the namespace Create in the assembly. These functions return an initialized instance. In the section Type Organization there is more information about the organization of the types in assemblies built with Eiffel for .NET, along with an example of using types from such an assembly. + + + + diff --git a/documentation/18.11/solutions/platform-specifics/microsoft-windows/net/eiffel-net-language/conventions/eiffel-class-and-feature-names.wiki b/documentation/18.11/solutions/platform-specifics/microsoft-windows/net/eiffel-net-language/conventions/eiffel-class-and-feature-names.wiki new file mode 100644 index 00000000..11ad8675 --- /dev/null +++ b/documentation/18.11/solutions/platform-specifics/microsoft-windows/net/eiffel-net-language/conventions/eiffel-class-and-feature-names.wiki @@ -0,0 +1,218 @@ +[[Property:title|Eiffel Class and Feature Names]] +[[Property:weight|2]] +[[Property:uuid|16e4a231-7aae-4b37-52fd-67876cc222ad]] +Certain naming conventions are respected by Eiffel programmers. Although Eiffel is not case-sensitive, convention dictates the use of upper and lower case in particular situations. When you program in Eiffel for .NET, you create new Eiffel classes, but you also use types from .NET assemblies. These .NET types are presented to you in a view that is consistent with Eiffel conventions. + +==Eiffel Class Names== + +Convention dictates that Eiffel class names are always all upper case characters with words separated by the underscore ("_") character. Eiffel classes are not qualified by "namespace" as in some other languages. This means that Eiffel class names must be unique with in a system. It also means that any types from existing .NET assemblies will have their names mapped to conventional Eiffel class names in order to be used by Eiffel classes in EiffelEnvision + +Here are some class names and their descriptions from the Eiffel Base Library. These class names comply with the Eiffel class naming convention. + +STRING + + Sequences of characters, accessible through integer indices in a contiguous range. + +RANDOM + + Pseudo-random number sequence, linear congruential method. + +ARRAYED_LIST + + Lists implemented by resizable arrays. + +LINKED_QUEUE + + Unbounded queues implemented as linked lists. + + + +Now here are some type names from the .NET mscorlib as they appear as conventional Eiffel class names (i.e. , in the form in which they become available to Eiffel for .NET programmers), followed by their full .NET type and their Summary from the .NET library. names. + +SYSTEM_STRING + +System.String + + Represents an immutable series of characters. + +SYSTEM_RANDOM + +System.Random + + Represents a pseudo-random number generator, a device that produces a sequence of numbers that meet certain statistical requirements for randomness. + +ARRAY_LIST + +System.Collections.ArrayList + + Implements the System.Collections.IListinterface using an array whose size is dynamically increased as required. + +SYSTEM_QUEUE + +System.Collections.Queue + + Represents a first-in, first-out collection of objects. + + + +In summary, Eiffel class names and type names from .NET assemblies made available to Eiffel programmers will be all upper case, with words separated by the underscore character. + +===Eiffel Names for .NET Types=== + +How Eiffel compliant names are derived from .NET type names is fairly simple in most cases. The "simple" class name, that is, the word following the rightmost dot in the full class name, is converted to an Eiffel compliant name by making it upper case and separating in embedded words by underscore. In the example above, System.Collection.ArrayList becomes ARRAY_LIST. + +The other cases in the example are not quite so simple. If the basic derivation produces a name which conflicts with a classname in the Eiffel Base Library, then it will be disambiguated. The simple derivation of System.String would be STRING, but this would conflict with Eiffel's STRING class, so System.String becomes available to Eiffel for .NET programmers as SYSTEM_STRING. + +Sometimes it is better to disambiguate an entire assembly rather than handling individual exceptions to the simple derivation. This is done by specifying a common prefix for all types in the assembly. For example, EiffelEnvision uses a prefix of " DATA_" for all classes in the .NET assembly System.Data. As a result, the type System.Data.Constraint is available in Eiffel as class DATA_CONSTRAINT. + +You'll see a little more about namespaces, assemblies, and Eiffel clusters in [[Type Organization|Type Organization]] . + +===Similar Types from Both Libraries=== + +You may have noticed a similarity in the names and descriptions from the Eiffel Base Library and those from the .NET "mscorlib" library. This is not by accident. The Eiffel class STRING is a different class from the .NET type System.String, which Eiffel programmers see represented as Eiffel class SYSTEM_STRING. There is more on this subject in [[Similar Types Occurring in Both Libraries|Similar Types Occurring in Both Libraries]] . + +==Eiffel Feature Names== + +By convention, feature names in Eiffel use all lower case characters, and like class names, words are separated by underscore. Also as with class names, the names of members from .NET assemblies will be represented in a form that complies with the Eiffel convention. + +Let's look at some simple examples. First some feature names from the Eiffel Base Library. + +to_upper + + From class STRING: Converts to upper case. + +item_double + + From class RANDOM: The current random number as a double between 0 and 1 + + + +Now check out these member names from the .NET "mscorlib" type library. These have been made available to Eiffel for .NET programmers in the Eiffel convention. Following the Eiffel name, you see their .NET member name and type name. + +to_upper + + Member ToUpper from typeSystem.String + + Returns a new System.String with the same content as the target, except all upper case. + +next_double + + Member NextDouble from type System.Random + + A double-precision floating point number greater than or equal to 0.0, and less than 1.0. + + + +So, Eiffel feature names, and the names of .NET members made available to Eiffel for .NET programmers, are all lower case with words separated by underscores. + +==Overloaded .NET Member Names== + +The .NET object model allows overloading of function names. This means that a .NET type can support multiple functions with the same name, that vary only by the types of the arguments they accept. For example, the .NET type System. Text. StringBuilder supports nineteen overloaded versions of the Append function. Here are a couple of examples, in their .NET forms: + +.NET function signature: Append(System.String) + +Member of type System.Text.StringBuilder + + Appends a copy of the specified string to the end of this instance. + +.NET function signature: Append(System.Char) + +Member of type System.Text.StringBuilder + + Appends the string representation of a specified Unicode character to the end of this instance. + + + +The Eiffel programming language does not allow overloading routine names. That means that you cannot code multiple routines with the same name in a single class. That in itself is not a problem. But it also means that to work in the .NET environment, where overloading is allowed some compromise has to be made. So, what happens is this: if you are programming in Eiffel for .NET and you are using types from a .NET assembly, those types will be presented to you as if they are Eiffel classes. We have already seen that the type and feature names will be shown in the Eiffel naming convention. With overloaded feature names, the presentation will use name augmentation to disambiguate the overloaded versions. What you see is a distinct feature name for each overloaded version. The basic feature name is augmented by adding the types of its respective arguments, separated by underscore. + +Let's look again at the two Append functions from System.Text.StringBuilder. + +.NET function signature: Append(System.String) + +Known to Eiffel as: append_string (value: SYSTEM_STRING) + +Member of type System.Text.StringBuilder, known to Eiffel as STRING_BUILDER + + Appends a copy of the specified string to the end of this instance. + +.NET function signature: Append(System.Char) + +Known to Eiffel as: append_character (value: CHARACTER) + +Member of type System.Text.StringBuilder, known to Eiffel as STRING_BUILDER + + Appends the string representation of a specified Unicode character to the end of this instance. + + + +The overloading story does not end quite yet. The .NET object model allows the overloading of constructors. This issue will be discussed in the section Constructors and Creation Procedures. + +==.NET Properties as Eiffel Features== + +Properties in .NET provide: +* the opportunity to '''strengthen encapsulation,''' because values cannot be receive assignment without executing the property's "set" code +* '''uniform access ''' queries because properties are queries, but unlike previous C-style OO languages in which properties did not exist, if a property is used in programming a client class, the programmer does not need to know whether the data provided by the property was done so from memory or through computation. This leaves the producer of the class with the property the latitude to change the implementation without breaking existing clients. + +In Eiffel, the same goals are fulfilled, but a little differently. Simple attributes are well-encapsulated, because the Eiffel programming language does not allow direct assignment to them from outside the control of their class. So any assignment of the form x. f := y is not valid in Eiffel. To allow client to set values of the attribute f, the producer of the class of which x is an instance would have built a command (a "set_" procedure) to do so. Then the code in a client to set f would look like this: x.set_f (y). + +Uniform access is achieved in Eiffel through the way in which clientssee features which are queries. The code " print ( x.count)" applies the query count to the object attached to x and prints the result. You cannot tell by looking at this code whether count is an attribute or a function, that is, whether the count is returned from memory or through computation. In fact, it could be either, but that is a matter for its producer to deal with. As reuse consumers the implementation of countis not important to us ...but the fact that the producer can change the implementation without causing our code to need modification is very important to us. + +Because Eiffel does not support properties directly, the propertiesof typeswhich Eiffel for .NET programmers usefrom .NET assemblies have to be mapped to Eiffel features. + +In order to ask for the property's current value (technically, receiving the result of the property's get routine), a query feature is generated for the property. The query will be namedthe Eiffel name of the property. + +As noted above, setting the value of a property cannot be done in Eiffel as it is done in C# and VB.NET because Eiffel disallows assignments of the form x.f := y. So, for each writable property, an Eiffel command feature is available to set the value of the property. The name for this command will be "set_" followed by the Eiffel name for the property. + +As a result, the code for using a .NET property looks very much like the code to use an Eiffel attribute. In the following code fragment, an instance of the type System.Windows.Forms.Form which is available in Eiffel for .NET as WINFORMS_FORM is used by an Eiffel client. System.Windows.Forms.Form has a property Text which is of type System.String. Here the Text property is being set using the set_text feature, and then being recalled by using the query text. + + local + my_window: WINFORMS_FORM + my_string: SYSTEM_STRING + do + create my_window.make + my_window.set_text (my_window_title) -- Set Text property + my_string := my_window.text -- Query Text property + . + . + end + + +==Static Features in .NET== + +In the .NET object model it is possible for certain members of a type to be "static". When these members are used, they are used without an instance of the class as a target. In essence, they are called on the class itself. + +In Eiffel for .NET, these staticmembers will made available with feature names derivedusing the same conventions as ordinary features, but applying them will be a bit different. + +There is not a concept analogous to static members in Eiffel. The model for object-oriented computation in Eiffel specifies that whenever feature application takes place, there must be an object, i.e. an instance of some class, that serves as a target. + +In order to use .NET types that include static members, a special syntax has been added into Eiffel for .NET. The following example uses this syntax to call a static function: + + local + my_window: WINFORMS_FORM + do + create my_window.make + my_window.set_text (my_window_title) + . + . + feature {WINFORMS_APPLICATION}.run_form (my_window) + end + + + +The type System.Windows.Forms.Application is used here. It is available to Eiffel under the name WINFORMS_APPLICATION. The static member being used is Run, in particular the overloaded version of Run which takes an argument of type System.Windows.Forms.Form. That version is available in Eiffel under the name run_form. + +The important thing to see here is that when you need to apply a static member, you introduce the call with the keyword feature. Then enclose the type name in braces and apply the feature as if it were targeted to an object. This isfairly close to the way that the call would be made in C#, where the feature name would be applied to the type name, versus a target object: + +{ + Form my_window; + my_window = new Form(); + my_window.Text = "Hello World!"; + . + . + Application.Run(my_window); // This is C# +} + + + + + diff --git a/documentation/18.11/solutions/platform-specifics/microsoft-windows/net/eiffel-net-language/conventions/eiffel-net-terminology.wiki b/documentation/18.11/solutions/platform-specifics/microsoft-windows/net/eiffel-net-language/conventions/eiffel-net-terminology.wiki new file mode 100644 index 00000000..a61f0b2c --- /dev/null +++ b/documentation/18.11/solutions/platform-specifics/microsoft-windows/net/eiffel-net-language/conventions/eiffel-net-terminology.wiki @@ -0,0 +1,172 @@ +[[Property:title|Eiffel for .NET Terminology]] +[[Property:weight|1]] +[[Property:uuid|ab1ac480-e2d3-df5d-5f06-963899f1072d]] +==Eiffel Terminology Defined for C# and VB.NET Programmers== + +Eiffel programmers feel that it is important to have a set of precise terms with which to communicate about our method of software development. Like everything else in Eiffel, the use of certain terms is not accidental. They were chosen carefully to impart particular meaning. Many of the Terms that Eiffel programmers use are different from those used by developers using other object-oriented languages. But that does not mean that their meanings will be foreign to you. If you have some understanding of object-oriented technology, you will find that in many cases the Eiffel terms describe concepts with which you were already familiar, just under different names, and possibly with slightly different meanings. + +The intention of this glossary is to give you a list of these terms with extended definitions that will relate the Eiffel terms to language with which you may be more familiar. Also, you will find an occasional term which comes from other programming cultures but is not used in Eiffel. +{| +|- +| Term +| Definition +|- +| Ancestors +| The set of Classes from which a particular Class Inherits, including the Class itself. Somewhat analogous to Bases and Interfaces in C# and VB.NET (see Proper Ancestors). +|- +| Argument +| An object which is passed to a routine. Called a Parameter in C# and VB.NET. +|- +| Assertion +| A declaritive expression that evaluates to true or false. Assertions in Eiffel are of different types and are used primarily for expressing software specification to potential Reuse Consumers and ensuring that executing software complies with specification. Any violation of an assertion causes an exception, and is generally indicative of a defect in the software system. +|- +| Attribute +| A Feature which represents storage used in every instance of a class. Used like a Field member in C#. +|- +| Class +| Software text which is the static definition of a Type (or the pattern for a Type in the case of a Generic Class). Used in very nearly the same way as in C#. In C# Classes are used for reference types and Structures for value types. In Eiffel, Classes are used for both, but see Expanded Class. +|- +| Class invariant +| An Assertion on a Class which defines the valid or stable state for objects which are instances of the Class. All instances of the Class must comply with the Class Invariant at any time that they are accessible to Clients. +|- +| Client +| A Class whose role is that of Client in a Client/Supplier Relationship with another Class. +|- +| Client/Supplier relationship +| One of the two Relationships that can exist between Classes. Client/Supplier is characterized by a situation in which one Class, called the Client, has or uses, instances of the other Class, called the Supplier. For example, if class "X" declares an entity "y" of type STRING, then Class X becomes a Client to Class STRING as a result. At the same time, Class STRING becomes a Supplier to class X. +|- +| Cluster +| A group of classes (or recursively, clusters) which share some criteria which justifies their being grouped together. Classes are usually clustered together because they model similar entities or have similar functionality. For example, in the Eiffel Base Library, there is a cluster called "structures" which contains clusters for data structures. One cluster is "list" which contains classes like LINKED_LIST and TWO_WAY_LIST. Another "structures" cluster is "dispensers" which contains classes like "ARRAYED_STACK" and "PRIORITY_QUEUE". When .NET assemblies are made available to Eiffel programmers, each assembly is viewed as a cluster. +|- +| Command +| A Class Feature which can change the state of the instance to which it is applied, and does not return a result. It is the Reuse Consumer's view of a Procedure. +|- +| Contract +| Like a contract between human parties, a software Contract is a formal agreement between software components, Classes in the case of Eiffel. The contract is written in the Assertions of a Supplier Class and specifies in precise terms those conditions with which potential Clients may interact with the Supplier. The contract for a particular Class is composed of the contracts for each Exported Routine of the Class as well as the Class Invariant. +|- +| Creation Procedure +| A Procedure which can be used to initialize and instance of a Class. Similar to a Constructor in C# or VB.NET, but slightly different. A Creation Procedure can be applied when an object is being created, but can also be applied later to reinitialize an existing object (such is not the case with Constructors). Also, Creation Procedures are responsible for ensuring that newly created objects comply with their Class Invariants. +|- +| Deferred Class +| A class which has at least one Deferred Feature. The term "Deferred" is used in the Eiffel culture like the term "Abstract" in .NET. Like an abstract class in C# or VB.NET, it is not possible to make direct runtime instances of a Deferred Class. +|- +| Deferred feature +| A Class Feature which has not implementation. Like a virtual method in C#. Can apply to Commands or Queries. +|- +| Descendents +| The set of all Classes which Inherit from a particular Class, including the Class itself. Somewhat analogous to subclasses in C# and VB.NET (see Proper Descendants). +|- +| Design by contract +| A method of developing software in which a System is composed of a set of interacting Classes which cooperate based upon precisely defined Contracts. +|- +| Direct instance +| A runtime Object of some type, based directly on the definition from a specific Effective Class. See Instance for more information. Usually used in conjunction with the class name, e.g. "an instance of class POLYGON". +|- +| Effective class +| A Class which has no Deferred Features. Only if a Class is Effective can it have direct runtime instances. Effective classes are called Concrete Classes in some programming cultures. +|- +| Eiffel Metadata Consumer +| Applicable to Eiffel for .NET only, this is a mechanism that works behind the scenes to make Types from .NET assemblies available to Eiffel programmers. The Metadata Consumer reconciles the differences between the naming conventions of Eiffel and .NET by providing an Eiffel compliant view of the Types in .NET assemblies. +|- +| Expanded Class +| Like a value type in C#, but with some restrictions. .NET value types are viewed to Eiffel programmers as Expanded Classes. For reference types, an object field holds a reference to a runtime object (or is Void). For value types, the object field holds the fields of the runtime object. A Type based on an Expanded Class is an Expanded Type. +|- +| Exported feature +| A Feature which is available to Client Classes. Analogous to "public" in C# and VB.NET. However, Exporting in Eiffel has fine granularity. It is possible to make certain Features available to Clients of all types or only to Clients which conform to certain named Classes (vs Public, Protected, Private) +|- +| Feature +| Any of a Class's Attributes or Routines. Used similarly to the term Member as in C#. In Eiffel class features can be only Attributes or Routines. +|- +| Feature Application +| The process of using the Class Features on instances of the Class. The model for Feature Application is "x.f(a,...)" where "x" is an entity which will be attached to some object at runtime, "f" is some Feature of the Class on which x is based, and "a,..." is an optional list of arguments which may be appropriate for some Routines. Feature "f" is "applied" to the object attached to "x". Feature Application may involve calling Routines, or may only involve returning the value of an Attribute from memory. Feature application is sometimes called "feature call". +|- +| Function +| A Routine that returns a result. In C# function results can be typed as "void", meaning that there is no result returned. Eiffel functions cannot be typed "void" (see Procedure). All Functions must specify a result type. Of course, if the result type is a reference type, there could be cases in which the reference resulting from some specific call might be Void. +|- +| Generic Class +| A Class which is written using parameters to represent other Classes or Types to enhance its reusability. For example, the Class LINKED_LIST [G] is a generic class in which "G" represents some other Class. So, LINKED_LIST is written independent of the items an instance of the list will hold. We cannot declare a LINKED_LIST without specifiying a Class to substitute for "G". If we want a list of cats we can declare one by using the Type: LINKED_LIST [CAT]. Generic Classes are not currently implemented in .NET, so there's no corresponding concept in C#. +|- +| Inheritance +| One of the two Relationships that can exist between Classes. If Class B inherits from Class A, then every feature in Class A is potentially available to instances of Class B. Also, when ever an instance of Class A is required, an instance of Class B will suffice. Inheritance is used in Eiffel much the same as in C#. The Eiffel model allows full, controlled multiple inheritance, though. Eiffel Classes may inherit from multiple Concrete Classes and name clashes are handled through a process called Feature Adaptation. +|- +| Heir +| The adjacent Proper Descendants of a Class. If class C inherits from class B and class B inherits from class A, then class A's Proper Descendants include B and C, but A's Heirs only include B. +|- +| Instance +| A runtime Object of some type, based on the definition from a Class. Usually used in conjunction with the class name, e.g. "an instance of class POLYGON". In contrast with Direct Instance, an Instance of class POLYGON is a Direct Instance of POLYGON or any Proper Descendant of POLYGON such, perhaps, as RECTANGLE. So it its possible to have Objects which are Instances of Deferred Classes, but it is impossible to have Objects which are Direct Instances of Deferred Classes. +|- +| Interface +| Not supported as such in Eiffel. Used in C# and VB.NET, Interfaces provide sets of specific Class Features which must be effected by any Concrete Class that "implements" the Interface. There is no concept of Interface in Eiffel that is separate from the concept of Class. So, Interfaces from .NET appear to Eiffel programmers to be completely Deferred (abstract) Classes. +|- +| Manifest string +| A quoted string used in source code, for example the "Hello World!" in:
+my_string := "Hello World!"
+This is often called a "literal" string in other languages. In Eiffel, the quoted string "Hello World!" above is, by virtue of its presence, an instance of the Eiffel STRING class. In Eiffel there are manifest constants of other types as well, like numbers coded explicitly in software text, and the keywords True and False as the manifest booleans. +|- +| Module +| A syntactical grouping of software text. Source code is divided into Modules in order to help organize it in some meaningful way or to achieve some goal. +|- +| Object +| An instance of a Class during system execution. As such, Objects only exist at runtime. +|- +| Overloading +| Not supported in Eiffel. Overloading is the ability to have more than one Feature with the same name, varying only by the Types of its Arguments. Overloading is supported by the underlying object model in .NET. As a result many classes in .NET assemblies have overloaded methods. The Eiffel Metadata Consumer disambiguates the overloaded names so that by the time you see them in the Eiffel context they appear no longer to be overloaded. +|- +| Parent +| The adjacent Proper Ancestors of a Class. If class C inherits from class B and class B inherits from class A, then class C's Proper Ancestors include A and B, but C's Parents only include B. +|- +| Postcondition +| An assertion coded on a Routine which defines the conditions will be true upon successful completion of the Routine. It is the responsibility of the Routine to ensure that the Postcondition holds after the Routine executes. +|- +| Precondition +| An assertion coded on a Routine which defines the conditions under which the Routine can complete successfully. It is the responsibility of the Client to ensure that the Precondition holds before attempting to call the Routine. +|- +| Procedure +| A Routine that does not return a result. Much like a "void" function in C#. +|- +| Proper ancestors +| The set of all Classes from which a particular Class Inherits, excluding the Class itself. +|- +| Proper descendents +| The set of all Classes which Inherit from a particular Class, excluding the Class itself. +|- +| Query +| A Class Feature which returns information from the instance to which it is applied. Queries are the Reuse Consumer's view of Attributes and Functions. +|- +| Reference type +| A type whose instances are accessed via a reference. For reference types, an object field holds a reference to a runtime object (or is Void). This is in contrast to value types, in which case, the object field holds the fields of the runtime object. In Eiffel, reference types are based on reference classes, i.e., any class which is not an Expanded Class. +|- +| Relationship +| An association between two classes. There are only two types of Relationships that can exist between classes: Client/Supplier and Inheritance. +|- +| Reuse consumer +| The role a software engineer assumes when in the process of making use of Classes or Types already in existence. As a reuse consumer, the engineer is interested primarily in the specification of those Classes or Types being used, rather than their implementation. +|- +| Reuse producer +| The role a software engineer assumes when in the process or creating a new Class. In this role the engineer attempts to produce a product which will be reusable by him or herself and other engineers in the future. In the Eiffel culture, whenever a software engineer creates a class, it is as a Reuse Producer, and with the thought that each new class has the potential to become reusable. +|- +| Root class +| For any System, the Class which will be instantiated to start the system. Specified by project settings. +|- +| Root procedure +| A Creation Procedure of the Root Class of a System which will be applied to an initial instance of the Root Class at System startup. Similar to Main() in C# and VB.NET, but with the important difference that the fact that a particular Creation Procedure is the Root Procedure for a System is not define in the Class itself as with Main(). Rather, it is specified outside the Class in project settings. This helps Reuse Producers keep Classes more autonomous and therefore potentially more reusable. +|- +| Routine +| A computational Class Feature which is either a Function or Procedure. Routines are the executable parts of a Class. Routines are similar to Methods in C#. +|- +| Software specification +| A statement of how a software element is to be used and what it will do when executed. Ideally, this is stated in terms that do not betray how the software does what it does.In Eiffel, specification is included in the code, rather than a separate document. For a routine, it consists of its call signature and its contract. For a class, it consists of the signatures and contracts for all public features. +|- +| Supplier +| A Class whose role is that of Supplier in a Client/Supplier Relationship with another Class. +|- +| System +| A set of Classes related by the two Relationships which can be compiled to produce an executable. +|- +| Type +| The description of a set of Objects equipped with certain Features. +|} + + + + diff --git a/documentation/18.11/solutions/platform-specifics/microsoft-windows/net/eiffel-net-language/conventions/eiffel-reserved-words.wiki b/documentation/18.11/solutions/platform-specifics/microsoft-windows/net/eiffel-net-language/conventions/eiffel-reserved-words.wiki new file mode 100644 index 00000000..c97048ee --- /dev/null +++ b/documentation/18.11/solutions/platform-specifics/microsoft-windows/net/eiffel-net-language/conventions/eiffel-reserved-words.wiki @@ -0,0 +1,9 @@ +[[Property:title|Eiffel reserved words]] +[[Property:weight|6]] +[[Property:uuid|3b80ea3e-2ed1-adf6-ddf5-acd4e18c6d03]] +The Eiffel programming language reserves certain words as meaningful to the Eiffel compiler. + +To learn more about the reserved words specified by the current Eiffel standard, see the [[Eiffel programming language reserved words]] page of the [[Quick reference to the Eiffel programming language]]. + + + diff --git a/documentation/18.11/solutions/platform-specifics/microsoft-windows/net/eiffel-net-language/conventions/index.wiki b/documentation/18.11/solutions/platform-specifics/microsoft-windows/net/eiffel-net-language/conventions/index.wiki new file mode 100644 index 00000000..48659d0b --- /dev/null +++ b/documentation/18.11/solutions/platform-specifics/microsoft-windows/net/eiffel-net-language/conventions/index.wiki @@ -0,0 +1,15 @@ +[[Property:title|Conventions]] +[[Property:weight|1]] +[[Property:uuid|1f101597-06cd-b851-8cc1-e214b3eedb3e]] +In this section, you'll find information about how the conventions that are normally used in Eiffel programming are affected by working in the presence of .NET. + +Also, you'll find out how .NET types sometimes look a little different in the presence of Eiffel. + +Because there are differences in the underlying object models upon which .NET and Eiffel have been designed, before .NET types can be made available to Eiffel developers, the assemblies in which they reside must be processed by a utility called the Eiffel Metadata Consumer. Fortunately, this all happens behind the scenes for you. You need only be aware that when you are looking at .NET types from within EiffelEnvision, you're seeing them through Eiffel-tinted lenses. + +This is really the same thing that happens with other .NET languages with Visual Studio .NET support. For example, if you look at a constructor in a .NET type using the "ildasm" utility, the constructor will be named ".ctor". But, if you're in C# and look at the same constructor in the Visual Studio .NET Object Browser, the constructor will have the same name as the type ...it's a C# convention. Likewise, the same constructor viewed in Visual Basic .NET will have the name New ...that's the Visual Basic .NET convention. So, when you use EiffelEnvision, you see things as presented using Eiffel Conventions. + +Consider what happens when you look at .NET types using EiffelEnvision. When you look, for example at the type System.EventArgs, you will see it represented as an Eiffel class called EVENT_ARGS. The members of the .NET type will show up as features of the Eiffel class. Of course, you can also see the corresponding .NET names as they exist in the assembly metadata. + +The documents in this section tell you what you need to know in order to use .NET types in Eiffel, and vice versa. + diff --git a/documentation/18.11/solutions/platform-specifics/microsoft-windows/net/eiffel-net-language/conventions/similar-types-occurring-both-libraries.wiki b/documentation/18.11/solutions/platform-specifics/microsoft-windows/net/eiffel-net-language/conventions/similar-types-occurring-both-libraries.wiki new file mode 100644 index 00000000..ed26a85a --- /dev/null +++ b/documentation/18.11/solutions/platform-specifics/microsoft-windows/net/eiffel-net-language/conventions/similar-types-occurring-both-libraries.wiki @@ -0,0 +1,77 @@ +[[Property:title|Similar Types Occurring in Both Libraries]] +[[Property:weight|5]] +[[Property:uuid|4c9f6ad8-107b-af69-3eb3-3f076f2c936c]] +==Whose String is it anyway?== + +Over the last 15 years or so, the Eiffel class libraries have been a source for reusable software components for developers. + +The Eiffel Base library contains classes for commonly used objects like different kinds of numbers, strings, files, and data structures. + +But there are also libaries of Eiffel classes for sophisticated purposes like lexical analysis and parsing, data access, and graphical user interface development. + +Likewise .NET is delivered with assemblies containing thousands of powerful types with similar purposes. + +===Working in Both Worlds=== + +When we build software that has access to both the rich Eiffel libraries and the many useful .NET types, we inevitably run into types from both worlds that have similar names and purposes, but are still different types with different semantics. + +===The Case of Strings=== + +The example of these similar types which will almost certainly get in your face is the string types. You may remember that we looked briefly at the case of the string types in Naming Conventions and Name Handling. + +The Eiffel Base Library contains class STRING; the .NET assembly contains type System.String, which Eiffel for .NETusers see as SYSTEM_STRING. At an abstract level both of these model sequences of characters. But they are not the same type. In fact, they are different in some important ways. For example, instances of System.String are immutable. So you cannot append to an instance of System.String. If you want to build a string by appending, you should use an instance of System.Text.StringBuilder to do the appending, then extract the instance of System.String from it. With STRING it is permissible to append, so you don't need a helper like the System.Text.StringBuilder type. + +So the two types are similar at an abstract level, but different semantically. There are reasonable arguments for the design of each. + +Many types in the delivered assemblies have properties which are strings or methods which return or take strings as arguments. In all these cases, the strings in question are instances of System.String. + +Many classes in the delivered Eiffel libraries have features involving strings, that is attributes which are strings or routines which return or take strings as arguments. In all these cases, the strings are instances of STRING (except for those designed for .NET compliance). + +In C# and VB.NET, if you specify a quoted string like "Hello World!" in your code, that string will conform to type System.String. If you do the same in Eiffel, then "Hello World!" will be an instance of STRING. In Eiffel terminology, "Hello World!" appearing in source code is a manifest string. + +What all this means to you is that you cannot use an instance of System.String when an instance of STRING is called for, and vice versa. Three out of four of the executable lines in the following code sample are invalid: + + local + my_string: STRING + my_system_string: SYSTEM_STRING + do + my_system_string := "Hello World!" -- Invalid + my_string := "Hello World!" -- Valid + my_string := my_system_string -- Invalid + my_system_string := my_string -- Invalid + . + . + end + + +To handle this issue, the Eiffel for .NET class STRING has two features which can be used when a string of the other type is needed. + +The first of these features is a query to_cil which returns an object of type System.String which has a sequence of characters equivalent to that of the STRING to which to_cil is applied. The to_cil can be applied to manifest strings by enclosing the manifest string in parentheses. + +The other feature is a creation procedure named make_from_cil which takes as an argument an instance of System.String and initializes its target STRING with a sequence of characters equivalent to that of the argument. + +In the following sample, we use these features of STRING to make all the lines from the previous sample valid. + + local + my_string: STRING + my_system_string: SYSTEM_STRING + do + my_system_string := ("Hello World!").to_cil -- Valid + my_string := "Hello World!" -- Valid + my_string.make_from_cil (my_system_string) -- Valid + my_system_string := my_string.to_cil -- Valid + . + . + end + + +{{note|As shown in the above example, it is necessary to apply to_cil to a manifest string if you are assigning it to a System.String or passing it as an argument where a System.String is called for.
+This is expected to change in a future release. It shall become unnecesary to apply to_cil to manifest strings. Instead, whether a STRING or System.String is needed will be determined by the context in which the manifest string is being used, and the proper type of object will be generated. }} + +===Other Similar Types=== + +There are many other cases of types available from the .NET assemblies which have similar purpose and semantics to those found in the Eiffel libraries. Fortunately, there is none that you will have to deal with as often as strings. + + + + diff --git a/documentation/18.11/solutions/platform-specifics/microsoft-windows/net/eiffel-net-language/conventions/type-organization.wiki b/documentation/18.11/solutions/platform-specifics/microsoft-windows/net/eiffel-net-language/conventions/type-organization.wiki new file mode 100644 index 00000000..8aa4f7f3 --- /dev/null +++ b/documentation/18.11/solutions/platform-specifics/microsoft-windows/net/eiffel-net-language/conventions/type-organization.wiki @@ -0,0 +1,56 @@ +[[Property:title|Type Organization]] +[[Property:weight|3]] +[[Property:uuid|1837e091-695b-339c-f04f-cbfaea791a6c]] +In any comprehensive object-oriented system, the act of programming results in creation of new data types. There must be a way of organizing these types and/or their static representation as classes. This section tells you how classes are organized in Eiffel and in .NET, and how these organization methods are used together. + +==Eiffel Clusters== + +Eiffel classes are grouped in clusters. These clusters of classes ordinarily share some commonality of functionality or purpose. In other words,the classes in a particular cluster may provide the same sorts of capabilities or relate to a single software model. In the Eiffel Base Library there is a cluster called list which contains classes which implement different types of lists, for example, ARRAYED_LIST, LINKED_LIST, SORTED_TWO_WAY_LIST, TWO_WAY_CIRCULAR. At an abstract level all these classes are related to the software model of the notion of "list". + +The cluster list is actually a subcluster of the cluster structures which contains clusters other than list related to data structures other than lists. Eiffel convention dictates that a cluster should either contain classes or subclusters, but not both. + +So clusters serve both to categorize and locate classes. So, class LINKED_LIST can be described as a basic library class implementing a data structure, more particularly a list. As such, it can be found in the Base Library, in cluster structures in subcluster list. + +==.NET Namespaces and Assemblies== + +In .NET, types (the language independent, compiled form of classes) are stored in "assemblies". So, we locate a type we want to use by referencing the assembly in which it resides. +As .NET programmers, we think of types as being categorized by namespace. For example, we view the type System.Windows.Forms.TextBox as the TextBox type in the context of the windows forms namespace ( System.Windows.Forms). Particularly, this is in contrast to type System.Web.UI.TextBox which is a TextBox for web forms. As it relates to making .NET types usable by Eiffel, the important thing to understand is that the real .NET type name is the fully qualified type name, including the namespace. Namespaces are simply a bit of "syntactic sugar" that keeps us from having to repeat the entire type name every time we use it in source code. +===.NET Assemblies Available to Eiffel=== +When types from .NET assemblies are made available to Eiffel programmers, each assembly is mapped to a cluster. So all the types in an assembly appear as if they were Eiffel classes in a cluster which corresponds to the .NET assembly. +To summarize, as you learned in Naming Conventions and Name Handling, unambiguous Eiffel-style names are made available for the.NET types in an assembly. The assembly is represented to Eiffel for .NET programmers as a cluster of classes. The process of name derivation is based upon a portion of the .NET type name, possibly augmented with a prefix to ensure uniqueness. + +===Assemblies Built with Eiffel=== + +The object model for which Eiffel was designed differs in some ways from the .NET object model. Importantly, Eiffel supports the facilties of full, controllable multiple inheritance, and genericity, among other things, that the inherent .NET object model does not. That does not mean that these things cannot work in .NET. Indeed they can, and they make Eiffel for .NET very powerful. But, they do make things look a little different. + +When you compile Eiffel for .NET, the result is a .NET assembly; either an executable system, or a library of potentially reusable data types. Because the object model for Eiffel is different from that of .NET, the assembly resulting from a compile is different in some ways. + +First an assembly built using Eiffel for .NET will likely contain lots of types and interfaces. This is because as you use a class from the Eiffel libraries, say class STRING, all the classes upon which STRING depends ( STRING's suppliers and ancestors) must also be included in the assembly. That's because the Eiffel libraries, unlike the Microsoft .NET libraries like mscorlib and System.Data, are not distributed as shared type libraries. + +Another thing you may notice is that each Eiffel class you produce is represented by three entities in the assembly ... two classes and an interface. So, if you produce a class called GUARD_DOG, then in the assembly you'd see an interface called GuardDog, a class called Impl.GuardDog, and a class called Create.GuardDog. Again, this is done for reasons that concern the differences in the object models between Eiffel and .NET. + +The GuardDog interface is what you use when you declare an entity or variable of that type. The objects attached to that entity at runtime will be of the type Impl.GuardDog. You create an instance of Impl.GuardDog and attach it to an entity of type GuardDog by calling a routine in the factory class Create.GuardDog. The factory routines will almost always have names that begin with the word " Make", and represent the creation routines of Eiffel the classes. So in the case of using an instance of GuardDog from a C# class, the code would like this: + +{ + GuardDog aGuardDog = Create.GuardDog.Make(); //Create an instance + aGuardDog.RollOver(); // Apply a feature +} + + +This object creation model accounts for some of the differences between constructors in .NET and creation procedures in Eiffel. These differences will be discussed in more detail in Constructors and Creation Procedures. + +Another advantage is that it provides a syntax that is similar to that used to create objects in Eiffel. An Eiffel for .NET client to the class GUARD_DOG might use the following code to create and use an instance. + + local + a_guard_dog: GUARD_DOG -- Declare an entity of the type + do + create a_guard_dog.make -- Create an instance and attach to entity + a_guard_dog.roll_over -- Apply a feature + end + + +You may have noticed in these examples that even though the type GuardDog was compiled from an Eiffel class, when the C# client uses GuardDog, it uses what would be considered the .NET naming convention for the type GuardDog (vs. GUARD_DOG) and the method name RollOver (vs roll_over). What happens here is that when assemblies are produced from Eiffel classes, by default .NET naming standards are used in the assembly. + + + + diff --git a/documentation/18.11/solutions/platform-specifics/microsoft-windows/net/eiffel-net-language/eiffel-net-integration.wiki b/documentation/18.11/solutions/platform-specifics/microsoft-windows/net/eiffel-net-language/eiffel-net-integration.wiki new file mode 100644 index 00000000..71c963ef --- /dev/null +++ b/documentation/18.11/solutions/platform-specifics/microsoft-windows/net/eiffel-net-language/eiffel-net-integration.wiki @@ -0,0 +1,76 @@ +[[Property:title|Eiffel for .NET Integration]] +[[Property:weight|3]] +[[Property:uuid|fe8a6a7d-4590-0db2-d59a-307082b18ecc]] +==Differences between Eiffel and Eiffel for .NET== + +===Limitation of Eiffel for .NET in version 5. 5=== + +Most of the Eiffel mechanisms are supported in 5. 5. All missing features listed below are planned for addition in future releases: +* No creation of Eiffel expanded class support +* Partial implementation of generic conformance (same as what was supported up to and including the 4.2 release of the Eiffel development environment). + +Eiffel for .NET supports: +* Multiple Inheritance +* Design By Contract +* Exception handling +* Genericity +* Covariance +* Compilation of any existing Eiffel libraries as long as it does not include C externals that call into the Eiffel Software C runtime + +===Added to Eiffel and Eiffel for .NET=== + +The following syntax can be used to declare .NET custom attributes on Eiffel entities (features and classes): + + empty: BOOLEAN + note + description: "Is Current empty?" + metadata: create {OBSOLETE_ATTRIBUTE}.make_obsoleteattribute_1 ("Use `is_empty' instead") end + obsolete + "Use is_empty instead" + do + Result := is_empty + end + + +The previous example shows the declaration of the obsolete feature empty . The custom attribute defined by OBSOLETE_ATTRIBUTE is used to ensure that any consumer of the resulting assembly will see the feature as being obsolete. The custom attribute is defined in the note clause metadata. The definition consists of a creation expression that creates the custom attribute with the right parameters. + +Using the metadata tag is the most general way of applying a custom attribute. There are however some variations that are explained below: +*metada: most general way, it applies a custom attribute to both the class and interface generated by the Eiffel compiler. +*class_metadata: applies only to the class generated by the Eiffel compiler (mostly for advanced users). +*interface_metadata: applies only to the interface generated by the Eiffel compiler (mostly for advanced users). +*property_metadata: applies a custom attribute to the associated property generated by the Eiffel compiler for a query. +*assembly_metadata: applies a custom attribute for the current assembly. It only works when present in the Eiffel system root class note clause. + +==Differences between Eiffel for .NET and .NET== + +===Covariance=== + +The CLR (Common Language Runtime) does not support [[ET: Inheritance#Covariance and anchored declarations|covariance]] due to a type safety issue that full covariance implies (known as a polymorphic [[ET: Inheritance#Catcalls|catcall]] in Eiffel). Although very rare, catcalls are not suitable to .NET where safety is one of the primary goals. + +Eiffel for .NET implements a safe variant of covariance that will always perform a check on the types to avoid a catcall. So when a catcall is going to be performed a `Invalid Cast Exception` will be raised by the CLR instead of an unexpected behavior as is the default behavior in classic Eiffel (i.e., the behavior without catcall detection explicitly enabled). + +Another advantage of Eiffel for .NET's implementation of covariance is that it can be easily understood by CLS compliant consumer tools. These tools will actually benefit from the Eiffel for .NET covariance. + +===Genericity=== + +The CLR does not support generics at all, so that the following Eiffel for .NET classes: +* LIST [ANY] +* LIST [INTEGER] + +will actually be generated as: +* LIST_ANY +* LIST_Int32 + +Meaning that if one wants to reuse an Eiffel generic class from another language than Eiffel for .NET, one has to use either LIST_ANY or LIST_Int32. + +===Enum types=== + +Eiffel for .NET supports .NET enum types implicitly. From the point of view of Eiffel, they are just considered as expanded classes. The only difference is in the code generation. Eiffel for .NET cannot declare new enum types yet. + +===ByRef=== + +Eiffel does not have the notion of `byref` argument passing. At the moment, Eiffel for .NET cannot call nor can it redefine a feature that has a byref argument. + + + + diff --git a/documentation/18.11/solutions/platform-specifics/microsoft-windows/net/eiffel-net-language/eiffel-net/adding-class-features.wiki b/documentation/18.11/solutions/platform-specifics/microsoft-windows/net/eiffel-net-language/eiffel-net/adding-class-features.wiki new file mode 100644 index 00000000..7fbb3869 --- /dev/null +++ b/documentation/18.11/solutions/platform-specifics/microsoft-windows/net/eiffel-net-language/eiffel-net/adding-class-features.wiki @@ -0,0 +1,535 @@ +[[Property:title|Adding Class Features]] +[[Property:weight|2]] +[[Property:uuid|04261c22-b28f-b045-a5d7-2c85efe992b9]] +The features of a class make it useful. They are the things that objects which are instances of the class have and can do. + +It is during the process of adding class features that we relate a class we are producing to other classes via the client/supplier relationship. + +It is when we add features to a class that we can build the executable code that makes things happen. + +==Categorizing Features== + +In Eiffel, we have several ways of thinking abstractly about features and categorizing them. As you saw in [[Eiffel Classes|Eiffel Classes]] the feature clause gives us a way to group features in the software text. We have ways to group features more generally, too. Here are some. + +===Source=== + +You remember the example class from [[Eiffel Classes|Eiffel Classes]] : + +note + description: Objects that model lists + revision: $Revision: 1.5 $ + +class + OLD_FASHIONED_LIST [G] + +obsolete "This class is obsolete, use LINKED_LIST [G] instead" + +inherit + DYNAMIC_LIST [G] + +create + make + +feature -- Initialization + + make + -- Create an empty list. + do + before := True + ensure + is_before: before + end + +feature -- Access + + item: G + -- Current item + do + Result := active.item + end + + first: like item + -- Item at first position + do + Result := first_element.item + end + + ... other features omitted ... + +invariant + before_constraint: before implies (active = first_element) + after_constraint: after implies (active = last_element) +end + + + +The example shows three of the features ( make, item, and first) coded directly in the class. These features (and the ones omitted from the example in the interest of brevity) may not be the only features of the class OLD_FASHIONED_LIST. In fact we can just about guarantee that there are other features of this class. Remember the inheritance part of the class: + + inherit + DYNAMIC_LIST [G] + + +This means that every feature in DYNAMIC_LIST will be a feature of OLD_FASHIONED_LIST. So one way we can think of features is by their source. +* Immediate features are those that are introduced by a class itself. +* Inherited features are those that come to the class from its proper ancestors. + +We will see more about this in [[Inheritance|Inheritance]] . + +===Implementation Type=== + +Whenever we are building a class in Eiffel, we are potential reuse producers. As such, we can categorize the features of a class based on the three types of feature implementation: +* Attribute +* Function +* Procedure + +Attributes are those features which occupy storage in an instance. When you code an attribute in a class that you are producing, that class becomes a client to the class of the attribute. This is the most common way to establish a client/supplier relationship between the classses. Client/supplier is one of the two relationships that can exist between classes. + +Functions and procedures are the computation features, that is they are features that involve executable code. Functions and procedures together are themselves categorized as routines. + +Also, from the producer standpoint we may view features as whether they work from memory or through computation: +* Memory +** Attribute + +* Computation +** Function +** Procedure + + +This view can be valuable when a producer is considering performance issues. For example, if there is some class function called count, a producer might investigate whether it is better to leave count as a function, computing it each time the feature is applied, or to change it to an attribute and compute it less often. + +===Usage=== + +A times we find it appropriate to categorize features by how we use them. Specifically, as: +* Query +** Attribute +** Function + +* Command +** Procedure + + +Queries are features that, when applied to an instance, provide a value in response. Commands instruct an intance to take some action, but do not return a value. Seeing features as either queries or commands is of primary interest to reuse consumers. But as producers there are important reasons for ensuring that when we implement a feature, we implement it as a query or as a command, but not both. We will see more about this in [[Design by Contract and Assertions|Design by Contract and Assertions]] . + +==General Syntax of Features== + +===More Sample Features=== + +Here is another example class. Again this class contrived, so it does not do anyhing worthwhile except show you what different types of features look like. This class has an attribute and a constant attribute, and functions and procedures both with and without arguments. + +class + SOME_CLASS + +create + make, + make_with_arguments + +feature -- Initialization + + make + -- Creation procedure + do + an_attribute := 5 + end + + make_with_arguments (hour: INTEGER; minute: INTEGER; second: INTEGER) + -- Another creation procedure + do + an_attribute := second + (minute * 60) + (hour * 3600) + end + +feature -- Access + + an_attribute: INTEGER + -- An attribute of type INTEGER + + another_attribute: INTEGER = 46 + -- A constant attribute + + a_function: STRING is + -- A function without arguments + do + Result := an_attribute.out + end + + another_function (an_int: INTEGER): INTEGER + -- A function with arguments + do + Result := an_attribute + an_int + end + +feature -- Basic Operations + + a_procedure + -- A procedure with no arguments + do + an_attribute := an_attribute + 5 + end + + another_procedure (an_int: INTEGER; another_int: INTEGER) + -- A procedure with arguments + do + an_attribute := an_attribute + an_int + another_int + end + +end -- Class SOME_CLASS + + +===Feature Declaration=== + +When you write a feature in a class, you typically will include some of the following: +* The feature's name +{{note|In Eiffel every feature of a class must have a name that is unique within that class. }} + +* The feature's type (in the case of an attribute or a function) +* The feature's formal argument list (in the case of a function or procedure that has arguments) +* The actual value of the feature (in the case of a constant attribute) +* The implementation code (in the case of a function or procedure) + +Let's dissect one feature and identify its parts: + + another_function (an_int: INTEGER): INTEGER + -- A function with arguments + do + Result := an_attribute + an_int + end + + +In this feature: +* "another_function" is the feature's name. +* "(an_int: INTEGER)" is the argument list. +** "an_int" is the name of the first argument +** "INTEGER" is the type "an_int" + +* "INTEGER" (after the argument list) is the feature's type. +* "do " introduces the implementation code. +* "Result := an_attribute + an_int" is an instruction. + +{{note|This feature is a function. As a consequence the computation uses the keyword "Result' as an entity name for the value to be returned by the function }} + +* "end" ends the feature declaration + +==General Structure of Routines== + +As you can imagine, the possibilities for coding routines are more complex than those for coding attributes. Routines always contain the keyword "is" after the first part of the feature declaration. The part after the "is" is called the routine part. + +The routine part is made up of the following sections: +* [[#Header Comment|Header Comment]] +* [[#obsolete|Obsolete]] +* [[#Precondition|Precondition]] +* [[#Local Declarations|Local Declarations]] +* [[#Routine Body|Routine Body]] +* [[#Postcondition|Postcondition]] +* [[#Rescue|Rescue]] + +All of the sections except the Routine Body are optional. + +Here is another feature, a routine, which has all of these except obsolete and rescue. + + insert_text_header_item (a_label: STRING; + a_width, a_format: INTEGER; insert_after_item_no: INTEGER) + -- Insert a text item to the header control + -- after the `insert_item_item_no' item. + require + exists: exists + label_not_void: a_label /= Void + insert_after_item_no_positive: insert_after_item_no >= 0 + local + hd_item: WEL_HD_ITEM + do + create hd_item.make + hd_item.set_text (a_label) + hd_item.set_width (a_width) + hd_item.set_format (a_format) + insert_header_item (hd_item, insert_after_item_no) + ensure + item_count_increased: item_count = old item_count + 1 + end + + +Using this example, let's identify and discuss the different sections. + +===Header Comment=== + + -- Insert a text item to the header control + -- after the `insert_item_item_no' item. + + +Although the feature's header comment is optional, most Eiffel programmers and their technical managers feel that it should never be omitted. Header comments are included by some language processing tools in specialized views of classes. Header comments are almost always short, usually no more than a few lines. Header comments serve to provide a natural language description of what the feature will do (in the case of features that are commands) or what information it provides (in the case of queries). + +===Obsolete=== + +The feature insert_text_header_item is not obsolete ... but if it were it would include an obsolete clause. This works much like the obsolete part for classes that we saw in [[Eiffel Classes|Eiffel Classes]] : the keyword "obsolete" followed by a manifest string which bears a message to potential reuse consumers: + +===Precondition=== + + require + exists: exists + label_not_void: a_label /= Void + insert_after_item_no_positive: insert_after_item_no >= 0 + + +The precondition part of a feature is introduced by the keyword "require". It contains a set of assertions which define the state necessary for the correct execution of a routine. We will see more about assertions in [[Design by Contract and Assertions|Design by Contract and Assertions]] . + +===Local Declarations=== + + local + hd_item: WEL_HD_ITEM + + +This part contains the declarations for any "local entities" used by the feature. Sometimes the computation accomplished in a feature requires the use of entities which are only temporary. It would not be appropriate to make these attributes of the class. So, instead we can use local entities, which have scope only within the feature in which they are declared. In the example, hd_item is available as type WEL_HD_ITEM during the computation of feature insert_text_header_item. + +{{note|A local entity name must not be the same as any feature of the class in which its feature occurs or the same as any argument name of the feature in which it occurs. }} + +===Routine Body=== + + do + create hd_item.make + hd_item.set_text (a_label) + hd_item.set_width (a_width) + hd_item.set_format (a_format) + insert_header_item (hd_item, insert_after_item_no) + + +This is the routine body for a fairly typical effective, internal routine. It contains the instructions that get the job done for the feature. You may notice that experienced Eiffel programmers rarely write routine bodies that are more than a few lines long. The reason for this is more that just intuitive. This phenomenon will be explained in the section [[Design by Contract and Assertions|Design by Contract and Assertions]] . + +There are other forms that a routine body can take. Here are some examples of some others: + +====External Routines==== + + cwin_tooltips_class: POINTER + external + "C [macro ] : EIF_POINTER" + alias + "TOOLTIPS_CLASS" + end + + +The routine body above is for an "external" routine. External routines are used to represent within Eiffel classes, routines that are written in other languages. + +{{tip|Because of the high degree of language interaction provided by Microsoft.NET, it is not necessary in Eiffel for.NET to use externals to use software components from.NET assemblies. Instead, these components are presented to the Eiffel programmer as if they were Eiffel classes. Read more about this in [[Conventions|Conventions]] . }} + +====Once Routines==== + + once + Result := some_computation + + +This is the routine body of a "once" routine, specifically a "once function". A once routine is introduced by the keyword "once" rather than do. It contains an computational body that executes only the first time it is called. Upon subsequent calls it has no effect. + +Once procedures are useful for doing things that for some reason should not be done multiple times. + +If the once routine is a function (as the example above), it computes the resulting object on the first call, then on subsequent calls, it returns the object it originally created without executing the computation. Once functions facilitate shared objects which helps us in avoiding global entities. A class containing a once function can be inherited by many other classes. The first object to apply the once function causes the resulting object to be created and initialized. Subsequent applications by any other object accesses the originally created instance. + +====Deferred Routines==== + + deferred + + +The body for a deferred routine is simply the keyword "deferred". Below is the deferred routine body in the context of an entire feature. + + set_position (new_position: INTEGER) + -- Set `position' with `new_position' + require + exists: exists + valid_minimum: new_position >= minimum + valid_maximum: new_position <= maximum + deferred + ensure + position_set: position = new_position + end + + +As we learned in [[Eiffel Classes|Eiffel Classes]] a deferred routine has specification, but no implementation. We will investigate deferred classes and features further in [[Inheritance|Inheritance]] . + +===Postcondition=== + + ensure + item_count_increased: item_count = old item_count + 1 + + +The postcondition part of a routine is introduced by the keyword "ensure". The postcondition is a group of assertions which describe the state that must be satisfied upon the successful completion of the routine. We will see more about assertions in [[Design by Contract and Assertions|Design by Contract and Assertions]] . + +===Rescue=== + +Our example feature does not have an explicitly coded rescue part. The rescue, introduced by the keyword "rescue", provides a routine with a chance to do additional processing in the case that it incurs an exeption during normal processing. We will learn about the rescue clause in the section [[Exception Mechanism|Exception Mechanism]] . Until then, you can see what a rescue part looks like in the feature below. + + bind + -- Bind socket to local address in `address'. + require + socket_exists: exists + valid_local_address: address /= Void + local + ext: ANY + retried: BOOLEAN + do + if not retried then + ext := address.socket_address + c_bind (descriptor, $ext, address.count) + is_open_read := True + end + rescue + if not assertion_violation then + is_open_read := False + retried := True + retry + end + end + + +==Making Features Available to Clients== + +Remember that when we build classes in Eiffel, we keep in mind the possibility that these classes may eventually become valued, reusable software components. As a result we have a responsibility to make sure that our classes allow clients to use them in a safe and productive fashion. We make available those features that it is appropriate for clients to use, and we hide the rest. In Eiffel we say that a feature that is available to clients is "exported". + +Control of the export of features inherited from ancestors is done by using the "export" keyword. Export of inherited features will be discussed in Inheritance. + +Control of the export of immediate features (those features introduced in the text of a class) is done with the "feature" clause. We have encountered the feature clause already: + +feature -- Access + + an_attribute: INTEGER + -- An attribute of type INTEGER + + another_attribute: INTEGER = 46 + -- A constant attribute + + a_function: STRING + -- A function without arguments + do + Result := an_attribute.out + end + + another_function (an_int: INTEGER): INTEGER + -- A function with arguments + do + Result := an_attribute + an_int + end + +feature -- Basic Operations + + a_procedure + -- A procedure with no arguments + do + an_attribute := an_attribute + 5 + end + + another_procedure (an_int: INTEGER; another_int: INTEGER) + -- A procedure with arguments + do + an_attribute := an_attribute + an_int + another_int + end + + +A feature clause like the ones in the example above means that all the features that follow, until the next feature clause are exported to clients based on any class. Technically, this + +feature -- Basic Operations + + +is equivalent to + +feature {ANY} -- Basic Operations + + +which means that the following features are available to clients which conform to class ANY. And in Eiffel, ANY is the class from which all other classes inherit. As a consequence all classes conform to ANY. + +Inside the braces is a list of classes which are eligible as clients. + +feature {STRING_HANDLER} -- Implementation + + +Features following this example from class STRING will be available to client class STRING_HANDLER and all its proper descendants. + +As stated above, you can put a list of class names in the braces: + +feature {CLASS_A, CLASS_B, CLASS_C} -- Semi-private features + + +Often features which are solely for implementation should not be seen or used by clients of any type. You can ensure this by exporting to class NONE, the class from which no other class can inherit: + +feature {NONE} -- Implementation + + +==Eiffel Instructions and Control Structures== + +When you begin to write routines in Eiffel, you will need to understand how to write instructions. Fortunately, the set of instruction types you can code is fairly small. Here we will look the most common of these. You will see some more in other topics. + +===Creation=== + + create hd_item.make + + +We discussed creation procedures and the process of bringing new objects into being in [[Eiffel Classes|Eiffel Classes]] . A creation instruction starts with the keyword "create". It creates a new object, initialize its fields, may apply a creation procedure, and attaches the object to an entity. + +===Procedure Call=== + + hd_item.set_text (a_label) + + +The application of a feature to an object constitutes an instruction if the feature is a procedure. + +===Assignment=== + +In Eiffel, assignment syntax is simple. But depending upon the types involved, what actually happens may need some explanation. Assume here that is_open_read is an attribute declared as type BOOLEAN: + + is_open_read := False + + +In this instruction, an attribute of type BOOLEAN named is_open_read is being assigned the value of the manifest boolean "False". The attribute is_open_read is based on an expanded class BOOLEAN, so that means that the value for False is held in the field for is_open_read. This is in contrast to what happens with reference types. + + my_string := some_other_string + + +In this assignment, we will assume that both entities are type STRING. Because STRING is a reference type, the field for my_string will hold either a reference to an instance of STRING, or it will be Void. When the assignment above executes, then whatever was in the field for my_string is replaced with a reference to the same object that some_other_string refers to. + +In summary, for objects based on expanded classes, assignment means assignment of value. For objects based on reference classes, assignment means assignment of reference. + +====Conformance==== + +There is an important rule about assignment in Eiffel. The rule exists to ensure type safety. Consider the following assignment which we would read as "x receives y" or "x gets y". + + x := y + + +then the rule says that this assignment is valid only if the type of y conforms to the type of x. + +The rule is clear enough ... if you know what "conform" means. In the presence of mechanisms like expanded types, inheritance, and genericity, a precise definition of conformance is lengthy. + +But we can get by for a while with much less. For now let us be satisfied with this: + +Consider the classes in the declarations for x and y. + +You might be tempted to say that to achieve "conformance", the classes would have to be the same. And for the case in which the declarations for x and y are expanded classes, you'd be correct. They conform only if they are the same class. + +But for reference types, that constraint is unnecessarily restrictive. So, for reference types, the class of y conforms to that x if it is the same class or a proper descendant of that class. This facilitates a powerful idea known as polymorphic attachment that we will see more closely in the section on [[Inheritance|Inheritance]] . + +===Conditional=== + + if l_c.is_digit then + l_state := 2 + elseif l_c = '-' or l_c = '+' then + l_state := 1 + else + l_state := 3 + end + + +Conditionals in Eiffel use at a minimum the keywords "if", "then", and "end". Optionally, they may use the keywords "elseif" and "else". + +===Loop=== + + from + i := lower + until + i > upper + loop + if item (i) /= Void and then v.is_equal (item (i)) then + Result := Result + 1 + end + i := i + 1 + end + + +There is only one structure for loops in Eiffel. In its typical form it uses the four keywords "from", "until", "loop", and "end". The instructions following the from keyword do any initialization necessary for the loop. After until is a boolean expression which is the exit condition. The loop body after loop is a list of instructions that are executed for every iteration. As you can imagine, something in the loop body should most likely cause the exit condition eventually to become true. + + + + diff --git a/documentation/18.11/solutions/platform-specifics/microsoft-windows/net/eiffel-net-language/eiffel-net/design-contract-and-assertions.wiki b/documentation/18.11/solutions/platform-specifics/microsoft-windows/net/eiffel-net-language/eiffel-net/design-contract-and-assertions.wiki new file mode 100644 index 00000000..84d0a195 --- /dev/null +++ b/documentation/18.11/solutions/platform-specifics/microsoft-windows/net/eiffel-net-language/eiffel-net/design-contract-and-assertions.wiki @@ -0,0 +1,322 @@ +[[Property:title|Design by Contract and Assertions]] +[[Property:weight|5]] +[[Property:uuid|41172f82-227a-96b1-2dad-624f04374ee0]] +==Motivation: Concerning Correctness== + +When you produce an element of software, how do you know that what you produced is correct? + +This is a difficult question for anyone to answer. Informally speaking, correct software is software that does what it is supposed to do. That is what makes answering the question so tricky. Before you can have any idea whether the software is correct, you must be able to express what it is supposed to do ... and that proves to be quite difficult itself. + +In conventional software engineering, a document called a software specification is written in order to describe what it is that a piece of software is supposed to do. Writers of software specifications tend to pursue one of two approaches: the informal or the formal. + +Informal specifications attempt to describe software behavior in the natural languages with which humans communicate on a daily basis. There are problems with this approach. Natural language is not precise. Informal specifications are subject to interpretation and affected by the ambiguities, noise, and contradiction inherent in natural language. + +In order to avoid these problems, proponents of formal methods of specification turn to the most precise language they know: mathematics. It may be no exaggeration that the study of formal methods has produced more PhD's in Computer Science than it has well-specified software systems. Still the idea that the precision of mathematics can be brought to bear on the problem of specifying software is quite appealing. But, problems lurk here as well. Formal specifications are difficult and time-consuming to construct and verify against themselves, and most software engineers do not have a working knowledge of the mathematics required to work with formal specifications. + +There is one more significant problem with both of these approaches. Even if you have a very precise specification, expressed in elegant text and graphics, and placed carefully in an expensive ring binder, how do you know that the software product actually reflects that specification and vice versa? If either is changed, the other must be as well. This is the document synchronization problem. + +===Design by Contract to the Rescue=== + +Design by Contract (DbC) begins as an implementation of some of the ideas from formal methods and matures into a powerful way of thinking about software. And it does it in a way that is easy for programmers and managers to understand. DbC also puts the software specification into the software document itself which makes it checkable at runtime and eliminates the document synchronization problem. + +==Model for Software Correctness== + +Design by Contract is built around a model for software correctness that is really pretty simple. + +Suppose there is software routine called s. If we were going to test s, we would probably devise some test inputs or test values to be in place when s starts and then observe what things look like after s completes. If they look the way we think they should then that leads us to believe that S is working correctly for those test inputs. + +We can generalize and formalize that process a bit, taking it back from testing an into design. If indeed we know what it means for s to be correct, then we should be able to make a statement of any conditions that must be true prior to executing s. That is, we will state the conditions required for it to be possible for s to run correctly. We call this statement of preconditions for success s's precondition. + +Likewise we should be able to make a statement of the conditions that will be true always if s works correctly. This we call s's postcondition. + +As an example, suppose s accepted an argument of type REAL and returned another REAL which was the square root of the argument. The precondition for s would be that the argument could not be less that zero, as there is no real square root for negative numbers. s's postcondition would be that the result multiplied by itself would yield the value of the original argument (give or take a little to allow for floating point error). + +==Assertions in Eiffel== + +Each Eiffel feature which is a routine, i.e. a function or procedure, can support one assertion for a precondition and one for a postcondition. We saw where precondition and postcondition fit into the structure of the routine in [[Adding Class Features|Adding Class Features]] . An assertion is expressed as one or more assertion clauses which are logically and-ed together to produce the assertion. Assertions clauses are boolean expressions that evaluate to true or false. + +Let's look at another example. Assume you need to produce a class to model a time of day. Each instance of TIME_OF_DAY would hold some particular time of day accurate to the second between 00:00:00 and 23:59:59 inclusive. + +As a producer, you would be faced with a decision concerning how to maintain the time internally in each instance. For the purpose of our example, let us consider two alternatives: +# Keep three instance of INTEGER. One each for hour, minute, and second. +# Keep one instance of INTEGER representing the time of day as the number of seconds since 00:00:00. + +This would be an implementation issue for the producer, because it would not affect the services that TIME_OF_DAY could offer clients. If we have a query called minute the first alternative allows us simply to provide the value from storage. Whereas the second alternative will likely cause us to compute minute each time it is requested. But the service looks and works the same for the client in either alternative. + +For now let us assume that we are using the first design alternative. In that case we would code class features for hour, minute, and second. + +feature -- Access + + hour: INTEGER + -- Hour expressed as 24-hour value + + minute: INTEGER + -- Minutes past the hour + + second: INTEGER + -- Seconds past the minute + + +Below is the code for a procedure set_second which receives an argument of type INTEGER and sets the value of the second feature to the argurment. + + set_second (s: INTEGER) + -- Set the second from `s'. + do + second := s + end + + +The routine is simple enough, but there is a problem with it. Suppose a client calls set_second with an argument whose value is invalid, say 3574. Our routine would just stuff this value into second and we would end up with an instance of TIME_OF_DAY which is invalid. In the days before Design by Contract, as soon as we recognized that this problem exists, we would go into "defensive programming" mode and code some "if" statements inside the routine to validate the argument, before acting. + +Consider though what we can do with Design by Contract. We will add a precondition assertion to set_second that expresses the need for valid arguments. + + set_second (s: INTEGER) + -- Set the second from `s'. + require + valid_argument_for_second: 0 <= s and s <= 59 + do + second := s + end + + +The precondition is introduced by the keyword "require". The text "valid_argument_for_second" is the label for the assertion clause. The boolean expression "0 <= s and s <= 59" says that a good value for s will be between 0 and 59 inclusive. + +Remember that the precondition specifies those things that must be true if set_second has a chance of working correctly. As such, upon execution, the body of this routine will never be executed if an attempt is made to call it in a state that does not meet its precondition. Instead, the caller will incur a precondition violation exception. We will investigate more about what exceptions mean further in [[Exception Mechanism|Exception Mechanism]] . + +So, what about a postcondition? We noted earlier that a postcondition should make a statement of what will be true in the case that the routine does its work correctly. For set_second this means that after it finishes, the query second should have the same value as the argument that was received from the caller. Below is the feature with the postcondition added. + + set_second (s: INTEGER) + -- Set the second from `s'. + require + valid_argument_for_second: 0 <= s and s <= 59 + do + second := s + ensure + second_set: second = s + end + + +The postcondition is introduced by the keyword "ensure". Here the expression "second = s" makes certain that the routine did actually do the necessary work to ensure that the value of second matches the value of the argument received. + +As you look at the postcondition, you may be tempted to think that the one-line body of the routine is so simple as to make the postconditon unnecessary. To answer this concern we need to look again for a moment at software specification. + +===Specification of a Routine=== + +If we remove the instructions from a routine and leave its signature, header comment and assertions, we have a specification for the routine. + + set_second (s: INTEGER) + -- Set the second from `s'. + require + valid_argument_for_second: 0 <= s and s <= 59 + ensure + second_set: second = s + end + + +This specification of set_second tells us what is required of reuse consumers if they wish to use set_second and what set_second promises to do for them. Importantly, it does that without revealing how it does it does what it does. + +So, this specification view, officially called the contract view, is how consumers of class TIME_OF_DAY would view the feature. + +If this is the specification, then haven't we put the cart before the horse? The answer is yes. We have done so to illustrate the problems that assertion-based specification can help solve. + +Instead of starting with a routine and adding a specification, we really want to start in accepted software engineering fashion with specification first, and then add implementation. Therefore, the specification you see above would exist before the implementation. + +Now back to the concern over whether the postcondition is redundant for this simple one-line routine. Obviously, if this specification exists first, then the postcondition must be there, and it would be silly to remove it later. But, more importantly, suppose that when the producer of the class decided on an implementation, he or she chose the second design alternative we mentioned above. This would mean that the internal state of an instance of TIME_OF_DAY would be only one INTEGER with the number of seconds since midnight. That would mean that the query second would probably be a function that computed seconds from that one INTEGER instead of an attribute. + +What would change in the specification of set_second? Nothing. The implementation for the routine would be more complex, but what it does, setting the second in an instance of TIME_OF_DAY, would stay the same. + +In summary, the precondition and postcondition ensure for use that the routine will only execute if called in a state in which the precondition is true, and then will either complete in a state in which the postcondition is true, or cause a postcondition violation exception. + +===The Contract for a Routine=== + +Having assertions on its routines forms a contract between the TIME_OF_DAY class and all potential reuse consumers. The contract is much like a contract in business, with obligations and benefits for both parties. +* The client's benefits are outlined in the postcondition. +* The client's obligations come from the precondition. +* The supplier's obligations are in the postcondition. +* The supplier's benefits come from the precondition. + +We can see the specifics of these by using set_second as an example. +* The client gets the desired value for seconds set in the instance. +* The client must provide an argument that is valid for seconds. +* The supplier must update the instance successfully. +* The supplier need not risk disaster attempting to process in an invalid state nor waste time validating the argument received from the client. + +===Valid State for Instances=== + +Assertions on TIME_OF_DAY's routines gives us specification for each routine and guarantees that if the specification of a routine gets violated at runtime we will be served immediately with an exception. This will go a long way toward preventing invalid instances from going unnoticed in a running system and fouling up lots of other stuff. + +What will help even more is something called a class invariant. Using the class invariant we are able to state what it means for an instance of a class to be valid, or as it is sometimes put, in a stable state. + +The class invariant is an assertion like precondition and postcondition, but there is only one per class. Check [[Eiffel Classes|Eiffel Classes]] to see how the class invariant fits into the class structure. + +How would we code the class invariant for TIME_OF_DAY? An instance would be valid if its hour were between 0 and 23 inclusive, minute were between 0 and 59 inclusive, and its second were between 0 and 59 inclusive. We can code the invariant as shown below. + +invariant + hour_valid: 0 <= hour and hour <= 23 + minute_valid: 0 <= minute and minute <= 59 + second_valid: 0 <= second and second <= 59 + + +The name invariant implies that the assertion can never be false ... and that's true up to a point. It's really more like, "it must be true at times when it really counts". + +At runtime the invariant must be true for an instance at anytime that the instance is available to clients. In general, this means that the invariant must be true before and after the execution of every exported routine. + +As with the assertions on routines, if ever the invariant is not true when it should be, then a class invariant violation occurs. + +Remember in the example above, that the features hour, minute, and second are queries, but they could be either attributes or functions. + +==The Contract for a Class== + +Earlier we saw the contract for a routine. Now we can define the contract for a class as the aggregation of the contracts for all its exported features, plus its class invariant. + +In Design by Contract we design based on these contracts. They are the specifications for the modules in our system. We work in a reuse-oriented world. Whenever we produce a class, we produce it with a comprehensive contract which serves as its specification. We build each class with the thought that it may eventually become reusable. + +When we are in our reuse consumer role, using existing classes, we tend not to look at the implementations for the classes we use. Instead we look at their contract views. It is there that we find the obligations and benefits of using each class. + +==Contracts and Debugging== + +We saw earlier that having contracts in the code tends to expose bugs at an early stage of development. It is possible selectively to turn off and on the runtime checking of assertions by changing project settings. Checking assertions does involve processing. More about turn off assertion checking in a moment. + +Having contracts on a class gives another advantage when the contract gets broken. The contract tells us whose fault it is. Whenever there is a violation of a precondition, postcondition, or class invariant then the software is out of specification. This situation is called a defect, or bug. + +Whose fault is it? If a precondition was violated, then a client class attempted to call a routine in a supplier, but made the call in a state that did not satisfy the supplier's precondition. Therefore the bug is in the client. + +If a postcondition was violated, then a client made a call in a state that did satisfy the supplier's precondition, but the supplier was unable to complete the work as agreed. Therefore the fault lies with the supplier. + +If a class invariant was violated, then the instance has been placed in an invalid state during the execution of a routine, and left that way when the processing completed. This caused the invariant violation. As with the postcondition violation, because the problem occurred while executing routines in the supplier, preconditions must have been met. The supplier then is to blame. + +Based on this knowledge, we can say that it is most practical first to turn off runtime checking of postconditions and invariants as we gain confidence in a class. Meaning of course, that we feel confident that any calls that meet preconditions will be properly processed. Then our only worry is that some deranged client will, with total disregard for our carefully crafted preconditions, make calls to our routines from invalid states. So, maybe we will leave precondition checking turned on for a while. + +==Contracts and Inheritance== + +In the section titled [[Inheritance|Inheritance]] you saw that it was possible through inheritance to produce a new class that has all the features of an existing one. This is a very powerful notion, and could be dangerous. What would keep descendants from redefining inherited features with semantics that were totally different from those intended by the producer of the original class? Nothing if it were not for the contract. + +Simply speaking assertions on a parent class, preconditions, postconditions, and class invariants, all are inherited by the class's proper descendants. + +For class invariants, if any new invariants are coded in an heir, they will be added to those inherited from the parent, using a non-strict version of logical "and" (We will define non-strict booleans in Writing Assertions below). + +That is simple enough. And the situation is also simple for effective routines inherited and left unchanged ... the contracts stand as written. + +From our example above you may have gotten the idea that contracts are really useful only for effective routines. Such is not the case. In fact, specifying a contract on a deferred routine is really a powerful notion. It says not only that effective descendants must provide an implementation for this routine, but also that there is a contract that must be satisfied. Effecting or redefining a routine in a descendant class will not make the contract go away. Here is an feature from the Base Library deferred class ACTIVE which models data structures with a current item, and is an ancestor to many effective container type classes. + +feature -- Element change + + replace (v: G) + -- Replace current item by `v'. + require + writable: writable + deferred + ensure + item_replaced: item = v + end + + +Feature replace carries the semantics necessary for replacing an item in an ACTIVE. It does not, however provide an implementation. All implementers must produce versions of replace that satisfy the contract specified here. + +It actually is possible to alter a feature assertion in an effected or redefined version(technically its a replacement of the original version): +* The precondition can only become weaker than in the inherited contract. +* The postcondition can only become stronger than in the inherited contract. + +These rules are imposed as a consequence of the effect of effected or redefined routines on polymorphism and dynamic binding. But, you can understand them from an intuitive viewpoint, if you reconsider the business contract analogy. Suppose a contractor makes a deal with a client to do certain work (represented by the postcondition). Part of the deal might be that the client agrees to have a site ready by a certain date (represented by the precondition). The contractor represents the parent class in the analogy. Now suppose the contractor brings in a subcontractor (representing the heir class) to do a portion of the work. The subcontractor cannot force the client to change the date that the site is to be ready to an earlier date (no strengthing of the precondition). The deal with the client was made by the contractor and so no new or stronger requirements can be imposed by the subcontractor. Likewise the subcontractor must provide at least as much work as was bargained for by the contractor, but may promise to provide more if appropriate (strengthing of postcondition is allowed.) + +In Writing Assertions below you will see the syntax for weaking preconditions and strengthening postconditions. + +==Unfinished Business== + +In the section [[Adding Class Features|Adding Class Features]] , we promised to explain two issues during this discussion of Design by Contract. + +===Short Routines=== + +One of these is the tendency of mature Eiffel programmers to write routines that are quite short. It should be clear by now that we wish to build a contract on each routine. The contract describes the semantics of the routine in a declarative fashion. In other words, it tells what the routine does, without giving an indication of how it does it. + +Try to imagine giving a declarative description of a routine that was 50 lines long. This could get ugly. So experienced Eiffel developers decompose complex computations into chunks small enough to be described through a clear, concise set of assertions. + +===Command/Query Separation=== + +In [[Adding Class Features|Adding Class Features]] , we saw that we can categorize features as either queries or commands. A query will ask a question or make an observation about an instance. A command will tell the instance to take some action which may result in changing the instances internal state. + +We said that when program routines, that those routines should either be commands or queries but not both. Importantly, asking a question about an instance should not change the instance. Likewise, taking an action that changes the state of an instance should not return a result. + +Here's the rationale. In a routines postcondition we use boolean expressions to ensure that the routine has done its job properly. Likewise, class invariants, which define the valid state for instances, are written as boolean expressions. In both cases we may use the features of the class which are queries to ask about an instances current state. + +If a query that we use in an assertion were to change the state of the instance, then the result we received would be invalid as soon as we received it. + +Therein lies the primary reasoning behind command/query separation. You cannot reason about the integrity of an object if the act of asking a question changes the object. + +==Writing Assertions== + +You have seen fairly typical assertions written in the examples above. Study the classes in the libraries to see some excellent working examples. There are a couple of things that need to be covered. + +===Non-Strict Booleans=== + +One is that, as you can probably imagine, it is not a good thing to cause an exception during the process of checking an assertion. One of the most common ways to cause such an exception is to apply a feature to a Void reference. + +The way to avoid this is to use the non-strict booleans "and then" and "or else". These forms of "and" and "or" do not force the checking of all conditions. As soon as a determination can be made, they stop checking. It is typical to see "and then" used to avoid applying a feature to a void reference in preconditons. Below is a creation procedure that uses a non-strict boolean in its precondition. + + make (a_nm: STRING; a_offset: INTEGER) + -- Initalize with name `a_nm' and utcoffset `a_offset'. + require + name_not_empty: a_nm /= Void and then not a_nm.is_empty + offset_valid: a_offset >= -12 and a_offset <= 12 + do + name := a_nm.twin + utcoffset := a_offset + ensure + name_initialized: name.is_equal (a_nm) + utcoffset_initialized: utcoffset = a_offset + end + + +===Replacing Inherited Feature Assertions=== + +To replace a precondition on a feature you are effecting or redefining, you use the "require else" keywords to introduce new conditions. These conditions will be logically "or-ed" with the original precondition to form an new one. + +Likewise use "and then" to add conditions to a postcondition. The added conditions will be "and-ed" to the original. + +Below is an example of weakening a precondition. The first feature shown is from class DYNAMIC_CHAIN in the Base Library. + + remove_left + -- Remove item to the left of cursor position. + -- Do not move cursor. + require + left_exists: index > 1 + deferred + ensure + new_count: count = old count - 1 + new_index: index = old index - 1 + end + + +The next feature is from DYNAMIC_LIST, a proper descendant of DYNAMIC_CHAIN. DYNAMIC_LIST weakens the precondition it inherited from DYNAMIC_CHAIN. Originally in DYNAMIC_CHAIN, "index > 1" was required for remove_left. In DYNAMIC_LIST either "index > 1" or "not before" (or both) will suffice. + + remove_left + -- Remove item to the left of cursor position. + -- Do not move cursor. + require else + not_before: not before + deferred + end + + +==Not Writing Assertions== + +Let's close this discussion of Design by Contract with one more interesting and point to make about assertions. The precondition and postcondition parts of a routine are optional, as you may remember from [[Adding Class Features| Adding Class Features]] . Suppose you write a routine and do not code either precondition or postcondition. You might be tempted to think that you have simply written a routine that has no contract. But, that would not be the case. + +The contract exists, even though you do not code it explicitly. If it were written out, it would look as follows. + + my_routine + -- My descriptive header comment + require + True + ensure + True + end + + +What does this mean? It means that you have selected the weakest possible precondition and postcondition for your routine. Of course, this may be perfectly valid under some circumstances. + +Just understand that if your routine could speak, it would be telling you, "I can always work successfully without any particular guarantees from you at all. On the other hand, I won't promise you any particular results when I get done." + + + + diff --git a/documentation/18.11/solutions/platform-specifics/microsoft-windows/net/eiffel-net-language/eiffel-net/eiffel-classes.wiki b/documentation/18.11/solutions/platform-specifics/microsoft-windows/net/eiffel-net-language/eiffel-net/eiffel-classes.wiki new file mode 100644 index 00000000..37db14d5 --- /dev/null +++ b/documentation/18.11/solutions/platform-specifics/microsoft-windows/net/eiffel-net-language/eiffel-net/eiffel-classes.wiki @@ -0,0 +1,223 @@ +[[Property:title|Eiffel Classes]] +[[Property:weight|1]] +[[Property:uuid|f905426e-3109-b60b-adf0-c74b83c81b55]] +The unit of software reuse in Eiffel is the class. + +The unit of modularity in Eiffel is the class. + +The unit of type modeling in Eiffel is the class. + +All Eiffel code must exist within the context of a class. + +In Eiffel, application systems, or simply systems, are created by assembling a set of related classes. The classes in a system will be related only by one or both of the two allowable relationships in object-oriented design. + +Having read the above, you should be convinced that the concept of class is important and far-reaching. The fact that we have precise rules about classes simplifies life a lot. The only kind of module in Eiffel is a class. Each class exists in one source file (which contains only that class), and contains the code necessary to provide a static definition of a data type. Every runtime entity, i.e. every object, must be an instance of a class. Because we can depend upon these things in Eiffel, we have consistency and predictabililty in the inherently complex world of software development. + +Let's take a look at how classes are structured. + +The code that makes up an Eiffel class is divided into the following parts: + +==Structure of a Class== + +All of the above, except Class header, are optional. So the simplest Eiffel class you could build would look like this: + +class + SIMPLE +end + + +Okay, so class SIMPLE is only interesting in its simplicity. Let's look at an example that is more illustrative: + +note + description: Objects that model lists + revision: $Revision: 1.4 $ + +class + OLD_FASHIONED_LIST [G] + +obsolete "This class is obsolete, use LINKED_LIST [G] instead" + +inherit + DYNAMIC_LIST [G] + +create + make + +feature -- Initialization + + make + -- Create an empty list. + do + before := True + ensure + is_before: before + end + +feature -- Access + + item: G + -- Current item + do + Result := active.item + end + + first: like item + -- Item at first position + do + Result := first_element.item + end + + ... other features omitted ... + +invariant + before_constraint: before implies (active = first_element) + after_constraint: after implies (active = last_element) + +Here is a class that, although completely contrived, utilizes all of the required and optional parts of the class. Let's look at each part individually. +===Note=== + +note + description: Objects that model lists + revision: $Revision: 1.4 $ + + +The note part of a class is there to allow you as a producer to record information of your choice which will help you or other reuse consumers at some later time to locate understand the class. This important in Eiffel because we try to treat every class as if someday it will become reusable. + +Information in note does not change the semantics of the class. + +The note part in the class above is typical. It is introduced with the language keyword note, and contains two note clauses, each of which is comprised of an index and a single index value. You can code note clauses with indexes that you devise yourself, so there is nothing inherently special about "description" and "revision" as used above. But, these indexes could be special to tools which analyze libraries of classes use them. Although these clauses have only one index value each, it is permissible to put more, separated by commas. + +===Class Header=== + +class + OLD_FASHIONED_LIST [G] + + +The class header is introduced by the keyword "class", which in turn can be preceded by one of three keywords which mark the class as deferred, expanded, or frozen. In our example, the class has none of these markings, so it is an effective class whose instances are access by reference. + +The keyword class is followed by the class name, in this case "OLD_FASHIONED_LIST". + +Of the three keywords for header marks, the one which you will encounter most often is deferred. A class is deferred if it contains one or more features that are deferred, that is, features which have been specified in the class but for which no implementation has been provided. Proper descendants of a deferred class will provide implementations for its deferred features. + +===Formal Generics=== + +class + OLD_FASHIONED_LIST [G] + + +In this example the class name is followed by the specification of one formal generic parameter "G". The presence of one or more formal generic parameters will designate a class as a generic class. The formal generic parameter is a place holder for a class name which will be provided by reuse consumers. For example if we wrote a class which was a client to OLD_FASHIONED_LIST we would substitute the class name for the type of objects that we would want to build an OLD_FASHIONED_LIST of. We might make this declaration: + + my_list_of_cats: OLD_FASHION_LIST [CAT] + + +The entity my_list_of_cats could then be attached at runtime to an OLD_FASHIONED_LIST of objects of type CAT. So the class CAT becomes an actual generic parameter and substitutes for G in the declaration. + +Of course formal generic parameters cannot be the same name as a class name in the same universe. If multiple formal generic parameters are used, they are separated by commas. + +You will learn more about generic classes in the section titled [[Genericity|Genericity]] . + +===Obsolete=== + +obsolete "This class is obsolete, use LINKED_LIST [G] instead" + + +OLD_FASHION_LISTs are obsolete ... and the class is marked as such by include the line above. The manifest string contains an explanation, instructions, and/or recommended alternatives. Compilers and other language tools can deliver this message to potential reuse consumers. As with note, obsolete has no effect on the semantics of the class. + +Obsolete is rarely used because of the nature of certain elements of the Eiffel methodology. For example, if implementations are well-hidden behind implementation-independent specifications, then those implementations may be changed to adapt the class to changing execution environments in such a way that clients are unaffected. + +===Inheritance=== + +inherit + DYNAMIC_LIST [G] + + +One of the two possible relationships between classes, inheritance is also a powerful software reuse mechanism. In this example class OLD_FASHIONED_LIST declares itself to be a proper descendant of class DYNAMIC_LIST. + +There will be more in the section called . For now though, be aware of two important implications of this declaration: +* Every feature of DYNAMIC_LIST is available to OLD_FASHIONED_LIST and potentially available to its clients. +* Whenever an instance of DYNAMIC_LIST is called for, then an instance of OLD_FASHIONED_LIST will suffice. + +===Creators=== + +create + make + + +The creators part of a class declares a procedure as being a creation procedure. In this case the procedure in question is the one named make. By convention, creation procedure names begin with the word " make". + +Let's take a quick look at object creation. Consider this declaration: + + my_list_of_cats: OLD_FASHION_LIST [CAT] + + +Here the entity my_list_of_cats can be attached to an object of type OLD_FASHION_LIST [CAT] at runtime. The process of converting my_list_of_cats from holding a void reference to holding a reference to a object modeling a list of cats, starts when a creation instruction is executed. The creation instruction creates the instance and may apply a creation procedure to initialize the instance. A creation instruction for the declaration above would look like this: + + create my_list_of_cats.make + + +The create keyword is used to introduce a creation instruction. This instruction causes the following four things to happen: +* A shell of a new instance of OLD_FASHION_LIST [CAT] is created in memory with a memory field for every attribute +* Each field is initialized with standard default values +** False for type BOOLEAN +** Null character for type CHARACTER +** The appropriate form of zero for number types +** Void for reference types + +* Attach the new instance to the entity my_list_of_cats +* Apply the creation procedure make + +Once these steps complete successfully, my_list_of_cats will be attached to a valid instance (i.e., an instance in which the class invariant is true) of OLD_FASHIONED_LIST [CAT]. + +===Features=== + +feature -- Initialization + + make + -- Create an empty list. + do + before := True + ensure + is_before: before + end + +feature -- Access + + item: G + -- Current item + do + Result := active.item + end + + first: like item + -- Item at first position + do + Result := first_element.item + end + + +The features part of a class is the area in which we feel that most of the "programming" is done. It is here that we define those things that instances of a class have and can do. We will learn more about features in the next section [[Adding Class Features|Adding Class Features]] . + +Until then let's just take a quick look at how features fit into a class. Notice that in our example the features part is introduced by the keyword "feature". In fact there are two occurrences of feature in this example, each followed by a comment. + +You may declare multiple feature statements. This helps you group features in a manner that makes sense. Here we see the first group contains those features which are listed as creation procedures in the creators part of the class. The second group of features labeled "Access" contains a set of queries available to clients of the class. + +Although the words "Initialization" and "Access" are actually in comments after the feature keyword, some language processing tools apply some significance to these, for example, ordering the groups in "pretty-printed" views of a class. Also, some tools allow you to build templates for creating new classes which have feature clauses already in place for predetermined groups. + +{{tip|There is not a technical requirement governing the grouping or ordering of features in a class. It is the option of the producer of a class to group and order the features in a fashion that holds some meaning. Many years of Eiffel development experience are reflected in the classes in the EiffelBase Library. This is a good place to look for examples of well constructed classes. }} + + +===Invariant=== + +invariant + before_constraint: before implies (active = first_element) + after_constraint: after implies (active = last_element) + + + +Here's the last word in a class definition ... both literally and figuratively. The invariant part, introduced not surprisingly by the keyword "invariant", is that portion of the class in which we can state what it means for an object to be a valid instance of this class. + +We will learn more about class invariants in the section titled [[Design by Contract and Assertions|Design by Contract and Assertions]] . + + + + diff --git a/documentation/18.11/solutions/platform-specifics/microsoft-windows/net/eiffel-net-language/eiffel-net/eiffel-net-compliance.wiki b/documentation/18.11/solutions/platform-specifics/microsoft-windows/net/eiffel-net-language/eiffel-net/eiffel-net-compliance.wiki new file mode 100644 index 00000000..5f283bcc --- /dev/null +++ b/documentation/18.11/solutions/platform-specifics/microsoft-windows/net/eiffel-net-language/eiffel-net/eiffel-net-compliance.wiki @@ -0,0 +1,26 @@ +[[Property:title|Eiffel for .NET Compliance]] +[[Property:weight|9]] +[[Property:uuid|1e19c2f0-995e-02c1-0588-c134a11e0003]] +As of Eiffel for ASP.NET 5.6 and EiffelStudio 5.7; Eiffel for .NET introduces the notion of '''Eiffel-Compliance'''. .NET specifies a number of language interoperability rules in a [http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpguide/html/cpconwhatiscommonlanguagespecification.asp Common Language Specification-Compliance] specification. Eiffel for .NET supports all CLS-Compliant type and features in .NET but now additionally supports a number of non-CLS-compliant types and features. This is the purpose of the Eiffel-Compliant notion. + +The information contained within this page does not go into any depth on the Common Language Specification (CLS) or CLS-Compliance. For this information please see Microsoft's on-line documentation [http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpguide/html/cpconwhatiscommonlanguagespecification.asp What is the Common Language Specification?] + + +==Applicability== + +The CLS states a number of rules .NET tools have to abide by to be CLS-compliant. These rules relate to both a .NET producer, generally a compiler generating .NET code, and a consumer, which is generally a compiler that consumes .NET assemblies for reuse. Eiffel-Compliance relates only to consumption of .NET assemblies. + +==What is Eiffel-Compliant?== + +As already stated, anything CLS-compliant is Eiffel-compliant. Eiffel-Compliancy merely allows for exceptions so that non-CLS-compliant assemblies, types and members can be used in Eiffel for .NET. + +The following list outlines the supported non-CLS-compliant types: +* All unsigned numerical basic types such as System.UInt32 as System.UInt64, represented by NATURAL_xx. +* Native pointers (System.IntPtr), represented by POINTER + + +Typically assemblies, types or members are marked with the System.CLSCompliantAttribute attribute to explicitly indicate if they are CLS-compliant or not. The Eiffel for .NET compiler will now ignore this attribute and instead infer if they are Eiffel-Compliant. With such an inference engine at hand, Eiffel for .NET opens itself up to extended support for COM/Legacy interop as well support assemblies not adhering to CLS-compliant rules, for one reason or another. + + + + diff --git a/documentation/18.11/solutions/platform-specifics/microsoft-windows/net/eiffel-net-language/eiffel-net/event-programming-agents.wiki b/documentation/18.11/solutions/platform-specifics/microsoft-windows/net/eiffel-net-language/eiffel-net/event-programming-agents.wiki new file mode 100644 index 00000000..440d1cd5 --- /dev/null +++ b/documentation/18.11/solutions/platform-specifics/microsoft-windows/net/eiffel-net-language/eiffel-net/event-programming-agents.wiki @@ -0,0 +1,203 @@ +[[Property:title|Event Programming with Agents]] +[[Property:weight|7]] +[[Property:uuid|ea9d7b9d-daa1-a415-628a-e3a2f935c12a]] +In Eiffel there is a facility referred to as agents. + +The implementation of agents is an advanced topic, but you do not have to understand the details of the implementation of agents to put agents to work for you. That is what you will learn in this section. + +==Objects that Represent Operations== + +Object technology is based on the idea that when we model systems based on objects, representing the "things" they manipulate. As to operations on these objects, they appear in the corresponding classes, as routines (functions and procedures). Operations are not objects. + +Sometimes, on the other hand, the "things" we model with our objects could represent operations. For example, we might want to build a list of tasks to be performed later; each task is defined by a routine. Each of the objects in the list will represent the corresponding routine. + +Such an object, representing an operation, is called an agent. + +If we can have a run-time object that represents an operation, then we can place the object in the structure of another object, where at some later time, a client can cause the associated operation to execute. + +This is a very desirable model for event driven processing, like graphical user interfaces. The operations that are executed when a user take some action like clicking on a button, could be represented by agents. When the user interface element is initialized, agents that represent the action routines are stored within the interface element. Then at the time that an event, say a button click, occurs, the agents for that event are retrieved and their associated operations are executed. + +Another area in which agents are commonly used is in traversing data structures. Many of the data structure classes in the Base Library include routines which take agents as there arguments. For example, the feature do_all takes an agent which represents some procedure and will apply the procedure to every item in the structure. + +==Classes to Model Operations== + +We know that there are two types of routines in Eiffel, functions and procedures. + +The implementation of agents correspondingly relies on three classes in the Base Library: class ROUTINE for the general notion, and its heirs FUNCTION, with and PROCEDURE. In addition, PREDICATE, an heir of FUNCTION , covers the particular case of a function returning a boolean result. + +When you use an agent from a client routine, you will be building an instance of either FUNCTION or ROUTINE. + +==Using Agents== + +Below is an instruction which passes an agent as an argument to a procedure. + + button.select_actions.extend (agent gauge.step_forward) + + +In this example, the producer wants to add the action of stepping the gauge forward in the event that a button is clicked. The keyword "agent" is used to indicate that at runtime an object of type PROCEDURE should be created which represents applying the feature step_forward to the object attached to gauge. It is the object of type PROCEDURE that is passed as the argument. + +It is important to understand that step_forward does not get applied at the point that the instruction above is executed. Rather the procedure object that represents step_forward is given to the button to hold in reserve. Then at the point that the button click event takes place, the button will go through its list of select_actions executing their associated routines. Only then does step_forwardget applied to gauge. + +===Agents with Arguments=== + +In this example, the routine "step_forward" on which the agent is based takes no arguments. If you drilled down into the workings of this example you would find that class that implements the feature extend is class EV_NOTIFY_ACTION_SEQUENCE. You would also see that the signature for the feature extend is as essentially as follows. + + extend (v: PROCEDURE [TUPLE]) + + +We don't have to know too much about the workings of agents to see that "extend" takes an argument v which is of type PROCEDURE. The actual generic parameter TUPLE represents the set of "open" arguments. In this case, extend is expecting an agent with no open arguments. + +===Open and Closed Arguments=== + +It is this business of open and closed arguments which really makes agents remarkable. To get a feel for it, let's simplify the example some. Instead of considering an agent passed as an argument let's look at it as a simple assignment within a class. + +Suppose a class has a feature declared as shown below. + + my_procedure: PROCEDURE [TUPLE] + + +Then what can be assigned to my_procedure?. An agent, of course. Say the class has procedures as follows. + + no_argument_procedure + -- A procedure with no arguments + do + print ("No argument here!%N") + end + + two_argument_procedure (an_int: INTEGER; another_int: INTEGER) + -- A procedure with two arguments + do + print ("My arguments are: " + an_int.out + " and " + another_int.out + "%N") + end + + +Then the following assignment is valid. + + my_procedure := agent no_argument_procedure + + +What this means is that the agent created and associated with the procedure no_argument_procedure must conform to the type PROCEDURE [TUPLE]. The feature my_procedure (which is of type PROCEDURE [TUPLE]) can be attached at runtime to an agent representing a procedure with no open arguments, which indeed is what no_argument_procedure is. + +Now let's turn our attention to the other procedure two_argument_procedure. You might think that because it takes two arguments, that you would not be able to build an agent from it which could be assigned to the attribute my_procedure. But you can do it by closing the two arguments at the time that the agent is created, as in the following. + + my_procedure := agent two_argument_procedure (1, 2) -- Is Valid + + +What happens here is that values are fixed for those arguments at the time that the agent, an object of type PROCEDURE [ TUPLE] is created. + +So this is the wonderful thing about agents. A routine which will be represented as an agent does not have to be an exact fit for the expected signature. By closing some arguments at agent creation, you have effectively produced a new and conforming routine. + +The advantage of this is that you can sometimes avoid building specialized routines for the sole purpose of having a routine which conforms to the agent signature. + +To leave an argument open, you hold its place with a question mark. If you intend for all arguments to be open, then you may make them all question marks, or leave off the arguments entirely. + + my_procedure := agent two_argument_procedure (?, 2) -- Argument 1 left open + my_procedure := agent two_argument_procedure (?, ?) -- Both arguments left open + my_procedure := agent two_argument_procedure -- Both arguments left open + + +If an argument is open, then it means that a value is not provided for that argument at the time that the agent is created. The implication is that the value must be provided at some time prior to the time that the agent's associated routine gets executed. A precondition to executing a routine associated with an agent is that the agent has a valid set of arguments (called operands within the ROUTINE classes) for the call. If you were to leave one or both of the arguments to two_argument_procedure open as in the examples above, the assignment would still work due to the rules governing TUPLE conformance. But, at runtime unless the other arguments had been provided, the "valid operands" precondition would be violated. + +Let's see an example in which we leave a target open. Suppose we have a class that has a feature coded as below + + my_strings: LINKED_LIST [STRING] + + +and some code to put some strings in my_strings: + + create my_things.make + my_strings.extend ("Hello") + my_strings.extend ("World!") + + +Our class also has a feature called print_on_new_line which we created to print a string preceded by a new line character. + + print_on_new_line (s: STRING) + -- Print `s' preceded by a new line + do + print ("%N" + s) + end + + +Now suppose we want to print the values of all the strings in my_strings each on a separate line by invoking print_on_new_line. Traditionally, we would do it by traversing the LINKED_LIST and printing each item. Like this: + + from + my_list.start + until + my_list.exhausted + loop + print_on_new_line (my_list.item) + my_list.forth + end + + +The availability of agents gives us new options. LINKED_LIST has a feature do_all which comes to it from its ancestor LINEAR. The do_all feature's signature looks like this: + + do_all (action: PROCEDURE [TUPLE [G]]) + + +As an argument do_all takes an agent based on a procedure with one open argument which is the same type as the list items (in this class, G is the formal generic parameter representing the type of the items being stored). Then it traverses the list executing the routine associated with that agent and uses the current list item to satisfy the open argument. + +Instead of coding the loop shown above, we can code this instruction: + + my_list.do_all (agent print_on_new_line (?)) + + +we leave open the argument required by print, and do_all will provide it as a reference to the current list item as it traverses the list. + +===Targets for Agents' Routines=== + +In Eiffel every routine must be applied against a target object. In our model for computation, x.f (a, ...), the x is the target of the application of feature f. In the case of an agent, the agent must account for objects for each of the arguments and an object for the target of the routine. + +Let's identify the targets in the examples shown. First: + + button.select_actions.extend (agent gauge.step_forward) + + +Here the target is the object attached to the entity "gauge" which is (although you cannot determine it from this line taken out of context) an object of type EV_GAUGE. + +How about this: + + my_procedure := agent two_argument_procedure (1, 2) + + +Here, since there was no qualification, then the target is the current instance. Same with this: + + my_list.do_all (agent print_on_new_line (?)) + + +Again, consider the fact that the agent must account for objects for each of the arguments to a routine, and an object for the target. So, in the examples we've seen so far, the target is close, that is provided at the time of the creation of the agent. + +But we can actually leave the target open as well. Now we cannot use the question mark notation to do that, because if we did, there would be no way to know of which class the routine is a feature. So instead, we mark an open target with the class name in braces. + +Suppose in our list of strings example, we wanted to print the strings, then convert them to lower case, then print them again. Remember that "do_all" has one open argument, which will be provided as the current list item during the traversal. + + my_list.do_all (agent print_on_new_line (?)) + my_list.do_all (agent {STRING}.to_lower) + my_list.do_all (agent print_on_new_line (?)) + + +In between printing the list two times, we provide do_all with an agent that representing the STRING class's feature to_lower which will convert each string in the list to lower case. Notice that to_lower does not take an argument of type STRING as print_on_new_line did. Rather it gets applied to an instance of STRING, so it is targeted to a string. So we leave its target open and do_all provides the current list item as the target. + +Agents for Functions + +So far all the agents that we have coded have created instances of PROCEDURE. But functions are routines and can be represented as agents as well. The difference is that functions have a return value. + +Let's extend the string example by using an agent that represents a function. Suppose we wanted to print only those strings which contain a particular character, say the exclamation point. + +Here again we'll use a feature of the LINKED_LIST class. There is a feature called do_if which takes two agents as arguments. One is an action procedure like the argument that do_all takes, and the other is a function which returns a boolean and used as a test. As each list item is current, the test is applied first. If the result is true, then the action is applied with the current item. + + my_list.do_if (agent print_on_new_line(?), agent {STRING}.has('!')) + + + +The agent for the action is the same as we used earlier. We've added an agent for the test. It represents applying the has feature of the STRING class. Here the target is left open, because we want each of the strings in the list to be the target of has. + + +Compatibility note + +Versions of the Kernel Library classes ROUTINE, PROCEDURE, FUNCTION and PREDICATE prior to EiffelStudio 17-05 had an extra generic parameter at the initial position; the usual actual generic parameter was ANY. It has been removed. The compiler has been engineered so that in almost all cases it will still accept the old style. + + + + diff --git a/documentation/18.11/solutions/platform-specifics/microsoft-windows/net/eiffel-net-language/eiffel-net/exception-mechanism.wiki b/documentation/18.11/solutions/platform-specifics/microsoft-windows/net/eiffel-net-language/eiffel-net/exception-mechanism.wiki new file mode 100644 index 00000000..4c895703 --- /dev/null +++ b/documentation/18.11/solutions/platform-specifics/microsoft-windows/net/eiffel-net-language/eiffel-net/exception-mechanism.wiki @@ -0,0 +1,66 @@ +[[Property:title|Exception Mechanism]] +[[Property:weight|6]] +[[Property:uuid|84a159dd-4a19-af73-7b0b-0618a284142a]] +==Motivation: Concerning Robustness== + +The notion of software correctness that we saw in [[Design by Contract and Assertions|Design by Contract and Assertions]] is half of the formula for software reliability. Correctness covers what the software is supposed to do, that is, its specification. + +Of course,there is always a potential for things to go out of the bounds of the specification. This happens, for exampleif a client makes a call to a routine from a state in which the routine's precondition is not true. + +How well software responds to situations which outside specification is called robustness. Together correctness and robustness define software reliability. + +==Consequences of Contracts== + +In the presence of Design by Contract, what happens to running software boils down to a simple rule: + +A routine callcan complete in one of only two ways: +# The routine fulfills its contract. +# The routine fails to fulfill its contract. + +As a follow-on, we can add that: +* Any routine that fails to fulfill its contract must cause an exception in its caller. + +==Reacting to Exceptions== + +Again, because of Design by Contract, we can state the following rule for dealing with exceptions: + +A routine that incurs an exeception can react in one of only two ways: +# It can return the instance to a stable state and retry the entire routine with the same or a different strategy. +# It can fail, causing an exception in its caller. + +There is an Eiffel mechanism called the rescue clause which facilitates the first alternative. + +===The Rescue Clause=== + +The rescue clause is part of the routine structure we saw in [[Adding Class Features|Adding Class Features]] . The rescue clause is a sequence of instructions introduced by the keyword "rescue". At the point that an exception occurs, the processing of the normal instructions in the routine body will cease, and the instructions in the rescue clause will be executed instead. + +If the instructions in the rescue clause can set things up so that it might prove fruitful to attempt to retry the routine, it can do so by issuing a retry instruction. When the retry instruction is executed, the routine is restarted from its beginning, although local entities are not re-initialized. You will see why in the example below. + +If the rescue clause exits without issuing a retry instruction, then the routine fails. + +It should be noted that rescue clauses and retry instructions are not something that are used commonly. Out of the approximately 2000 classes in the delivered Eiffel libraries, there are only 16 occurrences. Many of these are oriented toward network and database operations for which some reasonable recovery might be possible. + + transmit: (p: PACKET) + -- Transmit packet `p' + require + packet_not_void: p /= Void + local + current_retries: INTEGER + r: RANDOM_NUMBER_GENERATOR + do + line.send (p) + rescue + if current_retries < max_retries then + r.next + wait_millisecs (r.value_between (20, 500)) + current_retries := current_retries + 1 + retry + end + end + + +In the example above, rescue is used to recover from a situation in which an exception occurs in trying to send a packet. When the exception occurs the rescue clause will, if the maximum number of retries has not been reached, wait for some random length of time. Then, after having updated the number of retries, it will issue the retry instruction. If the maximum number of retries is reached, the rescue clause will exit without executing the retry, constituting a failure. + + + + diff --git a/documentation/18.11/solutions/platform-specifics/microsoft-windows/net/eiffel-net-language/eiffel-net/genericity.wiki b/documentation/18.11/solutions/platform-specifics/microsoft-windows/net/eiffel-net-language/eiffel-net/genericity.wiki new file mode 100644 index 00000000..69bdfb3a --- /dev/null +++ b/documentation/18.11/solutions/platform-specifics/microsoft-windows/net/eiffel-net-language/eiffel-net/genericity.wiki @@ -0,0 +1,144 @@ +[[Property:title|Genericity]] +[[Property:weight|4]] +[[Property:uuid|3a0bfe10-78e7-00eb-d9a0-b977d1fa352a]] +We got a very short introduction to generic classes when we were looking at the formal generic part of class structure in [[Eiffel Classes|Eiffel Classes]] . That discussion left to the imagination the motivation and benefits for creating generic classes. + +You will see that most of the generic classes model containers for multiple items and at least one of their formal generic parameters represents the type of items that are to be stored in the container. Some generic classes, like LINKABLE, care for only one instance of the type represented by their formal generic parameter. + +==Motivation== + +Imagine that a software producer is planning to build a class which would represent a list of things. Someone might ask "What kinds of things?" To which the producer would reply, "Just things. I want my list to be usable for all kinds of things." + +Using the idea of polymorphic attachment that we learned in [[Inheritance|Inheritance]] , the producer could build such a class. It might have a query item which would return the thing from the list to which a cursor currently points. It might have a command put which would enter some new thing into the list. + +What would be the type of item? And what would be the type of the argument to put? + +If the producer wants the class to handle all kinds of things, then the answer must be class ANY, the class from which all others inherit. + +class + LIST_OF_THINGS + ... +feature -- Access + + item: ANY + -- The thing currently pointed to by cursor + ... +feature -- Element change + + put (new_item: ANY) + -- Add `new_item' at the end of the list + ... + + +This will work, but has some definite disadvantages. Suppose you choose to use this class to maintain a list of cats in one of your classes. You might make this declaration: + + my_cats: LIST_OF_THINGS + -- A list of my cats + + +Then you could add individual instances to the list: + + fluffy, twinkie: CAT + ... + my_cats.put (fluffy) + my_cats.put (twinkie) + + +One problem with this type of list is that the type system will not help you keep from doing something pathological like: + + fluffy, twinkie: CAT + thor: PSYCHOTIC_HYDROPHOBIC_CAT_HATING_DOG + -- A very nasty dog + ... + my_cats.put (fluffy) + my_cats.put (twinkie) + my_cats.put (thor) + + +Another problem is that to do any CAT things with an item in the list, you must reattach it to a CAT entity. The following is invalid. + + my_cats.item.purr -- Is invalid + + +This is because "item" is type ANY and although it may be currently attached to an instance of CAT, the static typing system cannot guarantee that. So you must use an object test as we saw in the polymorphism example in [[Inheritance|Inheritance]] . + + ... + if attached my_cats.item as some_cat then + some_cat.purr + end + + +You can see that this type of list has its drawbacks. Of course you could build a LIST_OF_CATS class in which item and the argument for put would be of type CAT. This would let you purr a cat without pulling it out of the list, and it would also prevent you from accidently letting old Thor in with the cats. But, every time you needed a list to hold a different type of object, you have to write a new class. + +Indeed, this is how things are done in environments without facilities genericity. + +What we would like to have is a way to produce the text of the list class once. Then only when we make declarations do we add the additional information about the particular types we want allowed in the list. + +==Basic Genericity== + +In Eiffel this is accomplished through generic classes. Generic classes are written relative not to a specific class but to a kind of phony class name called a formal generic parameter. With genericity, the LIST_OF_THINGS class might become a class called LIST which is a list of items of type G. In class LIST we would declare item as type G, as well as the argument to put. + +class + LIST [G] + ... +feature -- Access + item: G + -- The item currently pointed to by cursor + ... +feature -- Element change + put (new_item: G) + -- Add `new_item' at the end of the list + ... + + +We could declare feature my_cats as a LIST of items of type CAT. By doing so we are providing CAT as an "actual generic parameter" in the declaration. Then we are free to treat the features of LIST as if the class name CAT had been substituted for every occurrence of the formal generic parameter G. + + my_cats: LIST [CAT] + -- A list of my cats + fluffy, twinkie: CAT + ... + my_cats.put (fluffy) + my_cats.put (twinkie) + ... + my_cats.item.purr -- Valid now + + +The following would no longer be valid: + + my_cats: LIST [CAT] + -- A list of my cats + + thor: PSYCHOTIC_HYDROPHOBIC_CAT_HATING_DOG + ... + my_cats.put (thor) -- Is invalid + + +==Constrained Genericity== + +The generic class LIST illustrated above is perfectly useful for making typed lists of any type of object. The features of the LIST will not attempt to use the objects in the list in any way. Sometimes though, it is important for a class to be guaranteed more about the nature of the types that can be substituted for its formal generic parameter. + +Take for example the case of a class called SORTED_LIST. A SORTED_LIST is a list, of course, but it is special in that it acts upon the elements that it holds to keep them in order. + +A SORTED_LIST needs to be able to order its elements. So, it must be able to apply queries to those elements to determine which should sort high than which. The elements themselves must respond to ordering operations. + +If SORTED_LIST were defined like we did LIST + +class + SORTED_LIST [G] + + +there would be no guarantee that ordering operations, like "<" and ">" could be applied to all types that could be listed. An Eiffel facility called "constrained genericity" will solve this problemfor us. In the case of SORTED_LIST, we would add to the formal generic part as follows. + +class + SORTED_LIST [G -> COMPARABLE] + + +You may remember from [[Inheritance|Inheritance]] that if we make instances of a class comparable with each other, then we make the class inherit from COMPARABLE and effect the feature "<". + +Here, constrained genericity does two things for us. +* First, it states that any candidate for substitution for G must conform to class COMPARABLE. Typically this means it must inherit from COMPARABLE. +* Second, it allows, within the features of SORTED_LIST, the features of COMPARABLE to be applied to any item which has a type of G. + + + + diff --git a/documentation/18.11/solutions/platform-specifics/microsoft-windows/net/eiffel-net-language/eiffel-net/index.wiki b/documentation/18.11/solutions/platform-specifics/microsoft-windows/net/eiffel-net-language/eiffel-net/index.wiki new file mode 100644 index 00000000..2d322e0b --- /dev/null +++ b/documentation/18.11/solutions/platform-specifics/microsoft-windows/net/eiffel-net-language/eiffel-net/index.wiki @@ -0,0 +1,19 @@ +[[Property:title|Eiffel for .NET]] +[[Property:weight|2]] +[[Property:uuid|446038d8-abd6-0a0d-2b90-94124e1ac810]] +These pages contain documentation that describes the Eiffel programming language. + +Eiffel is considered both a development methodology and a programming language. + +Eiffel the methodology is a recipe for constructing quality software which is based on a small number of powerful concepts. Eiffel the programming language is a notation which is designed to support the methodology. + +Eiffel for.NET is the Eiffel programming language made available in the .NET environment. Eiffel for.NET components can use and inherit from components in .NET assemblies that were produced using other.NET languages. And, programmers using other.NET languages can use and inherit from components in assemblies produced using Eiffel for.NET. + +==Eiffel for.NET Conventions Documentation== + +In Eiffel, as in other languages, certain conventions have evolved which constitute "the way things are done". Conventions provide consistency and therefore predictability and readability of software text. + +When working in the.NET components, particularly when using components from .NET assemblies delivered from Microsoft or produced by other parties, the conventions of Eiffel are maintained in the view of these components. The first section, titled [[Conventions]], provides you with an understanding of Eiffel terminology, conventions , and how they work with .NET. + +The remaining sections of this section are a reference for the Eiffel for .NET language. It is not a complete reference, though. Rather, it is intended to help you with the tasks that Eiffel programmers commonly encounter. + diff --git a/documentation/18.11/solutions/platform-specifics/microsoft-windows/net/eiffel-net-language/eiffel-net/inheritance.wiki b/documentation/18.11/solutions/platform-specifics/microsoft-windows/net/eiffel-net-language/eiffel-net/inheritance.wiki new file mode 100644 index 00000000..e081c166 --- /dev/null +++ b/documentation/18.11/solutions/platform-specifics/microsoft-windows/net/eiffel-net-language/eiffel-net/inheritance.wiki @@ -0,0 +1,341 @@ +[[Property:title|Inheritance]] +[[Property:weight|3]] +[[Property:uuid|7e4cb7ba-fda6-8eac-3e27-bbb8fafd8673]] +Inheritance, along with client/supplier, are the two relationships that can exist between classes. + +Inheritance lets us mirror in software the types of abstractions that are common in many problem domains, i.e., the more general to the more specialized. + +Inheritance also gives a way us to combine these abstractions. + +Inheritance allows us to make extensions and adaptations to existing software, while at the same time, leaving the original software unaltered. + +==The Eiffel Inheritance Model== + +If class B inherits from class A, then: +* Every feature of A is also a feature of B +* In any case in which an instance of A is called for, then an instance of B will suffice. + +Flexibility and adaptability are key qualities of the Eiffel inheritance model. On an informal level, this means that, except as prevented by certain constraints, a class can inherit from a set of classes containing just about any other classes. + +Eiffel classes can be effective or deferred. If a class is effective, then it is completely implemented. As a result, it is possible to create and use direct instances of an effective class at runtime. + +If a class is deferred, then it is not completely implemented. A class is deferred if it contains at least one deferred feature. So, it is possible for you to mark a feature (and by consequence also its class) as deferred when you code it. This means that the specification for this class dictates that such a feature exists, but there is no implementation for the feature included in the class. As a result, there can be no direct instances of deferred classes at runtime. However, a class that inherits from a deferred class can implement, or effect, the deferred features. This results in an effective descendant to the deferred class. And it is possible to create direct instances of this effective descendant. Such instances would also be instances (albeit not direct instances) of the original deferred class. + +What this means to us as software producers, is that in any development effort, we have available a great number of classes which can serve as potential starting points. That is, classes that we could make parents to the classes we produce. And, those classes do not have to chosen from a strict dichotomy of classes which are either completely abstract or completely implemented. Inheritance from classes that are deferred but have some implemented features is both possible and encouraged. It reuses existing software and it reduces the opportunity for error. + +Consider the deferred class COMPARABLE from the Eiffel Base Library. A portion of COMPARABLE is shown below: + +deferred class + COMPARABLE + +feature -- Comparison + + is_less alias "<" (other: like Current): BOOLEAN + -- Is current object less than `other'? + deferred + end + + is_less_equal alias "<=" (other: like Current): BOOLEAN + -- Is current object less than or equal to `other'? + do + Result := not (other < Current) + end + + is_greater alias ">" (other: like Current): BOOLEAN + -- Is current object greater than `other'? + do + Result := other < Current + end + + is_greater_equal alias ">=" (other: like Current): BOOLEAN + -- Is current object greater than or equal to `other'? + do + Result := not (Current < other) + end + + is_equal (other: like Current): BOOLEAN + -- Is `other' attached to an object of the same type + -- as current object and identical to it? + do + Result := (not (Current < other) and not (other < Current)) + end + + +If you are producing a class that you wish to support basic comparison operators, like "<" and ">", you can have that class inherit from COMPARABLE, which has features which correspond to those operators. The text for COMPARABLE contains eight features. Seven of these are effective and one is deferred. + +So through inheritance from COMPARABLE, your class, let's call it WHATZIT, would now have these features available. But how would the features of COMPARABLE know what it means to compare WHATZITs? + +Of course, it would have no way of knowing, so you must show it. And you do that by writing the implementation for "<", the one deferred feature that WHATZIT inherits from the COMPARABLE class. + +When you look closely at the effective features of COMPARABLE, you see that their implementations are ultimately based on "<". If we were not able to inherit from multiple partially implemented classes, then we would be forced to implement many more features, a process which invites error, or, in the case of comparison, to move to a less appealing model. + +==The Inheritance Part of Classes in Eiffel== + +Because the inheritance model has such flexibility, it must also have adaptability. A consequence of inheriting from multiple classes is that it would be possible to inherit multiple features with the same name ... and you remember from [[Adding Class Features|Adding Class Features]] that a class is not allowed to have more than one feature with the same name. A process called feature adaptation allows us to resolve these issues in an heir. Feature adaptation is also done for reasons other than resolving name clashes as well. + +Feature adaptation is an enabling capability, but it is also one that takes some study to understand fully. + +We will look at the types of feature adaptation that will serve most useful to you as you begin to produce Eiffel software. + +In [[Eiffel Classes|Eiffel Classes]] you saw where the inheritance part fits into the class structure. Shown below is a portion of class LINKED_QUEUE from the Eiffel libraries. LINKED_QUEUE is an effective class which implements the abstract notion of a QUEUE (a deferred class) with an implementation based on the services provided by LINKED_LIST (an effective class). + +class + LINKED_QUEUE [G] +inherit + QUEUE [G] + undefine + is_empty, + copy, + is_equal + redefine + linear_representation, + prune_all, + extend + select + item, + put + end + LINKED_LIST [G] + rename + item as ll_item, + remove as ll_remove, + make as ll_make, + remove_left as remove, + put as ll_put + export + {NONE} + all + {ANY} + writable, + extendible, + wipe_out, + readable + undefine + fill, + append, + prune, + readable, + writable, + prune_all, + extend, + force, + is_inserted + redefine + duplicate, + linear_representation + select + remove + end + + +Okay ... now calm down ... please. This is an example from a very highly-evolved and sophisticated library which is replete with software reuse. LINKED_QUEUE has two parents and uses considerable feature adaptation. In fact, it uses every feature adaptation option available. The benefit is obvious, though. LINKED_QUEUE class has only seven features actually coded. In total there are only 26 lines of instructions! + +In practice you can use inheritance, even multiple inheritance, to do some quite productive programming in Eiffel without having to write anything that looks like the inheritance part of LINKED_QUEUE above. + +Regardless, let's break LINKED_QUEUE's inheritance part into chunks and take a look at some of them. + +===Rename=== + + rename + item as ll_item, + remove as ll_remove, + make as ll_make, + remove_left as remove, + put as ll_put + + +As you might have already guessed, the rename part, introduced oddly enough by the keyword "rename", is used to rename features. + +Specifically, it is used when an heir wants to use a feature from a parent, but wants to use it under a different name than that by which the parent knows it. So in the example, the feature known as item in LINKED_LIST is perfectly usable in LINKED_QUEUE, but must be applied as ll_item. + +This is common when your class inherits two different features with the same name from two different parents and you want to be able to use them both. Because you can only have one feature with a given name, then rename one of the features. + +===New Exports=== + + export + {NONE} + all + {ANY} + writable, + extendible, + wipe_out, + readable + + +The new exports part is introduced by the keyword "export". This section allows you to change the export status of inherited features. Remember from [[Adding Class Features|Adding Class Features]] that features become available (or not) to clients by their export status. Export status of immediate features is controlled in the feature clause. But here we are dealing with inherited features, so we control their status in the export part of the class's inheritance section. Any feature not mentioned will have the same export status as it did in the parent class. + +In this example, the keyword "all" is used first to say that all features inherited form LINKED_LIST are unavailable to any clients (export to class NONE). This is typical for a class like LINKED_QUEUE in which the features important to the client come from the deferred parent, in this case QUEUE, and the class LINKED_LIST is used only for implementation. But, it seems that also in this case, the producer felt differently about the features writable, extendible, wipe_out, and readable, and decided the allow clients of ANY type to utilize these features inherited from LINKED_LIST. + +===Undefine=== + + undefine + is_empty, + copy, + is_equal + + +Next, undefine ... it's probably not what you think. You might assume that undefine is a way to banish forever any inherited features that you just do not want to deal with. But what happens to features whose names are listed in an undefine clause is that they become deferred features in the heir. + +Undefine is useful if you inherit two different features of the same name from different parents, a situation you cannot live with. If you like one and you don't like the other, then you can undefine the one you don't like. The the only version you get is the one you like. + +Another way you might use undefine is in the case in which you actually want a feature to be deferred in an heir that was effective in a parent. + +===Redefine=== + + redefine + linear_representation, + prune_all, + extend + + +The redefine part lists the names of effective features for which the producer of the heir class would like to provide implementations that replace the inherited implementations. + +So, in this example the implementation for linear_representation, for example, that LINKED_QUEUE would have inherited from QUEUE will not be used. Instead LINKED_QUEUE implements its own version of linear_representation. + +{{note|When a class implements a version of an inherited feature which was deferred in its parent, this is known as "effecting" the feature. Because features being effected are getting their first implementation, it is not necessary to list their names in the redefine part, or anywhere else in the inheritance part of the heir. }} + +===Select=== + + select + remove + + +The select part is used only under special circumstances. The case in which select is required involves a situation called "repeated" inheritance. Repeated inheritance occurs when an heir inherits more than once from the same ancestor. Usually this means it has two or more parents who have a common proper ancestor (but it can occur directly). The features from the common ancestor are inherited by each of the parents and passed on to the heir. The rules and effects of repeated inheritance occupy an entire chapter in the official Eiffel programming language reference and will not be reproduced here. Justunderstand at this point that it is sometimes necessary to use select to provide the dynamic binding system with an unambiguous choice of features in the presence of polymorphic attachment. + +You should note also that repeated inheritance can and does occur often without causing any problem at all. In fact it happens in every case of multiple inheritance, due to the fact that all classes inherit from class ANY and receive its features as a result. The reason it is not a problem is that in the case that any feature makes it from the original common ancestor along multiple paths to the heir with its name and implementation still intact, it will arrive as only one feature heir. This is called sharing and nothing special needs to be done to make it happen. + +==Polymorphism== + +It is time now to see another way in which inheritance helps build more extendible software. + +Assume that we have to build classes that model different types of polygons. We would do this by building a class for polygon which would model a garden-variety polygon, a multi-sided closed figure. But when we consider that there are specialized types of polygons, like triangles and rectangles, we realize that to support these specializations, we need classes for them as well. And this is an obvious opportunity for inheritance. All triangles and rectangles are polygons. So, we start with class POLYGON and its proper descendants TRIANGLE and RECTANGLE. + +So we can make declarations like: + + my_polygon: POLYGON + your_polygon: POLYGON + my_triangle: TRIANGLE + my_rectangle: RECTANGLE + another_rectangle: RECTANGLE + + +Assume these declarations are in force for all the examples this section on polymorphism. + +We saw in [[Adding Class Features|Adding Class Features]] that we can say that one class conforms to another if it is the same class or one of its proper descendants. Therefore POLYGON conforms to POLYGON. Also, TRIANGLE and RECTANGLE conform to POLYGON. But, importantly, POLYGON does not conform to TRIANGLE or RECTANGLE. This makes sense intuitively, because we know all rectangles and triangles are polygons ... and we also know that not all polygons are rectangles. + +===Polymorphic Attachment=== + +These facts affect how assignments can work. Using the declarations above: + + my_polygon := your_polygon -- Is valid + your_polygon :=my_polygon -- Is valid + my_polygon :=my_rectangle -- Is valid + my_polygon := my_triangle -- Is valid + + +but + + my_rectangle := my_polygon -- Is not valid + my_triangle := my_polygon -- Is not valid + + +and of course + + my_rectangle := my_triangle -- Is not valid + + +Consider now the assignment below which is valid. + + my_polygon := my_rectangle + + +After an assignment like this executes the entity my_polygon will be holding at runtime a reference to an instance of a type which is not a direct instance of its declared type POLYGON. But conformance ensures us that, although it may not be a direct instance, it will indeed by an instance. (all rectangles are polygons). + +Depending upon how many different types of polygons get modeled in classes, the entity "my_polygon" could be attached objects of may different types ... it could take on many forms. This in fact is the basis for the term "polymorphism"; having many forms. So we speak of "polymorphic attachment" as the process by which at runtime entities can hold references to objects which are not of the entity's declared type ... but they are of conforming types. + +Now let's see how we get some value from this. + +===Dynamic Binding=== + +Suppose that one of the features of POLYGON is a query perimeter which returns an instance's perimeter. The producer of POLYGON may have implemented perimeter as a function that computes the perimeter by adding up the lengths of all the sides. This approach is guaranteed to work for all polygons, and we can apply the perimeter feature to any polygon. Let's print some perimeters: + + print (my_polygon.perimeter) + print (my_triangle.perimeter) + print (my_rectangle.perimeter) + + +TRIANGLE and RECTANGLE might have properties, expressed as queries, which as a part of their specialization, distinguish them from run-of-the-mill polygons. Two features of rectangles are width and height the lengths of the sides. + +Armed with these RECTANGLE-specific features, the producer of RECTANGLE may say, "Now I no longer have to depend upon that crude implementation of perimeter that is inherited from POLYGON. I can build an efficient RECTANGLE-specific implementation of perimeter, based on the knowledge that for all RECTANGLEs perimeter = 2*(width+height)" + +To implement this specialized version of perimeter, the producer of RECTANGLE must add the feature to the class, but also must list its name in the "redefine" part of the RECTANGLE's inheritance clause. + +class + RECTANGLE +inherit + POLYGON + redefine + perimeter + end + . + . +feature + perimeter: REAL + -- Sum of lengths of all sides + do + Result := 2 * (width + height) + end + + +You would expect then, that this version of perimeter would be executed in the following context: + + print (my_rectangle.perimeter) + + +But what makes this interesting is that even in the context below + + my_polygon := my_rectangle + print (my_polygon.perimeter) + + +in which perimeter is being applied to a entity declared as POLYGON, the specialized version of perimeter from RECTANGLE is being used. It would be impossible to ensure at compile time which version of perimeter is most appropriate. So it must be done at runtime. This ability to choose the best version of a feature to apply, just at the moment it needs to be applied, is called "dynamic binding". + +Static typing tells us at compile time that it is safe to apply perimeter to my_polygon No matter which of the types of polygons is attached to my_polygon, there will be a perimeter feature that will work. + +Dynamic binding tells us that when we apply perimeter, we know that the most appropriate version of the feature will get applied at runtime. + +===Object Test=== + +Now let's add another situation. Consider the code below: + + my_polygon := my_rectangle + print (my_polygon.perimeter) + print (my_polygon.width) -- Is invalid + + +We could apply perimeter to my_polygon and everything is fine ... we even get RECTANGLE's specialized version of the feature. But it is invalid for us to try to apply width to my_polygon even though we feel (with rather strong conviction) that at this point in execution, my_polygon will be attached to an object of type RECTANGLE, and we know that width is a valid query on RECTANGLEs. + +The reason follows. When we declared my_polygon as type POLYGON, we made a deal that says that the only features that can be applied to my_polygon are the features of POLYGON. Remember that static typing guarantees us at compile time that at runtime there will be at least one version of the feature available that can be applied. + + print (my_polygon.width) -- Is invalid + + +But in the case above, the guarantee cannot be made. my_polygon is declared with class POLYGON which has no width feature, despite the fact that some of its proper descendants might. + +Does this mean that we can never do RECTANGLE things with this instance again, once we have attached it to my_polygon? + +No. There is a language facility called the '''object test''' which will come to our rescue. The object test will allow us safely to attach our instance back to an entity typed as RECTANGLE. After doing so, we are free use RECTANGLE features. + + my_polygon := my_rectangle + print (my_polygon.perimeter) + if attached {RECTANGLE} my_polygon as l_rect then + print (l_rect.width) + end + +In this code, the entity l_rect is a fresh local entity produced during the object test. So, the code can be read: if at this point, my_polygon is attached to an instance of type RECTANGLE, then attach that instance to a fresh local entity named l_rect, then apply width to l_rect and print the result. + + +:'''Note:''' The object test replaces the functionality of an obsolete mechanism called assignment attempt. Assignment attempt used the syntax '''?=''' in the context of assignment versus the ''':=''' of normal assignment. + + + diff --git a/documentation/18.11/solutions/platform-specifics/microsoft-windows/net/eiffel-net-language/eiffel-net/referenced-assembly-type-and-feature-name-conversion.wiki b/documentation/18.11/solutions/platform-specifics/microsoft-windows/net/eiffel-net-language/eiffel-net/referenced-assembly-type-and-feature-name-conversion.wiki new file mode 100644 index 00000000..fcc4e197 --- /dev/null +++ b/documentation/18.11/solutions/platform-specifics/microsoft-windows/net/eiffel-net-language/eiffel-net/referenced-assembly-type-and-feature-name-conversion.wiki @@ -0,0 +1,49 @@ +[[Property:title|Referenced Assembly Type and Feature Name Conversion]] +[[Property:weight|10]] +[[Property:uuid|5d575090-35d9-f983-7308-172b1641173f]] +The [[The Eiffel for .NET language|Eiffel for .NET language]] is Eiffel. It is not a variant of Eiffel that spawned a new language, as is '''C#''', or a dramatic evolution of Eiffel, such as '''Visual Basic .NET''' is to '''VB6'''. As Eiffel stands today, and will probably remain, Eiffel's conventions for class names and features names match neither that of the OO Pascal variants nor the "Camel-casing" conventions recommended by Microsoft. Eiffel also does not support the notion of full quantified type names. The period (''''.'''') between namespace and type names is not valid Eiffel syntax. These naming convention rules pose a problem for maintaining the Eiffel programming language. To address this issue, when referencing .NET assemblies, all referenced assembly type names and feature names are converted into "Eiffel-case" when using Eiffel. + +==What is Eiffel-Case?== + +Eiffel-casing is almost the same for both class and class feature names, all words are separated using underscores (''''_''''). The differences between them are class names are always in uppercase and feature names always in lowercase. + +MY_CLASS is an example of an Eiffel-cased class name.
+my_feature is an example of an Eiffel-cased feature name. + +There are somewhat complex rules to ensure that the automatic formatting of .NET name, type, method, property and otherwise are formatted to the most readable name possible, given their casing convention. One absolute is that the Eiffel compilation process will remove the namespace from the fully qualified type name and format just the type name. + +For example System.Windows.Forms.Border3DStyle would yield BORDER_3D_STYLE. + +Stripping the namespace from the name is essential to keep type names short and usable, who wants to use SYSTEM_WINDOWS_FORMS_BORDER_3D_STYLE? Dropping the namespace does present a potential problem; assemblies may have two type that are of the same name but are located in different namespaces. A resolution to this comes in the form of assembly prefixes. For every assembly a class name prefix can be specified. Eiffel Software have reserved a set of assembly prefix pairs which should not be change as they are used by the Eiffel class libraries. For example, ''System.Windows.Forms.dll'' contains a commonly used type called System.Windows.Forms.Form. During the compilation process ''System.Windows.Forms.dll'' will be evaluated and System.Windows.Forms.Form will yield the FORM Eiffel class name. ''System.Windows.Forms.dll'' has been assigned the 'WINFORMS_' prefix, so FORM would actually be WINFORMS_FORM instead. + +==Reserved Prefixes== + +The following table displays the fixed assembly class name prefixes, assigned by Eiffel Software, for the Microsoft Foundation Class Libraries: +{| +|- +| mscorlib.dll +| No Prefix +|- +| System.dll +| SYSTEM_DLL_ +|- +| System.XML.dll +| XML_ +|- +| System.Data.dll +| DATA_ +|- +| System.Web.dll +| WEB_ +|- +| System.EnterpriseServices.dll +| ENTERPRISE_ +|- +| System.Windows.Forms.dll +| WINFORMS_ +|} + + + + + diff --git a/documentation/18.11/solutions/platform-specifics/microsoft-windows/net/eiffel-net-language/eiffel-net/using-referenced-assemblies.wiki b/documentation/18.11/solutions/platform-specifics/microsoft-windows/net/eiffel-net-language/eiffel-net/using-referenced-assemblies.wiki new file mode 100644 index 00000000..6e460f83 --- /dev/null +++ b/documentation/18.11/solutions/platform-specifics/microsoft-windows/net/eiffel-net-language/eiffel-net/using-referenced-assemblies.wiki @@ -0,0 +1,16 @@ +[[Property:title|Using Referenced Assemblies]] +[[Property:weight|8]] +[[Property:uuid|acbe0407-b95e-6268-fc20-238f91df595e]] +Eiffel for.NET is a first class citizen in the Microsoft.NET programming world. This means that if you are programming in Eiffel for.NET, you have full access to the thousands of software components in the .NET type libraries. But, that's not all. You also have full access to the thousands of components in the traditional Eiffel class libraries. And even that's not all. You have the ability to build software components which comply with.NET standards, so that they can be used by programmers using any other .NET language. Still not all. When you use Eiffel, you can choose to build software that will run under Microsoft.NET, but will be portable to other popular operating systems as well. + +Being an Eiffel for.NET programmer obviously put you in a very powerful position. How do you take advantage of it? + +To use.NET software components from Eiffel for.NET requires you to have some understanding of both.NET and Eiffel and how their respective object models differ. If you have read the rest of the help topics in [[Eiffel for .NET|this section]] then you have a pretty good idea of what the Eiffel method and language are all about. + +When you begin to build software in Eiffel for.NET, you will likely find a need to reuse types from the.NET libraries. These libraries are called assemblies. When you reference a assembly using Eiffel for.NET, the types in the assembly become available to you in a form that makes them look like so many Eiffel classes. The names for types and members will conform to Eiffel conventions. The same thing happens when you are programming against assemblies in Visual Basic.NET or Visual C#.NET. + +The section called [[Conventions]] covers the details the Eiffel conventions and how the.NET types are made available to Eiffel for.NET programmers. + + + + diff --git a/documentation/18.11/solutions/platform-specifics/microsoft-windows/net/eiffel-net-language/index.wiki b/documentation/18.11/solutions/platform-specifics/microsoft-windows/net/eiffel-net-language/index.wiki new file mode 100644 index 00000000..a2b50cb5 --- /dev/null +++ b/documentation/18.11/solutions/platform-specifics/microsoft-windows/net/eiffel-net-language/index.wiki @@ -0,0 +1,15 @@ +[[Property:title|The Eiffel for .NET language]] +[[Property:weight|2]] +[[Property:uuid|ba6cd8d3-683c-4167-bdef-a0274c392f34]] +This section focuses on defining Eiffel for .NET. The key requirement for Eiffel for .NET is the exclusive use of the common language runtime with a minimum Eiffel-specific runtime. The second requirement is to generate IL code that is CLS compliant, meaning that other CLS compliant languages/compilers/tools will be able to reuse .NET components written in Eiffel for .NET. The last requirement is to generate verifiable IL code. + +Because not all Eiffel functionalities are present in .NET, the task of the Eiffel compiler is made more complicated since it has to emulate those mechanisms instead of reusing what .NET provides. For example the common language runtime of .NET does not support: +* [[uuid:b8c10baa-4f50-adfe-a6f8-9cb56a8f1917#Multiple inheritance|multiple inheritance]] +* [[uuid:b8c10baa-4f50-adfe-a6f8-9cb56a8f1917#Genericity|genericity]] +* [[uuid:b8c10baa-4f50-adfe-a6f8-9cb56a8f1917#Covariance|covariance]] +* agents + +We will see: +* what is Eiffel on .NET +* which Eiffel mechanisms have been implemented and which haven't. + diff --git a/documentation/18.11/solutions/platform-specifics/microsoft-windows/net/eiffel-net-language/known-issues.wiki b/documentation/18.11/solutions/platform-specifics/microsoft-windows/net/eiffel-net-language/known-issues.wiki new file mode 100644 index 00000000..0c1c9806 --- /dev/null +++ b/documentation/18.11/solutions/platform-specifics/microsoft-windows/net/eiffel-net-language/known-issues.wiki @@ -0,0 +1,10 @@ +[[Property:title|Known issues]] +[[Property:weight|4]] +[[Property:uuid|78c6b5c1-a87b-805d-38bd-fe64cb4e7c0d]] +==Eiffel issues== +* Check here first for the [[Eiffel for .NET Integration|details of the integration of Eiffel with .NET]] . +* The root creation routine of the root class must not take any arguments. You can access the command line given to the application via the class ARGUMENTS. + + + + diff --git a/documentation/18.11/solutions/platform-specifics/microsoft-windows/net/index.wiki b/documentation/18.11/solutions/platform-specifics/microsoft-windows/net/index.wiki new file mode 100644 index 00000000..5409ccbf --- /dev/null +++ b/documentation/18.11/solutions/platform-specifics/microsoft-windows/net/index.wiki @@ -0,0 +1,8 @@ +[[Property:title|.NET]] +[[Property:weight|-15]] +[[Property:uuid|55eda2f0-0c60-f08c-b141-913e31a49c2f]] +==.NET== + +Eiffel support for Microsoft .NET. + + diff --git a/documentation/18.11/solutions/platform-specifics/microsoft-windows/net/net-installation-instructions.wiki b/documentation/18.11/solutions/platform-specifics/microsoft-windows/net/net-installation-instructions.wiki new file mode 100644 index 00000000..81cb8df4 --- /dev/null +++ b/documentation/18.11/solutions/platform-specifics/microsoft-windows/net/net-installation-instructions.wiki @@ -0,0 +1,5 @@ +[[Property:title|.NET Installation instructions]] +[[Property:weight|0]] +[[Property:uuid|64f7e3b1-f6ee-5cc4-1006-2fc4dfdaeae7]] +Before installing the .NET components for Eiffel for .NET you need to install either the .NET Framework, the .NET Framework SDK or Visual Studio .NET. If you do not have any of those installed, the installation program will prompt you with a warning because no .NET features support will be installed. + diff --git a/documentation/18.11/solutions/platform-specifics/microsoft-windows/net/samples/ado-net-samples/adonet-sample.wiki b/documentation/18.11/solutions/platform-specifics/microsoft-windows/net/samples/ado-net-samples/adonet-sample.wiki new file mode 100644 index 00000000..b6c08c19 --- /dev/null +++ b/documentation/18.11/solutions/platform-specifics/microsoft-windows/net/samples/ado-net-samples/adonet-sample.wiki @@ -0,0 +1,88 @@ +[[Property:title|ADO.NET Sample]] +[[Property:weight|0]] +[[Property:uuid|45d24893-63d0-c2a9-9f62-ead08ca4b901]] +This sample consist of a command line showing how to interact with a database. + +The DataReader object is somewhat synonymous with a read-only/forward-only cursor over data. The DataReader API supports flat as well as hierarchical data. A DataReader object is returned after executing a command against a database. The format of the returned DataReader object is different from a recordset. For example, you might use the DataReader to show the results of a search list in a web page. + +==Compiling== + +To compile the example: +# Launch EiffelStudio. +# Select '''Use existing Ace (control file)''' and click '''OK''' +# Browse to ''$ISE_EIFFEL\examples\dotnet\ado\ado3\'' +# Choose the Ace file for the version of the .net framework you are running +# Choose the directory where the project will be compiled, by default the same directory containing the Ace file. +# Click '''OK'''. + + +==Running== + +After you launch the sample, the following output appears: + +Customer ID Company Name +ALFKI Alfreds Futterkiste +ANATR Ana Trujillo Emparedados y helados +ANTON Antonio Moreno Taquera +AROUT Around the Horn +BERGS Berglunds snabbkp +BLAUS Blauer See Delikatessen +BLONP Blondesddsl p`re et fils +BOLID Blido Comidas preparadas +BONAP Bon app' +BOTTM Bottom-Dollar Markets +BSBEV B's Beverages +CACTU Cactus Comidas para llevar +CENTC Centro comercial Moctezuma +CHOPS Chop-suey Chinese +COMMI Comrcio Mineiro +CONSH Consolidated Holdings +DRACD Drachenblut Delikatessen +DUMON Du monde entier +EASTC Eastern Connection +... ... ... +WILMK Wilman Kala +WOLZA Wolski Zajazd + + +When the display is finished, the application wait for you to pressed the return key to finish the application. + +==Under the Hood== + +This application shows how to interact with a database. First the connection to the database is opened: + + create connection.make ("server=(local)\NetSDK;Trusted_Connection=yes;database=northwind") + +Then a request to the database is made: + + create command.make ("select * from customers", connection) + connection.open + reader := command.execute_reader + +Finally, the result of the request is displayed: + + from + ok := reader.read + until + not ok + loop + io.put_string (reader.item ("CustomerID").to_string) + io.put_string ("%T%T") + io.put_string (reader.item ("CompanyName").to_string) + io.new_line + ok := reader.read + end + + +This sample uses the following ADO.NET classes: +* SQL_DATA_READER +* SQL_CONNECTION +* SQL_COMMAND + +==Notes== + +This sample is translated from the example located in the QuickStart\howto\samples\adoplus subdirectory of the .NET Framework SDK samples directory of Microsoft Visual Studio .NET. + + + + diff --git a/documentation/18.11/solutions/platform-specifics/microsoft-windows/net/samples/ado-net-samples/index.wiki b/documentation/18.11/solutions/platform-specifics/microsoft-windows/net/samples/ado-net-samples/index.wiki new file mode 100644 index 00000000..9c327871 --- /dev/null +++ b/documentation/18.11/solutions/platform-specifics/microsoft-windows/net/samples/ado-net-samples/index.wiki @@ -0,0 +1,5 @@ +[[Property:title|ADO .NET Samples]] +[[Property:weight|0]] +[[Property:uuid|b58f17b4-57b0-ffe9-3160-86d95512f900]] +ADO .NET is the data access technology of Microsoft .NET. + diff --git a/documentation/18.11/solutions/platform-specifics/microsoft-windows/net/samples/console-samples/calculator-console.wiki b/documentation/18.11/solutions/platform-specifics/microsoft-windows/net/samples/console-samples/calculator-console.wiki new file mode 100644 index 00000000..e82a37c3 --- /dev/null +++ b/documentation/18.11/solutions/platform-specifics/microsoft-windows/net/samples/console-samples/calculator-console.wiki @@ -0,0 +1,102 @@ +[[Property:title|Calculator: console]] +[[Property:weight|0]] +[[Property:uuid|70cc4687-0d3e-2859-70f6-c603c05d085c]] +=The Calculator Sample= + +This sample consists of a command line reverse Polish notation (RPN) calculator. +{{note|A RPN calculator works slightly differently from standard calculators. It consists of a stack of numbers. Operations are applied to the two numbers on top of the stack. The result is then put on top of the stack so that it can be used in the next operation. This sample refers to the top of the stack as ''Accumulator''. }} + +==Compiling== + +To compile the example: +# Launch EiffelStudio. +# Click '''Add project''' +# Browse to ''$ISE_EIFFEL\examples\base\calculator\'' +# Choose ''calculator.ecf'' +# Change the target from classic to dotnet +# Choose the location where the project will be compiled, by default the same directory containing the configuration file. +# Click '''Open'''. + + +==Running== + +After you launch the sample, the following text appears in a console: + +********************************* +Calculator in reverse Polish form +********************************* +Allowable operations are: + '/': Divide top two numbers on the stack. + '0': Empty the stack. + 'a': Enter operand onto stack. + '?': Help. + '*': Multiply top two numbers on the stack. + '+': Add top two numbers on the stack + 'q': Quit. + '-': Subtract top two numbers on the stack. +Enter a number, followed by : + + +Enter the first number to be put onto the stack, for example 3. + +{{note|Failing to enter a number at this stage will cause the sample to stop. This sample was designed to showcase the use of EiffelBase data structures in the Microsoft .NET environment and is not protected against unexpected entries. }} + +You may then add another number on the stack by entering the character "a": + +********************************* +Calculator in reverse Polish form +********************************* +Allowable operations are: + '/': Divide top two numbers on the stack. + '0': Empty the stack. + 'a': Enter operand onto stack. + '?': Help. + '*': Multiply top two numbers on the stack. + '+': Add top two numbers on the stack + 'q': Quit. + '-': Subtract top two numbers on the stack. +Enter a number, followed by : 3 + +Accumulator = 3 + +Next operation? a +Enter a number, followed by : + + +Enter a second number, for example 2. You can then apply any operation to the two operands such as minus: + +... +Next operation? a +Enter a number, followed by : 2 + +Accumulator = 2 + +Next operation? - + +Accumulator = 1 + +Next operation? + + +You may use the operation 0 to clear the stack at any time. You may use q to quit the program. + +{{tip|You can use the command ? to display the list of available operations. }} + +==Under the Hood== + +This sample shows how to leverage EiffelBase data structures in a simple Eiffel system. The root class CALCULATOR first instantiates all ''state'' objects, each corresponding to one possible operation. The state classes all inherit from STATE. They are: +* PLUS: Add stack's two top numbers. +* MINUS: Substract stack's two top numbers. +* MULTIPLY: Multiply stack's two top numbers. +* DIVIDE: Divide stack's two top numbers. +* EMPTY: Empty stack. +* HELP: Prints available commands. +* QUESTION: Get number from user. +* QUIT: Close application. +Each of these classes implement the feature do_one_state from STATE which performs the operation associated with the state.The initial state is QUESTION which asks for the initial number to put in the ''accumulator''. Following states depend on the user input.Every descendant of STATE implement the feature operation which performs the corresponding stack transformation. + + + + + + diff --git a/documentation/18.11/solutions/platform-specifics/microsoft-windows/net/samples/console-samples/index.wiki b/documentation/18.11/solutions/platform-specifics/microsoft-windows/net/samples/console-samples/index.wiki new file mode 100644 index 00000000..6da9f556 --- /dev/null +++ b/documentation/18.11/solutions/platform-specifics/microsoft-windows/net/samples/console-samples/index.wiki @@ -0,0 +1,5 @@ +[[Property:title|Console Samples]] +[[Property:weight|1]] +[[Property:uuid|3f2c704c-9784-06a5-4cad-02ad58433b2c]] +Console application samples. + diff --git a/documentation/18.11/solutions/platform-specifics/microsoft-windows/net/samples/index.wiki b/documentation/18.11/solutions/platform-specifics/microsoft-windows/net/samples/index.wiki new file mode 100644 index 00000000..cd4d94da --- /dev/null +++ b/documentation/18.11/solutions/platform-specifics/microsoft-windows/net/samples/index.wiki @@ -0,0 +1,7 @@ +[[Property:title|Samples]] +[[Property:weight|3]] +[[Property:uuid|c1dbfdb5-c4d0-f674-d818-00d56c431c6e]] +In this chapter you will find a series of examples that will permit to you to understand the bases of programming with Dotnet. + +However, you should be familiar with Object-Oriented programming model. Almost all other examples can also be built for .NET if the dotnet target is choosen instead of classic. + diff --git a/documentation/18.11/solutions/platform-specifics/microsoft-windows/net/samples/threads-samples/index.wiki b/documentation/18.11/solutions/platform-specifics/microsoft-windows/net/samples/threads-samples/index.wiki new file mode 100644 index 00000000..5d6dcef8 --- /dev/null +++ b/documentation/18.11/solutions/platform-specifics/microsoft-windows/net/samples/threads-samples/index.wiki @@ -0,0 +1,5 @@ +[[Property:title|Threads Samples]] +[[Property:weight|2]] +[[Property:uuid|62e36a4c-0afd-e143-9a1f-98eab4022e6b]] +Samples using .NET threading technology. + diff --git a/documentation/18.11/solutions/platform-specifics/microsoft-windows/net/samples/threads-samples/pools.wiki b/documentation/18.11/solutions/platform-specifics/microsoft-windows/net/samples/threads-samples/pools.wiki new file mode 100644 index 00000000..224bab2e --- /dev/null +++ b/documentation/18.11/solutions/platform-specifics/microsoft-windows/net/samples/threads-samples/pools.wiki @@ -0,0 +1,53 @@ +[[Property:title|Pools]] +[[Property:weight|0]] +[[Property:uuid|ace044b0-1fb7-22a0-6c18-880281ed3b6d]] +This sample demonstrates use of the THREAD_POOL (ThreadPool) class. The sample queues up an asynchronous method call that is executed by a thread from the thread pool managed by the Common Language Runtime. The method "does some work" and then sets an event indicating that the work has finished. The main thread waits on the event and then exits. + +==Compiling== + +To compile the example: +# Launch EiffelStudio. +# Select '''Use existing Ace (control file)''' and click '''OK''' +# Browse to ''$ISE_EIFFEL\examples\dotnet\threading\pools\'' +# Choose the Ace file for the version of the .net framework you are running +# Choose the directory where the project will be compiled, by default the same directory containing the Ace file. +# Click '''OK'''. + + +==Running== + +After you launch the sample, the following output appears: + +Main thread: Queuing an asynchronous operation. +Main thread: Performing other operations. +WorkItem thread: Performing asynchronous operation +Main thread: Waiting for asynchronous operation to complete. + + +When the display is finished, the application wait for you to pressed the return key to finished the application. + +==Under the Hood== + +This application shows how to use the thread THREAD_POOL. +An asynchronous thread is launched: + + return := {THREAD_POOL}.queue_user_work_item (create {WAIT_CALLBACK}.make (Current, $async_operation, l_async_operation_done)) + +and is associated to the local variable l_async_operation_done. Both threads perform simultaneously some operations. The main thread wait for the asynchronous thread to complete his own operations + + return := l_async_operation_done.wait_one + to close the application. + + +This sample uses the following .NET types: +* THREAD_POOL +* WAIT_CALLBACK +* AUTO_RESET_EVENT + +==Notes== + +This sample is translated from the example located in the Samples\Technologies\Threading\Pools subdirectory of the .NET Framework SDK samples directory of Microsoft Visual Studio .NET. + + + + diff --git a/documentation/18.11/solutions/platform-specifics/microsoft-windows/net/samples/threads-samples/timers.wiki b/documentation/18.11/solutions/platform-specifics/microsoft-windows/net/samples/threads-samples/timers.wiki new file mode 100644 index 00000000..70aacb9c --- /dev/null +++ b/documentation/18.11/solutions/platform-specifics/microsoft-windows/net/samples/threads-samples/timers.wiki @@ -0,0 +1,51 @@ +[[Property:title|Timers]] +[[Property:weight|1]] +[[Property:uuid|325ac6e6-9660-891c-2605-dbeb621649f0]] +This sample consist in a command line demonstrating the use of the TIMER (Timer) class to generate a periodic callback to a method. The sample creates a TIMER object and passes to it a delegate object. When the TIMER fires, the delegate is invoked, and a static method is called asynchronously by a worker thread in the thread pool. + +==Compiling== + +To compile the example: +# Launch EiffelStudio. +# Click '''Add project''' +# Browse to ''$ISE_EIFFEL\examplesdotnet\threading\timers\'' +# Choose ''timers.ecf'' +# Choose the location where the project will be compiled, by default the same directory containing the configuration file. +# Click '''Open'''. + + +==Running== + +After you launch the sample, the following output appears: + +Checking for status updates every two seconds + +Checking Status. +Checking Status. +Checking Status. +Checking Status. +Checking Status. +... + + +When the display is finished, the application wait for you to pressed the return key to finished the application. + +==Under the Hood== + +This application shows how to use the thread TIMER. The timer is launched: + + create my_timer.make_with_callback (create {TIMER_CALLBACK}.make (Current, $check_status), Void, 0, 2000) + +and calls the feature check_status that displays the message "Checking Status." every two seconds. + +This sample uses the following .NET types: +* TIMER +* TIMER_CALLBACK + +==Notes== + +This sample is translated from the example located in the Samples\Technologies\Threading\Timers subdirectory of the .NET Framework SDK samples directory of Microsoft Visual Studio .NET. + + + + diff --git a/documentation/18.11/solutions/platform-specifics/microsoft-windows/net/samples/winform-samples/calculator-winform.wiki b/documentation/18.11/solutions/platform-specifics/microsoft-windows/net/samples/winform-samples/calculator-winform.wiki new file mode 100644 index 00000000..3df8c9bb --- /dev/null +++ b/documentation/18.11/solutions/platform-specifics/microsoft-windows/net/samples/winform-samples/calculator-winform.wiki @@ -0,0 +1,51 @@ +[[Property:title|Calculator: winform]] +[[Property:weight|-8]] +[[Property:uuid|9d064b1c-e109-35e8-70d5-73feec59fca1]] + +[[Image:calculator|Calculator]] + +
+ + +==Compiling== + +To compile the example: +# Launch EiffelStudio. +# Select '''Use existing Ace (control file)''' and click '''OK''' +# Browse to ''$ISE_EIFFEL\examples\dotnet\winforms\applications\world_calc'' +# Choose the Ace file for the version of the .net framework you are running +# Choose the directory where the project will be compiled, by default the same directory containing the Ace file. +# Click '''OK'''. + + +==Running== + +After launching the application, you will see a window displayed with a similar appearance to the one above. This is a really simple calculator that can take only two operands. So you should enter the first operand, then enter an operator, then the second operand. Click the "Calculate" button to generate the result. + + + +==Under the Hood== + +The application uses two local external assemblies, math.dll and parserutils.dll. + +parserutils parses the command line entered, and checks if it is of the form operand1 operator operand2. math.dll calculates the actual result of the command line. + +For the parserutils.dll, we have been obliged to introduce the prefix "PARSER_" to class names in this assembly in order to avoid conflicts between class names from this and other sources. + +This sample uses the following classes: +* FORM +* BUTTON +* TEXT_FIELD +* LABEL + +==Notes== + +This sample is translated from the example located in the Tutorials\resources and localization\worldcalc subdirectory of the.NET Framework SDK samples directory of Microsoft Visual Studio.NET. + + + + + + + + diff --git a/documentation/18.11/solutions/platform-specifics/microsoft-windows/net/samples/winform-samples/date-time-picker.wiki b/documentation/18.11/solutions/platform-specifics/microsoft-windows/net/samples/winform-samples/date-time-picker.wiki new file mode 100644 index 00000000..6b4f76e0 --- /dev/null +++ b/documentation/18.11/solutions/platform-specifics/microsoft-windows/net/samples/winform-samples/date-time-picker.wiki @@ -0,0 +1,55 @@ +[[Property:title|Date Time Picker]] +[[Property:weight|1]] +[[Property:uuid|9f94f4f3-3a6e-1fe7-f9c0-d9411913ce25]] +
+[[Image:date-time-picker|Hello world form]] +
+
+
+ + +==Compiling== + +To compile the example: +# Launch EiffelStudio. +# Click '''Add project''' +# Browse to ''$ISE_EIFFEL\examples\dotnet\winforms\control_reference\date_time_picker_ctrl\'' +# Choose ''date_time_picker_ctrl.ecf'' +# Choose the location where the project will be compiled, by default the same directory containing the configuration file. +# Click '''Open'''. + + +==Running== + +After launching the application, you will see a window displayed with a similar appearance to the one above. On the left side of the main window a date is displayed in a COMBO_BOX. Clicking on this COMBO_BOX and a CALENDAR control will appear showing the same date as in the COMBO_BOX. On the right side of the main window are the controls for selecting the format of the displayed date and the style of the CALENDAR control. + +Clicking on the "Change font" button and a change font dialog box will appear. + +[[Image:change-font-dialog|change font dialog box]] . + +Clicking on the "Change color" button and a dialog box will appear. This dialog box will permit you to customize the color appearance of the calendar. + +[[Image:dotnet-samples--date-time-picker-change-color-dlg|color dialog box]] . + + + +==Under the Hood== + +This application uses several different controls, but tend to show how to parameter the CALENDAR control using the FONT_DIALOG and COLOR_DIALOG. + +When one of the buttons "Change font" or "Change color" is pressed, an event is launched and open the corresponding dialog box. + +When the entry in the COMBO_BOX format changes, an event is launched and modify the format of the displayed date. + +This sample uses the following classes: +* CALENDAR +* COMBO_BOX +* BUTTON +* LABEL +* GROUP_BOX +* CHECK_BOX + +==Notes== + +This sample is translated from the example located in the QuickStart\winforms\samples\controlReference\dateTimePicker sub-directory of the .NET Framework SDK samples directory of Microsoft Visual Studio .NET. + diff --git a/documentation/18.11/solutions/platform-specifics/microsoft-windows/net/samples/winform-samples/gdi-plus-text.wiki b/documentation/18.11/solutions/platform-specifics/microsoft-windows/net/samples/winform-samples/gdi-plus-text.wiki new file mode 100644 index 00000000..9c6df2ca --- /dev/null +++ b/documentation/18.11/solutions/platform-specifics/microsoft-windows/net/samples/winform-samples/gdi-plus-text.wiki @@ -0,0 +1,38 @@ +[[Property:title|GDI plus - text]] +[[Property:weight|-7]] +[[Property:uuid|0c5210da-5512-5ae5-2971-a1a5095737c9]] +
+[[Image:text|Hello world form]] +
+
+
+ + +==Compiling== + +To compile the example: +# Launch EiffelStudio. +# Click '''Add project''' +# Browse to ''$ISE_EIFFEL\examples\dotnet\gdi_plus\text\'' +# Choose ''text.ecf'' +# Choose the location where the project will be compiled, by default the same directory containing the configuration file. +# Click '''Open'''. + + +==Running== + +After launching the application, you will see a window displayed with a similar appearance to the one above. + + + +==Under the Hood== + +This sample show how to draw some text in a window, using different brushes, different fonts, different style and different colors. + +This sample uses the following class: +* FORM + +==Notes== + +This sample is translated from the example located in the QuickStart\winforms\samples\gdiplus subdirectory of the .NET Framework SDK samples directory of Microsoft Visual Studio.NET. + diff --git a/documentation/18.11/solutions/platform-specifics/microsoft-windows/net/samples/winform-samples/index.wiki b/documentation/18.11/solutions/platform-specifics/microsoft-windows/net/samples/winform-samples/index.wiki new file mode 100644 index 00000000..61482c4b --- /dev/null +++ b/documentation/18.11/solutions/platform-specifics/microsoft-windows/net/samples/winform-samples/index.wiki @@ -0,0 +1,5 @@ +[[Property:title|Winform Samples]] +[[Property:weight|3]] +[[Property:uuid|24cbeb3c-ba2b-1fea-ccec-89600bbf3256]] +The following examples are classified generally from the easiest to the most complex. So, some notions are introduced in the few first examples and will not be explained again in the more complex examples! + diff --git a/documentation/18.11/solutions/platform-specifics/microsoft-windows/net/samples/winform-samples/mdi/index.wiki b/documentation/18.11/solutions/platform-specifics/microsoft-windows/net/samples/winform-samples/mdi/index.wiki new file mode 100644 index 00000000..956bf633 --- /dev/null +++ b/documentation/18.11/solutions/platform-specifics/microsoft-windows/net/samples/winform-samples/mdi/index.wiki @@ -0,0 +1,51 @@ +[[Property:title|MDI]] +[[Property:weight|-9]] +[[Property:uuid|d1cb553c-8394-9f27-4d75-8d69f8582e49]] +
+[[Image:mdi|Hello world form]] +
+
+
+ + +==Compiling== + +To compile the example: +# Launch EiffelStudio. +# Click '''Add project''' +# Browse to ''$ISE_EIFFEL\examples\dotnet\winforms\mdi\'' +# Choose ''mdi.ecf'' +# Choose the location where the project will be compiled, by default the same directory containing the configuration file. +# Click '''Open'''. + + +==Running== + +After launching the application, you will see a window displayed with a similar appearance to the one above. The main window contains a menu with three entries (File, Format and Window). This menu can merge with its child windows (Document). + +In the "File" entry, you can add a child window (Document),display the active child window, and exit the program. + +You can change the format of the text displayed in the child windows using the entry "Format" in the menu. + +You can choose the organization (cascade, title horizontal or title vertical) of the child windows using the entry "Window" in the menu. + + + +==Under the Hood== + +This application demonstrates how to create a multiple document interface. More information regarding the use of a MDI, is available [[MDI Details|here]] . + +This sample uses the following class: +* FORM + +==Notes== + +This sample is translated from the example located in the QuickStart\winforms\samples\MDI subdirectory of the .NET Framework SDK samples directory of Microsoft Visual Studio .NET. + + + + + + + + diff --git a/documentation/18.11/solutions/platform-specifics/microsoft-windows/net/samples/winform-samples/mdi/mdi-details.wiki b/documentation/18.11/solutions/platform-specifics/microsoft-windows/net/samples/winform-samples/mdi/mdi-details.wiki new file mode 100644 index 00000000..a1f944fa --- /dev/null +++ b/documentation/18.11/solutions/platform-specifics/microsoft-windows/net/samples/winform-samples/mdi/mdi-details.wiki @@ -0,0 +1,62 @@ +[[Property:title|MDI Details]] +[[Property:weight|0]] +[[Property:uuid|f39b5ac5-64ae-781d-8d43-305954ae8d28]] +Multiple Document Interface (MDI) applications have a single, primary window (the parent window) that contains a set of windows within its client region (child windows). Each child window is a form that is constrained to appear only within the parent. Children typically share the menu bar, tool bar, and other parts of the parent's interface. Secondary windows like dialog boxes are not constrained to the parent window's client region. + +==Creating an MDI Application== + +You can create an MDI application by following these steps: +# Create a '''Form''' ('''MainForm''') that represents the MDI parent window and set its '''IsMdiContainer''' property to '''True'''. The following code demonstrates how to set this property. + + set_is_mdi_container (True) + +# Create child forms and set the '''MdiParent''' property of each form to reference the parent form. The following code demonstrates setting the MDI parent for an instance of a child form.
+ + doc.set_mdi_parent (Current) + + +If you have different types of data to display, you can have multiple types of child forms. To display a child form, create an instance of the child form and call its '''Show''' method. + + + +==Standard MDI Menus== + +Typically, an MDI application has a '''Windows''' menu that allows the user to arrange the open child windows through tiling or cascading. The '''Windows''' menu also allows you to navigate to any of the open child windows. To create a '''Windows''' menu, add the menu items for tiling and cascading to a '''Windows''' menu in your parent form and set the '''MdiList''' property to '''True''' for the top-level '''Windows''' menu. The following code demonstrates how to create a '''Windows''' menu in an MDIapplication. + + mi_window: WINFORMS_MENU_ITEM + + ... + + mi_window := main_menu.get_menu_items.add ("&Window") + dummy := mi_window.get_menu_items.add_string_event_handler ("&Cascade", create {EVENT_HANDLER}.make (Current, $window_cascade_clicked)) + dummy := mi_window.get_menu_items.add_string_event_handler ("Tile &Horizontal", create {EVENT_HANDLER}.make (Current, $window_tile_h_clicked)) + dummy := mi_window.get_menu_items.add_string_event_handler ("Tile &Vertical", create {EVENT_HANDLER}.make (Current, $window_tile_v_clicked)) + mi_window.set_mdi_list (True) -- Adds the MDI Window List to the bottom of the menu + ... + + + + + + +==Child Window Activation== + +If you want your parent form to be notified when a child window is activated by the user, you can register an event-handling method for the '''MdiChildActivate''' event. You can determine which child window is active by using the '''ActiveMdiChild''' property of the '''Form''' class. For example, the following code updates a '''StatusBar''' control on the parent form with the name of the child window. + + ... + + add_mdi_child_activate (create {EVENT_HANDLER}.make (Current, $mdi_child_activated)) + + ... + + mdi_child_activated (sender: SYSTEM_OBJECT; e: EVENT_ARGS) + do + status_bar.set_text (active_mdi_child.get_text) + end + + ... + + + + + diff --git a/documentation/18.11/solutions/platform-specifics/microsoft-windows/net/samples/winform-samples/menus/index.wiki b/documentation/18.11/solutions/platform-specifics/microsoft-windows/net/samples/winform-samples/menus/index.wiki new file mode 100644 index 00000000..0e2cfb84 --- /dev/null +++ b/documentation/18.11/solutions/platform-specifics/microsoft-windows/net/samples/winform-samples/menus/index.wiki @@ -0,0 +1,45 @@ +[[Property:title|Menus]] +[[Property:weight|-10]] +[[Property:uuid|5a32fed4-0b46-51f8-a6b6-fc3eac70a844]] +
+[[Image:menu-principal|Hello world form]] +
+
+
+ + +==Compiling== + +==Running== + +After launching the application, you will see a window displayed with a similar appearance to the one above. The main window contains a main menu with two entries (File and Format). + +The main window also has a blue LABEL that contains a context menu, that is the clone of "Format" in the main menu. Right click on the LABEL and a context menu will appear + +[[Image:menu-contextuel|context menu]] . + + + +==Under the Hood== + +This application shows how to create a main menu and how to associate a context menu to a control (here to a LABEL). More information regarding the use of menus, is available [[Menu Details|here]] . + +This sample uses the following classes: +* FORM +* CONTEXT_MENU +* MAIN_MENU +* MENU_ITEM +* EVENT_HANDLER +* LABEL + +==Notes== + +This sample is translated from the example located in the QuickStart\winforms\samples\menus subdirectory of the .NET Framework SDK samples directory of Microsoft Visual Studio.NET. + + + + + + + + diff --git a/documentation/18.11/solutions/platform-specifics/microsoft-windows/net/samples/winform-samples/menus/menu-details.wiki b/documentation/18.11/solutions/platform-specifics/microsoft-windows/net/samples/winform-samples/menus/menu-details.wiki new file mode 100644 index 00000000..83310104 --- /dev/null +++ b/documentation/18.11/solutions/platform-specifics/microsoft-windows/net/samples/winform-samples/menus/menu-details.wiki @@ -0,0 +1,144 @@ +[[Property:title|Menu Details]] +[[Property:weight|0]] +[[Property:uuid|81ae03a0-387d-f776-17b9-f4a83c49b75f]] +Windows Forms supports menus and context menus. Main menus are displayed on a menu bar that is located immediately below the title bar of a form. The menu bar contains top-level menu items that are used to group related submenu items. For example, by clicking a '''File''' top-level menu item, you can display menu items that are related to file operations. Menu items typically appear as commands for your application (such as '''New''' and '''Open'''),but they can also appear as separator bars and submenu items. You can display a check mark next to a menu item to display the state of a command or a the state of a feature in your application. In Windows Forms, main menus are represented by the '''MainMenu''' control. + +Context menus can be displayed for a specific control or area of your form. They are typically accessed by clicking the right mouse button. In Windows Forms, context menus are represented by the '''ContextMenu''' control. + +'''ContextMenu''' and '''MainMenu''' derive from '''Menu'''. They share many properties, methods, and events. + +==Adding a MainMenu to a Form== + +The following code demonstrates how to add a '''MainMenu''' to a form. + + main_menu: WINFORMS_MAIN_MENU + + + create main_menu.make + set_menu (main_menu) + + +==Adding a Context Menu to a Control== + +The following code demonstrates how to create a '''ContextMenu''' and assign it to a control. + + label_1: WINFORMS_LABEL + label_1_context_menu: WINFORMS_CONTEXT_MENU + + + create label_1.make + create label_1_context_menu.make + label_1.set_context_menu (label_1_context_menu) + + +==Adding Menu Items== + +In the following example, a '''File''' menu item is added to the '''MainMenu'''. The '''File''' menu item contains submenu items called '''Open''' and '''Exit'''. + + mi_file: WINFORMS_MAIN_MENU + + + mi_file := main_menu. get_menu_items.add (("&File").to_cil ) + dummy := mi_file. get_menu_items.add_menu_item (create {WINFORMS_MENU_ITEM}.make_from_text (("&Open...").to_cil )) + dummy := mi_file. get_menu_items.add (("-").to_cil ) -- Gives us a separator + dummy := mi_file. get_menu_items.add_menu_item (create {WINFORMS_MENU_ITEM}.make_from_text(("E&xit").to_cil ) + + +
+ + +The following code demonstrates how to handle the '''Click''' event for both the '''Open''' and '''Exit''' menu items created in the previous code example. + + mi_file := main_menu.get_menu_items.add (("&File").to_cil) + dummy := mi_file.get_menu_items.add_menu_item (create {WINFORMS_MENU_ITEM}.make_from_text_and_on_click_and_shortcut + (("&Open...").to_cil, create {EVENT_HANDLER}.make (Current, $FileOpen_Clicked), feature {WINFORMS_SHORTCUT}.ctrl_O)) + dummy := mi_file.get_menu_items.add (("-").to_cil) -- Gives us a separator + dummy := mi_file.get_menu_items.add_menu_item (create {WINFORMS_MENU_ITEM}.make_from_text_and_on_click_and_shortcut + (("E&xit").to_cil, create {EVENT_HANDLER}.make (Current, $FileExit_Clicked), feature {WINFORMS_SHORTCUT}.ctrl_X)) + + +
+ + +The following example demonstrates how to define shortcut keys for the menu items created in the previous example. + + mi_file := main_menu.get_menu_items.add (("&File").to_cil) + dummy := mi_file.get_menu_items.add_menu_item (create {WINFORMS_MENU_ITEM}.make_from_text_and_on_click_and_shortcut + (("&Open...").to_cil, create {EVENT_HANDLER}.make (Current, $FileOpen_Clicked), feature {WINFORMS_SHORTCUT}.ctrl_O)) + dummy := mi_file.get_menu_items.add (("-").to_cil) -- Gives us a separator + dummy := mi_file.get_menu_items.add_menu_item (create {WINFORMS_MENU_ITEM}.make_from_text_and_on_click_and_shortcut + (("E&xit").to_cil, create {EVENT_HANDLER}.make (Current, $FileExit_Clicked), feature {WINFORMS_SHORTCUT}.ctrl_X)) + + + + +==Adding Submenus== + +The following example demonstrates how to create submenus. + + mi_format: WINFORMS_MAIN_MENU + + + -- Add Format Menu + mi_format := main_menu.get_menu_items.add (("F&ormat").to_cil) + + -- Font Face sub-menu + create mmi_sans_serif.make_from_text_and_on_click ((("").to_cil).concat_string_string (("&1. ").to_cil, + sans_serif_font_family.get_name), create {EVENT_HANDLER}.make (Current, $FormatFont_Clicked)) + mmi_sans_serif.set_checked (True) + mmi_sans_serif.set_default_item (True) + create mmi_serif.make_from_text_and_on_click ((("").to_cil).concat_string_string(("&2. ").to_cil, + serif_font_family.get_name), create {EVENT_HANDLER}.make (Current, $FormatFont_Clicked)) + create mmi_mono_space.make_from_text_and_on_click ((("").to_cil).concat_string_string(("&3. ").to_cil, + mono_space_font_family.get_name), create {EVENT_HANDLER}.make (Current, $FormatFont_Clicked)) + + create l_array_menu_item.make (3) + l_array_menu_item.put (0, mmi_sans_serif) + l_array_menu_item.put (1, mmi_serif) + l_array_menu_item.put (2, mmi_mono_space) + dummy := mi_format.get_menu_items.add_string_menu_item_array (("Font &Face").to_cil, l_array_menu_item) + + + + +==Adding Default Menu Items== + +The following example demonstrates how to specify a default menu item. + + mmi_sans_serif: WINFORMS_MAIN_MENU + + + create mmi_sans_serif.make_from_text_and_on_click ((("").to_cil).concat_string_string (("&1 ").to_cil, + sans_serif_font_family.get_name), create {EVENT_HANDLER}.make (Current, $format_font_clicked)) + mmi_sans_serif.set_checked (True) + + + + + + +==Adding Check Marks to Menu Items== + +The following example demonstrates how to display a check mark next to a menu item. The code also demonstrates how to track which item is checked. + + mi_medium: WINFORMS_MAIN_MENU + + + create mi_medium.make_from_text_and_on_click (("&Medium").to_cil, create {EVENT_HANDLER}.make (Current, $format_size_clicked)) + mi_medium.set_checked (True) + + +
+ + +==Cloning Menus== + +In many cases, the context menu for a control is a subset of the main menu. You cannot add the same menu items to multiple menus, but you can clone a menu item or set of menu items. The following code demonstrates how to clone the '''Format''' menu created previously and add it to the context menu of a '''Label'''. + mmy := label_1_context_menu.get_menu_items.add_menu_item (mi_format.clone_menu) + + + + + + + diff --git a/documentation/18.11/solutions/platform-specifics/microsoft-windows/net/samples/winform-samples/message-box.wiki b/documentation/18.11/solutions/platform-specifics/microsoft-windows/net/samples/winform-samples/message-box.wiki new file mode 100644 index 00000000..69031294 --- /dev/null +++ b/documentation/18.11/solutions/platform-specifics/microsoft-windows/net/samples/winform-samples/message-box.wiki @@ -0,0 +1,68 @@ +[[Property:title|Message Box]] +[[Property:weight|-11]] +[[Property:uuid|cbc37679-43b0-99b8-b8c7-1be8be49882e]] +
+[[Image:hello-world|Hello world form]]
+ [[Image:message-box|Hello world form]] +
+
+
+ + +==Compiling== + +To compile the example: +# Launch EiffelStudio. +# Click '''Add project''' +# Browse to ''$ISE_EIFFEL\examples\dotnet\winforms\hello_world_dlg\'' +# Choose ''hello_world_dlg.ecf'' +# Choose the location where the project will be compiled, by default the same directory containing the configuration file. +# Click '''Open'''. + + +==Running== + +After launching the application, you will see a window displayed with a similar appearance to the one above. + +Click on the BUTTON "Click Me!" and a message box will appear with the text that you have entered in the TEXT_BOX. + + + +==Under the Hood== + +The application shows how to use the very useful MESSAGE_BOX control. + +An event ( EVENT_HANDLER) is associated to a control (here to the BUTTON). So the line + + my_button.add_click (create {EVENT_HANDLER}.make (Current, $on_my_button_clicked )) +associates a click to my_button to the feature on_my_button_clicked. So every time the BUTTON my_button is clicked, the feature on_my_button_clicked is executed. + + +The feature my_button_clicked displays a MESSAGE_BOX + + {WINFORMS_MESSAGE_BOX}.show (msg) + +with the text contained in TEXT_BOX + + msg := "Text is : '" + msg.append (my_text_box.text) + msg.append ("'") + + +This sample uses the following classes: +* FORM +* BUTTON +* TEXT_BOX +* EVENT_HANDLER + +==Notes== + +This sample is translated from the example located in the QuickStart\winforms\samples\accessible subdirectory of the .NET Framework SDK samples directory of Microsoft Visual Studio.NET. + + + + + + + + diff --git a/documentation/18.11/solutions/platform-specifics/microsoft-windows/net/samples/winform-samples/progress-bar-sample.wiki b/documentation/18.11/solutions/platform-specifics/microsoft-windows/net/samples/winform-samples/progress-bar-sample.wiki new file mode 100644 index 00000000..715330fc --- /dev/null +++ b/documentation/18.11/solutions/platform-specifics/microsoft-windows/net/samples/winform-samples/progress-bar-sample.wiki @@ -0,0 +1,41 @@ +[[Property:title|Progress bar sample]] +[[Property:weight|6]] +[[Property:uuid|3b888246-2382-ec0b-ed4c-e1d35fe1bd79]] +
+[[Image:progress-bar|Hello world form]] +
+==Compiling== + +To compile the example: +# Launch EiffelStudio. +# Click '''Add project''' +# Browse to ''$ISE_EIFFEL\examples\dotnet\winforms\control_reference\progress_bar_ctl\'' +# Choose ''progress_bar_ctl.ecf'' +# Choose the location where the project will be compiled, by default the same directory containing the configuration file. +# Click '''Open'''. + + +==Running== + +After launching the application, you will see a window displayed with a similar appearance to the one above. On the left of the form you have the PROGRESS_BAR control, and on the right you have some controls to configure the PROGRESS_BAR. + + + +==Under the Hood== + +The application shows how to configure a PROGRESS_BAR. + +The feature on_load is redefined and launch a thread (THREAD_START) that simulates the progression of a process. + +This sample uses the following classes: +* PROGRESS_BAR +* GROUP_BOX +* TRACK_BAR +* COMBO_BOX +* LABEL +* THREAD_START + +==Notes== + +This sample is translated from the example located in the QuickStart\winforms\samples\controlReference\ProgressBar sub-directory of the .NET Framework SDK samples directory of Microsoft Visual Studio .NET. + diff --git a/documentation/18.11/solutions/platform-specifics/microsoft-windows/net/samples/winform-samples/simple-data-binding.wiki b/documentation/18.11/solutions/platform-specifics/microsoft-windows/net/samples/winform-samples/simple-data-binding.wiki new file mode 100644 index 00000000..327924df --- /dev/null +++ b/documentation/18.11/solutions/platform-specifics/microsoft-windows/net/samples/winform-samples/simple-data-binding.wiki @@ -0,0 +1,48 @@ +[[Property:title|Simple data binding]] +[[Property:weight|7]] +[[Property:uuid|5a0572cb-435c-1558-9e05-7de7e6ba08f1]] +
+[[Image:simple-data-binding|Hello world form]] +
+
+
+ + +==Compiling== + +To compile the example: +# Launch EiffelStudio. +# Click '''Add project''' +# Browse to ''$ISE_EIFFEL\examples\dotnet\winforms\data\simple_binding\'' +# Choose ''simple_binding.ecf'' +# Choose the location where the project will be compiled, by default the same directory containing the configuration file. +# Click '''Open'''. + + +==Running== + +After launching the application, you will see a window displayed with a similar appearance to the one above. + +This is a list of five customers you can parse, and we display the details of the current customer in the list. + +Clicking on the left button (|<) will bring you on the first customer of the list. + +Clicking on the left button (<) will bring you on the precedent customer in the list. + +Clicking on the right button (>) will bring you on the next customer in the list. + +Clicking on the right button (>|) will bring you on the last customer of the list. + + + +==Under the Hood== + + + +This sample uses the following class: +* FORM + +==Notes== + +This sample is translated from the example located in the QuickStart\winforms\samples\dataBinding subdirectory of the .NET Framework SDK samples directory of Microsoft Visual Studio.NET. + diff --git a/documentation/18.11/solutions/platform-specifics/microsoft-windows/net/samples/winform-samples/simple-hello-world-form-sample.wiki b/documentation/18.11/solutions/platform-specifics/microsoft-windows/net/samples/winform-samples/simple-hello-world-form-sample.wiki new file mode 100644 index 00000000..8647c140 --- /dev/null +++ b/documentation/18.11/solutions/platform-specifics/microsoft-windows/net/samples/winform-samples/simple-hello-world-form-sample.wiki @@ -0,0 +1,50 @@ +[[Property:title|Simple Hello world form sample]] +[[Property:weight|-12]] +[[Property:uuid|f4f924a5-20a2-403b-ee1d-a39c77fbb8fd]] +
+[[Image:simple-hello-world|Hello world form]] +
+==Compiling== + +To compile the example: +# Launch EiffelStudio. +# Click '''Add project''' +# Browse to ''$ISE_EIFFEL\examples\dotnet\winforms\hello_world\'' +# Choose ''hello_world.ecf'' +# Choose the location where the project will be compiled, by default the same directory containing the configuration file. +# Click '''Open'''. + + +==Running== + +After launching the application, you will see a window displayed with a similar appearance to the one above. This is the simplest windows form we can display. We have just set the title with "HelloWorld". + + + +==Under the Hood== + +The application shows how to display a Windows Form under the windows environment. The application inherits the FORM class, and just set the title with "Hello world" with the inherited feature set_text. + + set_text ("Hello world") + + +The application is launched in a PROCESS with this command line: + + {WINFORMS_APPLICATION}.run_form (Current). + + +This sample uses the following classes: +* FORM +* WINFORMS_APPLICATION + +==Notes== + +This sample is translated from the example located in the QuickStart\winforms\samples\simple hello world subdirectory of the.NET Framework SDK samples directory of Microsoft Visual Studio.NET. + + + + + + + + diff --git a/documentation/18.11/solutions/platform-specifics/microsoft-windows/net/samples/winform-samples/tree-view.wiki b/documentation/18.11/solutions/platform-specifics/microsoft-windows/net/samples/winform-samples/tree-view.wiki new file mode 100644 index 00000000..0353a87e --- /dev/null +++ b/documentation/18.11/solutions/platform-specifics/microsoft-windows/net/samples/winform-samples/tree-view.wiki @@ -0,0 +1,42 @@ +[[Property:title|Tree view]] +[[Property:weight|9]] +[[Property:uuid|28ca95af-120a-f99c-16ba-090dd290c23a]] +
+[[Image:tree-view|Hello world form]] +
+
+
+ + +==Compiling== + +To compile the example: +# Launch EiffelStudio. +# Click '''Add project''' +# Browse to ''$ISE_EIFFEL\examples\dotnet\winforms\control_reference\tree_view_ctl\'' +# Choose ''tree_view_ctl.ecf'' +# Choose the location where the project will be compiled, by default the same directory containing the configuration file. +# Click '''Open'''. + + +==Running== + +After launching the application, you will see a window displayed with a similar appearance to the one above. On the left of the form you have the TREE_VIEW control, and on the right you have some controls to configure the TREE_VIEW. + + + +==Under the Hood== + +The application shows how to use a TREE_VIEW and what are all its different configurations. + +This sample uses the following classes: +* TREE_VIEW +* GROUP_BOX +* CHECK_BOX +* COMBO_BOX +* LABEL + +==Notes== + +This sample is translated from the example located in the QuickStart\winforms\samples\ControlReference\TreeView subdirectory of the .NET Framework SDK samples directory of Microsoft Visual Studio .NET. + diff --git a/documentation/18.11/solutions/platform-specifics/microsoft-windows/resourcebench/features.wiki b/documentation/18.11/solutions/platform-specifics/microsoft-windows/resourcebench/features.wiki new file mode 100644 index 00000000..f4b2e1af --- /dev/null +++ b/documentation/18.11/solutions/platform-specifics/microsoft-windows/resourcebench/features.wiki @@ -0,0 +1,14 @@ +[[Property:title|Features]] +[[Property:weight|0]] +[[Property:uuid|3f6c7915-7e08-fc2b-f25a-7d98dff38631]] +==ResourceBench Features== +* Parse any resource file (created by Microsoft Developer Studio or Borland Resource Workshop). +* Show resources by using a tree view control. +* Display some resource's informations. +* Open and Save a Project (projects are not compatible with upcoming version of ResourceBench). +* Generate both Eiffel Classes and resource file. +* Let you specify which part of your resource file will be generated. + + + + diff --git a/documentation/18.11/solutions/platform-specifics/microsoft-windows/resourcebench/index.wiki b/documentation/18.11/solutions/platform-specifics/microsoft-windows/resourcebench/index.wiki new file mode 100644 index 00000000..d60e9dca --- /dev/null +++ b/documentation/18.11/solutions/platform-specifics/microsoft-windows/resourcebench/index.wiki @@ -0,0 +1,10 @@ +[[Property:title|ResourceBench]] +[[Property:weight|1]] +[[Property:uuid|a39ba4ef-460f-eab7-080d-c83d91546484]] +Type: Tool
+Platform: Any
+Version: 5.4
+Availability: Basic Package + + + diff --git a/documentation/18.11/solutions/platform-specifics/microsoft-windows/resourcebench/tour.wiki b/documentation/18.11/solutions/platform-specifics/microsoft-windows/resourcebench/tour.wiki new file mode 100644 index 00000000..2ea02423 --- /dev/null +++ b/documentation/18.11/solutions/platform-specifics/microsoft-windows/resourcebench/tour.wiki @@ -0,0 +1,47 @@ +[[Property:title|Tour]] +[[Property:weight|1]] +[[Property:uuid|5990eda2-2eac-6a40-8e99-5a0c5e9fc15f]] +1 - Launch the Resource Bench application. This small dialog box will appear for the initialization process: + +[[Image:retriev]] + +Then you get the main window of Resource Bench: + +[[Image:rb]] + +2 - Open a resource file (why not the example.rc file provided with this release of Resource Bench). Let the application parse the file. You will see a dialog box that informs you of the parsings state.
+First, there is the preprocessing of the resource file: + +[[Image:prepro]] + +Then you have the analysis phase: + +[[Image:analyz]] + +3 - After these two steps you will see a hierarchical view of the resource file that show you what resource's type are included in the resource file (Below the result of the "example.rc" file). + +[[Image:collaps]] + +You can expand the tree view to see associated resources for each resource's type. + +[[Image:expand]] + +At this point you are able to: +* Select some properties for the Eiffel code generation +* Save a project file +* Generate Eiffel Code +* Regenerate the same resource file (the third point is very useful when you have a Resource Bench Project and do not have the original resource file that permits its creation). + + +4 - To save a project file, click on the save button of the toolbar or select the save item in the file menu. A standard save dialog box will appear in which you can specify the file name of your project. The file's extension for a Resource Bench project is "*.prb" + +5 - To generate Eiffel Code, select the "Generate Eiffel Code..." item in the Build menu, this dialog box will appear to ask you in which directory Resource Bench must save the Eiffel classes: + +[[Image:browse]] + +6 - To generate a resource file, select the "Generate Resource file..." item in the Build menu, a standard save dialog box will appear to save the file. + + + + + diff --git a/documentation/18.11/solutions/platform-specifics/microsoft-windows/resourcebench/troubleshooting.wiki b/documentation/18.11/solutions/platform-specifics/microsoft-windows/resourcebench/troubleshooting.wiki new file mode 100644 index 00000000..eada5ab7 --- /dev/null +++ b/documentation/18.11/solutions/platform-specifics/microsoft-windows/resourcebench/troubleshooting.wiki @@ -0,0 +1,7 @@ +[[Property:title|Troubleshooting]] +[[Property:weight|2]] +[[Property:uuid|775c2f23-7138-c830-4e14-4d9898043229]] +If you have problems when you parse a resource file, you can first try to remove the grammar file (its name is "rb.gram"), and then re-launch Resource Bench. It creates again the grammar file to allow parsing resource files (on a Pentium 120 it takes less than one minute). + + + diff --git a/documentation/18.11/solutions/platform-specifics/microsoft-windows/wel/index.wiki b/documentation/18.11/solutions/platform-specifics/microsoft-windows/wel/index.wiki new file mode 100644 index 00000000..37b526a6 --- /dev/null +++ b/documentation/18.11/solutions/platform-specifics/microsoft-windows/wel/index.wiki @@ -0,0 +1,15 @@ +[[Property:title|WEL]] +[[Property:weight|-13]] +[[Property:uuid|a8f57de5-a0eb-262e-a825-95a706392640]] +==WEL (Windows Eiffel Library)== + +Type: Library
+Platform: Windows
+ +WEL is an encapsulation of the Win32 Application Programming Interface (API), and provides users with a powerful means of creating Win32 Applications. + +==Getting started with WEL== + +If you are new to WEL, then the best place to begin is the [[WEL Tutorial|tutorial]], which consists of a series of samples demonstrating the development of a simple WEL system. +Also take a look at [[WEL Common Concepts|WEL common concepts]] for details of some common concepts used in WEL programming. + diff --git a/documentation/18.11/solutions/platform-specifics/microsoft-windows/wel/wel-class-reference.wiki b/documentation/18.11/solutions/platform-specifics/microsoft-windows/wel/wel-class-reference.wiki new file mode 100644 index 00000000..87a18fe7 --- /dev/null +++ b/documentation/18.11/solutions/platform-specifics/microsoft-windows/wel/wel-class-reference.wiki @@ -0,0 +1,5 @@ +[[Property:title|WEL Class Reference]] +[[Property:weight|3]] +[[Property:uuid|a7745f7c-48e0-342b-8eeb-c0aad7553e29]] +==View the [[ref:libraries/wel/reference/index|WEL Class Reference]]== + diff --git a/documentation/18.11/solutions/platform-specifics/microsoft-windows/wel/wel-common-concepts/common-message-hooks.wiki b/documentation/18.11/solutions/platform-specifics/microsoft-windows/wel/wel-common-concepts/common-message-hooks.wiki new file mode 100644 index 00000000..81de24ae --- /dev/null +++ b/documentation/18.11/solutions/platform-specifics/microsoft-windows/wel/wel-common-concepts/common-message-hooks.wiki @@ -0,0 +1,23 @@ +[[Property:title|Common message hooks]] +[[Property:weight|4]] +[[Property:uuid|356b5211-f710-6509-3609-8d717ff425f7]] +Each WEL library component implements a set of routines for processing the most common messages that a component receives. For example, looking at [[ref:libraries/wel/reference/wel_frame_window_chart|WEL_FRAME_WINDOW]] , you will see that there are many features which begin `on_`. Each of these features enable the user to know when a specific event has occurred, and to perform the appropriate processing as a result of this event. Most of the time, you will only be interested in a small subset of these, necessary to your program. For example, below is the code for on_paint: + + on_paint (paint_dc: WEL_PAINT_DC; invalid_rect: WEL_RECT) + --Draw a centered text + do + end + + + +An on_paint message corresponds to the Wm_paint message generated by Windows whenever it needs to re-paint a window, and if you look at the feature, you can see that the arguments are a [[ref:libraries/wel/reference/wel_paint_dc_chart|WEL_PAINT_DC]] and a[[ref:libraries/wel/reference/wel_rect_chart| WEL_RECT]] . which are relevant to this message. By redefining this feature (and others as required), your code will be able to respond appropriately to windows events. +{{note|See [[Tutorial Step 2|step2]] in the [[WEL Tutorial|tutorial]] for a simple demonstration involving the re-definition of on_left_button_down. }} + + +For different messages received by a control, the arguments will differ (sometimes there are none), but those arguments will always be relevant to the message. For example, on_menu_command from [[ref:libraries/wel/reference/wel_composite_window_chart|WEL_COMPOSITE_WINDOW]] has an INTEGER as an argument, the value of which is a unique menu identifier.
+ +{{note|Not all windows events have a corresponding "on_" message hook defined in WEL. If you wish to process a Windows message that does not correspond to one of the available features, you will need to redefine process_message. +}} + + + diff --git a/documentation/18.11/solutions/platform-specifics/microsoft-windows/wel/wel-common-concepts/index.wiki b/documentation/18.11/solutions/platform-specifics/microsoft-windows/wel/wel-common-concepts/index.wiki new file mode 100644 index 00000000..4cc93b43 --- /dev/null +++ b/documentation/18.11/solutions/platform-specifics/microsoft-windows/wel/wel-common-concepts/index.wiki @@ -0,0 +1,6 @@ +[[Property:title|WEL Common Concepts]] +[[Property:weight|0]] +[[Property:uuid|f2486cae-0ce5-7360-d40f-aea5f2766ebd]] +WEL concepts you should understand. + + diff --git a/documentation/18.11/solutions/platform-specifics/microsoft-windows/wel/wel-common-concepts/inheriting-wel-application.wiki b/documentation/18.11/solutions/platform-specifics/microsoft-windows/wel/wel-common-concepts/inheriting-wel-application.wiki new file mode 100644 index 00000000..5563d13e --- /dev/null +++ b/documentation/18.11/solutions/platform-specifics/microsoft-windows/wel/wel-common-concepts/inheriting-wel-application.wiki @@ -0,0 +1,9 @@ +[[Property:title|Inheriting WEL_APPLICATION]] +[[Property:weight|1]] +[[Property:uuid|e6b092c9-dfb1-7bf1-67fc-647d047b6a01]] +For most WEL applications that you write, you will need to inherit [[ref:libraries/wel/reference/wel_application_chart|WEL_APPLICATION]] . + +{{note|. See [[Tutorial Step 1|step1]] in the [[WEL Tutorial|tutorial]] for a simple demonstration of how to do this }} + + + diff --git a/documentation/18.11/solutions/platform-specifics/microsoft-windows/wel/wel-common-concepts/redefining-init-application.wiki b/documentation/18.11/solutions/platform-specifics/microsoft-windows/wel/wel-common-concepts/redefining-init-application.wiki new file mode 100644 index 00000000..530356b9 --- /dev/null +++ b/documentation/18.11/solutions/platform-specifics/microsoft-windows/wel/wel-common-concepts/redefining-init-application.wiki @@ -0,0 +1,5 @@ +[[Property:title|Redefining `init_application']] +[[Property:weight|2]] +[[Property:uuid|95d9b971-7470-9191-3023-b99c22354e8f]] +[[ref:libraries/wel/reference/wel_application_chart|WEL_APPLICATION]] contains a feature init_application which does nothing by default, but is called before the application is started. This can be redefined to execute tasks that must be performed before the application is running. A common redefinition is to allow the loading of common dll's, see [[List View|list_view]] sample for a demonstration of this technique. + diff --git a/documentation/18.11/solutions/platform-specifics/microsoft-windows/wel/wel-common-concepts/redefining-main-window.wiki b/documentation/18.11/solutions/platform-specifics/microsoft-windows/wel/wel-common-concepts/redefining-main-window.wiki new file mode 100644 index 00000000..8d83837d --- /dev/null +++ b/documentation/18.11/solutions/platform-specifics/microsoft-windows/wel/wel-common-concepts/redefining-main-window.wiki @@ -0,0 +1,9 @@ +[[Property:title|Redefining main_window]] +[[Property:weight|1]] +[[Property:uuid|f7bfd5d0-86ef-5387-ba79-5461a516bcf6]] +When you inherit [[ref:libraries/wel/reference/wel_application_chart|WEL_APPLICATION]] , you will need to implement the deferred feature main_window as a once function. This will be the main window of your application, and can be any descendent of [[ref:libraries/wel/reference/wel_composite_window_chart|WEL_COMPOSITE_WINDOW]] . + +{{note|. See [[Tutorial Step 2|step2]] in the [[WEL Tutorial|tutorial]] for a simple demonstration of how to do this. }} + + + diff --git a/documentation/18.11/solutions/platform-specifics/microsoft-windows/wel/wel-interface-content/controls-cluster/index.wiki b/documentation/18.11/solutions/platform-specifics/microsoft-windows/wel/wel-interface-content/controls-cluster/index.wiki new file mode 100644 index 00000000..ef828e2b --- /dev/null +++ b/documentation/18.11/solutions/platform-specifics/microsoft-windows/wel/wel-interface-content/controls-cluster/index.wiki @@ -0,0 +1,54 @@ +[[Property:title|controls cluster]] +[[Property:weight|1]] +[[Property:uuid|622aa1e2-75a6-4b2e-ac1a-44f1e7be6a3b]] +==Overview== + +A Control is a window which provides a means of interacting with the application. For example, the [[ref:libraries/wel/reference/wel_edit_chart|WEL_EDIT]] control provides a user with the means of entering and modifying text. There are many common controls available within this cluster, each with a specific use. + +{{note|Each control inherits from [[ref:libraries/wel/reference/wel_control_chart|WEL_CONTROL]] which is a descendent of [[ref:libraries/wel/reference/wel_window_chart|WEL_WINDOW]] This provides the control with a large number of general features (including full window functionality). Each control also provides its own feature set which give access to specific properties of that control. }} + +==Creating controls== + +Each type of control generally has its own creation procedure that is specific to the type of control. For example, [[ref:libraries/wel/reference/wel_scroll_bar_chart|WEL_SCROLL_BAR]] has two creation procedures; make_vertical and make_horizontal. Depending on which of these two creation procedures used, you will get a scroll bar aligned vertically or horizontally. + +==Control types== + +The following effective controls are available within this cluster: +* [[ref:libraries/wel/reference/wel_bitmap_button_chart|WEL_BITMAP_BUTTON]] +* [[WEL_CHECKBOX|WEL_CHECK_BOX]] +* [[WEL_CHECK_BOX_3_STATE|WEL_CHECK_BOX_3_STATE]] +* [[ref:libraries/wel/reference/wel_drop_down_combo_box_chart|WEL_DROP_DOWN_COMBO_BOX]] +* [[ref:libraries/wel/reference/wel_drop_down_combo_box_ex_chart|WEL_DROP_DOWN_COMBO_BOX_EX]] +* [[ref:libraries/wel/reference/wel_drop_down_list_combo_box_chart|WEL_DROP_DOWN_LIST_COMBO_BOX]] +* [[ref:libraries/wel/reference/wel_drop_down_list_combo_box_ex_chart|WEL_DROP_DOWN_LIST_COMBO_BOX_EX]] +* [[ref:libraries/wel/reference/wel_flat_tool_bar_chart|WEL_FLAT_TOOL_BAR]] +* [[WEL_GROUP_BOX|WEL_GROUP_BOX]] +* [[ref:libraries/wel/reference/wel_header_control_chart|WEL_HEADER_CONTROL]] +* [[ref:libraries/wel/reference/wel_imagelist_tool_bar_chart|WEL_IMAGE_LIST_TOOL_BAR]] +* [[WEL_LIST_VIEW|WEL_LIST_VIEW]] +* [[WEL_MULTIPLE_LINE_EDIT|WEL_MULTIPLE_LINE_EDIT]] +* [[WEL_MULTIPLE_SELECTION_LIST_BOX|WEL_MULTIPLE_SELECTION_LIST_BOX]] +* [[ref:libraries/wel/reference/wel_owner_draw_button_chart|WEL_OWNER_DRAW_BUTTON]] +* [[WEL_PROGRESS_BAR|WEL_PROGRESS_BAR]] +* [[WEL_PUSH_BUTTON|WEL_PUSH_BUTTON]] +* [[WEL_RADIO_BUTTON|WEL_RADIO_BUTTON]] +* [[ref:libraries/wel/reference/wel_rebar_chart|WEL_REBAR]] +* [[ref:libraries/wel/reference/wel_rich_edit_chart|WEL_RICH_EDIT]] +* [[WEL_SCROLL_BAR|WEL_SCROLL_BAR]] +* [[ref:libraries/wel/reference/wel_selectable_button_chart|WEL_SELECTABLE_BUTTON]] +* [[ref:libraries/wel/reference/wel_simple_combo_box_chart|WEL_SIMPLE_COMBO_BOX]] +* [[WEL_SINGLE_LINE_EDIT|WEL_SINGLE_LINE_EDIT]] +* [[WEL_SINGLE_SELECTION_LIST_BOX|WEL_SINGLE_SELECTION_LIST_BOX]] +* [[ref:libraries/wel/reference/wel_static_chart|WEL_STATIC]] +* [[ref:libraries/wel/reference/wel_static_bitmap_chart|WEL_STATIC_BITMAP]] +* [[ref:libraries/wel/reference/wel_status_window_chart|WEL_STATUS_WINDOW]] +* [[ref:libraries/wel/reference/wel_tab_control_chart|WEL_TAB_CONTROL]] +* [[ref:libraries/wel/reference/wel_tool_bar_chart|WEL_TOOL_BAR]] +* [[WEL_TOOLTIP|WEL_TOOLTIP]] +* [[WEL_TRACK_BAR|WEL_TRACK_BAR]] +* [[ref:libraries/wel/reference/wel_tree_view_chart|WEL_TREE_VIEW]] +* [[WEL_UP_DOWN_CONTROL|WEL_UP_DOWN_CONTROL]] + + + + diff --git a/documentation/18.11/solutions/platform-specifics/microsoft-windows/wel/wel-interface-content/controls-cluster/wel-check-box-3-state.wiki b/documentation/18.11/solutions/platform-specifics/microsoft-windows/wel/wel-interface-content/controls-cluster/wel-check-box-3-state.wiki new file mode 100644 index 00000000..358ad8df --- /dev/null +++ b/documentation/18.11/solutions/platform-specifics/microsoft-windows/wel/wel-interface-content/controls-cluster/wel-check-box-3-state.wiki @@ -0,0 +1,22 @@ +[[Property:title|WEL_CHECK_BOX_3_STATE]] +[[Property:weight|1]] +[[Property:uuid|61726774-89f4-2a6f-8383-bda19e6db217]] +[[ref:libraries/wel/reference/wel_check_box_3_state_chart| A WEL_CHECK_BOX_3_STATE]] control can take three states, checked, indeterminate or unchecked. + +==Appearance== +A [[ref:libraries/wel/reference/wel_check_box_3_state_chart|WEL_CHECK_BOX_3_STATE]]
+[[Image:wel-check-box-3-state-unchecked|wel_check_box_3_state_unchecked]]
+
+A checked [[ref:libraries/wel/reference/wel_check_box_3_state_chart|WEL_CHECK_BOX_3_STATE]]
+[[Image:wel-check-box-3-state-checked|wel_check_box_3_state_checked]]
+
+A indeterminate [[ref:libraries/wel/reference/wel_check_box_3_state_chart|WEL_CHECK_BOX_3_STATE]]
+[[Image:wel-check-box-3-state-indeterminate|wel_check_box_3_state_indeterminate]]
+
+ +{{seealso|
+[[WEL_CHECKBOX|WEL_CHECK_BOX]] }} + + + + diff --git a/documentation/18.11/solutions/platform-specifics/microsoft-windows/wel/wel-interface-content/controls-cluster/wel-checkbox.wiki b/documentation/18.11/solutions/platform-specifics/microsoft-windows/wel/wel-interface-content/controls-cluster/wel-checkbox.wiki new file mode 100644 index 00000000..008fd70b --- /dev/null +++ b/documentation/18.11/solutions/platform-specifics/microsoft-windows/wel/wel-interface-content/controls-cluster/wel-checkbox.wiki @@ -0,0 +1,17 @@ +[[Property:title|WEL_CHECKBOX]] +[[Property:weight|0]] +[[Property:uuid|daed1ee2-dac2-b606-7c3c-2fdbd88f6a92]] +A [[ref:libraries/wel/reference/wel_check_box_chart|WEL_CHECK_BOX]] control can take two states, checked or unchecked. + +==Appearance== +A [[ref:libraries/wel/reference/wel_check_box_chart|WEL_CHECK_BOX]]
+[[Image:wel-check-box-unchecked|wel_check_box_unchecked]]
+
+A checked [[ref:libraries/wel/reference/wel_check_box_chart|WEL_CHECK_BOX]]
+[[Image:wel-check-box-checked|wel_check_box_checked]] +{{seealso|
+[[WEL_CHECK_BOX_3_STATE|WEL_CHECK_BOX_3_STATE]] }} + + + + diff --git a/documentation/18.11/solutions/platform-specifics/microsoft-windows/wel/wel-interface-content/controls-cluster/wel-down-control.wiki b/documentation/18.11/solutions/platform-specifics/microsoft-windows/wel/wel-interface-content/controls-cluster/wel-down-control.wiki new file mode 100644 index 00000000..880a58d2 --- /dev/null +++ b/documentation/18.11/solutions/platform-specifics/microsoft-windows/wel/wel-interface-content/controls-cluster/wel-down-control.wiki @@ -0,0 +1,9 @@ +[[Property:title|WEL_UP_DOWN_CONTROL]] +[[Property:weight|15]] +[[Property:uuid|71cbdf70-3bf0-a087-6859-30c1564c27a4]] +A [[ref:libraries/wel/reference/wel_up_down_control_chart|WEL_UP_DOWN_CONTROL]] consists of a pair of arrows which are used to increment or decrement a value. Using set_buddy_window, a window of type [[ref:libraries/wel/reference/wel_window_chart|WEL_WINDOW]] can be linked to this control, and is commonly used to display the current value. +==Appearance== +[[Image:wel-up-down-control|wel_up_down_control]] + + + diff --git a/documentation/18.11/solutions/platform-specifics/microsoft-windows/wel/wel-interface-content/controls-cluster/wel-group-box.wiki b/documentation/18.11/solutions/platform-specifics/microsoft-windows/wel/wel-interface-content/controls-cluster/wel-group-box.wiki new file mode 100644 index 00000000..7d30bc7f --- /dev/null +++ b/documentation/18.11/solutions/platform-specifics/microsoft-windows/wel/wel-interface-content/controls-cluster/wel-group-box.wiki @@ -0,0 +1,10 @@ +[[Property:title|WEL_GROUP_BOX]] +[[Property:weight|2]] +[[Property:uuid|9ef874da-4d1f-b3f4-9645-9b50b1718daf]] +A [[ref:libraries/wel/reference/wel_group_box_chart|WEL_GROUP_BOX]] is used to enclose other controls, and certain controls such as a [[WEL_RADIO_BUTTON|WEL_RADIO_BUTTON]] have special behavior when parented in a [[ref:libraries/wel/reference/wel_group_box_chart|WEL_GROUP_BOX]] . + +==Appearance== +[[Image:wel-group-box|wel_group_box]] + + + diff --git a/documentation/18.11/solutions/platform-specifics/microsoft-windows/wel/wel-interface-content/controls-cluster/wel-list-view.wiki b/documentation/18.11/solutions/platform-specifics/microsoft-windows/wel/wel-interface-content/controls-cluster/wel-list-view.wiki new file mode 100644 index 00000000..fabd2f3c --- /dev/null +++ b/documentation/18.11/solutions/platform-specifics/microsoft-windows/wel/wel-interface-content/controls-cluster/wel-list-view.wiki @@ -0,0 +1,19 @@ +[[Property:title|WEL_LIST_VIEW]] +[[Property:weight|3]] +[[Property:uuid|730f6b22-f858-816f-090e-c32ec1bebfd9]] +A [[ref:libraries/wel/reference/wel_list_view_chart|WEL_LIST_VIEW]] control is an encapsulation of the Windows List View control and provides several ways of displaying a collection of items. Each item can consist of a text and an icon. Certain styles allow additional information to be displayed in columns to the right of the icon and label. +==Appearance== +A [[ref:libraries/wel/reference/wel_list_view_chart|WEL_LIST_VIEW]] with the Lvs_report style.
+[[Image:wel-list-view-style-lvs-report|list_view_style_lvs_report]]
+
+A [[ref:libraries/wel/reference/wel_list_view_chart|WEL_LIST_VIEW]] with the Lvs_list style.
+[[Image:wel-list-view-style-lvs-list|list_view_style_lvs_list]]
+
+A [[ref:libraries/wel/reference/wel_list_view_chart|WEL_LIST_VIEW]] with the Lvs_icon style.
+[[Image:wel-list-view-style-lvs-icon|list_view_style_lvs_icon]]
+
+A [[ref:libraries/wel/reference/wel_list_view_chart|WEL_LIST_VIEW]] with the Lvs_smallicon style.
+[[Image:wel-list-view-style-lvs-small-icon|list_view_style_lvs_icon_small]] + + + diff --git a/documentation/18.11/solutions/platform-specifics/microsoft-windows/wel/wel-interface-content/controls-cluster/wel-multiple-line-edit.wiki b/documentation/18.11/solutions/platform-specifics/microsoft-windows/wel/wel-interface-content/controls-cluster/wel-multiple-line-edit.wiki new file mode 100644 index 00000000..58ec8c34 --- /dev/null +++ b/documentation/18.11/solutions/platform-specifics/microsoft-windows/wel/wel-interface-content/controls-cluster/wel-multiple-line-edit.wiki @@ -0,0 +1,10 @@ +[[Property:title|WEL_MULTIPLE_LINE_EDIT]] +[[Property:weight|4]] +[[Property:uuid|752a587f-4c17-f8bf-0f16-c0cf9f69bdc6]] +A [[ref:libraries/wel/reference/wel_multiple_line_edit_chart|WEL_MULTIPLE_LINE_EDIT]] is used to display multiple lines of text. Using set_read_only, the text can be made non-editable. + +==Appearance== +[[Image:wel-multiple-line-edit|wel_multiple_line_edit]] + + + diff --git a/documentation/18.11/solutions/platform-specifics/microsoft-windows/wel/wel-interface-content/controls-cluster/wel-multiple-selection-list-box.wiki b/documentation/18.11/solutions/platform-specifics/microsoft-windows/wel/wel-interface-content/controls-cluster/wel-multiple-selection-list-box.wiki new file mode 100644 index 00000000..9353261c --- /dev/null +++ b/documentation/18.11/solutions/platform-specifics/microsoft-windows/wel/wel-interface-content/controls-cluster/wel-multiple-selection-list-box.wiki @@ -0,0 +1,15 @@ +[[Property:title|WEL_MULTIPLE_SELECTION_LIST_BOX]] +[[Property:weight|5]] +[[Property:uuid|9f1f5944-969a-2d44-9cea-5c4c3d316917]] +A [[ref:libraries/wel/reference/wel_multiple_selection_list_box_chart|WEL_MULTIPLE_SELECTION_LIST_BOX ]] is a control used to display a list of STRING. Multiple items may be selected at once. + +==Appearance== +[[Image:wel-multiple-selection-list-box|wel_multiple_selection_list_box]]
+
+ +{{seealso|
+[[WEL_SINGLE_SELECTION_LIST_BOX|WEL_SINGLE_SELECTION_LIST_BOX]] }} + + + + diff --git a/documentation/18.11/solutions/platform-specifics/microsoft-windows/wel/wel-interface-content/controls-cluster/wel-owner-draw-button.wiki b/documentation/18.11/solutions/platform-specifics/microsoft-windows/wel/wel-interface-content/controls-cluster/wel-owner-draw-button.wiki new file mode 100644 index 00000000..9014d819 --- /dev/null +++ b/documentation/18.11/solutions/platform-specifics/microsoft-windows/wel/wel-interface-content/controls-cluster/wel-owner-draw-button.wiki @@ -0,0 +1,15 @@ +[[Property:title|WEL_OWNER_DRAW_BUTTON]] +[[Property:weight|6]] +[[Property:uuid|c17da029-c9dc-e664-86ce-53b1e3e4e2cc]] +A [[ref:libraries/wel/reference/wel_owner_draw_button_chart|WEL_OWNER_DRAW_BUTTON]] is a control that the user can click to provide notification to the application, and behaves in a similar fashion to [[ref:libraries/wel/reference/wel_push_button_chart|WEL_PUSH_BUTTON]] except that on_paint must be implemented to give the button the desired appearance. + +==Appearance== + +There is no sample appearance for this control. + +{{seealso|
+[[WEL_PUSH_BUTTON|WEL_PUSH_BUTTON]] }} + + + + diff --git a/documentation/18.11/solutions/platform-specifics/microsoft-windows/wel/wel-interface-content/controls-cluster/wel-progress-bar.wiki b/documentation/18.11/solutions/platform-specifics/microsoft-windows/wel/wel-interface-content/controls-cluster/wel-progress-bar.wiki new file mode 100644 index 00000000..36a059eb --- /dev/null +++ b/documentation/18.11/solutions/platform-specifics/microsoft-windows/wel/wel-interface-content/controls-cluster/wel-progress-bar.wiki @@ -0,0 +1,13 @@ +[[Property:title|WEL_PROGRESS_BAR]] +[[Property:weight|7]] +[[Property:uuid|6c8b5b4c-2d55-9635-1c29-361c28f09b14]] +A [[ref:libraries/wel/reference/wel_progress_bar_chart|WEL_PROGRESS_BAR]] control is an encapsulation of the Win32 progress bar. It can be used to display the progress of a lengthy operation. + +{{note|By specifying the style Pbs_vertical, the progress bar will be displayed vertically. }} + +==Appearance== +A [[ref:libraries/wel/reference/wel_progress_bar_chart|WEL_PROGRESS_BAR]] .
+[[Image:wel-progress-bar-half|wel_progress_bar_half]] + + + diff --git a/documentation/18.11/solutions/platform-specifics/microsoft-windows/wel/wel-interface-content/controls-cluster/wel-push-button.wiki b/documentation/18.11/solutions/platform-specifics/microsoft-windows/wel/wel-interface-content/controls-cluster/wel-push-button.wiki new file mode 100644 index 00000000..6e8601c6 --- /dev/null +++ b/documentation/18.11/solutions/platform-specifics/microsoft-windows/wel/wel-interface-content/controls-cluster/wel-push-button.wiki @@ -0,0 +1,9 @@ +[[Property:title|WEL_PUSH_BUTTON]] +[[Property:weight|8]] +[[Property:uuid|186eb349-b7c9-9944-285e-34dd9968c4e0]] +A [[ref:libraries/wel/reference/wel_push_button_chart|WEL_PUSH_BUTTON]] is a control that the user can click to provide notification to the application. +==Appearance== +[[Image:wel-push-button|wel_push_button]] + + + diff --git a/documentation/18.11/solutions/platform-specifics/microsoft-windows/wel/wel-interface-content/controls-cluster/wel-radio-button.wiki b/documentation/18.11/solutions/platform-specifics/microsoft-windows/wel/wel-interface-content/controls-cluster/wel-radio-button.wiki new file mode 100644 index 00000000..5dd8641e --- /dev/null +++ b/documentation/18.11/solutions/platform-specifics/microsoft-windows/wel/wel-interface-content/controls-cluster/wel-radio-button.wiki @@ -0,0 +1,14 @@ +[[Property:title|WEL_RADIO_BUTTON]] +[[Property:weight|9]] +[[Property:uuid|ce7c3bfb-7950-95fb-0f92-7e33abdefa3b]] +A [[ref:libraries/wel/reference/wel_radio_button_chart|WEL_RADIO_BUTTON]] control can take two states, checked or unchecked. By placing more than one of these in a [[ref:libraries/wel/reference/wel_group_box_chart|WEL_GROUP_BOX]] , they will become grouped, and only one may be checked at once. + +==Appearance== +A [[ref:libraries/wel/reference/wel_radio_button_chart|WEL_RADIO_BUTTON]]
+[[Image:wel-radio-button-unchecked|wel_radio_button_unchecked]]
+
+A checked [[ref:libraries/wel/reference/wel_radio_button_chart|WEL_RADIO_BUTTON]]
+[[Image:wel-radio-button-checked|wel_radio_button_checked]] + + + diff --git a/documentation/18.11/solutions/platform-specifics/microsoft-windows/wel/wel-interface-content/controls-cluster/wel-scroll-bar.wiki b/documentation/18.11/solutions/platform-specifics/microsoft-windows/wel/wel-interface-content/controls-cluster/wel-scroll-bar.wiki new file mode 100644 index 00000000..3d09f8c6 --- /dev/null +++ b/documentation/18.11/solutions/platform-specifics/microsoft-windows/wel/wel-interface-content/controls-cluster/wel-scroll-bar.wiki @@ -0,0 +1,14 @@ +[[Property:title|WEL_SCROLL_BAR]] +[[Property:weight|10]] +[[Property:uuid|74da6cc8-0398-0b51-885b-d73b7ec104e0]] +A [[ref:libraries/wel/reference/wel_scroll_bar_chart|WEL_SCROLL_BAR]] control is an encapsulation of the Windows scroll bar control and is often used to specify which portion of a large control that cannot be viewed completely, is currently visible. + +==Appearance== +A [[ref:libraries/wel/reference/wel_scroll_bar_chart|WEL_SCROLL_BAR]] created with make_horizontal.
+[[Image:wel-scroll-bar-horizontal|wel_scroll_bar_horizontal]]
+
+A [[ref:libraries/wel/reference/wel_scroll_bar_chart|WEL_SCROLL_BAR]] created with make_vertical.
+[[Image:wel-scroll-bar-vertical|wel_scroll_bar_vertical]] + + + diff --git a/documentation/18.11/solutions/platform-specifics/microsoft-windows/wel/wel-interface-content/controls-cluster/wel-single-line-edit.wiki b/documentation/18.11/solutions/platform-specifics/microsoft-windows/wel/wel-interface-content/controls-cluster/wel-single-line-edit.wiki new file mode 100644 index 00000000..93e46d9d --- /dev/null +++ b/documentation/18.11/solutions/platform-specifics/microsoft-windows/wel/wel-interface-content/controls-cluster/wel-single-line-edit.wiki @@ -0,0 +1,9 @@ +[[Property:title|WEL_SINGLE_LINE_EDIT]] +[[Property:weight|11]] +[[Property:uuid|69694ef8-a422-7f46-d97b-d42a16bfe838]] +A [[ref:libraries/wel/reference/wel_single_line_edit_chart|WEL_SINGLE_LINE_EDIT]] is a control used to input a single line of text. +==Appearance== +[[Image:wel-single-line-edit|wel_single_line_edit]] + + + diff --git a/documentation/18.11/solutions/platform-specifics/microsoft-windows/wel/wel-interface-content/controls-cluster/wel-single-selection-list-box.wiki b/documentation/18.11/solutions/platform-specifics/microsoft-windows/wel/wel-interface-content/controls-cluster/wel-single-selection-list-box.wiki new file mode 100644 index 00000000..66480f0d --- /dev/null +++ b/documentation/18.11/solutions/platform-specifics/microsoft-windows/wel/wel-interface-content/controls-cluster/wel-single-selection-list-box.wiki @@ -0,0 +1,15 @@ +[[Property:title|WEL_SINGLE_SELECTION_LIST_BOX]] +[[Property:weight|12]] +[[Property:uuid|4123c28b-da84-8d4b-5d51-844716569c44]] +A [[ref:libraries/wel/reference/wel_single_selection_list_box_chart|WEL_SINGLE_SELECTION_LIST_BOX]] is a control used to display a list of STRING. Only one item may be selected at once. + +==Appearance== +[[Image:wel-single-selection-list-box|wel_single_selection_list_box]]
+
+ +{{seealso|
+[[WEL_MULTIPLE_SELECTION_LIST_BOX|WEL_MULTIPLE_SELECTION_LIST_BOX]] }} + + + + diff --git a/documentation/18.11/solutions/platform-specifics/microsoft-windows/wel/wel-interface-content/controls-cluster/wel-tooltip.wiki b/documentation/18.11/solutions/platform-specifics/microsoft-windows/wel/wel-interface-content/controls-cluster/wel-tooltip.wiki new file mode 100644 index 00000000..317eed85 --- /dev/null +++ b/documentation/18.11/solutions/platform-specifics/microsoft-windows/wel/wel-interface-content/controls-cluster/wel-tooltip.wiki @@ -0,0 +1,9 @@ +[[Property:title|WEL_TOOLTIP]] +[[Property:weight|13]] +[[Property:uuid|2eb53721-d1a8-cec0-5c6a-692e9dc58755]] +A [[ref:libraries/wel/reference/wel_tooltip_chart|WEL_TOOLTIP]] is an encapsulation of the Win32 tooltip control, and controls pop-up windows which display text. Each tooltip may control multiple pop-up windows, which are added to the tooltip using add_tool. +==Appearance== +[[Image:wel-tooltip|wel_tooltip]] + + + diff --git a/documentation/18.11/solutions/platform-specifics/microsoft-windows/wel/wel-interface-content/controls-cluster/wel-track-bar.wiki b/documentation/18.11/solutions/platform-specifics/microsoft-windows/wel/wel-interface-content/controls-cluster/wel-track-bar.wiki new file mode 100644 index 00000000..307beacf --- /dev/null +++ b/documentation/18.11/solutions/platform-specifics/microsoft-windows/wel/wel-interface-content/controls-cluster/wel-track-bar.wiki @@ -0,0 +1,14 @@ +[[Property:title|WEL_TRACK_BAR]] +[[Property:weight|14]] +[[Property:uuid|ceb2589f-4caf-686c-b19f-6f2769b0edcb]] +A [[ref:libraries/wel/reference/wel_track_bar_chart|WEL_TRACK_BAR]] control has a sliding pointer and optional tick marks. + +==Appearance== +A [[ref:libraries/wel/reference/wel_track_bar_chart|WEL_TRACK_BAR]] created with make_horizontal.
+[[Image:wel-track-bar-horizontal|wel_track_bar_horizontal]]
+
+A [[ref:libraries/wel/reference/wel_track_bar_chart|WEL_TRACK_BAR]] created with make_vertical.
+[[Image:wel-track-bar-vertical|wel_track_bar_vertical]] + + + diff --git a/documentation/18.11/solutions/platform-specifics/microsoft-windows/wel/wel-interface-content/index.wiki b/documentation/18.11/solutions/platform-specifics/microsoft-windows/wel/wel-interface-content/index.wiki new file mode 100644 index 00000000..42f9e245 --- /dev/null +++ b/documentation/18.11/solutions/platform-specifics/microsoft-windows/wel/wel-interface-content/index.wiki @@ -0,0 +1,19 @@ +[[Property:title|WEL Interface Content]] +[[Property:weight|1]] +[[Property:uuid|e779c244-ec00-6a80-41e6-3ff79eb1efdb]] +WEL is an encapsulation of the Win32 Application Programming Interface (API), and provides users with a powerful means of creating Win32 Applications. + +==Components== + +The WEL library includes the following clusters: +* [[windows cluster|windows]] cluster containing classes representing available windows types +* [[controls cluster|controls]] cluster containing classes representing available controls +* [[stddlgs cluster|stddlgs]] cluster containing classes representing standard Win32 dialogs +* consts cluster which contains constants used by WEL +* gdi cluster which contains classes allowing access to WIN32 Graphics Device Interfaces +* gdistock cluster which contains standard Graphic Device Interfaces used by WEL +* messages cluster which contains classes encapsulating windows messages +* shared cluster which contains classes encapsulating system wide shared +* structs cluster which contains classes for data structures required by Win32 +* support cluster which contains many supporting classes + diff --git a/documentation/18.11/solutions/platform-specifics/microsoft-windows/wel/wel-interface-content/stddlgs-cluster/index.wiki b/documentation/18.11/solutions/platform-specifics/microsoft-windows/wel/wel-interface-content/stddlgs-cluster/index.wiki new file mode 100644 index 00000000..8342ad45 --- /dev/null +++ b/documentation/18.11/solutions/platform-specifics/microsoft-windows/wel/wel-interface-content/stddlgs-cluster/index.wiki @@ -0,0 +1,6 @@ +[[Property:title|stddlgs cluster]] +[[Property:weight|2]] +[[Property:uuid|0af8dcbf-ed31-51d7-885c-c677090f0633]] +This cluster contains different standard dialogs provided by WEL. + + diff --git a/documentation/18.11/solutions/platform-specifics/microsoft-windows/wel/wel-interface-content/stddlgs-cluster/wel-choose-color-dialog.wiki b/documentation/18.11/solutions/platform-specifics/microsoft-windows/wel/wel-interface-content/stddlgs-cluster/wel-choose-color-dialog.wiki new file mode 100644 index 00000000..deeb7105 --- /dev/null +++ b/documentation/18.11/solutions/platform-specifics/microsoft-windows/wel/wel-interface-content/stddlgs-cluster/wel-choose-color-dialog.wiki @@ -0,0 +1,15 @@ +[[Property:title|WEL_CHOOSE_COLOR_DIALOG]] +[[Property:weight|0]] +[[Property:uuid|d827c9d8-068b-bade-f6a5-6aeb6be145e3]] +The [[ref:libraries/wel/reference/wel_choose_color_dialog_chart|WEL_CHOOSE_COLOR_DIALOG]] is an encapsulation of the Win32 choose color dialog, and provides a means of selecting standard colors or creating custom colors. + +==Appearance== +[[Image:wel-choose-color-dialog|wel_choose_color_dialog]]
+
+ +{{seealso|
+[[stddlgs cluster|Standard dialogs]] }} + + + + diff --git a/documentation/18.11/solutions/platform-specifics/microsoft-windows/wel/wel-interface-content/stddlgs-cluster/wel-choose-folder-dialog.wiki b/documentation/18.11/solutions/platform-specifics/microsoft-windows/wel/wel-interface-content/stddlgs-cluster/wel-choose-folder-dialog.wiki new file mode 100644 index 00000000..95b4cb56 --- /dev/null +++ b/documentation/18.11/solutions/platform-specifics/microsoft-windows/wel/wel-interface-content/stddlgs-cluster/wel-choose-folder-dialog.wiki @@ -0,0 +1,15 @@ +[[Property:title|WEL_CHOOSE_FOLDER_DIALOG]] +[[Property:weight|1]] +[[Property:uuid|cd4eaeb8-2322-e95f-0528-75ec0849d0fe]] +The [[ref:libraries/wel/reference/wel_choose_folder_dialog_chart|WEL_CHOOSE_FOLDER_DIALOG]] allows the directory structure to be viewed and a folder selected. + +==Appearance== +[[Image:wel-choose-folder-dialog|wel_choose_folder_dialog]]
+
+ +{{seealso|
+[[stddlgs cluster|Standard dialogs]] }} + + + + diff --git a/documentation/18.11/solutions/platform-specifics/microsoft-windows/wel/wel-interface-content/stddlgs-cluster/wel-choose-font-dialog.wiki b/documentation/18.11/solutions/platform-specifics/microsoft-windows/wel/wel-interface-content/stddlgs-cluster/wel-choose-font-dialog.wiki new file mode 100644 index 00000000..986d20d7 --- /dev/null +++ b/documentation/18.11/solutions/platform-specifics/microsoft-windows/wel/wel-interface-content/stddlgs-cluster/wel-choose-font-dialog.wiki @@ -0,0 +1,15 @@ +[[Property:title|WEL_CHOOSE_FONT_DIALOG]] +[[Property:weight|2]] +[[Property:uuid|046ecb0d-819b-fbc5-d736-629d0497b8b5]] +The [[ref:libraries/wel/reference/wel_choose_font_dialog_chart|WEL_CHOOSE_FONT_DIALOG]] is an encapsulation of the Win32 choose font dialog, and provides a means of selecting a font available on the system. + +==Appearance== +[[Image:wel-choose-font-dialog|wel_choose_font_dialog]]
+
+ +{{seealso|
+[[stddlgs cluster|Standard dialogs]] }} + + + + diff --git a/documentation/18.11/solutions/platform-specifics/microsoft-windows/wel/wel-interface-content/stddlgs-cluster/wel-open-file-dialog.wiki b/documentation/18.11/solutions/platform-specifics/microsoft-windows/wel/wel-interface-content/stddlgs-cluster/wel-open-file-dialog.wiki new file mode 100644 index 00000000..ac28fc02 --- /dev/null +++ b/documentation/18.11/solutions/platform-specifics/microsoft-windows/wel/wel-interface-content/stddlgs-cluster/wel-open-file-dialog.wiki @@ -0,0 +1,16 @@ +[[Property:title|WEL_OPEN_FILE_DIALOG]] +[[Property:weight|3]] +[[Property:uuid|b97583e1-ecfd-d2c0-2718-cc7bb90c9ec7]] +The [[ref:libraries/wel/reference/wel_open_file_dialog_chart|WEL_OPEN_FILE_DIALOG]] is an encapsulation of the Win32 open file dialog, and provides a means of specifying a file to be opened. + +==Appearance== +[[Image:wel-open-file-dialog|wel_open_file_dialoG]]
+
+ +{{seealso|
+[[stddlgs cluster|Standard dialogs]]
+[[WEL_SAVE_FILE_DIALOG|WEL_SAVE_FILE_DIALOG]] }} + + + + diff --git a/documentation/18.11/solutions/platform-specifics/microsoft-windows/wel/wel-interface-content/stddlgs-cluster/wel-print-dialog.wiki b/documentation/18.11/solutions/platform-specifics/microsoft-windows/wel/wel-interface-content/stddlgs-cluster/wel-print-dialog.wiki new file mode 100644 index 00000000..a29b1896 --- /dev/null +++ b/documentation/18.11/solutions/platform-specifics/microsoft-windows/wel/wel-interface-content/stddlgs-cluster/wel-print-dialog.wiki @@ -0,0 +1,15 @@ +[[Property:title|WEL_PRINT_DIALOG]] +[[Property:weight|4]] +[[Property:uuid|c6c2866e-c14a-601c-8898-845c4b8d92a3]] +The [[ref:libraries/wel/reference/wel_print_dialog_chart|WEL_PRINT_DIALOG]] is an encapsulation of the Win32 print dialog and provides a means of specifying print preferences. + +==Appearance== +[[Image:wel-print-dialog|wel_print_dialog]]
+
+ +{{seealso|
+[[stddlgs cluster|Standard dialogs]] }} + + + + diff --git a/documentation/18.11/solutions/platform-specifics/microsoft-windows/wel/wel-interface-content/stddlgs-cluster/wel-save-file-dialog.wiki b/documentation/18.11/solutions/platform-specifics/microsoft-windows/wel/wel-interface-content/stddlgs-cluster/wel-save-file-dialog.wiki new file mode 100644 index 00000000..8d41fdf0 --- /dev/null +++ b/documentation/18.11/solutions/platform-specifics/microsoft-windows/wel/wel-interface-content/stddlgs-cluster/wel-save-file-dialog.wiki @@ -0,0 +1,16 @@ +[[Property:title|WEL_SAVE_FILE_DIALOG]] +[[Property:weight|5]] +[[Property:uuid|db6de1e7-1edb-3968-6ee5-60bf5d6f75cb]] +The [[ref:libraries/wel/reference/wel_save_file_dialog_chart|WEL_SAVE_FILE_DIALOG]] is an encapsulation of the Win32 save file dialog, and provides a means of specifying a file name and location for saving. + +==Appearance== +[[Image:wel-save-file-dialog|wel_save_file_dialoG]]
+
+ +{{seealso|
+[[stddlgs cluster|Standard dialogs]]
+[[WEL_OPEN_FILE_DIALOG|WEL_OPEN_FILE_DIALOG]] }} + + + + diff --git a/documentation/18.11/solutions/platform-specifics/microsoft-windows/wel/wel-interface-content/windows-cluster.wiki b/documentation/18.11/solutions/platform-specifics/microsoft-windows/wel/wel-interface-content/windows-cluster.wiki new file mode 100644 index 00000000..faedb7f8 --- /dev/null +++ b/documentation/18.11/solutions/platform-specifics/microsoft-windows/wel/wel-interface-content/windows-cluster.wiki @@ -0,0 +1,20 @@ +[[Property:title|windows cluster]] +[[Property:weight|-1]] +[[Property:uuid|dc1af280-2e91-713c-751f-e88ce87197cf]] +This cluster contains the different types of windows available to a [[ref:libraries/wel/reference/wel_application_chart|WEL_APPLICATION]] . + +The following effective window types are available: +* [[ref:libraries/wel/reference/wel_popup_window_chart|WEL_POPUP_WINDOW]] +* [[ref:libraries/wel/reference/wel_modal_dialog_chart|WEL_MODAL_DIALOG]] +* [[ref:libraries/wel/reference/wel_modeless_dialog_chart|WEL_MODELESS_DIALOG]] +* [[ref:libraries/wel/reference/wel_mdi_frame_window_chart|WEL_MDI_FRAME_WINDOW]] +* [[ref:libraries/wel/reference/wel_mdi_client_window_chart|WEL_MDI_CLIENT_WINDOW]] +* [[ref:libraries/wel/reference/wel_mdi_child_window_chart|WEL_MDI_CHILD_WINDOW]] +* [[ref:libraries/wel/reference/wel_main_dialog_chart|WEL_MAIN_DIALOG]] +* [[ref:libraries/wel/reference/wel_frame_window_chart|WEL_FRAME_WINDOW]] +* [[ref:libraries/wel/reference/wel_control_window_chart|WEL_CONTROL_WINDOW]] + +{{note|A WEL application must contain at least one window. See the [[WEL Tutorial]] for details of how to set up your first window within a [[ref:libraries/wel/reference/wel_application_chart|WEL_APPLICATION]] . }} + + + diff --git a/documentation/18.11/solutions/platform-specifics/microsoft-windows/wel/wel-samples/bmpview.wiki b/documentation/18.11/solutions/platform-specifics/microsoft-windows/wel/wel-samples/bmpview.wiki new file mode 100644 index 00000000..6b77b88b --- /dev/null +++ b/documentation/18.11/solutions/platform-specifics/microsoft-windows/wel/wel-samples/bmpview.wiki @@ -0,0 +1,34 @@ +[[Property:title|Bmpview]] +[[Property:weight|-15]] +[[Property:uuid|c3df2d26-d913-e298-c7bc-929451617903]] +[[Image:bmpview|bmpview]]
+
+ +==Compiling== + +To compile the example: +* Launch EiffelStudio. +* Click '''Add project''' +* Browse to ''$ISE_EIFFEL\examples\wel\bmpview\''. +* Choose ''bmpview.ecf'' +* Choose the location where the project will be compiled, by default the same directory containing the configuration file. +* Click '''OK'''. + +==Running== +After launching the program, a window will be displayed as illustrated above, although no child windows will be present. Selecting "Open" from the "File" menu will allow you to browse for a .BMP file to view. Multiple files may be opened and each opens in a new child window. The options on the "Window" menu provide features for positioning the child windows. Selecting "Close" will close the currently selected child window, while selecting "Exit" or closing the window manually will exit the program. +==Under the Hood== +MAIN_WINDOW inherits [[ref:libraries/wel/reference/wel_mdi_frame_window_chart|WEL_MDI_FRAME_WINDOW]] and redefines on_menu_command to handle the menu selections. CHILD_WINDOW inherits [[ref:libraries/wel/reference/wel_mdi_child_window_chart|WEL_MDI_CHILD_WINDOW]] and implements make to load a named bitmap, while on_paint has been redefined to re-draw the bitmap. A [[ref:libraries/wel/reference/wel_open_file_dialog_chart|WEL_OPEN_FILE_DIALOG]] is used to select files for viewing. +This sample contains the following classes: +* BMP_VIEW +* MAIN_WINDOW +* CHILD_WINDOW +* APPLICATION_IDS + +{{seealso|
+[[WEL_OPEN_FILE_DIALOG|WEL_OPEN_FILE_DIALOG]]
+[[MDI (Multiple Document Interface)|Mdi sample]] }} + + + + + diff --git a/documentation/18.11/solutions/platform-specifics/microsoft-windows/wel/wel-samples/brushes.wiki b/documentation/18.11/solutions/platform-specifics/microsoft-windows/wel/wel-samples/brushes.wiki new file mode 100644 index 00000000..5e119bbf --- /dev/null +++ b/documentation/18.11/solutions/platform-specifics/microsoft-windows/wel/wel-samples/brushes.wiki @@ -0,0 +1,35 @@ +[[Property:title|Brushes]] +[[Property:weight|-14]] +[[Property:uuid|6bca9e95-d5fe-3b88-bea0-284eb60d2dcf]] +[[Image:brushes|brushes]]
+
+ +==Compiling== + +To compile the example: +* Launch EiffelStudio. +* Click '''Add project''' +* Browse to ''$ISE_EIFFEL\examples\wel\brushes\''. +* Choose ''brushes.ecf'' +* Choose the location where the project will be compiled, by default the same directory containing the configuration file. +* Click '''OK'''. + +==Running== +After launching the program you will see a window displayed containing three push buttons marked "Brushes", "Rectangles" and "3D". Clicking "Brushes" will open a new window demonstrating different brushes available. Clicking "Rectangles" will open a new window within which many different shaped and colored rectangles will be drawn. Clicking"3D" will open a new window demonstrating the use of multiple bitmaps for animation. +==Under the Hood== +Each of the three windows that are opened from the programs MAIN_WINDOW inherit [[ref:libraries/wel/reference/wel_frame_window_chart|WEL_FRAME_WINDOW]] and contains code for generating their output. BRUSHES_DEMO redefines idle_action to force a re-draw on the applicable windows. +{{note|If enable_idle_action is not called, then idle_action is never executed. }} + +This sample contains the following classes: +* APPLICATION_IDS +* BRUSH_DEMO +* BRUSHES_DEMO +* DEMO_3D +* MAIN_WINDOW +* PROJECTION +* RECTANGLE_DEMO + + + + + diff --git a/documentation/18.11/solutions/platform-specifics/microsoft-windows/wel/wel-samples/commands.wiki b/documentation/18.11/solutions/platform-specifics/microsoft-windows/wel/wel-samples/commands.wiki new file mode 100644 index 00000000..0bfb80d6 --- /dev/null +++ b/documentation/18.11/solutions/platform-specifics/microsoft-windows/wel/wel-samples/commands.wiki @@ -0,0 +1,34 @@ +[[Property:title|Commands]] +[[Property:weight|-12]] +[[Property:uuid|e1942cb8-02df-352e-061c-2c87c280ead8]] +[[Image:commands|commands]]
+
+ +==Compiling== + +To compile the example: +* Launch EiffelStudio. +* Click '''Add project''' +* Browse to ''$ISE_EIFFEL\examples\wel\commands\''. +* Choose ''commands.ecf'' +* Choose the location where the project will be compiled, by default the same directory containing the configuration file. +* Click '''OK'''. + +==Running== +After launching the program, you will see a window displayed with a similar appearance to the one illustrated above. Please follow the instructions displayed in the window. +==Under the Hood== +MAIN_DIALOG inherits [[ref:libraries/wel/reference/wel_main_dialog_chart|WEL_MAIN_DIALOG]] which provides the feature put_command, used to associate a [[ref:libraries/wel/reference/wel_command_chart|WEL_COMMAND]] to a Windows message received by the window. A [[ref:libraries/wel/reference/wel_command_chart|WEL_COMMAND]] contains a deferred feature, execute which is executed when the command is fired. SHOW_COMMAND_INFORMATION, SHOW_MOUSE_BUTTON_INFORMATION and SHOW_MOVE_INFORMATION all inherit [[ref:libraries/wel/reference/wel_command_chart|WEL_COMMAND]] . +{{note|execute has an argument of type ANY which is used to pass any additional information required. }} + +This sample contains the following classes: +* APPLICATION_IDS +* COMMANDS_DEMO +* MAIN_DIALOG +* SHOW_COMMAND_INFORMATION +* SHOW_MOUSE_BUTTON_INFORMATION +* SHOW_MOVE_INFORMATION + + + + + diff --git a/documentation/18.11/solutions/platform-specifics/microsoft-windows/wel/wel-samples/common-controls.wiki b/documentation/18.11/solutions/platform-specifics/microsoft-windows/wel/wel-samples/common-controls.wiki new file mode 100644 index 00000000..05eed728 --- /dev/null +++ b/documentation/18.11/solutions/platform-specifics/microsoft-windows/wel/wel-samples/common-controls.wiki @@ -0,0 +1,33 @@ +[[Property:title|Common Controls]] +[[Property:weight|-13]] +[[Property:uuid|d50d633a-2ba5-995e-637c-6694cee8bf55]] +[[Image:comctrls|comctrls]]
+
+ +==Compiling== + +To compile the example: +* Launch EiffelStudio. +* Click '''Add project''' +* Browse to ''$ISE_EIFFEL\examples\wel\comctrls\''. +* Choose ''comctrls.ecf'' +* Choose the location where the project will be compiled, by default the same directory containing the configuration file. If you select another directory than the default one, please copy icons (*.ico) and resource files (*.rc) from the default directory (the one containing the ecf file) to the new one. +* Click '''OK'''. + +==Running== + +After launching the program, a window will be displayed as illustrated above. Selecting "Progress bar demonstration" from the "File" menu will update the progress bar to a full state. Leaving the mouse stationary above the track bar, progress bar or toolbar buttons will cause a tooltip control to be displayed. + +==Under the Hood== + +There is one [[ref:libraries/wel/reference/wel_tooltip_chart|WEL_TOOLTIP]] used for all the controls, but each control adds a new [[ref:libraries/wel/reference/wel_tool_info_chart|WEL_TOOL_INFO]] to provide different output for each control. The feature on_notify has been redefined to handle the Ttn_needtext notification which is posted by a control, and received by the controls parent, when a control needs to display a tooltip. The feature on_menu_select has been redefined to output the text of the selected menu item in the [[ref:libraries/wel/reference/wel_status_window_chart|WEL_STATUS_WINDOW]] located at the bottom of MAIN_WINDOW. +This sample contains the following classes: +* APPLICATION_IDS +* MAIN_WINDOW +* COMCTRLS_DEMO + + + + + + diff --git a/documentation/18.11/solutions/platform-specifics/microsoft-windows/wel/wel-samples/controls-sample.wiki b/documentation/18.11/solutions/platform-specifics/microsoft-windows/wel/wel-samples/controls-sample.wiki new file mode 100644 index 00000000..99ab2ae5 --- /dev/null +++ b/documentation/18.11/solutions/platform-specifics/microsoft-windows/wel/wel-samples/controls-sample.wiki @@ -0,0 +1,44 @@ +[[Property:title|Controls Sample]] +[[Property:weight|-11]] +[[Property:uuid|7f9a091f-61af-9ea2-18c3-469573ba14f3]] +[[Image:controls|controls]]
+
+ +==Compiling== + +To compile the example: +* Launch EiffelStudio. +* Click '''Add project''' +* Browse to ''$ISE_EIFFEL\examples\wel\controls\''. +* Choose ''controls.ecf'' +* Choose the location where the project will be compiled, by default the same directory containing the configuration file. +* Click '''OK'''. + +==Running== + +After launching the program, an empty window will be displayed. There are numerous menus in the window, each relating to a different type of [[Controls cluster|control]]. Each menu has "Create" and "Delete" along with a other options specific to each control. By selecting these menu options, controls will be created and modified as demonstrated in the above illustration. + +==Under the Hood== + +Each menu is an instance of [[ref:libraries/wel/reference/wel_menu_chart|WEL_MENU]] and on_menu_command has been redefined in MAIN_WINDOW to perform the appropriate actions. +This sample contains the following classes: +* APPLICATION_IDS +* CONTROLS +* MAIN_WINDOW + +{{seealso|
+[[WEL_LIST_VIEW|WEL_LIST_VIEW]]
+[[ref:libraries/wel/reference/wel_combo_box_chart|WEL_COMBO_BOX]]
+[[WEL_PUSH_BUTTON|WEL_PUSH_BUTTON]]
+[[ref:libraries/wel/reference/wel_edit_chart|WEL_EDIT]]
+[[WEL_RADIO_BUTTON|WEL_RADIO_BUTTON]]
+[[WEL_PUSH_BUTTON|WEL_CHECK_BUTTON]]
+[[WEL_MULTIPLE_LINE_EDIT|WEL_MULTIPLE_LINE_EDIT]]
+[[WEL_SCROLL_BAR|WEL_SCROLL_BAR]] }} + + + + + + + diff --git a/documentation/18.11/solutions/platform-specifics/microsoft-windows/wel/wel-samples/ctlcolor.wiki b/documentation/18.11/solutions/platform-specifics/microsoft-windows/wel/wel-samples/ctlcolor.wiki new file mode 100644 index 00000000..54c68ffd --- /dev/null +++ b/documentation/18.11/solutions/platform-specifics/microsoft-windows/wel/wel-samples/ctlcolor.wiki @@ -0,0 +1,34 @@ +[[Property:title|Ctlcolor]] +[[Property:weight|-10]] +[[Property:uuid|0f9f5155-1c21-dd20-4810-32c105eeb02a]] +[[Image:ctlcolor|ctlcolor]]
+
+ +==Compiling== + +To compile the example: +* Launch EiffelStudio. +* Click '''Add project''' +* Browse to ''$ISE_EIFFEL\examples\wel\ctlcolor\''. +* Choose ''ctlcolor.ecf'' +* Choose the location where the project will be compiled, by default the same directory containing the configuration file. +* Click '''OK'''. + +==Running== + +After launching the program, you will see a window displayed as above. Clicking on the "Foreground color" button will display a color dialog which allows you to select a new foreground color for the controls. Clicking on the "Background color" button will display a color dialog which allows you to select a new background color for the controls. + +==Under the Hood== + +A [[ref:libraries/wel/reference/wel_color_control_chart|WEL_COLOR_CONTROL]] is used to retrieve the color selection of the user through the feature rgb_result which returns an object of type [[ref:libraries/wel/reference/wel_color_ref_chart|WEL_COLOR_REF]] . + +This sample contains the following classes: +* CTLCOLOR_DEMO +* MAIN_WINDOW +* MY_BUTTON +* PRECOMP_MAIN_WINDOW + + + + + diff --git a/documentation/18.11/solutions/platform-specifics/microsoft-windows/wel/wel-samples/cursors.wiki b/documentation/18.11/solutions/platform-specifics/microsoft-windows/wel/wel-samples/cursors.wiki new file mode 100644 index 00000000..a292722d --- /dev/null +++ b/documentation/18.11/solutions/platform-specifics/microsoft-windows/wel/wel-samples/cursors.wiki @@ -0,0 +1,34 @@ +[[Property:title|Cursors]] +[[Property:weight|-9]] +[[Property:uuid|2f1abcdd-182f-3fdf-27b9-861d1c2e2167]] +[[Image:cursors|cursors]]
+
+ +==Compiling== + +To compile the example: +* Launch EiffelStudio. +* Click '''Add project''' +* Browse to ''$ISE_EIFFEL\examples\wel\cursors\''. +* Choose ''cursors.ecf'' +* Choose the location where the project will be compiled, by default the same directory containing the configuration file. +* Click '''OK'''. +* After the example compiles, select menu path "Project -> Freeze..." to freeze the project. This is necessary to include the compiled resource (.rc) file. + +==Running== + +After launching the program, a window will be displayed as illustrated above. Selecting one of the cursor types from the "Cursors" menu will cause the selected cursor to be displayed when the mouse pointer is over the client area of the window. + +==Under the Hood== + +The feature on_menu_command has been redefined in MAIN_WINDOW to create the appropriate cursor when a menu selection is made, while on_set_cursor has been redefined to update the style of the displayed cursor. + +This sample contains the following classes: +* CURSORS_DEMO +* MAIN_WINDOW +* APPLICATION_IDS + + + + + diff --git a/documentation/18.11/solutions/platform-specifics/microsoft-windows/wel/wel-samples/disk-space.wiki b/documentation/18.11/solutions/platform-specifics/microsoft-windows/wel/wel-samples/disk-space.wiki new file mode 100644 index 00000000..e79c0ed9 --- /dev/null +++ b/documentation/18.11/solutions/platform-specifics/microsoft-windows/wel/wel-samples/disk-space.wiki @@ -0,0 +1,31 @@ +[[Property:title|Disk Space]] +[[Property:weight|-8]] +[[Property:uuid|09c90710-45c8-f674-376c-30ed0da738cd]] +[[Image:diskspace|diskspace]]
+
+ +==Compiling== + +To compile the example: +* Launch EiffelStudio. +* Click '''Add project''' +* Browse to ''$ISE_EIFFEL\examples\wel\diskspace\''. +* Choose ''diskspace.ecf'' +* Choose the location where the project will be compiled, by default the same directory containing the configuration file. +* Click '''OK'''. + +==Running== + +After launching the application, you will see text output showing the size and amount of free space available on each of your local drives. + +==Under the Hood== + +DISCSPACE_DEMO contains a once feature, diskspace which returns an instance of [[ref:libraries/wel/reference/wel_disk_space_chart|WEL_DISK_SPACE]] , used to query the local drives. + +This sample contains only one class: +* DISKSPACE_DEMO + + + + + diff --git a/documentation/18.11/solutions/platform-specifics/microsoft-windows/wel/wel-samples/fontenum.wiki b/documentation/18.11/solutions/platform-specifics/microsoft-windows/wel/wel-samples/fontenum.wiki new file mode 100644 index 00000000..fd5b2b74 --- /dev/null +++ b/documentation/18.11/solutions/platform-specifics/microsoft-windows/wel/wel-samples/fontenum.wiki @@ -0,0 +1,33 @@ +[[Property:title|Fontenum]] +[[Property:weight|-7]] +[[Property:uuid|7dbb5e5c-3e00-e4f6-9fc6-29ba4f2476d9]] +[[Image:fontenum|fontenum]]
+
+ +==Compiling== + +To compile the example: +* Launch EiffelStudio. +* Click '''Add project''' +* Browse to ''$ISE_EIFFEL\examples\wel\fontenum\''. +* Choose ''fontenum.ecf'' +* Choose the location where the project will be compiled, by default the same directory containing the configuration file. If you select another directory than the default one, please copy icons (*.ico) and resource files (*.rc) from the default directory (the one containing the ecf file) to the new one. +* Click '''OK'''. + +==Running== + +After launching the program, a window will be displayed as illustrated above. Selecting one of the available fonts (Listed on the left hand side) will cause a sample text to be displayed in the currently entered font size. Clicking the button marked "Close" will cause the program to end. + +==Under the Hood== + +MAIN_DIALOG inherits from [[ref:libraries/wel/reference/wel_main_dialog_chart|WEL_MAIN_DIALOG]] and also WEL_FONT_FAMILY_ENUMERATOR. MAIN_DIALOG implements action which was deferred from WEL_FONT_ENUMERATOR and executed every an enumeration finds a new font. This new implementation is used to display the available fonts in the [[ref:libraries/wel/reference/wel_list_view_chart|WEL_LIST_VIEW]] + +This sample contains the following classes: +* APPLICATION_IDS +* FONTENUM_DEMO +* MAIN_DIALOG + + + + + diff --git a/documentation/18.11/solutions/platform-specifics/microsoft-windows/wel/wel-samples/fun.wiki b/documentation/18.11/solutions/platform-specifics/microsoft-windows/wel/wel-samples/fun.wiki new file mode 100644 index 00000000..cb5bf3aa --- /dev/null +++ b/documentation/18.11/solutions/platform-specifics/microsoft-windows/wel/wel-samples/fun.wiki @@ -0,0 +1,32 @@ +[[Property:title|Fun]] +[[Property:weight|-6]] +[[Property:uuid|ad05362e-76a3-db98-a58d-d49f9f2b5f2a]] +[[Image:fun|fun]]
+
+ +==Compiling== + +To compile the example: +* Launch EiffelStudio. +* Click '''Add project''' +* Browse to ''$ISE_EIFFEL\examples\wel\fun\''. +* Choose ''fun.ecf'' +* Choose the location where the project will be compiled, by default the same directory containing the configuration file. +* Click '''OK'''. + +==Running== +After launching the program, a window will be displayed as illustrated above. Clicking the push button marked "Maze" will open a new window and draw a maze within this window. Clicking the push button marked "Artist" will open a new window, and display output dependent on the movement of the mouse pointer within the client area of that window. Clicking the push button marked "Fun" will open a new window which contains a fake error message and a close push button which moves when you try to move the mouse pointer over it. +==Under the Hood== +Both FUN_DIALOG and ARTIST redefine on_mouse_move to track the actions of the mouse pointer and respond accordingly. +This sample contains the following classes: +* APPLICATION_IDS +* ARTIST +* FUN_DEMO +* FUN_DIALOG +* MAIN_WINDOW +* MAZE + + + + + diff --git a/documentation/18.11/solutions/platform-specifics/microsoft-windows/wel/wel-samples/header-control.wiki b/documentation/18.11/solutions/platform-specifics/microsoft-windows/wel/wel-samples/header-control.wiki new file mode 100644 index 00000000..b6a3b73f --- /dev/null +++ b/documentation/18.11/solutions/platform-specifics/microsoft-windows/wel/wel-samples/header-control.wiki @@ -0,0 +1,34 @@ +[[Property:title|Header Control]] +[[Property:weight|-5]] +[[Property:uuid|9b2bee5f-8676-4f9f-c6e0-e00b44b3bef4]] +[[Image:header-ctrl|header_ctrl]]
+
+ +==Compiling== + +To compile the example: +* Launch EiffelStudio. +* Click '''Add project''' +* Browse to ''$ISE_EIFFEL\examples\wel\header_ctrl\''. +* Choose ''header_ctrl.ecf'' +* Choose the location where the project will be compiled, by default the same directory containing the configuration file. If you select another directory than the default one, please copy icons (*.ico) and resource files (*.rc) from the default directory (the one containing the ecf file) to the new one. +* Click '''OK'''. + +==Running== + +After launching the program, a window will be displayed as shown above. By manipulating the header control, you will see notification of the events that occur displayed in the [[ref:libraries/wel/reference/wel_list_view_chart|WEL_LIST_VIEW]] situated below. + +==Under the Hood== + +HEADER_CONTROL inherits [[ref:libraries/wel/reference/wel_header_control_chart|WEL_HEADER_CONTROL]] and redefines many of the `on_` notification features to display the output. + +This sample contains the following classes: +* APPLICATION_IDS +* HEADER_CONTROL +* HEADER_CONTROL_DEMO +* MAIN_WINDOW + + + + + diff --git a/documentation/18.11/solutions/platform-specifics/microsoft-windows/wel/wel-samples/hello-world.wiki b/documentation/18.11/solutions/platform-specifics/microsoft-windows/wel/wel-samples/hello-world.wiki new file mode 100644 index 00000000..4be0d825 --- /dev/null +++ b/documentation/18.11/solutions/platform-specifics/microsoft-windows/wel/wel-samples/hello-world.wiki @@ -0,0 +1,45 @@ +[[Property:title|Hello World!]] +[[Property:weight|-4]] +[[Property:uuid|37b82651-78e9-dd6a-97bf-0fe3c444157d]] +[[Image:hello|hello]]
+
+ +==Compiling== + +To compile the example: +* Launch EiffelStudio. +* Click '''Add project''' +* Browse to ''$ISE_EIFFEL\examples\wel\hello\''. +* Choose ''hello.ecf'' +* Choose the location where the project will be compiled, by default the same directory containing the configuration file. +* Click '''OK'''. + +==Running== + +After you launch the sample, You should see a window displayed as illustrated above. You will have full control over the window, and the program will quit when you close the window. + +==Under the Hood== + +MAIN_WINDOW inherits WEL_FRAME_WINDOW. In this example, we have redefined on_paint as shown below: + + on_paint (paint_dc: WEL_PAINT_DC; invalid_rect: WEL_RECT) + --Draw a centered text + do + paint_dc.draw_centered_text("Hello, World!", client_rect) + end + + +{{note|If you look at MAIN_WINDOW, you will see that it contains many features. However, nearly all of these are features are inherited from WEL_FRAME_WINDOW. }} + +This sample contains the following classes: +* HELLO_DEMO +* MAIN_WINDOW + + +{{seealso|
+[[Tutorial Step 3|Tutorial Step3]]
+[[Common message hooks|Common message hooks]] }} + + + + diff --git a/documentation/18.11/solutions/platform-specifics/microsoft-windows/wel/wel-samples/index.wiki b/documentation/18.11/solutions/platform-specifics/microsoft-windows/wel/wel-samples/index.wiki new file mode 100644 index 00000000..010fd334 --- /dev/null +++ b/documentation/18.11/solutions/platform-specifics/microsoft-windows/wel/wel-samples/index.wiki @@ -0,0 +1,8 @@ +[[Property:title|WEL Samples]] +[[Property:weight|4]] +[[Property:uuid|f6df9869-52b7-0d10-dd0c-52796f631998]] +There are a large number of samples provided with the WEL library, each designed to demonstrate different functionality. The samples available are listed below. + +{{note|If you are new to WEL programming, the recommended place to start is the set of samples called the [[WEL Tutorial]]. }} + + diff --git a/documentation/18.11/solutions/platform-specifics/microsoft-windows/wel/wel-samples/list-view.wiki b/documentation/18.11/solutions/platform-specifics/microsoft-windows/wel/wel-samples/list-view.wiki new file mode 100644 index 00000000..a1369569 --- /dev/null +++ b/documentation/18.11/solutions/platform-specifics/microsoft-windows/wel/wel-samples/list-view.wiki @@ -0,0 +1,39 @@ +[[Property:title|List View]] +[[Property:weight|-3]] +[[Property:uuid|709475e9-e01c-6ce7-942f-7dc6bf6f3bec]] +[[Image:list-view|list_view]]
+
+ +==Compiling== + +To compile the example: +* Launch EiffelStudio. +* Click '''Add project''' +* Browse to ''$ISE_EIFFEL\examples\wel\list_view\''. +* Choose ''list_view.ecf'' +* Choose the location where the project will be compiled, by default the same directory containing the configuration file. +* Click '''OK'''. + +==Running== +After launching the program, a window will be displayed containing a pair of [[ref:libraries/wel/reference/wel_list_view_chart|WEL_LIST_VIEW]] . Clicking the button marked "style" will modify the style of the lower list view. If you click the mouse within this lower list view, you will see notification of events appearing in the upper list view. +==Under the Hood== + +LISTVIEW_DEMO redefines init_application in order to load the [[ref:libraries/wel/reference/wel_common_controls_dll_chart|WEL_COMMON_CONTROLS_DLL]] and the [[ref:libraries/wel/reference/wel_rich_edit_dll_chart|WEL_RICH_EDIT_DLL]] . + +LISTVIEW redefines many of the `on_` features inherited from [[ref:libraries/wel/reference/wel_list_view_chart|WEL_LIST_VIEW]] in order to generate output for the user. + +The style of the LISTVIEW_DEMO is changed by calling set_style with the required new style. + +This sample contains the following classes: +* LISTVIEW +* MAIN_WINDOW +* LISTVIEW_DEMO +* APPLICATION_IDS + +{{seealso|
+WEL_LIST_VIEW }} + + + + + diff --git a/documentation/18.11/solutions/platform-specifics/microsoft-windows/wel/wel-samples/magnify.wiki b/documentation/18.11/solutions/platform-specifics/microsoft-windows/wel/wel-samples/magnify.wiki new file mode 100644 index 00000000..b6d9ae9a --- /dev/null +++ b/documentation/18.11/solutions/platform-specifics/microsoft-windows/wel/wel-samples/magnify.wiki @@ -0,0 +1,31 @@ +[[Property:title|Magnify]] +[[Property:weight|-2]] +[[Property:uuid|2c50fccc-2481-6f2d-d223-b4b246398636]] +[[Image:magnify|MAGNIFY]]
+
+ +==Compiling== + +To compile the example: +* Launch EiffelStudio. +* Click '''Add project''' +* Browse to ''$ISE_EIFFEL\examples\wel\magnify\''. +* Choose ''magnify.ecf'' +* Choose the location where the project will be compiled, by default the same directory containing the configuration file. +* Click '''OK'''. + +==Running== +After launching the application, you will see a window displayed with a similar appearance to the one above. Selecting "Quick reference..." from the "Help" menu will display the full instructions for using this application. +==Under the Hood== + +In order to be able to control the output of the sample, MAIN_WINDOW redefines many features from [[ref:libraries/wel/reference/wel_frame_window_chart|WEL_FRAME_WINDOW]] . The feature draw_zoom_rectangle is used to display the output and on_menu_command handles the notifications sent to the window when a menu_selection has been made. + +This sample contains the following classes: +* APPLICATION_IDS +* MAIN_WINDOW +* MAGNIFY_DEMO + + + + + diff --git a/documentation/18.11/solutions/platform-specifics/microsoft-windows/wel/wel-samples/mdi-multiple-document-interface.wiki b/documentation/18.11/solutions/platform-specifics/microsoft-windows/wel/wel-samples/mdi-multiple-document-interface.wiki new file mode 100644 index 00000000..e9acc377 --- /dev/null +++ b/documentation/18.11/solutions/platform-specifics/microsoft-windows/wel/wel-samples/mdi-multiple-document-interface.wiki @@ -0,0 +1,32 @@ +[[Property:title|MDI (Multiple Document Interface)]] +[[Property:weight|-1]] +[[Property:uuid|e5f4b1d5-31a1-51a3-46ea-3cf70a4b40d7]] +[[Image:mdi--mdi|mdi]]
+
+ +==Compiling== + +To compile the example: +* Launch EiffelStudio. +* Click '''Add project''' +* Browse to ''$ISE_EIFFEL\examples\wel\mdi\''. +* Choose ''mdi.ecf'' +* Choose the location where the project will be compiled, by default the same directory containing the configuration file. +* Click '''OK'''. + +==Running== +After launching the program, a window will be displayed as illustrated above. Selecting "New" from the "File" menu will create a new child window, while selecting "Close" will close the currently selected child window. The options available on the "Window" menu allow positioning of the child windows. Selecting "Exit" from the "File" menu or closing the window manually will exit the program. +==Under the Hood== +MAIN_WINDOW inherits [[ref:libraries/wel/reference/wel_mdi_frame_window_chart|WEL_MDI_FRAME_WINDOW]] to provide the multiple document interface behavior while each child window is of type [[ref:libraries/wel/reference/wel_mdi_child_window_chart|WEL_MDI_CHILD_WINDOW]] . When "Close" is selected from the "File" menu, the feature active_window from [[ref:libraries/wel/reference/wel_mdi_frame_window_chart|WEL_MDI_FRAME_WINDOW]] is used to select the window that must be closed. +This sample contains the following classes: +* APPLICATION_IDS +* MAIN_WINDOW +* MDI_DEMO + +{{seealso|
+[[Bmpview|Bmpview]] }} + + + + + diff --git a/documentation/18.11/solutions/platform-specifics/microsoft-windows/wel/wel-samples/minimal.wiki b/documentation/18.11/solutions/platform-specifics/microsoft-windows/wel/wel-samples/minimal.wiki new file mode 100644 index 00000000..e20b34ec --- /dev/null +++ b/documentation/18.11/solutions/platform-specifics/microsoft-windows/wel/wel-samples/minimal.wiki @@ -0,0 +1,31 @@ +[[Property:title|Minimal]] +[[Property:weight|1]] +[[Property:uuid|270db90c-dc2a-b6c4-8c2d-62a6657d01de]] +[[Image:minimal|minimal]]
+
+ +==Compiling== + +To compile the example: +* Launch EiffelStudio. +* Click '''Add project''' +* Browse to ''$ISE_EIFFEL\examples\wel\minimal\''. +* Choose ''minimal.ecf'' +* Choose the location where the project will be compiled, by default the same directory containing the configuration file. +* Click '''OK'''. + +==Running== +After launching the program, a window will be displayed as illustrated above. There is no other functionality, but clicking on the close icon (Cross in top right hand corner), will close the window. +==Under the Hood== +MINIMAL_DEMO inherits [[ref:libraries/wel/reference/wel_application_chart|WEL_APPLICATION]] and redefines main_window in order to display a [[ref:libraries/wel/reference/wel_frame_window_chart|WEL_FRAME_WINDOW]] . +This sample contains only one class: +* MINIMAL_DEMO + + +{{seealso|
+[[Tutorial Step 1|tutorial step 1]]
+[[ref:libraries/wel/reference/wel_frame_window_chart|WEL_FRAME_WINDOW]] }} + + + + diff --git a/documentation/18.11/solutions/platform-specifics/microsoft-windows/wel/wel-samples/pizza.wiki b/documentation/18.11/solutions/platform-specifics/microsoft-windows/wel/wel-samples/pizza.wiki new file mode 100644 index 00000000..02357152 --- /dev/null +++ b/documentation/18.11/solutions/platform-specifics/microsoft-windows/wel/wel-samples/pizza.wiki @@ -0,0 +1,33 @@ +[[Property:title|Pizza]] +[[Property:weight|2]] +[[Property:uuid|5375fdad-ab5e-7f6e-ef44-a4f34d137231]] +=Pizza Sample= + [[Image:pizza|pizza]]
+
+ +==Compiling== + +To compile the example: +* Launch EiffelStudio. +* Click '''Add project''' +* Browse to ''$ISE_EIFFEL\examples\wel\pizza\''. +* Choose ''pizza.ecf'' +* Choose the location where the project will be compiled, by default the same directory containing the configuration file. +* Click '''OK'''. + +==Running== + +After launching the program, a window will be displayed titled "WEL Pizza" If you select "Order" from the "Pizza" menu, a new window will appear (Illustrated above), which allows you to enter details of a new pizza order. When the order is completed, clicking the "ok" button will display the details of the order that was entered. Selecting "Exit from the "Pizza" menu or closing the original window will exit the program. + +==Under the Hood== +MAIN_WINDOW inherits [[ref:libraries/wel/reference/wel_frame_window_chart|WEL_FRAME_WINDOW]] while DIALOG inherits [[ref:libraries/wel/reference/wel_modal_dialog_chart|WEL_MODAL_DIALOG]] . DIALOG demonstrates the use of a selection of common controls to build a custom user interface. +This sample contains the following classes: +* APPLICATION_IDS +* DIALOG +* MAIN_WINDOW +* PIZZA_DEMO + + + + + diff --git a/documentation/18.11/solutions/platform-specifics/microsoft-windows/wel/wel-samples/printer.wiki b/documentation/18.11/solutions/platform-specifics/microsoft-windows/wel/wel-samples/printer.wiki new file mode 100644 index 00000000..8d36f706 --- /dev/null +++ b/documentation/18.11/solutions/platform-specifics/microsoft-windows/wel/wel-samples/printer.wiki @@ -0,0 +1,34 @@ +[[Property:title|Printer]] +[[Property:weight|3]] +[[Property:uuid|ee50d48e-4f39-adbc-1f69-1f9d9ef6e101]] +[[Image:printer|printer]]
+
+ +==Compiling== + +To compile the example: +* Launch EiffelStudio. +* Click '''Add project''' +* Browse to ''$ISE_EIFFEL\examples\wel\printer\''. +* Choose ''printer.ecf'' +* Choose the location where the project will be compiled, by default the same directory containing the configuration file. +* Click '''OK'''. + +==Running== + +After launching the program, a window will be displayed as illustrated above. Selecting "Print" from the "File" menu will open a print dialog which will allow you to specify a printer and additional print information before printing the contents of the window. + +==Under the Hood== +MAIN_WINDOW inherits [[ref:libraries/wel/reference/wel_frame_window_chart|WEL_FRAME_WINDOW]] and the feature on_paint has been redefined to display the output in the client area. A [[WEL_PRINT_DIALOG|WEL_PRINT_DIALOG]] is used to retrieve the print options before the printing occurs through the interface provided by a [[ref:libraries/wel/reference/wel_printer_dc_chart|WEL_PRINTER_DC]] . +This sample contains the following classes: +* APPLICATION_IDS +* MAIN_WINDOW +* PRINTER_DEMO + +{{seealso|
+[[WEL_PRINT_DIALOG|WEL_PRINT_DIALOG]] }} + + + + + diff --git a/documentation/18.11/solutions/platform-specifics/microsoft-windows/wel/wel-samples/rich-edit.wiki b/documentation/18.11/solutions/platform-specifics/microsoft-windows/wel/wel-samples/rich-edit.wiki new file mode 100644 index 00000000..44c43569 --- /dev/null +++ b/documentation/18.11/solutions/platform-specifics/microsoft-windows/wel/wel-samples/rich-edit.wiki @@ -0,0 +1,43 @@ +[[Property:title|Rich Edit]] +[[Property:weight|4]] +[[Property:uuid|d0a35ffd-a253-406f-ba15-c78400e8acd5]] +[[Image:richedit|richedit]]
+
+ +==Compiling== + +To compile the example: +* Launch EiffelStudio. +* Click '''Add project''' +* Browse to ''$ISE_EIFFEL\examples\wel\richedit\''. +* Choose ''richedit.ecf'' +* Choose the location where the project will be compiled, by default the same directory containing the configuration file. +* Click '''OK'''. + +==Running== + +After launching the program, a window will be displayed as shown above. The program is a simple text editor which allows you to load and save files; select fonts and colors; and print files. The operations are accessible through the menu bar and/or the tool bar. + +==Under the Hood== + +Both the menu items and the tool bar buttons are handled by on_menu_command which has been redefined in MAIN_WINDOW. + +Four of the [[stddlgs cluster|standard dialogs]] provided by WEL are used to receive input from the user. +This sample contains the following classes: +* APPLICATION_IDS +* MAIN_WINDOW +* RICHEDIT_DEMO + +{{seealso|
+[[ref:libraries/wel/reference/wel_rich_edit_chart|WEL_RICH_EDIT]]
+[[WEL_PRINT_DIALOG|WEL_PRINT_DIALOG]]
+[[WEL_SAVE_FILE_DIALOG|WEL_SAVE_FILE_DIALOG]]
+[[WEL_OPEN_FILE_DIALOG|WEL_OPEN_FILE_DIALOG]]
+[[WEL_CHOOSE_COLOR_DIALOG|WEL_CHOOSE_COLOR_DIALOG]]
+[[WEL_CHOOSE_FONT_DIALOG|WEL_CHOOSE_FONT_DIALOG]] }} + + + + + + diff --git a/documentation/18.11/solutions/platform-specifics/microsoft-windows/wel/wel-samples/split-area.wiki b/documentation/18.11/solutions/platform-specifics/microsoft-windows/wel/wel-samples/split-area.wiki new file mode 100644 index 00000000..12166c53 --- /dev/null +++ b/documentation/18.11/solutions/platform-specifics/microsoft-windows/wel/wel-samples/split-area.wiki @@ -0,0 +1,34 @@ +[[Property:title|Split Area]] +[[Property:weight|5]] +[[Property:uuid|b53ef206-7cda-5f27-649c-e43b47688061]] +[[Image:splitarea|splitarea]]
+
+ +==Compiling== + +To compile the example: +* Launch EiffelStudio. +* Click '''Add project''' +* Browse to ''$ISE_EIFFEL\examples\wel\splitarea\''. +* Choose ''split_area.ecf'' +* Choose the location where the project will be compiled, by default the same directory containing the configuration file. +* Click '''OK'''. + +==Running== +After launching the program, a window will be displayed containing a pair of [[ref:libraries/wel/reference/wel_rich_edit_chart|WEL_RICH_EDIT]] in a split area. Clicking the mouse on the split area (between the two rich edits) and dragging the mouse, will adjust the split area and its content accordingly. +==Under the Hood== + +There is no split area class provided with WEL, but WEL_SPLIT_AREA was created for this sample to illustrate how new controls can be built when required. Redefining some of the `on_` features inherited from [[ref:libraries/wel/reference/wel_window_chart|WEL_WINDOW]] in WEL_SPLIT_AREA shows how the control over the contents of the split area is achieved. + +This sample contains the following classes: +* APPLICATION +* SPLIT_AREA_DEMO +* WEL_SPLIT_AREA + + +{{seealso|
+[[ref:libraries/wel/reference/wel_rich_edit_chart|WEL_RICH_EDIT]] }} + + + + diff --git a/documentation/18.11/solutions/platform-specifics/microsoft-windows/wel/wel-samples/standard-dialogs-sample.wiki b/documentation/18.11/solutions/platform-specifics/microsoft-windows/wel/wel-samples/standard-dialogs-sample.wiki new file mode 100644 index 00000000..a83ce65d --- /dev/null +++ b/documentation/18.11/solutions/platform-specifics/microsoft-windows/wel/wel-samples/standard-dialogs-sample.wiki @@ -0,0 +1,35 @@ +[[Property:title|Standard Dialogs Sample]] +[[Property:weight|6]] +[[Property:uuid|0d706af1-8c76-64b3-5907-0d9effb2bb8f]] +[[Image:stddlgs|stddlgs]]
+
+ +==Compiling== + +To compile the example: +* Launch EiffelStudio. +* Click '''Add project''' +* Browse to ''$ISE_EIFFEL\examples\wel\stddlgs\''. +* Choose ''stddlgs.ecf'' +* Choose the location where the project will be compiled, by default the same directory containing the configuration file. +* Click '''OK'''. + +==Running== +After launching the program, a window will displayed with a menu allowing you to select some of the standard dialogs provided by WEL. +==Under the Hood== +on_menu_command has been redefined in MAIN_WINDOW to display a different standard dialog when each of the menu items is selected. +This sample contains the following classes: +* APPLICATION_IDS +* MAIN_WINDOW +* STDDLG_DEMO + +{{seealso|
+[[WEL_OPEN_FILE_DIALOG|WEL_OPEN_FILE_DIALOG]]
+[[WEL_CHOOSE_FONT_DIALOG|WEL_CHOOSE_FONT_DIALOG]]
+[[WEL_CHOOSE_COLOR_DIALOG|WEL_CHOOSE_COLOR_DIALOG]]
+[[WEL_PRINT_DIALOG|WEL_PRINT_DIALOG]] }} + + + + + diff --git a/documentation/18.11/solutions/platform-specifics/microsoft-windows/wel/wel-samples/timer.wiki b/documentation/18.11/solutions/platform-specifics/microsoft-windows/wel/wel-samples/timer.wiki new file mode 100644 index 00000000..f0be5f88 --- /dev/null +++ b/documentation/18.11/solutions/platform-specifics/microsoft-windows/wel/wel-samples/timer.wiki @@ -0,0 +1,29 @@ +[[Property:title|Timer]] +[[Property:weight|7]] +[[Property:uuid|ec5895ca-5d09-292f-f5dc-4787d3495bae]] +[[Image:timer|timer]]
+
+ +==Compiling== + +To compile the example: +* Launch EiffelStudio. +* Click '''Add project''' +* Browse to ''$ISE_EIFFEL\examples\wel\timer\''. +* Choose ''timer.ecf'' +* Choose the location where the project will be compiled, by default the same directory containing the configuration file. +* Click '''OK'''. + +==Running== +After launching the program, a window will be displayed as illustrated above. Clicking on any of the push buttons marked "Start Timer" will start a timer running, and the hatched area immediately above the push button will change its appearance to reflect the interval of the timer. +==Under the Hood== +A [[ref:libraries/wel/reference/wel_window_chart|WEL_WINDOW]] supports multiple timers, set by set_timer which takes a unique id for each timer. The on_timer feature is called every time a timer interval is reached with an argument corresponding to the id of the timer. Within MAIN_WINDOW, on_timer has been redefined to update the appearance of the hatched areas. +This sample contains the following classes: +* APPLICATION_IDS +* MAIN_WINDOW +* TIMER + + + + + diff --git a/documentation/18.11/solutions/platform-specifics/microsoft-windows/wel/wel-samples/tree-view-sample.wiki b/documentation/18.11/solutions/platform-specifics/microsoft-windows/wel/wel-samples/tree-view-sample.wiki new file mode 100644 index 00000000..4120bee0 --- /dev/null +++ b/documentation/18.11/solutions/platform-specifics/microsoft-windows/wel/wel-samples/tree-view-sample.wiki @@ -0,0 +1,37 @@ +[[Property:title|Tree View Sample]] +[[Property:weight|8]] +[[Property:uuid|31c64f11-3aa4-cfff-b9f3-09027acfc143]] +[[Image:tree-view--tree-view|tree_view]]
+
+ +==Compiling== + +To compile the example: +* Launch EiffelStudio. +* Click '''Add project''' +* Browse to ''$ISE_EIFFEL\examples\wel\tree_view\''. +* Choose ''tree_view.ecf'' +* Choose the location where the project will be compiled, by default the same directory containing the configuration file. +* Click '''OK'''. + +==Running== + +After launching the program, a window will be displayed as illustrated above. Selecting or expanding one of the tree items will cause notification to be displayed in the list at the top of the window. Various other notifications are also displayed, such as pressing a key in the tree. + +==Under the Hood== + +TREEVIEW inherits [[ref:libraries/wel/reference/wel_tree_view_chart|WEL_TREE_VIEW]] and redefines make to initialize items within the tree. A [[ref:libraries/wel/reference/wel_tree_view_insert_struct_chart|WEL_TREE_VIEW_INSERT_STRUCT]] is used to insert each [[ref:libraries/wel/reference/wel_tree_view_item_chart|WEL_TREE_VIEW_ITEM]] while a [[ref:libraries/wel/reference/wel_image_list_chart|WEL_IMAGE_LIST]] is used to reference images within the tree. +This sample contains the following classes: +* TREEVIEW +* MAIN_WINDOW +* TREEVIEW_DEMO +* APPLICATION_IDS + +{{seealso|
+[[ref:libraries/wel/reference/wel_tree_view_chart|WEL_TREE_VIEW]] }} + + + + + + diff --git a/documentation/18.11/solutions/platform-specifics/microsoft-windows/wel/wel-samples/unicode-sample.wiki b/documentation/18.11/solutions/platform-specifics/microsoft-windows/wel/wel-samples/unicode-sample.wiki new file mode 100644 index 00000000..75280aff --- /dev/null +++ b/documentation/18.11/solutions/platform-specifics/microsoft-windows/wel/wel-samples/unicode-sample.wiki @@ -0,0 +1,43 @@ +[[Property:title|Unicode Sample]] +[[Property:weight|9]] +[[Property:uuid|9905de6c-3f13-1c31-2f8c-efddd71abc6d]] +[[Image:unicode|unicode]]
+
+ +==Requirements== + +This sample demonstrates Unicode compatibility. It therefore assumes a fully Unicode compatible operating system and recommends the system has more than one input locale installed. The system used to generate the above screenshot shows the sample running on Windows 2000 with the Korean IME installed. Since Windows 95/98/Me does not provide full built-in support for Unicode please refer to "Compiling WEL for Unicode on Windows 95/98/Me" before attempting to run this example. + +==Compiling== + +To compile the example: +* Launch EiffelStudio. +* Click '''Add project''' +* Browse to ''$ISE_EIFFEL\examples\wel\unicode\''. +* Choose ''unicode.ecf'' +* Choose the location where the project will be compiled, by default the same directory containing the configuration file. +* Click '''OK'''. + +==Running== + +After launching the program, a window will be displayed as illustrated above. Selecting the input locale combo box will allow you to switch to a new input locale. To add new input locales to your system do the following: +* Click on '''Start''' -> '''Settings''' -> '''Control Panel''' -> '''Regional Options''' +* Select the ''' Input Locale''' tab and click '''Add'''. +* Select the input locale then click '''OK''' +* To test the new input locale restart the Unicode sample. +Selecting an input locale allows entry of the chosen input locale characters into the rich-edit control to right. Clicking the "Apply to Controls" button will update the controls in the pane below to display the same text as the rich-edit control. If the selected input locale is associated with an Input Method Editor (IME), the details for this will be displayed in the "Input Method Editor" group box and IME specific options will be made available from the "IME Options" menu. + +==Under the Hood== + +There is one MAIN_WINDOW class used for all the controls. The feature init_locale_list is used to determine the systems available input locales and populate the corresponding "Input Locales" combo box. The features 'change_font' and 'change_control' are used to change the applications font (in case the currently selected font does not correctly display Unicode characters), and to set the text property of all controls to the same as that in the rich-edit box. +This sample contains the following classes: +* UNICODE_DEMO +* MAIN_WINDOW +* DISPLAY_TEXT +* APPLICATION_IDS + + + + + + diff --git a/documentation/18.11/solutions/platform-specifics/microsoft-windows/wel/wel-samples/wel-sample-menus.wiki b/documentation/18.11/solutions/platform-specifics/microsoft-windows/wel/wel-samples/wel-sample-menus.wiki new file mode 100644 index 00000000..522d066e --- /dev/null +++ b/documentation/18.11/solutions/platform-specifics/microsoft-windows/wel/wel-samples/wel-sample-menus.wiki @@ -0,0 +1,28 @@ +[[Property:title|Wel Sample: Menus]] +[[Property:weight|0]] +[[Property:uuid|9cd62273-3624-fc6c-44d5-c42150d9b684]] +[[Image:menus|menus]]
+
+ +==Compiling== + +To compile the example: +* Launch EiffelStudio. +* Click '''Add project''' +* Browse to ''$ISE_EIFFEL\examples\wel\menus\''. +* Choose ''menus.ecf'' +* Choose the location where the project will be compiled, by default the same directory containing the configuration file. +* Click '''OK'''. + +==Running== +After launching the program, you will see a window displayed with a similar appearance to the one displayed above. If you right click in the client area of the window, a menu will pop up at the cursor position. The same menu is also accessible from the "File" menu. Selecting any of the menu options will display a notification of which option was selected. +==Under the Hood== +A [[ref:libraries/wel/reference/wel_menu_chart|WEL_MENU]] is used for the menu's in this sample. The feature show_track is used to display the menu at the cursor position and a [[ref:libraries/wel/reference/wel_msg_box_chart|WEL_MSG_BOX]] is used to display the notification when a menu selection has occurred. +This sample contains the following classes: +* MAIN_WINDOW +* MENUS_DEMO + + + + + diff --git a/documentation/18.11/solutions/platform-specifics/microsoft-windows/wel/wel-samples/windows-sample.wiki b/documentation/18.11/solutions/platform-specifics/microsoft-windows/wel/wel-samples/windows-sample.wiki new file mode 100644 index 00000000..00d87ef9 --- /dev/null +++ b/documentation/18.11/solutions/platform-specifics/microsoft-windows/wel/wel-samples/windows-sample.wiki @@ -0,0 +1,36 @@ +[[Property:title|Windows Sample]] +[[Property:weight|10]] +[[Property:uuid|3ace1338-c85b-c7d8-faaf-52e9fb4e157e]] +[[Image:windows|windows]]
+
+ +==Compiling== + +To compile the example: +* Launch EiffelStudio. +* Click '''Add project''' +* Browse to ''$ISE_EIFFEL\examples\wel\windows\''. +* Choose ''windows.ecf'' +* Choose the location where the project will be compiled, by default the same directory containing the configuration file. +* Click '''OK'''. + +==Running== + +After launching the program, a window will appear with a custom ON_OFF_CONTROL control displayed. Clicking on this control will cause its state to change. If you select one of the options from the "Windows" menu, that type of window will be displayed. +==Under the Hood== + +The ON_OFF_CONTROL inherits [[ref:libraries/wel/reference/wel_control_window_chart|WEL_CONTROL_WINDOW]] and demonstrates how to build your controls. The classes MODAL and MODELESS inherit [[ref:libraries/wel/reference/wel_modal_dialog_chart|WEL_MODAL_DIALOG]] and [[ref:libraries/wel/reference/wel_modeless_dialog_chart|WEL_MODELESS_DIALOG]] respectively. + +This sample contains the following classes: +* APPLICATION_IDS +* MAIN_WINDOW +* MODAL +* MODELESS +* ON_OFF_CONTROL +* WINDOWS_DEMO + + + + + + diff --git a/documentation/18.11/solutions/platform-specifics/microsoft-windows/wel/wel-samples/xcell.wiki b/documentation/18.11/solutions/platform-specifics/microsoft-windows/wel/wel-samples/xcell.wiki new file mode 100644 index 00000000..2e864281 --- /dev/null +++ b/documentation/18.11/solutions/platform-specifics/microsoft-windows/wel/wel-samples/xcell.wiki @@ -0,0 +1,36 @@ +[[Property:title|Xcell]] +[[Property:weight|11]] +[[Property:uuid|b48ed2d1-d91f-e288-5705-7a6bfa612c29]] +[[Image:xcell|xcell]]
+
+ +==Compiling== + +* Launch EiffelStudio. +* Click '''Add project''' +* Browse to ''$ISE_EIFFEL\examples\wel\xcell\''. +* Choose ''xcell.ecf'' +* Choose the location where the project will be compiled, by default the same directory containing the configuration file. +* Click '''OK'''. + + +==Running== +After launching the program, a window will be displayed. Selecting "New" from the "Game" menu or pressing F2, will cause a new game to start and the window should take a similar appearance to the above illustration. Selecting "How to play..." from the "Help" menu will display the instructions for playing the game. +==Under the Hood== + +This sample contains the following classes: +* APP_CONSTANTS +* CARD +* COLUMN +* GAME +* GAME_CONSTANTS +* GAME_MANAGER +* MAIN_WINDOW +* SELECT_GAME_NUMBER_DIALOG +* SELECT_NUMBER_OF_CARDS_DIALOG +* XCELL_DEMO + + + + + diff --git a/documentation/18.11/solutions/platform-specifics/microsoft-windows/wel/wel-samples/xy-co-ordinates.wiki b/documentation/18.11/solutions/platform-specifics/microsoft-windows/wel/wel-samples/xy-co-ordinates.wiki new file mode 100644 index 00000000..c85b8c5d --- /dev/null +++ b/documentation/18.11/solutions/platform-specifics/microsoft-windows/wel/wel-samples/xy-co-ordinates.wiki @@ -0,0 +1,35 @@ +[[Property:title|XY Co-ordinates]] +[[Property:weight|12]] +[[Property:uuid|f0b46125-2954-1504-0f47-c023462957f3]] +[[Image:xy|xy]]
+
+ +==Compiling== + +To compile the example: +* Launch EiffelStudio. +* Click '''Add project''' +* Browse to ''$ISE_EIFFEL\examples\wel\xy\''. +* Choose ''xy.ecf'' +* Choose the location where the project will be compiled, by default the same directory containing the configuration file. +* Click '''OK'''. + +==Running== +After launching the sample, you should see a [[ref:libraries/wel/reference/wel_frame_window_chart|WEL_FRAME_WINDOW]] displayed. If you click the left mouse button in the client area of the window, the coordinates of the click (Relative to the top left of the client area), will be displayed. Clicking the [[ref:libraries/wel/reference/wel_push_button_chart|WEL_PUSH_BUTTON]] marked "Clear" will clear the client area of the window. +==Under the Hood== + +A [[ref:libraries/wel/reference/wel_client_dc_chart|WEL_CLIENT_DC]] is used to display output in the client area of the window during the execution of on_left_button_down which has been redefined in MAIN_WINDOW. + +This sample contains the following classes: +* XY_DEMO +* MAIN_WINDOW + + +{{seealso|
+[[Tutorial Step 3|tutorial_step3]]
+[[WEL_PUSH_BUTTON|WEL_PUSH_BUTTON]]
+}} + + + + diff --git a/documentation/18.11/solutions/platform-specifics/microsoft-windows/wel/wel-tutorial/index.wiki b/documentation/18.11/solutions/platform-specifics/microsoft-windows/wel/wel-tutorial/index.wiki new file mode 100644 index 00000000..2f6df39e --- /dev/null +++ b/documentation/18.11/solutions/platform-specifics/microsoft-windows/wel/wel-tutorial/index.wiki @@ -0,0 +1,16 @@ +[[Property:title|WEL Tutorial]] +[[Property:weight|2]] +[[Property:uuid|68faa545-c658-ad5e-ca6f-ab693a7aabf8]] +WEL is shipped with a tutorial among its sample programs. This tutorial shows you how to develop a simple WEL application and contains eight different samples listed below: +* [[Tutorial Step 1|Step1]] - A Basic WEL Application. +* [[Tutorial Step 2|Step2]] - Responding to an event. +* [[Tutorial Step 3|Step3]] - Displaying output on a WEL_CLIENT_DC. +* [[Tutorial Step 4|Step4]] - A very basic drawing program. +* [[Tutorial Step 5|Step5]] - Using a WEL_MODAL_DIALOG. +* [[Tutorial Step 6|Step6]] - Re-drawing a window by redefining on_paint. +* [[Tutorial Step 7|Step7]] - Adding menus. +* [[Tutorial Step 8|Step8]] - Using a WEL_OPEN_FILE_DIALOG and a WEL_SAVE_FILE_DIALOG. + + + + diff --git a/documentation/18.11/solutions/platform-specifics/microsoft-windows/wel/wel-tutorial/tutorial-step-1.wiki b/documentation/18.11/solutions/platform-specifics/microsoft-windows/wel/wel-tutorial/tutorial-step-1.wiki new file mode 100644 index 00000000..bf15de38 --- /dev/null +++ b/documentation/18.11/solutions/platform-specifics/microsoft-windows/wel/wel-tutorial/tutorial-step-1.wiki @@ -0,0 +1,37 @@ +[[Property:title|Tutorial Step 1]] +[[Property:weight|0]] +[[Property:uuid|b952d232-1ef9-04a8-bac4-117185aa316d]] +This sample shows you how to set up your first [[ref:libraries/wel/reference/wel_application_chart|WEL_APPLICATION]] consisting of a single [[ref:libraries/wel/reference/wel_frame_window_chart|WEL_FRAME_WINDOW]] . This is one of the simplest WEL applications you can write, and the output is shown below: + +[[Image:step1|step1]] +
+ +==Compiling== + +* Launch EiffelStudio. +* Click '''Add project''' +* Browse to ''$ISE_EIFFEL\examples\wel\tutorial\step1\''. +* Choose ''tutorial_step1.ecf'' +* Choose the location where the project will be compiled, by default the same directory containing the configuration file. +* Click '''OK'''. + + +==Running== + +After you launch the sample, You should see the window displayed in the screen as illustrated above. You will have full control over the window, and the program will quit when you close the window. + +{{note|The size and shape of the window may be different on your machine. }} + +==Under the Hood== + +Although this system does nothing except create and display a [[ref:libraries/wel/reference/wel_frame_window_chart|WEL_FRAME_WINDOW]] , it shows how to set up your first [[ref:libraries/wel/reference/wel_application_chart|WEL_APPLICATION]] . + +This sample only contains one class, TUTORIAL_STEP1 which inherits [[ref:libraries/wel/reference/wel_application_chart|WEL_APPLICATION]] and redefines main_window + +{{seealso|
+[[Inheriting WEL_APPLICATION|Inheriting WEL application]]
+[[Redefining main_window|Redefining main_window]] }} + + + + diff --git a/documentation/18.11/solutions/platform-specifics/microsoft-windows/wel/wel-tutorial/tutorial-step-2.wiki b/documentation/18.11/solutions/platform-specifics/microsoft-windows/wel/wel-tutorial/tutorial-step-2.wiki new file mode 100644 index 00000000..f979a497 --- /dev/null +++ b/documentation/18.11/solutions/platform-specifics/microsoft-windows/wel/wel-tutorial/tutorial-step-2.wiki @@ -0,0 +1,40 @@ +[[Property:title|Tutorial Step 2]] +[[Property:weight|1]] +[[Property:uuid|f4a73538-8a2f-ce6b-5190-6bd4d0e8c8d1]] +This sample shows you how to respond to an event occurring within your application. It also demonstrates the use of a [[ref:libraries/wel/reference/wel_msg_box_chart|WEL_MSG_BOX]] control and a redefinition of closeable from [[ref:libraries/wel/reference/wel_composite_window_chart|WEL_COMPOSITE_WINDOW]] . + +[[Image:step2|step2]]
+
+ +==Compiling== + +* Launch EiffelStudio. +* Click '''Add project''' +* Browse to ''$ISE_EIFFEL\examples\wel\tutorial\step2\''. +* Choose ''tutorial_step2.ecf'' +* Choose the location where the project will be compiled, by default the same directory containing the configuration file. +* Click '''OK'''. + + +==Running== + +After launching the sample, you should see a [[ref:libraries/wel/reference/wel_frame_window_chart|WEL_FRAME_WINDOW]] displayed. If you click the left mouse button in the client area of the window, a [[ref:libraries/wel/reference/wel_msg_box_chart|WEL_MSG_BOX]] will appear, notifying you of your click. + +==Under the Hood== + +This system is a demonstration of how to connect an event to one of the common message hooks available within WEL. See [[WEL Common Concepts|Common message hooks]] for more information. In this example, on_left_button_down has been redefined from [[ref:libraries/wel/reference/wel_window_chart|WEL_WINDOW]] to display a [[ref:libraries/wel/reference/wel_msg_box_chart|WEL_MSG_BOX]] containing notification of the event occurring. + +If you look at closeable from MAIN_WINDOW, you will see that it has been redefined to display a [[ref:libraries/wel/reference/wel_msg_box_chart|WEL_MSG_BOX]] and the result from this message box is used to generate the return value of closeable. If this Result is True, the window will be closed. +This sample contains the following classes: +* TUTORIAL_STEP2 +* MAIN_WINDOW + + +{{seealso|
+[[WEL Common Concepts|Common message hooks]]
+}} + + + + + diff --git a/documentation/18.11/solutions/platform-specifics/microsoft-windows/wel/wel-tutorial/tutorial-step-3.wiki b/documentation/18.11/solutions/platform-specifics/microsoft-windows/wel/wel-tutorial/tutorial-step-3.wiki new file mode 100644 index 00000000..408391be --- /dev/null +++ b/documentation/18.11/solutions/platform-specifics/microsoft-windows/wel/wel-tutorial/tutorial-step-3.wiki @@ -0,0 +1,38 @@ +[[Property:title|Tutorial Step 3]] +[[Property:weight|2]] +[[Property:uuid|7d79155a-fe75-e252-49d7-b03243ac96fd]] +This sample demonstrates the use of a [[ref:libraries/wel/reference/wel_client_dc_chart|WEL_CLIENT_DC]] to display output in the MAIN_WINDOW. The output is shown below: + +[[Image:step3|step3]]
+
+ +==Compiling== + +* Launch EiffelStudio. +* Click '''Add project''' +* Browse to ''$ISE_EIFFEL\examples\wel\tutorial\step3\''. +* Choose ''tutorial_step3.ecf'' +* Choose the location where the project will be compiled, by default the same directory containing the configuration file. +* Click '''OK'''. + + +==Running== +After launching the sample, you should see a [[ref:libraries/wel/reference/wel_frame_window_chart|WEL_FRAME_WINDOW]] displayed . If you click the left mouse button in the client area of the window, the coordinates of the click (Relative to the top left of the client area), will be displayed. Clicking the right mouse button in the client area will clear the window. +==Under the Hood== + +This system is a demonstration of how to gain access to the client area of a window using a [[ref:libraries/wel/reference/wel_client_dc_chart|WEL_CLIENT_DC]] . The creation procedure of the DC takes a WEL_WINDOW as an argument, and in this sample, we pass the MAIN_WINDOW. Using this DC, it is a simple step to output the position of the mouse which is provided as arguments to on_left_button_down. + +on_right_button_down has also been redefined to call invalidate which clears the client area of the window. +This sample contains the following classes: +* TUTORIAL_STEP3 +* MAIN_WINDOW + + +{{seealso|
+[[Common message hooks|Common message hooks]]
+}} + + + + + diff --git a/documentation/18.11/solutions/platform-specifics/microsoft-windows/wel/wel-tutorial/tutorial-step-4.wiki b/documentation/18.11/solutions/platform-specifics/microsoft-windows/wel/wel-tutorial/tutorial-step-4.wiki new file mode 100644 index 00000000..d5e00ced --- /dev/null +++ b/documentation/18.11/solutions/platform-specifics/microsoft-windows/wel/wel-tutorial/tutorial-step-4.wiki @@ -0,0 +1,32 @@ +[[Property:title|Tutorial Step 4]] +[[Property:weight|3]] +[[Property:uuid|a43c069c-d56e-47f0-f1b0-d58df627b5a4]] +This sample builds on the knowledge learned in the previous tutorials ( [[Tutorial Step 1|1]] , [[Tutorial Step 2|2]] and [[Tutorial Step 3|3]] ) and again demonstrates the use of a [[ref:libraries/wel/reference/wel_client_dc_chart|WEL_CLIENT_DC]] . + +[[Image:step4|step4]]
+
+ +==Compiling== + +* Launch EiffelStudio. +* Click '''Add project''' +* Browse to ''$ISE_EIFFEL\examples\wel\tutorial\step4\''. +* Choose ''tutorial_step4.ecf'' +* Choose the location where the project will be compiled, by default the same directory containing the configuration file. +* Click '''OK'''. + + +==Running== +After launching the sample, you will see a [[ref:libraries/wel/reference/wel_frame_window_chart|WEL_FRAME_WINDOW]] displayed. By holding down the left mouse button, and moving the mouse (Within the client area of the window), you will be able to draw on the client area of the window. Pressing the right mouse button within the window will clear the client area of the window. +==Under the Hood== + +This system is an improvement over tutorial [[Tutorial Step 3|step3]] and only uses WEL techniques demonstrated in previous tutorials to allow you to draw on the client DC of the window. + +This sample contains the following classes: +* TUTORIAL_STEP4 +* MAIN_WINDOW + + + + + diff --git a/documentation/18.11/solutions/platform-specifics/microsoft-windows/wel/wel-tutorial/tutorial-step-5.wiki b/documentation/18.11/solutions/platform-specifics/microsoft-windows/wel/wel-tutorial/tutorial-step-5.wiki new file mode 100644 index 00000000..9a44a94b --- /dev/null +++ b/documentation/18.11/solutions/platform-specifics/microsoft-windows/wel/wel-tutorial/tutorial-step-5.wiki @@ -0,0 +1,36 @@ +[[Property:title|Tutorial Step 5]] +[[Property:weight|4]] +[[Property:uuid|05145328-5d2a-4d48-68cc-746ddf66b68f]] +The sample builds on tutorial [[Tutorial Step 4|step 4]] and also demonstrates the use of a [[ref:libraries/wel/reference/wel_modal_dialog_chart|WEL_MODAL_DIALOG]] . The output is shown below: + +[[Image:step5|step5]]
+
+ +==Compiling== + +* Launch EiffelStudio. +* Click '''Add project''' +* Browse to ''$ISE_EIFFEL\examples\wel\tutorial\step5\''. +* Choose ''tutorial_step5.ecf'' +* Choose the location where the project will be compiled, by default the same directory containing the configuration file. +* Click '''OK'''. + + +==Running== + +After launching the sample, you will see a [[ref:libraries/wel/reference/wel_frame_window_chart|WEL_FRAME_WINDOW]] displayed. By holding down the left mouse button, and moving the mouse (Within the client area of the window), you will be able to draw on the client are of the window. If you press the right mouse button, a [[ref:libraries/wel/reference/wel_modal_dialog_chart|WEL_MODAL_DIALOG]] will pop up which allows you to enter the thickness of the line that is drawn. + +==Under the Hood== + +This system builds on tutorial [[Tutorial Step 4|step 4]] by adding a [[ref:libraries/wel/reference/wel_modal_dialog_chart|WEL_MODAL_DIALOG]] . The class LINE_THICKNESS_DIALOG inherits [[ref:libraries/wel/reference/wel_modal_dialog_chart|WEL_MODAL_DIALOG]] and uses a WEL_SINGLE_LINE_EDIT to input the desired line width. +This sample contains the following classes: +* TUTORIAL_STEP5 +* MAIN_WINDOW +* LINE_THICKNESS_DIALOG +* APPLICATION_IDS + + + + + + diff --git a/documentation/18.11/solutions/platform-specifics/microsoft-windows/wel/wel-tutorial/tutorial-step-6.wiki b/documentation/18.11/solutions/platform-specifics/microsoft-windows/wel/wel-tutorial/tutorial-step-6.wiki new file mode 100644 index 00000000..e16337ba --- /dev/null +++ b/documentation/18.11/solutions/platform-specifics/microsoft-windows/wel/wel-tutorial/tutorial-step-6.wiki @@ -0,0 +1,38 @@ +[[Property:title|Tutorial Step 6]] +[[Property:weight|5]] +[[Property:uuid|90d557e1-c4a6-e6ff-ff19-95a44c99f0ae]] +This sample builds on tutorial [[Tutorial Step 5|step 5]] by preventing the loss of the drawing when Windows re-draws the client area of the [[ref:libraries/wel/reference/wel_frame_window_chart|WEL_FRAME_WINDOW]] . The output is shown below: + +[[Image:step6|step6]]
+
+ +==Compiling== + +* Launch EiffelStudio. +* Click '''Add project''' +* Browse to ''$ISE_EIFFEL\examples\wel\tutorial\step6\''. +* Choose ''tutorial_step6.ecf'' +* Choose the location where the project will be compiled, by default the same directory containing the configuration file. +* Click '''OK'''. + + +==Running== + +After launching the sample, you will see a [[ref:libraries/wel/reference/wel_frame_window_chart|WEL_FRAME_WINDOW]] displayed. By holding down the left mouse button, and moving the mouse (Within the client area of the window), you will be able to draw on the client are of the window. If you press the right mouse button, a [[ref:libraries/wel/reference/wel_modal_dialog_chart|WEL_MODAL_DIALOG]] will pop up which allows you to enter the thickness of the line that is drawn. If you re-size the window, then the drawing will be re-drawn. + +==Under the Hood== + +This system uses a redefined on_paint to re-draw the contents of the window. A LINKED_LIST of LINES is used to store all the lines that have been drawn and during on_paint, this list is traversed in order to re-draw each line. +This sample contains the following classes: +* TUTORIAL_STEP6 +* MAIN_WINDOW +* LINE_THICKNESS_DIALOG_CHART +* APPLICATION_IDS +* POINT +* LINE + + + + + + diff --git a/documentation/18.11/solutions/platform-specifics/microsoft-windows/wel/wel-tutorial/tutorial-step-7.wiki b/documentation/18.11/solutions/platform-specifics/microsoft-windows/wel/wel-tutorial/tutorial-step-7.wiki new file mode 100644 index 00000000..133e1529 --- /dev/null +++ b/documentation/18.11/solutions/platform-specifics/microsoft-windows/wel/wel-tutorial/tutorial-step-7.wiki @@ -0,0 +1,38 @@ +[[Property:title|Tutorial Step 7]] +[[Property:weight|6]] +[[Property:uuid|751a492d-6902-838e-7468-38b67e40f4e2]] +This sample builds on tutorial [[Tutorial Step 6|step 6]] , and also demonstrates the use of a [[ref:libraries/wel/reference/wel_menu_chart|WEL_MENU]] . The output is shown below: + +[[Image:step7|step7]]
+
+ +==Compiling== + +* Launch EiffelStudio. +* Click '''Add project''' +* Browse to ''$ISE_EIFFEL\examples\wel\tutorial\step7\''. +* Choose ''tutorial_step7.ecf'' +* Choose the location where the project will be compiled, by default the same directory containing the configuration file. +* Click '''OK'''. + + +==Running== + +After launching the sample, you will see a [[ref:libraries/wel/reference/wel_frame_window_chart|WEL_FRAME_WINDOW]] displayed. By holding down the left mouse button, and moving the mouse (Within the client area of the window), you will be able to draw on the client are of the window. Selecting "Line_thickness" from the "Line" menu, will bring up a [[ref:libraries/wel/reference/wel_modal_dialog_chart|WEL_MODAL_DIALOG]] which allows you to change the thickness of the line that is drawn. If you select "Exit" from the "File" menu, you will be prompted if you wish to exit the application. Selecting "New" from the "File" menu will clear the window. The other menu options on the "File" menu do nothing in this example. + +==Under the Hood== + +During the creation of MAIN_WINDOW, the menu is assigned to the window and on_menu_command is redefined to allow processing of the menu selections. + +This sample contains the following classes: +* TUTORIAL_STEP7 +* MAIN_WINDOW +* LINE_THICKNESS_DIALOG_CHART +* APPLICATION_IDS +* POINT +* LINE + + + + + diff --git a/documentation/18.11/solutions/platform-specifics/microsoft-windows/wel/wel-tutorial/tutorial-step-8.wiki b/documentation/18.11/solutions/platform-specifics/microsoft-windows/wel/wel-tutorial/tutorial-step-8.wiki new file mode 100644 index 00000000..f52d2690 --- /dev/null +++ b/documentation/18.11/solutions/platform-specifics/microsoft-windows/wel/wel-tutorial/tutorial-step-8.wiki @@ -0,0 +1,41 @@ +[[Property:title|Tutorial Step 8]] +[[Property:weight|7]] +[[Property:uuid|38c3a22d-2c15-cb68-a685-99a25d191885]] +This sample builds on tutorial [[Tutorial Step 7|step 7]] , and also demonstrates the use of a [[ref:libraries/wel/reference/wel_open_file_dialog_chart|WEL_OPEN_FILE_DIALOG]] and a [[ref:libraries/wel/reference/wel_save_file_dialog_chart|WEL_SAVE_FILE_DIALOG]] . The output is shown below: + +[[Image:step8|step8]]
+
+ +==Compiling== + +* Launch EiffelStudio. +* Click '''Add project''' +* Browse to ''$ISE_EIFFEL\examples\wel\tutorial\step8\''. +* Choose ''tutorial_step8.ecf'' +* Choose the location where the project will be compiled, by default the same directory containing the configuration file. +* Click '''OK'''. + + +==Running== + +After launching the sample, you will see a [[ref:libraries/wel/reference/wel_frame_window_chart|WEL_FRAME_WINDOW]] displayed. By holding down the left mouse button, and moving the mouse (Within the client area of the window), you will be able to draw on the client are of the window. Selecting "Line_thickness" from the "Line" menu, will display a [[ref:libraries/wel/reference/wel_modal_dialog_chart|WEL_MODAL_DIALOG]] which allows you to change the thickness of the line that is drawn. If you select "Exit" from the "File" menu, you will be prompted if you wish to exit the application. Selecting "New" from the "File" menu will clear the window. Selecting "Save" from the "File" menu will display a [[ref:libraries/wel/reference/wel_save_file_dialog_chart|WEL_SAVE_FILE_DIALOG]] which allows you to specify the filename and location of the picture you have drawn. Selecting "Open" from the "File" menu will display a [[ref:libraries/wel/reference/wel_open_file_dialog_chart|WEL_OPEN_FILE_DIALOG]] which allows you to specify a previously saved drawing to open. + +==Under the Hood== +The [[ref:libraries/wel/reference/wel_open_file_dialog_chart|WEL_OPEN_FILE_DIALOG]] and the [[ref:libraries/wel/reference/wel_save_file_dialog_chart|WEL_SAVE_FILE_DIALOG]] are both activated from the redefinition of on_menu_command. A new class, LINES is now used to store the lines drawn by the user and this inherits [[ref:libraries/base/reference/storable_chart|STORABLE]] which allows it to be easily stored and retrieved. +This sample contains the following classes: +* TUTORIAL_STEP6 +* MAIN_WINDOW +* LINE_THICKNESS_DIALOG_CHART +* APPLICATION_IDS +* POINT +* LINES +* LINE + +{{seealso|
+[[ref:libraries/wel/reference/wel_save_file_dialog_chart|Save file dialog]]
+[[ref:libraries/wel/reference/wel_open_file_dialog_chart|Open file dialog]] }} + + + + + diff --git a/documentation/18.11/solutions/porting-instructions/index.wiki b/documentation/18.11/solutions/porting-instructions/index.wiki new file mode 100644 index 00000000..8c0267af --- /dev/null +++ b/documentation/18.11/solutions/porting-instructions/index.wiki @@ -0,0 +1,8 @@ +[[Property:title|Porting instructions]] +[[Property:weight|-11]] +[[Property:uuid|381d6e34-799a-3ba8-b1ec-c4ef73bce54f]] +=Porting from one platform to another= + + + + diff --git a/documentation/18.11/solutions/porting-instructions/porting-eiffel-application-unix-windows-or-vice-versa.wiki b/documentation/18.11/solutions/porting-instructions/porting-eiffel-application-unix-windows-or-vice-versa.wiki new file mode 100644 index 00000000..48efa697 --- /dev/null +++ b/documentation/18.11/solutions/porting-instructions/porting-eiffel-application-unix-windows-or-vice-versa.wiki @@ -0,0 +1,45 @@ +[[Property:title|Porting an Eiffel application from UNIX to Windows or vice-versa]] +[[Property:weight|-14]] +[[Property:uuid|d20773e7-dc7a-f500-e437-8b1f5fcffd58]] +==Requirements== + +Before starting your project, you must first decide if you want your program to run either single or multi-platform. If you decide to go multi-platform make sure you use platform independent Eiffel libraries or C/C++ code. Eiffel Software provides the following multi-platform libraries: +* Eiffel2Java (on platform that supports JNI) +* EiffelBase +* EiffelLex/EiffelParse +* EiffelNet (except UNIX specific classes) +* EiffelPreferences +* EiffelStore +* EiffelThread +* EiffelTime +* EiffelVision2 +* EiffelWeb +* EiffelWizards + +==Configuring your project== + +For porting between different UNIX systems, you simply need one simple configuration file as the C/C++ externals should be the same. If this is not the case, as with UNIX and Windows, you will need to use conditions in the configuration file. + +The usual scenario is to port from UNIX to Windows or vice versa. In this case, the only thing that needs to be conditioned in the configuration file are the externals. Conditioning of externals can be done in the project settings. + +Note that externals are (in contrast to almost all other locations) taken literally, so you may need to use `\` for paths on Windows and `/` on UNIX. + +It is important to also note that some multi-platform libraries such as EiffelVision2 do not include the same clusters for both UNIX and Windows. As with externals, clusters need to be specified depending on the target platform. + +==UNIX systems== + +When compiling for many UNIX system, you should finalize without launching the C compilation. At the end, the EIFGENs/target_name/F_code directory is built. This is the portable C code that you can take from one platform to another. We recommend you to create an archive of the F_code for backup. + +To compile on a given platform, you have to make sure that you have a complete EiffelStudio delivery for the target platform and that your PATH environment variable contains $ISE_EIFFEL/studio/spec/$ ISE_PLATFORM/bin. You then have to check that all C externals that you are using have been compiled for this platform. + +You can then launch [[finish_freezing utility|finish_freezing]] that will automatically recompile the C generated code and generate a new executable for the given platform. + +==Between UNIX and Windows== + +As shown above you will need to have a configuration file with conditions to port your Windows application to UNIX. You can then use the UNIX configuration file to re-finalize your project (without C compilation) and then you have ANSI compliant C code that may be compiled on a UNIX platform using the above instructions. + +To compile your UNIX application on Windows simply follow the same instructions as above using a Windows configuration file instead. When the ANSI C code is generated, run [[finish_freezing utility|finish_freezing]] in the F_code directory on the target Windows platform and your system will be compiled. + + + + diff --git a/documentation/18.11/solutions/preferences/eiffelpreferences/eiffelpreferences-class-reference.wiki b/documentation/18.11/solutions/preferences/eiffelpreferences/eiffelpreferences-class-reference.wiki new file mode 100644 index 00000000..060a7b38 --- /dev/null +++ b/documentation/18.11/solutions/preferences/eiffelpreferences/eiffelpreferences-class-reference.wiki @@ -0,0 +1,5 @@ +[[Property:title|EiffelPreferences Class Reference]] +[[Property:weight|1]] +[[Property:uuid|9929ec96-07e2-1e6c-26db-d19ab947e1be]] +==View the [[ref:libraries/preferences/reference/index|EiffelPreferences Class Reference]]== + diff --git a/documentation/18.11/solutions/preferences/eiffelpreferences/eiffelpreferences-sample.wiki b/documentation/18.11/solutions/preferences/eiffelpreferences/eiffelpreferences-sample.wiki new file mode 100644 index 00000000..4599f118 --- /dev/null +++ b/documentation/18.11/solutions/preferences/eiffelpreferences/eiffelpreferences-sample.wiki @@ -0,0 +1,44 @@ +[[Property:title|EiffelPreferences Sample]] +[[Property:weight|2]] +[[Property:uuid|f492e71c-07a8-9b1d-f72a-d59330acbf16]] +
+
+ +==Compiling== + +* Launch EiffelStudio. +* Click '''Add project''' +* Browse to ''$ISE_EIFFEL\examples\preferences\''. +* Choose ''preferences_example.ecf'' +* Choose the location where the project will be compiled, by default the same directory containing the configuration file. +* Choose the target: ''registry'' (Windows only) will use the registry to store the preferences, ''xml'' will use a xml file to store the preferences. +* Click '''OK'''. + + +==Running== + +After launching the application, you will see a window displayed with 2 buttons. When clicked each will display a window showing the preferences, one is the default view provided with the library, the other is a custom view for purposes of example. The default view looks like: + +[[Image:normal|preferences_example_normal_view]] + +The custom view looks like: + +[[Image:custom|preferences_example_normal_view]] + +In each dialog you can select the preferences and alter the values. +==Under the Hood== + +This example shows you how to achieve the following tasks: + +* Create preferences using the library supplied preference types and associated views +* Use the default widget for viewing preferences and manipulating their values +* Create a custom preference (a preference for storing correctly formatted directory path names) +* Create a widget to view and change the custom preference type value +* Create a custom manager to register custom types to the system +* Create a custom dialog for viewing all the preferences + + + + + + diff --git a/documentation/18.11/solutions/preferences/eiffelpreferences/eiffelpreferences-tutorial/index.wiki b/documentation/18.11/solutions/preferences/eiffelpreferences/eiffelpreferences-tutorial/index.wiki new file mode 100644 index 00000000..cc13be39 --- /dev/null +++ b/documentation/18.11/solutions/preferences/eiffelpreferences/eiffelpreferences-tutorial/index.wiki @@ -0,0 +1,7 @@ +[[Property:title|EiffelPreferences Tutorial]] +[[Property:weight|0]] +[[Property:uuid|0c717db7-fb53-80b3-e32f-cc8356afa5f8]] +The EiffelPreferences library is a platform independent library that can be used to add preference and configuration settings to your application. Briefly, the library provides support for creating fully configurable preference values, on a per application or per user basis. It also provides a graphical interface for manipulation of these values, and a easily extensible design for you to add your own custom preference types. + + + diff --git a/documentation/18.11/solutions/preferences/eiffelpreferences/eiffelpreferences-tutorial/initialization.wiki b/documentation/18.11/solutions/preferences/eiffelpreferences/eiffelpreferences-tutorial/initialization.wiki new file mode 100644 index 00000000..d9989a71 --- /dev/null +++ b/documentation/18.11/solutions/preferences/eiffelpreferences/eiffelpreferences-tutorial/initialization.wiki @@ -0,0 +1,154 @@ +[[Property:title|Initialization]] +[[Property:weight|1]] +[[Property:uuid|2f69a1b5-b5fd-57be-46e0-60eb2406ff5d]] +This document details how to setup preferences for your application. + +==Initializating the preferences== + +The first thing you must do to setup preferences for your application is create a PREFERENCES object. Ideally any access to preference information should be done through this object. There are 5 creation routines available to initialize the preferences: +* 2 recommended routines (more flexible) +** make_with_storage +** make_with_defaults_and_storage +* and 3 other routines (might become obsolete one day) +** make +** make_with_location +** make_with_defaults_and_location + +The make_with_storage will create an instance of PREFERENCES using the underlying storage passed as argument, and without any default preference values. +The current supported underlying storages are ''XML file'' (PREFERENCES_STORAGE_XML), and on Windows-only ''Windows Registry'' storage (PREFERENCES_STORAGE_REGISTRY). + +''Note:'' that you can build your own custom storage, by implementing the class PREFERENCES_STORAGE_I, and use such object as storage in the associated creation routine. + +The option make_with_defaults_and_storage is similar to make_with_storage except an additional parameter is given to retrieve one or more default file locations. This will be one or more XML files on disk containing the default values to use for some or all of your preferences. It is a convenient way to initialize your application with all the default values required `out of the box` for correct or preferred functioning. Those files also contain additional attributes for preference configuration such as more detailed descriptions of the preference. If two files list the same preference, the last one to mention it takes precedence. + +The format of the XML default file is very simple: + + + ...More preferences... + + +The "HIDDEN" attribute indicates if this preference is to be hidden from view and is used for preferences that you do not wish for your users to modify or see. The "RESTART" attribute allows for you to flag that when a particular preference is changed it may be necessary to restart the application for the changes to take effect. You can handle this in your application by querying for this value in the preference and dispalying appropriate dialogs and messages for your application. + +For backward compatibility, there is a default PREFERENCES_STORAGE_DEFAULT, which is based on XML file or Windows Registry depending if you compile using the ''preferences_xml.ecf'' or the ''preferences_registry.ecf'' configuration file (nb: on non Windows platform, only the XML version is supported). +And if you use the make, make_with_location, make_with_defaults_and_location, this is pretty similar to use an object PREFERENCES_STORAGE_DEFAULT instantiated with the specified location (if any), see next ''Storage'' section for more details. + + +== Storage == +To create an implementation of PREFERENCES_STORAGE_I (XML or Windows Registry), there are 2 creation routines available: +* make_empty +* make_with_location + +The option make_empty will create a preferences storage (implementer of PREFERENCES_STORAGE_I) object for you with no specific underlying datastore location. + +In this scenario an underlying data store location will be created for you automatically based on the current system settings. For example, if you are using the Windows Registry as your data store, and your program is is called ''my_program.exe'', then a registry key will be created in ''HKEY_CURRENT_USER\Software\myprogram.exe''. In between user sessions the preference name-value pairs will be stored in this key location. This particular method of creating preferences is ideal if you are not particularly concerned where the values are stored. You may think of it as the "it just works" mode, and it is ideal for development and simple use. + +The option ( make_with_location) will take a location value to use for the underlying data storage. Values will be stored to and retrieved from this location between sessions (it could be a specific XML file location, or a specific Windows Registry path, depending if you use XML or REGISTRY storage). + +==Managers== + +Once you have created a PREFERENCES object using one of the creation routines described above you will create a PREFERENCE_MANAGER to store related preference values. For example, if your application is a web browser control that has preferences for user favorites and also a user browsing history you could create 2 managers, one for the favorites and one for the history. It is not mandatory that you create 2 managers and you could just create one and have all preferences stored therein, but for reasons of management 2 would be better. Each separate manager must have a unique name to distinguish it from the other managers in the system. We may have one called "favorites" and one called "history". + +==Creating preferences== + +Now you have your preferences and at least one manager to put them in you can create the actual preferences. Preferences are generic, and all preferences inherit the class TYPED_PREFERENCE [G]. G denotes the type of the preference, for example INTEGER for a preference containing an integer value. Depending on the type you will use a factory class to actually create the new preference. By default the library supports 6 types of preferences, 4 basic type ones and 2 graphical types. The table below clearly indicates the currently available preferences and the factory class you should use to create them: +{| border="1" +|- +| '''Preference type''' +| '''Description''' +| '''Factory class''' +| '''Factory method''' +|- +| BOOLEAN_PREFERENCE +| Stores boolean value (true or false) +| BASIC_PREFERENCE_FACTORY +| new_boolean_preference_value +|- +| INTEGER_PREFERENCE +| Stores an integer value +| BASIC_PREFERENCE_FACTORY +| new_integer_preference_value +|- +| STRING_PREFERENCE +| Stores a string value +| BASIC_PREFERENCE_FACTORY +| new_string_preference_value +|- +| ARRAY_PREFERENCE +| Stores a list of string values +| BASIC_PREFERENCE_FACTORY +| new_array_preference_value +|- +| COLOR_PREFERENCE +| Stores a color value (rgb) +| GRAPHICAL_PREFERENCE_FACTORY +| new_color_preference_value +|- +| FONT_PREFERENCE +| Stores a font value (font name, face, height, etc) +| GRAPHICAL_PREFERENCE_FACTORY +| new_font_preference_value +|} +As you can see creating preferences is very easy. Also you will notice that color and font preferences use the GRAPHICAL_PREFERENCE_FACTORY. If you wish to use these preferences in your application you will need to use EiffelVision2 since these preference values are stored as EV_COLOR and EV_FONT types. If you wish to store preference value that are different to those offered by the 6 available preferences it also very easy to extend the design and add your own custom types. Simply inherit TYPED_PREFERENCE [G] and implement the deferred features for your specific preference. There is an example of this in the sample application. + +==Default Values== + +When you create a preference using a factory class you will provide a manager, a name for the preference, and a value. For example, in BASIC_PREFERENCE_FACTORY you create an integer preference by calling new_integer_preference_value: + + new_integer_preference_value (a_manager: PREFERENCE_MANAGER; a_name: STRING; a_fallback_value: INTEGER): INTEGER_PREFERENCE + -- Add a new integer preference with name `a_name'. If preference cannot be found in + -- underlying datastore or in a default values then `a_fallback_value' is used for the value. + require + name_valid: a_name /= Void + name_not_empty: not a_name.is_empty + not_has_preference: not a_manager.known_preference (a_name) + ensure + has_result: Result /= Void + preference_name_set: Result.name.is_equal (a_name) + preference_added: a_manager.preferences.has_preference (a_name) + end + +An appropriate example in code of this could be: + + + window_width_preference: INTEGER_PREFERENCE + -- Preference holding value for width of application main window + + initialize_my_preferences + -- Initialize the application preferences + local + factory: BASIC_PREFERENCE_FACTORY + do + create factory + window_width_preference := factory.new_integer_preference_value (my_manager, "window_width", 480) + end +This will create a new preference, which you can then use in your application to get, set and save the corresponding value when necessary. The issue to be aware of here though involves the value that the preference will contain when it is created. You see in the code above we pass the integer value 480. '''This does not mean, however, the initial value of the preference will be 480'''. This may sound odd, so let me explain... +The value of a preference when initialized is determined by a number of factors. The first of these is the underlying data store value. If a preference value was changed in a previous session, by the user or by the application directly, and was saved to the underlying data store, then this value will be given priority. This makes sense, since if a user changes their preferences they don't want to have to do it every time they use your program. So, if they want the default window width to be larger, say 600, then this will be the value of the preference named "window_width" when initialized next time. Following this, if there is no previously saved value then the library will look for a default value to use. If a default file was given when the preferences were created (see above), and this default specifies a default value of 240 for the integer preference called "window_width", then this will be used. Finally, if no preference value was previously stored ''and'' no value is provided as a default value then the supplied value in the code is used - our 480 value from the example above. Although this process may seem confusing it is infact very simple and intuitive way to initialze the preferences. The process chart below illustrates more clearly the various permutations. + +[[Image:value-chart]] + +==Using and Manipulating Preferences== + +Now you have preferences created you may use them from your application. Using the example preference above, window_width_preference, you can query the value of the preferences by simply querying the preference directly: +window_width := window_width_preference.value + +Or for a value which should always be associated to the preference: + + window_width: INTEGER + -- Width of window + do + Result := window_width_preference.value + end + + +If you need to react when a preference value is changed you can hook up an agent to the change_actions of the preference: +window_width_preference.change_actions.extend (agent my_agent_routine) + +To manually set the value of the preference call set_value or set_value_from_string, and to set a value for the default value call set_default_value. To reset a preference value back to it's original default value use reset. + +To save the current preference to the underlying data store you must call save_preference on the PREFERENCES object. This will persist the value to the data store for retrieval in the next session. Remember, if you change a preference value during execution and do not save it then the value will be lost when execution has finished. + +The preference window interface provided with the library will allow users to set there own preference values and will save the values upon confirmation. However, if you are using preferences in your code and do not wish to provide an interface for preference modification you must remember to manually save the preferences. + +You can save all preferences at once my calling save_preferences in PREFERENCES, or individually with save_preference. + + diff --git a/documentation/18.11/solutions/preferences/eiffelpreferences/eiffelpreferences-tutorial/interface-preferences.wiki b/documentation/18.11/solutions/preferences/eiffelpreferences/eiffelpreferences-tutorial/interface-preferences.wiki new file mode 100644 index 00000000..93cc5efe --- /dev/null +++ b/documentation/18.11/solutions/preferences/eiffelpreferences/eiffelpreferences-tutorial/interface-preferences.wiki @@ -0,0 +1,53 @@ +[[Property:title|Interface for preferences]] +[[Property:weight|2]] +[[Property:uuid|6f4964b1-8cf6-d9d4-0778-94d8a3737cad]] +This document describes the use of graphical widgets to display and manipulate preferences. + +The preference library contains a cluster called interface. This cluster provides some basic classes which can be used to graphically display and manipulate the PREFERENCE types used by the library. There are various widget classes which correspond to particular types of preferences and can be used to view and change the values of an associated preference. The table below illustrates which widgets are used to display each of the known preference types: + +{| border="1" +|- +| '''Preference Type''' +| '''Associated Widget''' +|- +| INTEGER_PREFERENCE +| STRING_PREFERENCE_WIDGET +|- +| BOOLEAN_PREFERENCE +| BOOLEAN_PREFERENCE_WIDGET +|- +| STRING_PREFERENCE +| STRING_PREFERENCE_WIDGET +|- +| ARRAY_PREFERENCE +| STRING_PREFERENCE_WIDGET or CHOICE_PREFERENCE_WIDGET +|- +| COLOR_PREFERENCE +| COLOR_PREFERENCE_WIDGET +|- +| FONT_PREFERENCE +| FONT_PREFERENCE_WIDGET +|} + + +All of these widgets inherit the abstract base class PREFERENCE_WIDGET and implement the required deferred features therein. Each implementation implements handling of an EV_GRID_ITEM widget from EiffelVision2 for use in the EV_GRID control, which allows for viewing and editing of the underlying preference value. For example, BOOLEAN_PREFERENCE_WIDGET uses an EV_GRID_CHECKABLE_LABEL_ITEM to display the 'True' and 'False' properties of a BOOLEAN_PREFERENCE. Another example: CHOICE_PREFERENCE_WIDGET uses EV_GRID_CHOICE_ITEM, when the widget is loaded it displays the current value of the associated preference in the combo box. When the user changes the combo box value the preference value is changed also, and optionally saved. + +Using these supplied widgets in your interface is simply a matter of creating the object and adding the change_item_widget to an instance of EV_GRID. + +By default the library provides such a view, in the form of PREFERENCES_GRID_CONTROL, and for easier usage PREFERENCES_GRID_DIALOG, which is a dialog control that contains a grid PREFERENCES_GRID_CONTROL and has all the necessary logic to handle graphical manipulation of the preference types provided in the library. + +The PREFERENCES_GRID_DIALOG is a EV_DIALOG with a navigable tree/grid for finding groups of related preferences (i.e. managers), and the various preferences as a row. It is a useful, general purpose interface for preference manipulation. + +You have the possibility to view the preferences as a ''tree'', or a ''flat view''. In this ''flat view'', you can filter the preferences to find easily a preference. + +As with preferences themselves you may create your own custom view if this dialog is not sufficient for your needs, and can use the code therein as a template for your own code. You can also use the PREFERENCES_GRID_CONTROL to embed the preferences grid control in your application interface. + +Below is an image of the supplied window as it appears in the EiffelStudio preferences environment. + +[[Image:preference-window]] + +For an example of creating custom widget views for individual preferences, or a custom view for all preferences, please refer to the [[EiffelPreferences Sample|example]] in this documentation. + + + + diff --git a/documentation/18.11/solutions/preferences/eiffelpreferences/eiffelpreferences-tutorial/overview.wiki b/documentation/18.11/solutions/preferences/eiffelpreferences/eiffelpreferences-tutorial/overview.wiki new file mode 100644 index 00000000..a3bb15cb --- /dev/null +++ b/documentation/18.11/solutions/preferences/eiffelpreferences/eiffelpreferences-tutorial/overview.wiki @@ -0,0 +1,32 @@ +[[Property:title|Overview]] +[[Property:weight|0]] +[[Property:uuid|8f90ea04-493b-0e00-1327-c707a49e1c04]] +This document gives a brief overview of the EiffelPreferences library. + +==Introduction== + +Simply, preferences are name-value pairs. All preferences are descendants of the deferred class PREFERENCE, and therefore all inherit the common properties of name, value, default values and string representations. Common to all PREFERENCE objects is the notion of `manager`. All preferences belong to a manager, which is a helper class used for organizational and hierarchical management of your applications preferences. + +So, all preferences belong to a PREFERENCE_MANAGER. The manager itself belongs to a set of related PREFERENCES. In fact, when you create a new manager for a group of preferences you must provide a PREFERENCES object to the creation routine to indicate which set of preferences the new manager will be associated: + + make (a_preferences: PREFERENCES; a_namespace: STRING) + -- New manager. + require + preferences_not_void: a_preferences /= Void + namespace_not_void: a_namespace /= Void + namespace_not_empty: not a_namespace.is_empty + ensure + has_preferences: preferences /= Void + inserted_in_preferences: preferences.has_manager (namespace) + has_namespace: namespace /= Void + namespace_valid: not a_namespace.is_empty + end + + +You can see in the post-condition inserted_in_preferences that indeed the PREFERENCES object will have the new manager in its list of managers. + +For every group of preferences or configuration values you therefore wish to create for your project, you will need a corresponding PREFERENCES object. In general one PREFERENCES object should be sufficient for most applications, and will be the point of reference for all preference values in the entire application. This class may be initialized in a number of ways, depending on the specific configuration of your application. It will be used to create new managers, store default preference values, and handle the saving and retrieval of preference values to and from the underlying data store between sessions. In between sessions the preference name and value pairs are persisted to an underlying data store. This may be any imaginable datastore, such as a file, database or external storage device. Support for XML and the Windows Registry is provided in the library by default, but EiffelPreferences allows you to provide an implementation tailored to your specific needs (such as SQL database store). + + + + diff --git a/documentation/18.11/solutions/preferences/eiffelpreferences/index.wiki b/documentation/18.11/solutions/preferences/eiffelpreferences/index.wiki new file mode 100644 index 00000000..0baf9320 --- /dev/null +++ b/documentation/18.11/solutions/preferences/eiffelpreferences/index.wiki @@ -0,0 +1,11 @@ +[[Property:title|EiffelPreferences]] +[[Property:weight|1]] +[[Property:uuid|f56ec405-6032-67dd-55e1-5a5ff7a4193c]] +==EiffelPreferences Library== + +Type: Library
+Platform: Any
+ +Eiffel classes for adding preferences and settings to applications. + + diff --git a/documentation/18.11/solutions/preferences/index.wiki b/documentation/18.11/solutions/preferences/index.wiki new file mode 100644 index 00000000..5631ed05 --- /dev/null +++ b/documentation/18.11/solutions/preferences/index.wiki @@ -0,0 +1,6 @@ +[[Property:title|Preferences]] +[[Property:weight|-5]] +[[Property:uuid|08efd11f-6326-90e0-bd63-8dfed4b55890]] +== Application preferences management solutions == + + diff --git a/documentation/18.11/solutions/text-processing/eiffellex/eiffellex-class-reference.wiki b/documentation/18.11/solutions/text-processing/eiffellex/eiffellex-class-reference.wiki new file mode 100644 index 00000000..e5f19c92 --- /dev/null +++ b/documentation/18.11/solutions/text-processing/eiffellex/eiffellex-class-reference.wiki @@ -0,0 +1,5 @@ +[[Property:title|EiffelLex Class Reference]] +[[Property:weight|1]] +[[Property:uuid|51198de0-9cad-6b47-e351-6e0de86942ce]] +==View the [[ref:libraries/lex/reference/index|EiffelLex Class Reference]]== + diff --git a/documentation/18.11/solutions/text-processing/eiffellex/eiffellex-sample/eiffel-scanner/eiffel-scan-console-input.wiki b/documentation/18.11/solutions/text-processing/eiffellex/eiffellex-sample/eiffel-scanner/eiffel-scan-console-input.wiki new file mode 100644 index 00000000..9818c141 --- /dev/null +++ b/documentation/18.11/solutions/text-processing/eiffellex/eiffellex-sample/eiffel-scanner/eiffel-scan-console-input.wiki @@ -0,0 +1,55 @@ +[[Property:title|eiffel_scan console input]] +[[Property:weight|2]] +[[Property:uuid|ce4da828-6772-e1c3-0917-82f6669cccf9]] + +-- Example of a lexical analyzer based on the Eiffel syntax. +-- The analyzer itself is found in the file ``eiffel_lex'', which +-- is created according to the file ``eiffel_token'' if not +-- previously built and stored. + +class EIFFEL_SCAN + +inherit + + SCANNING + rename + make as scanning_make + end; + + ARGUMENTS + undefine + copy, consistent, is_equal, setup + end + +create + + make + +feature + + make + -- Create a lexical analyser for Eiffel if none, + -- then use it to analyze the file of name + -- `file_name'. + local + file_name: STRING; + do + if argument_count < 1 then + io.error.putstring ("Usage: eiffel_scan eiffel_class_file.e%N") + else + file_name := argument (1); + scanning_make; + build ("eiffel_lex", "eiffel_regular"); + io.putstring ("Scanning file `"); + io.putstring (file_name); + io.putstring ("'.%N"); + analyze (file_name) + end + end -- make + +end -- class EIFFEL_SCAN + + + + + diff --git a/documentation/18.11/solutions/text-processing/eiffellex/eiffellex-sample/eiffel-scanner/eiffel-scan-console-output.wiki b/documentation/18.11/solutions/text-processing/eiffellex/eiffellex-sample/eiffel-scanner/eiffel-scan-console-output.wiki new file mode 100644 index 00000000..109ac19c --- /dev/null +++ b/documentation/18.11/solutions/text-processing/eiffellex/eiffellex-sample/eiffel-scanner/eiffel-scan-console-output.wiki @@ -0,0 +1,118 @@ +[[Property:title|eiffel_scan console output]] +[[Property:weight|3]] +[[Property:uuid|a233d1b0-b964-ba44-7b24-7204d9fa6932]] + +Scanning file `eiffel_scan.e'. + + +--------------- LEXICAL ANALYSIS: ---- + +Token type 11: -- Example of a lexical analyzer based on the Eiffel syntax. +-- The analyzer itself is found in the file ``eiffel_lex'', which +-- is created according to the file ``eiffel_token'' if not +-- previously built and stored. + +Keyword: class Code: 1819086195 +Token type 32: EIFFEL_SCAN +Keyword: inherit Code: 1080299636 +Token type 32: SCANNING +Keyword: rename Code: 2076787557 +Token type 32: make +Keyword: as Code: 24947 +Token type 32: scanning_make +Keyword: end Code: 6647396 +Token type 15: ; +Token type 32: ARGUMENTS +Keyword: undefine Code: 1472863845 +Token type 32: copy +Token type 17: , +Token type 32: consistent +Token type 17: , +Token type 32: is_equal +Token type 17: , +Token type 32: setup +Keyword: end Code: 6647396 +Token type 32: create +Token type 32: make +Keyword: feature Code: 1951938661 +Token type 32: make +Keyword: is Code: 26995 +Token type 11: -- Create a lexical analyser for Eiffel if none, + -- then use it to analyze the file of name + +Token type 11: -- `file_name'. + +Keyword: local Code: 1869613420 +Token type 32: file_name +Token type 16: : +Token type 32: STRING +Token type 15: ; +Keyword: do Code: 25711 +Keyword: if Code: 26982 +Token type 32: argument_count +Token type 10: < +Token type 2: 1 +Keyword: then Code: 1952998766 +Token type 32: io +Token type 13: . +Token type 32: error +Token type 13: . +Token type 32: putstring +Token type 20: ( +Token type 3: "Usage: eiffel_scan eiffel_class_file.e%N" +Token type 21: ) +Keyword: else Code: 1701606245 +Token type 32: file_name +Token type 18: := +Token type 32: argument +Token type 20: ( +Token type 2: 1 +Token type 21: ) +Token type 15: ; +Token type 32: scanning_make +Token type 15: ; +Token type 32: build +Token type 20: ( +Token type 3: "eiffel_lex" +Token type 17: , +Token type 3: "eiffel_regular" +Token type 21: ) +Token type 15: ; +Token type 32: io +Token type 13: . +Token type 32: putstring +Token type 20: ( +Token type 3: "Scanning file `" +Token type 21: ) +Token type 15: ; +Token type 32: io +Token type 13: . +Token type 32: putstring +Token type 20: ( +Token type 32: file_name +Token type 21: ) +Token type 15: ; +Token type 32: io +Token type 13: . +Token type 32: putstring +Token type 20: ( +Token type 3: "'.%N" +Token type 21: ) +Token type 15: ; +Token type 32: analyze +Token type 20: ( +Token type 32: file_name +Token type 21: ) +Keyword: end Code: 6647396 +Keyword: end Code: 6647396 +Token type 11: -- make + +Keyword: end Code: 6647396 +Token type 11: -- class EIFFEL_SCAN + +Token type -1: + + + + + diff --git a/documentation/18.11/solutions/text-processing/eiffellex/eiffellex-sample/eiffel-scanner/eiffel-scan-text.wiki b/documentation/18.11/solutions/text-processing/eiffellex/eiffellex-sample/eiffel-scanner/eiffel-scan-text.wiki new file mode 100644 index 00000000..2bb58404 --- /dev/null +++ b/documentation/18.11/solutions/text-processing/eiffellex/eiffellex-sample/eiffel-scanner/eiffel-scan-text.wiki @@ -0,0 +1,54 @@ +[[Property:title|EIFFEL_SCAN Text]] +[[Property:weight|1]] +[[Property:uuid|092bd183-2fc4-ae65-02b9-d66933492a50]] + + +class + EIFFEL_SCAN + +inherit + SCANNING + rename + make as scanning_make + end + + ARGUMENTS + undefine + copy, + consistent, + is_equal, + setup + end + +create + make + +feature + + make + -- Create a lexical analyser for Eiffel if none, + -- then use it to analyze the file of name + -- file_name. + local + file_name: STRING + do + if argument_count < 1 then + io.error.putstring ("Usage: eiffel_scan eiffel_class_file.e%N") + else + file_name := argument (1) + scanning_make + build ("eiffel_lex", "eiffel_regular") + io.putstring ("Scanning file `") + io.putstring (file_name) + io.putstring ("'.%N") + analyze (file_name) + end + end + +end -- class EIFFEL_SCAN + + + + + + diff --git a/documentation/18.11/solutions/text-processing/eiffellex/eiffellex-sample/eiffel-scanner/eiffellex-samples.wiki b/documentation/18.11/solutions/text-processing/eiffellex/eiffellex-sample/eiffel-scanner/eiffellex-samples.wiki new file mode 100644 index 00000000..21389446 --- /dev/null +++ b/documentation/18.11/solutions/text-processing/eiffellex/eiffellex-sample/eiffel-scanner/eiffellex-samples.wiki @@ -0,0 +1,100 @@ +[[Property:title|EiffelLex Samples]] +[[Property:weight|0]] +[[Property:uuid|2e4911de-4838-00fc-1742-a8ebd1ae05ff]] + + + +Real $R +Integer $Z +String ("\"" -> "\"") +Div "//" +Mod "\\" +Quotient '/' +Product '*' +Plus '+' +Minus '-' +Relational ('=' | '<' | '>' | ('<' '=') | ('>' '=') | ('/' '=')) +Comment ("--" -> "\n") *(' '| '\t') *("--" -> "\n") +FeatureAddress '$' +Dot '.' +Dotdot ".." +Semicolon ';' +Colon ':' +Comma ',' +Assign ":=" +ReverseAssign "?=" +Lparan '(' +Rparan ')' +Lcurly '{' +Rcurly '}' +Lsquare '[' +Rsquare ']' +Bang '!' +LeftArray "<<" +RightArray ">>" +Power '^' +Constraint "->" +Character (('\''$P'\'') | ('\'''\\'['t'|'n'|'r'|'f']'\'') | ('\''+('0'..'7')'\'')) +Identifier ~('a'..'z') *(~('a'..'z') | '_' | ('0'..'9')) +-- Keywords +as +and +check +class +current +debug +deferred +do +else +elseif +end +ensure +expanded +export +external +false +feature +from +if +implies +indexing +infix +inherit +inspect +integer +invariant +is +language +like +local +loop +not +obsolete +old +once +or +prefix +real +redefine +require +rename +rescue +result +retry +select +strip +then +true +undefine +unique +until +variant +void +when +xor + + + + + + diff --git a/documentation/18.11/solutions/text-processing/eiffellex/eiffellex-sample/eiffel-scanner/index.wiki b/documentation/18.11/solutions/text-processing/eiffellex/eiffellex-sample/eiffel-scanner/index.wiki new file mode 100644 index 00000000..881fe0e5 --- /dev/null +++ b/documentation/18.11/solutions/text-processing/eiffellex/eiffellex-sample/eiffel-scanner/index.wiki @@ -0,0 +1,13 @@ +[[Property:title|Eiffel scanner]] +[[Property:weight|0]] +[[Property:uuid|c0d6ad9d-2bac-c5ad-69b6-873db2e47aa9]] +In the directory '''$ISE_EIFFEL/examples/lex''' you will find a system that scans Eiffel classes. It consists of the class [[EIFFEL_SCAN Text|EIFFEL_SCAN]] . It uses the file [[EiffelLex Samples|eiffel_regular]] as lexical grammar to analyze an Eiffel class passed on the command line. + +When compiling the example, the executable '''eiffel_scan(.exe)''' is created. Use the program as follows: +eiffel_scan ; + +As an example, when the [[eiffel_scan console input|source code]] of the root class is run through the scanner, it outputs a [[eiffel_scan console output|list]] of all consecutive tokens and keywords in that class to the console. + + + + diff --git a/documentation/18.11/solutions/text-processing/eiffellex/eiffellex-sample/index.wiki b/documentation/18.11/solutions/text-processing/eiffellex/eiffellex-sample/index.wiki new file mode 100644 index 00000000..e6f45381 --- /dev/null +++ b/documentation/18.11/solutions/text-processing/eiffellex/eiffellex-sample/index.wiki @@ -0,0 +1,8 @@ +[[Property:title|EiffelLex Sample]] +[[Property:weight|2]] +[[Property:uuid|79ad35f3-75a9-429c-ad47-f304fec23306]] +* [[Eiffel scanner|Eiffel scanner]] + + + + diff --git a/documentation/18.11/solutions/text-processing/eiffellex/eiffellex-tutorial.wiki b/documentation/18.11/solutions/text-processing/eiffellex/eiffellex-tutorial.wiki new file mode 100644 index 00000000..deabeab9 --- /dev/null +++ b/documentation/18.11/solutions/text-processing/eiffellex/eiffellex-tutorial.wiki @@ -0,0 +1,567 @@ +[[Property:title|EiffelLex Tutorial]] +[[Property:weight|0]] +[[Property:uuid|9ea43bef-1483-fbf2-4791-2be6a31d394d]] +==OVERVIEW== + +When analyzing a text by computer, it is usually necessary to split it into individual components or '''tokens'''. In human languages, the tokens are the words; in programming languages, tokens are the basic constituents of software texts, such as identifiers, constants and special symbols. + +The process of recognizing the successive tokens of a text is called lexical analysis. This chapter describes the EiffelLex library, a set of classes which make it possible to build and apply lexical analyzers to many different languages. + +Besides recognizing the tokens, it is usually necessary to recognize the deeper syntactic structure of the text. This process is called '''parsing''' or '''syntax analysis''' and is studied in the next chapter. + +Figure 1 shows the inheritance structure of the classes discussed in this chapter. Class [[ref:libraries/parse/reference/l_interface_chart|L_INTERFACE]] has also been included although we will only study it in the [[EiffelParse Tutorial]]; it belongs to the Parse library, where it takes care of the interface between parsing and lexical analysis. + + +[[Image:figure1]] + +Figure 1: Lexical classes + +==AIMS AND SCOPE OF THE EIFFELLEX LIBRARY== + +To use the EiffelLex library it is necessary to understand the basic concepts and terminology of lexical analysis. + +===Basic terminology=== + +The set of tokens accepted by a lexical analyzer is called a '''lexical grammar'''. For example, the basic constructs of Eiffel (identifiers, keywords, constants, special symbols) constitute a lexical grammar. For reasons that will be clear below, a lexical grammar is also known as a '''regular grammar'''. + +A lexical grammar defines a number of '''token types''', such as Identifier and Integer for Eiffel. A token that conforms to the structure defined for a certain token type is called a '''specimen''' of that token type. For example, the token my_identifier, which satisfies the rules for Eiffel tokens, is a specimen of the token type Identifier; 201 is a specimen of the token type Integer. + +To define a lexical grammar is to specify a number of token types by describing precisely, for each token type, the form of the corresponding specimens. For example a lexical grammar for Eiffel will specify that Identifier is the token type whose specimens are sequences of one or more characters, of which the first must be a letter (lower-case or upper-case) and any subsequent one is a letter, a digit (0 to 9) or an underscore. Actual grammar descriptions use a less verbose and more formal approach, studied below: regular expressions. + +A lexical analyzer is an object equipped with operations that enable it to read a text according to a known lexical grammar and to identify the text's successive tokens. + +The classes of the EiffelLex library make it possible to define lexical grammars for many different applications, and to produce lexical analyzers for these grammars. + +===Overview of the classes=== + +For the user of the EiffelLex library, the classes of most direct interest are [[ref:libraries/lex/reference/token_chart|TOKEN]] , [[ref:libraries/lex/reference/lexical_chart|LEXICAL]] , [[ref:libraries/lex/reference/metalex_chart|METALEX]] and [[ref:libraries/lex/reference/scanning_chart|SCANNING]] . + +An instance of [[ref:libraries/lex/reference/token_chart|TOKEN]] describes a token read from an input file being analyzed, with such properties as the token type, the corresponding string and the position in the text (line, column) where it was found. + +An instance of [[ref:libraries/lex/reference/lexical_chart|LEXICAL]] is a lexical analyzer for a certain lexical grammar. Given a reference to such an instance, say analyzer, you may analyze an input text through calls to the features of class [[ref:libraries/lex/reference/lexical_chart|LEXICAL]] , for example: + + analyzer.get_token + + +Class [[ref:libraries/lex/reference/metalex_chart|METALEX]] defines facilities for building such lexical analyzers. In particular, it provides features for reading the grammar from a file and building the corresponding analyzer. Classes that need to build and use lexical analyzers may be written as descendants of [[ref:libraries/lex/reference/metalex_chart|METALEX]] to benefit from its general-purpose facilities. + +Class [[ref:libraries/lex/reference/scanning_chart|SCANNING]] is one such descendant of [[ref:libraries/lex/reference/metalex_chart|METALEX]] . It contains all the facilities needed to build an ordinary lexical analyzer and apply it to the analysis of input texts. Because these facilities are simpler to use and are in most cases sufficient, SCANNING will be discussed first; the finer-grain facilities of [[ref:libraries/lex/reference/metalex_chart|METALEX]] are described towards the end of this chapter. + +These classes internally rely on others, some of which may be useful for more advanced applications. [[ref:libraries/lex/reference/lex_builder_chart|LEX_BUILDER]] , one of the supporting classes, will be introduced after [[ref:libraries/lex/reference/metalex_chart|METALEX]] . + +===Library example=== + +The EiffelStudio delivery includes (in the examples/library/lex subdirectory) a simple example using the EiffelLex library classes. The example applies EiffelLex library facilities to the analysis of a language which is none other than Eiffel itself. + +The root class of that example, EIFFEL_SCAN, is only a few lines long; it relies on the general mechanism provided by [[ref:libraries/lex/reference/scanning_chart|SCANNING]] (see below). The actual lexical grammar is given by a lexical grammar file (a concept explained below): the file of name eiffel_regular in the same directory. + +===Dealing with finite automata=== + +Lexical analysis relies on the theory of finite automata. The most advanced of the classes discussed in this chapter, [[ref:libraries/lex/reference/lex_builder_chart|LEX_BUILDER]] , relies on classes describing various forms of automata: +* [[ref:libraries/lex/reference/dfa_chart|DFA]] : deterministic finite automata. +* [[ref:libraries/lex/reference/pdfa_chart|PDFA]] : partially deterministic finite automata. +* [[ref:libraries/lex/reference/ndfa_chart|NDFA]] : non-deterministic finite automata. +* [[ref:libraries/lex/reference/automaton_chart|AUTOMATON]] , the most general: finite automata. +* [[ref:libraries/lex/reference/fixed_automaton_chart|FIXED_AUTOMATON]] , [[ref:libraries/lex/reference/linked_automaton_chart|LINKED_AUTOMATON]] . + +These classes may also be useful for systems that need to manipulate finite automata for applications other than lexical analysis. The interface of [[ref:libraries/lex/reference/lex_builder_chart|LEX_BUILDER]] , which includes the features from [[ref:libraries/lex/reference/automaton_chart|AUTOMATON]] , [[ref:libraries/lex/reference/ndfa_chart|NDFA]] and [[ref:libraries/lex/reference/pdfa_chart|PDFA]] , will provide the essential information. + +==TOKENS== + +A lexical analyzer built through any of the techniques described in the rest of this chapter will return tokens - instances of class [[ref:libraries/lex/reference/token_chart|TOKEN]] . Here are the most important features of this class: +* string_value: a string giving the token's contents. +* type: an integer giving the code of the token's type. The possible token types and associated integer codes are specified during the process of building the lexical analyzer in one of the ways described below. +* is_keyword: a boolean indicating whether the token is a keyword. +* keyword_code: an integer, meaningful only if is_keyword is True, and identifying the keyword by the code that was given to it during the process of building the analyzer. +* line_number, column_number: two integers indicating where the token appeared in the input text. + +==BUILDING AND USING LEXICAL ANALYZERS== + +The general method for performing lexical analysis is the following. +# Create an instance of [[ref:libraries/lex/reference/lexical_chart|LEXICAL]] , giving a lexical analyzer for the desired grammar. +# Store the analyzer into a file. +# Retrieve the analyzer from the file. +# Use the analyzer to analyze the tokens of one or more input texts by calling the various features of class [[ref:libraries/lex/reference/lexical_chart|LEXICAL]] on this object. + +Steps 2 and 3 are obviously unnecessary if this process is applied as a single sequence. But in almost all practical cases you will want to use the same grammar to analyze many different input texts. Then steps 1 and 2 will be performed once and for all as soon as the lexical grammar is known, yielding an instance of [[ref:libraries/lex/reference/lexical_chart|LEXICAL]] that step 2 stores into a file; then in every case that requires analyzing a text you will simply retrieve the analyzer and apply it, performing steps 3 and 4 only. + +The simplest way to store and retrieve the instance of [[ref:libraries/lex/reference/lexical_chart|LEXICAL]] and all related objects is to use the facilities of class [[ref:libraries/base/reference/storable_chart|STORABLE]] : procedure store and one of the retrieval procedures. To facilitate this process, [[ref:libraries/lex/reference/lexical_chart|LEXICAL]] inherits from [[ref:libraries/base/reference/storable_chart|STORABLE]] . + +The next sections explain how to perform these various steps. In the most common case, the best technique is to inherit from class [[ref:libraries/lex/reference/scanning_chart|SCANNING]] , which provides a framework for retrieving an analyzer file if it exists, creating it from a grammar description otherwise, and proceed with the lexical analysis of one or more input texts. + +==LEXICAL GRAMMAR FILES AND CLASS SCANNING== + +Class [[ref:libraries/lex/reference/scanning_chart|SCANNING]] may be used as an ancestor by classes that need to perform lexical analysis. When using [[ref:libraries/lex/reference/scanning_chart|SCANNING]] you will need a '''lexical grammar file''' that contains the description of the lexical grammar. Since it is easy to edit and adapt a file without modifying the software proper, this technique provides flexibility and supports the incremental development and testing of lexical analyzers. + +===The build procedure=== + +To obtain a lexical analyzer in a descendant of class [[ref:libraries/lex/reference/scanning_chart|SCANNING]] , use the procedure + + build (store_file_name, grammar_file_name: STRING) + +If no file of name store_file_name exists, then build reads the lexical grammar from the file of name grammar_file_name, builds the corresponding lexical analyzer, and stores it into store_file_name. + +If there already exists a file of name grammar_file_name, build uses it to recreate an analyzer without using the grammar_file_name . +===Lexical grammar files=== + +A lexical grammar file (to be used as second argument to build, corresponding to grammar_file_name) should conform to a simple structure, of which the file ''eiffel_regular'' in the examples directory provides a good illustration. + +Here is the general form: + +Token_type_1 Regular_expression_1 +Token_type_2 Regular_expression_2 +... +Token_type_m Regular_expression_m + + +-- Keywords + +Keyword_1 +Keyword_2 +... +Keyword_n + + + +In other words: one or more lines, each containing the name of a token type and a '''regular expression'''; a line beginning with two dashes -- (the word '''Keywords''' may follow them to signal that this is the beginning of keywords); and one or more lines containing one keyword each. + +Each ''Token_type_i'' is the name of a token type, such as ''Identifier'' or ''Decimal_constant''. Each ''Regular_expression_i'' is a regular expression, built according to a precisely specified format. That format is defined later in this chapter, but even without having seen that definition it is not hard to understand the following small and typical example of lexical grammar file without keywords: + +Decimal '0'..'9' +Natural +('0'..'9') +Integer ['+'|'-'] '1'..'9' *('0'..'9') + + +The first expression describes a token type whose specimens are tokens made of a single-letter decimal digit (any character between 0 and 9). In the second, the + sign denotes repetition (one or more); the specimens of the corresponding token type are all non-empty sequences of decimal digits - in other words, natural numbers, with leading zeroes permitted. In the third, the | symbol denotes alternation, and the asterisk denotes repetition (zero or more); the corresponding tokens are possibly signed integer constants, with no leading zeroes. + +As explained below, keywords are regular expressions which are treated separately for convenience and efficiency. If you are using lexical grammar files of the above form, all keywords must be specimens of the last regular expression given ( ''Regular_expression_m'' above). More details below. + +===Using a lexical analyzer=== + +Once build has given you an analyzer, you may use it to analyze input texts through calls to the procedure + + analyze (input_file_name: STRING) + +This will read in and process successive input tokens. Procedure analyze will apply to each of these tokens the action of procedure do_a_token. As defined in SCANNING, this procedure prints out information on the token: its string value, its type, whether it is a keyword and if so its code. You may redefine it in any descendant class so as to perform specific actions on each token. + +The initial action begin_analysis, which by default prints a header, and the terminal action end_analysis, which by default does nothing, may also be redefined. + +To build lexical analyzers which provide a higher degree of flexibility, use [[ref:libraries/lex/reference/metalex_chart|METALEX]] or [[ref:libraries/lex/reference/lex_builder_chart|LEX_BUILDER]] , as described in the last part of this chapter. + +==ANALYZING INPUT== + +Let us look more precisely at how we can use a lexical analyzer to analyze an input text. + +===Class LEXICAL=== + +Procedure analyze takes care of the most common needs of lexical analysis. But if you need more advanced lexical analysis facilities you will need an instance of class [[ref:libraries/lex/reference/lexical_chart|LEXICAL]] (a direct instance of [[ref:libraries/lex/reference/lexical_chart|LEXICAL]] itself or of one of its proper descendants). If you are using class [[ref:libraries/lex/reference/scanning_chart|SCANNING]] as described above, you will have access to such an instance through the attribute analyzer. + +This discussion will indeed assume that you have an entity attached to an instance of [[ref:libraries/lex/reference/lexical_chart|LEXICAL]] . The name of that entity is assumed to be analyzer, although it does not need to be the attribute from [[ref:libraries/lex/reference/scanning_chart|SCANNING]] . You can apply to that analyzer the various exported features features of class [[ref:libraries/lex/reference/lexical_chart|LEXICAL]] , explained below. All the calls described below should use analyzer as their target, as in + + analyzer.set_file ("my_file_name") + + +===Creating, retrieving and storing an analyzer=== + +To create a new analyzer, use + + create analyzer.make_new + + +You may also retrieve an analyzer from a previous session. [[ref:libraries/lex/reference/lexical_chart|LEXICAL]] is a descendant from [[ref:libraries/base/reference/storable_chart|STORABLE]] , so you can use feature retrieved for that purpose. In a descendant of [[ref:libraries/base/reference/storable_chart|STORABLE]] , simply write + + analyzer ?= retrieved + + +If you do not want to make the class a descendant of [[ref:libraries/base/reference/storable_chart|STORABLE]] , use the creation procedure make of [[ref:libraries/lex/reference/lexical_chart|LEXICAL]] , not to be confused with make_new above: + + create analyzer.make + analyzer ?= analyzer.retrieved + + +===Choosing a document=== + +To analyze a text, call set_file or set_string to specify the document to be parsed. With the first call, the analysis will be applied to a file; with the second, to a string. + +{{note|if you use procedure analyze of [[ref:libraries/lex/reference/scanning_chart|SCANNING]] , you do not need any such call, since analyze calls set_file on the file name passed as argument. }} + +===Obtaining the tokens=== + +The basic procedure for analyzing successive tokens in the text is get_token, which reads in one token and sets up various attributes of the analyzer to record properties of that token: +* last_token, a function of type [[ref:libraries/lex/reference/token_chart|TOKEN]] , which provides all necessary information on the last token read. +* token_line_number and token_column_number, to know where the token is in the text. These queries return results of type INTEGER. +* token_type, giving the regular expression type, identified by its integer number (which is the value No_token if no correct token was recognized). +* other_possible_tokens, an array giving all the other possible token types of the last token. (If token_type is No_token the array is empty.) +* end_of_text, a boolean attribute used to record whether the end of text has been reached. If so, subsequent calls to get_token will have no effect. + +Procedure get_token recognizes the longest possible token. So if <, = and <= are all regular expressions in the grammar, the analyzer recognizes <= as one token, rather than < followed by =. You can use other_possible_tokens to know what shorter tokens were recognized but not retained. + +If it fails to recognize a regular expression, get_token sets token_type to No_token and advances the input cursor by one character. + +===The basic scheme=== + +Here is the most common way of using the preceding facilities: + + from + set_file ("text_directory/text_to_be_parsed") + -- Or: set_string ("string to parse") + begin_analysis + until + end_of_text + loop + analyzer.get_token + if analyzer.token_type = No_token then + go_on + end + do_a_token (lexical.last_token) + end + end_analysis + + +This scheme is used by procedure analyze of class [[ref:libraries/lex/reference/scanning_chart|SCANNING]] , so that in standard cases you may simply inherit from that class and redefine procedures begin_analysis, do_a_token, and end_analysis. If you are not inheriting from [[ref:libraries/lex/reference/scanning_chart|SCANNING]] , these names simply denote procedures that you must provide. + +==REGULAR EXPRESSIONS== + +The EiffelLex library supports a powerful set of construction mechanisms for describing the various types of tokens present in common languages such as programming languages, specification languages or just text formats. These mechanisms are called '''regular expressions'''; any regular expression describes a set of possible tokens, called the '''specimens''' of the regular expression. + +Let us now study the format of regular expressions. This format is used in particular for the lexical grammar files needed by class [[ref:libraries/lex/reference/scanning_chart|SCANNING]] and (as seen below) by procedure read_grammar of class [[ref:libraries/lex/reference/metalex_chart|METALEX]] . The ''eiffel_regular'' grammar file in the examples directory provides an extensive example. + +Each regular expression denotes a set of tokens. For example, the first regular expression seen above,
+ + + + '0'..'9' + +
+denotes a set of ten tokens, each consisting of a single digit. + +===Basic expressions=== + +A character expression, written '' 'character' '' where ''character'' is a single character, describes a set of tokens with just one element: the one-character token character. For example, '' '0' '' describes the set containing the single-digit single token ''0''. + +Cases in which character is not a printable character use the following conventions: +{| border="1" +|- +| '\ooo' +| Character given by its three-digit octal code ''ooo''. +|- +| '\xx' +| Character given by its two-digit hexadecimal code ''xx''.
+(Both lower- and upper-case may be used for letters in ''xx''.) +|- +| '\r' +| Carriage return +|- +| '\'' +| Single quote +|- +| '\\' +| Backslash +|- +| '\t' +| Tabulation +|- +| '\n' +| New line +|- +| '\b' +| Backspace +|- +| '\f' +| Form feed +|} + +===Intervals=== + +An interval, written ''lower..upper'' where ''lower'' and ''upper'' are character expressions, describes a set of one-character tokens: all the characters whose ASCII code is between the codes for the characters in ''lower'' and ''upper''. For example, '' '0'..'9' '' contains all tokens made of a single decimal digit. + +===Basic operator expressions=== + +A parenthesized expression, written (''exp'') where ''exp'' is a regular expression, describes the same set of tokens as ''exp''. This serves to remove ambiguities in complex regular expressions. For example, the parenthesized expression ('' '0'..'9' '') also describes all single-decimal-digit tokens. + +A difference, written ''interval - char'', where ''interval'' is an interval expression and ''char'' is a character expression, describes the set of tokens which are in ''exp'' but not in ''char''. For example, the difference '' '0'..'9' - '4' '' describes all single-decimal-digit tokens except those made of the digit 4. + +{{caution|A difference may only apply to an interval and a single character. }} + +===Iterations=== + +An unbounded iteration, written ''*exp'' or ''+exp'' where ''exp'' is a regular expression, describes the set of tokens made of sequences of zero or more specimens of ''exp'' (in the first form, using the asterisk), or of one or more specimens of ''exp'' (in the second form, using the plus sign). For example, the iteration ''+('0'..'9')'' describes the set of tokens made of one or more consecutive decimal digits. + +A fixed iteration, written ''n exp'' where ''n'' is a natural integer constant and ''exp'' is a regular expression, describes the set of tokens made of sequences of exactly ''n'' specimens of ''exp''. For example, ''3 ('A'..'Z')'' describes the set of all three-letter upper-case tokens. +===Other operator expressions=== + +A concatenation, written exp1 exp2 ... expn, describes the set of tokens made of a specimen of exp1 followed by a specimen of exp2 etc. For example, the concatenation '' '1'..'9' * ('0'..'9')'' describes the set of tokens made of one or more decimal digits, not beginning with a zero - in other words, integer constants in the usual notation. + +An optional component, written ''[exp]'' where ''exp'' is a regular expression, describes the set of tokens that includes the empty token and all specimens of ''exp''. Optional components usually appear in concatenations. + +Concatenations may be inconvenient when the concatenated elements are simply characters, as in '' 'A' ' ' 'T' 'e' 'x' 't' ''. In this case you may use a '''string''' in double quotes, as in
+ + "A Text" + + +More generally, a string is written "a1 a2 ... an" for ''n >= 0'', where the "ai" are characters, and is an abbreviation for the concatenation 'a1' 'a2' ... 'an', representing a set containing a single token. In a string, the double quote character " is written \" and the backslash character \ is written \\. No other special characters are permitted; if you need special characters, use explicit concatenation. As a special case, "" represents the set containing a single empty token. + +A union, written exp1 | exp2 | ... | expn, describes the set of tokens which are specimens of exp1, or of exp2, etc. For example, the union ''('a'..'z') | ('A'..'Z')'' describes the set of single-letter tokens (lower-case or upper-case). + +===Predefined expressions=== + +A joker, written '''$?''', describes the set of all tokens made of exactly one character. A joker is considered to be an interval expression, so that it may be the first operand of a difference operation. + +A printable, written '''$P''', describes the set of all tokens made of exactly one printable character. + +A blank, written '''$B''', describes the set of all tokens made of one or more specimens of the characters blank, new-line, carriage-return and tabulation. + +The following non-elementary forms are abbreviations for commonly needed regular expressions: +{| border="1" +|- +| Code +| Equivalent expression +| Role +|- +| '''$L''' +| '' '\n' '' +| New-line character +|- +| '''$N''' +| ''+('0'..'9')'' +| Natural integer constants +|- +| '''$R''' +| '' ['+'|'-'] +('0'..'9') '.' *('0'..'9')['e'|'E' ['+'|'-'] +('0'..'9')] '' +| Floating point constants +|- +| '''$W''' +| '' +( '''$P''' - ' ' - '\t' - '\n' - '\r') '' +| Words +|- +| '''$Z''' +| '' ['+'|'-'] +('0'..'9') '' +| Possibly signed integer constants +|} + +A delimited string, written ''->string'', where ''string'' is of the form,"a1 a2 ... an", represents the set of tokens made of any number of printable characters and terminated by ''string''. +One more form of regular expression, case-sensitive expressions, using the ~ symbol, will be introduced below. + +===Combining expression-building mechanisms=== + +You may freely combine the various construction mechanisms to describe complex regular expressions. Below are a few examples. +{| border="1" +|- +| '' 'a'..'z' - 'c' - 'e' '' +| Single-lower-case-letter tokens, except ''c'' and ''e''. +|- +| ''$? - '\007''' +| Any single-character token except ASCII 007. +|- +| ''+('a'..'z')'' +| One or more lower-case letters. +|- +| '' ['+'|'-'] '1'..'9' *('0'..'9') '' +| Integer constants, optional sign, no leading zero. +|- +| ''->"*/"'' +| Any string up to and including an occurrence of */
+(the closing symbol of a PL/I or C comment). +|- +| ''"\"" ->"\""'' +| Eiffel strings. +|} + +===Dealing with keywords=== + +Many languages to be analyzed have keywords - or, more generally, "reserved words". Eiffel, for example, has reserved words such as class and Result. +{{note|in Eiffel terminology reserved words include keywords; a keyword is a marker playing a purely syntactical role, such as class. Predefined entities and expressions such as Result and Current, which have an associated value, are considered reserved words but not keywords. The present discussion uses the term "keyword" although it can be applied to all reserved words. }} + +In principle, keywords could be handled just as other token types. In Eiffel, for example, one might treat each reserved words as a token type with only one specimen; these token types would have names such as Class or Then and would be defined in the lexical grammar file: + +''Class'' ''''c' 'l' 'a' 's' 's''''
+''Then'' ''''t' 'h' 'e' 'n''''
+... + +This would be inconvenient. To simplify the task of language description, and also to improve the efficiency of the lexical analysis process, it is usually preferable to treat keywords as a separate category. + +If you are using class SCANNING and hence a lexical grammar file, the list of keywords, if any, must appear at the end of the file, one per line, preceded by a line that simply reads + +'''-- Keywords''' + +For example the final part of the example Eiffel lexical grammar file appears as: + + ... Other token type definitions ... +Identifier ~('a'..'z') *(~('a'..'z') | '_' | ('0'..'9')) + +-- Keywords +alias +all +and +as +BIT +BOOLEAN +... Other reserved words ... + + +{{caution|Every keyword in the keyword section must be a specimen of one of the token types defined for the grammar, and that token type must be the last one defined in the lexical grammar file, just before the '''Keywords''' line. So in Eiffel where the keywords have the same lexical structure as identifiers, the last line before the keywords must be the definition of the token type ''Identifier'', as shown above. }} + +{{note|The rule that all keywords must be specimens of one token type is a matter of convenience and simplicity, and only applies if you are using SCANNING and lexical grammar files. There is no such restriction if you rely directly on the more general facilities provided by [[ref:libraries/lex/reference/metalex_chart|METALEX]] or [[ref:libraries/lex/reference/lex_builder_chart|LEX_BUILDER]] . Then different keywords may be specimens of different regular expressions; you will have to specify the token type of every keyword, as explained later in this chapter. }} + +===Case sensitivity=== + +By default, letter case is not significant for regular expressions and keywords. So if ''yes'' matches a token type defined by a regular expression, or is a keyword, the input values ''Yes'', ''yEs'' and ''yES'' will all yield the same token or keyword. This also means that '' 'a'..'z' '' and '' 'a'..'z' | 'A'..'Z' '' describe the same set of tokens. + +The regular expression syntax introduced above offers a special notation to specify that a particular expression is case-sensitive: ''~exp'', where ''exp'' is a regular expression. For example, ''~('A'..'Z')'' only covers single-upper-case-letter tokens. But for all other kinds of expression letter case is not taken into account. + +You may change this default behavior through a set of procedures introduced in class [[ref:libraries/lex/reference/lex_builder_chart|LEX_BUILDER]] and hence available in its descendants [[ref:libraries/lex/reference/metalex_chart|METALEX ]] and [[ref:libraries/lex/reference/scanning_chart|SCANNING]] . + +To make subsequent regular expressions case-sensitive, call the procedure + + distinguish_case + + +To revert to the default mode where case is not significant, call the procedure + + ignore_case + + +Each of these procedures remains in effect until the other one is called, so that you only need one call to define the desired behavior. + +For keywords, the policy is less tolerant. A single rule is applied to the entire grammar: keywords are either all case-sensitive or all case-insensitive. To make all keywords case-sensitive, call + + keywords_distinguish_case + + +The inverse call, corresponding to the default rule, is + + keywords_ignore_case + + +Either of these calls must be executed before you define any keywords; if you are using [[ref:libraries/lex/reference/scanning_chart|SCANNING]] , this means before calling procedure build. Once set, the keyword case-sensitivity policy cannot be changed. + +==USING METALEX TO BUILD A LEXICAL ANALYZER== + +(You may skip the rest of this chapter if you only need simple lexical facilities.) + +Class [[ref:libraries/lex/reference/scanning_chart|SCANNING]] , as studied above, relies on a class [[ref:libraries/lex/reference/metalex_chart|METALEX]] . In some cases, you may prefer to use the features of [[ref:libraries/lex/reference/metalex_chart|METALEX]] directly. Since [[ref:libraries/lex/reference/scanning_chart|SCANNING]] inherits from [[ref:libraries/lex/reference/metalex_chart|METALEX]] , anything you do with [[ref:libraries/lex/reference/metalex_chart|METALEX]] can in fact be done with [[ref:libraries/lex/reference/scanning_chart|SCANNING]] , but you may wish to stay with just [[ref:libraries/lex/reference/metalex_chart|METALEX]] if you do not need the additional features of [[ref:libraries/lex/reference/scanning_chart|SCANNING]] . + +===Steps in using METALEX=== + +[[ref:libraries/lex/reference/metalex_chart|METALEX]] has an attribute analyzer which will be attached to a lexical analyzer. This class provides tools for building a lexical analyzer incrementally through explicit feature calls; you can still use a lexical grammar file, but do not have to. + +The following extract from a typical descendant of [[ref:libraries/lex/reference/metalex_chart|METALEX]] illustrates the process of building a lexical analyzer in this way: + + Upper_identifier, Lower_identifier, Decimal_constant, Octal_constant, Word: INTEGER is unique + + ... + + distinguish_case + keywords_distinguish_case + put_expression("+('0'..'7'"), Octal_constant, "Octal") + put_expression ("'a'..'z' *('a'..'z'|'0'..'9'|'_')", Lower_identifier, "Lower") + put_expression ("'A'..'Z' *('A'..'Z'|'0'..'9'|'_' )", Upper_identifier, "Upper") + + + dollar_w (Word) + ... + put_keyword ("begin", Lower_identifier) + put_keyword ("end", Lower_identifier) + put_keyword ("THROUGH", Upper_identifier) + ... + make_analyzer + + +This example follows the general scheme of building a lexical analyzer with the features of [[ref:libraries/lex/reference/metalex_chart|METALEX]] , in a class that will normally be a descendant of [[ref:libraries/lex/reference/metalex_chart|METALEX]] : +# Set options, such as case sensitivity. +# Record regular expressions. +# Record keywords (this may be interleaved with step 2.) +# "Freeze" the analyzer by a call to make_analyzer. + +To perform steps 2 to 4 in a single shot and generate a lexical analyzer from a lexical grammar file, as with [[ref:libraries/lex/reference/scanning_chart|SCANNING]] , you may use the procedure + + read_grammar (grammar_file_name: STRING) + + +In this case all the expressions and keywords are taken from the file of name grammar_file_name rather than passed explicitly as arguments to the procedures of the class. You do not need to call make_analyzer, since read_grammar includes such a call. + +The rest of this discussion assumes that the four steps are executed individually as shown above, rather than as a whole using read_grammar. +===Recording token types and regular expressions=== + +As shown by the example, each token type, defined by a regular expression, must be assigned an integer code. Here the developer has chosen to use Unique constant values so as not to worry about selecting values for these codes manually, but you may select any values that are convenient or mnemonic. The values have no effect other than enabling you to keep track of the various lexical categories. Rather than using literal values directly, it is preferable to rely on symbolic constants, Unique or not, which will be more mnemonic. + +Procedure put_expression records a regular expression. The first argument is the expression itself, given as a string built according to the rules seen earlier in this chapter. The second argument is the integer code for the expression. The third argument is a string which gives a name identifying the expression. This is useful mostly for debugging purposes; there is also a procedure put_nameless_expression which does not have this argument and is otherwise identical to put_expression. + +Procedure dollar_w corresponds to the '''$W''' syntax for regular expressions. Here an equivalent call would have been + + put_nameless_expression ( "$W" ,Word ) + + +Procedure declare_keyword records a keyword. The first argument is a string containing the keyword; the second argument is the regular expression of which the keyword must be a specimen. The example shows that here - in contrast with the rule enforced by [[ref:libraries/lex/reference/scanning_chart|SCANNING]] - not all keywords need be specimens of the same regular expression. + +The calls seen so far record a number of regular expressions and keywords, but do not give us a lexical analyzer yet. To obtain a usable lexical analyzer, you must call + + make_analyzer + + +After that call, you may not record any new regular expression or keyword. The analyzer is usable through attribute analyzer. +{{note|for readers knowledgeable in the theory of lexical analysis: one of the most important effects of the call to make_analyzer is to transform the non-deterministic finite automaton resulting from calls such as the ones above into a deterministic finite automaton. }} + +Remember that if you use procedure read_grammar, you need not worry about make_analyzer, as the former procedure calls the latter. +Another important feature of class [[ref:libraries/lex/reference/metalex_chart|METALEX]] is procedure store_analyzer, which stores the analyzer into a file whose name is passed as argument, for use by later lexical analysis sessions. To retrieve the analyzer, simply use procedure retrieve_analyzer, again with a file name as argument. + +==BUILDING A LEXICAL ANALYZER WITH LEX_BUILDER== + + + +To have access to the most general set of lexical analysis mechanisms, you may use class [[ref:libraries/lex/reference/lex_builder_chart|LEX_BUILDER]] , which gives you an even finer grain of control than [[ref:libraries/lex/reference/metalex_chart|METALEX]] . This is not necessary in simple applications. + +===Building a lexical analyzer=== + +[[ref:libraries/lex/reference/lex_builder_chart|LEX_BUILDER]] enables you to build a lexical analyzer by describing successive token types and keywords. This is normally done in a descendant of [[ref:libraries/lex/reference/lex_builder_chart|LEX_BUILDER]] . For each token type, you call a procedure that builds an object, or '''tool''', representing the associated regular expression. + +For the complete list of available procedures, refer to the flat-short form of the class; there is one procedure for every category of regular expression studied earlier in this chapter. Two typical examples of calls are: + + interval ('a', 'z') + -- Create an interval tool + + union (Letter, Underlined) + -- Create a union tool + + +Every such procedure call also assigns an integer index to the tool it creates; this number is available through the attribute last_created_tool. You will need to record it into an integer entity, for example Identifier or Letter. +===An example=== + +The following extract from a typical descendant of [[ref:libraries/lex/reference/lex_builder_chart|LEX_BUILDER]] illustrates how to create a tool representing the identifiers of an Eiffel-like language. + + Identifier, Letter, Digit, Underlined, Suffix, Suffix_list: INTEGER + + build_identifier + do + interval ('a', 'z') + Letter := last_created_tool + interval ('0', '9') + Digit := last_created_tool + interval ('_', '_') + Underlined := last_created_tool + union (Digit, Underlined) + Suffix := last_created_tool + iteration (Suffix) + Suffix_list := last_created_tool + append (Letter, Suffix_list) + Identifier := last_created_tool + end + + +Each token type is characterized by a number in the tool_list. Each tool has a name, recorded in tool_names, which gives a readable form of the corresponding regular expression. You can use it to check that you are building the right tool. +===Selecting visible tools=== + +In the preceding example, only some of the tools, such as Identifier, are of interest to the clients. Others, such as Suffix and Suffix_list, only play an auxiliary role. + +When you create a tool, it is by default invisible to clients. To make it visible, use procedure select_tool. Clients will need a number identifying it; to set this number, use procedure associate. For example the above extract may be followed by: + + select_tool (Identifier) + associate (Identifier, 34) + put_keyword ("class", Identifier) + put_keyword ("end", Identifier) + put_keyword ("feature", Identifier) + + +If the analysis encounters a token that belongs to two or more different selected regular expressions, the one entered last takes over. Others are recorded in the array other_possible_tokens. + +If you do not explicitly give an integer value to a regular expression, its default value is its rank in tool_list. diff --git a/documentation/18.11/solutions/text-processing/eiffellex/index.wiki b/documentation/18.11/solutions/text-processing/eiffellex/index.wiki new file mode 100644 index 00000000..664cd32e --- /dev/null +++ b/documentation/18.11/solutions/text-processing/eiffellex/index.wiki @@ -0,0 +1,11 @@ +[[Property:title|EiffelLex]] +[[Property:weight|1]] +[[Property:uuid|52e88d58-1a02-d4e2-5503-e405253e7656]] +==EiffelLex Library== + +Type: Library
+Platform: Any
+ +Eiffel classes to facilitate lexical analysis. + + diff --git a/documentation/18.11/solutions/text-processing/eiffelparse/eiffelparse-class-reference.wiki b/documentation/18.11/solutions/text-processing/eiffelparse/eiffelparse-class-reference.wiki new file mode 100644 index 00000000..665ab8a8 --- /dev/null +++ b/documentation/18.11/solutions/text-processing/eiffelparse/eiffelparse-class-reference.wiki @@ -0,0 +1,5 @@ +[[Property:title|EiffelParse Class Reference]] +[[Property:weight|1]] +[[Property:uuid|6b37fcc9-198c-a846-2ff2-32fc30c0d029]] +==View the [[ref:libraries/parse/reference/index|EiffelParse Class Reference]]== + diff --git a/documentation/18.11/solutions/text-processing/eiffelparse/eiffelparse-tutorial.wiki b/documentation/18.11/solutions/text-processing/eiffelparse/eiffelparse-tutorial.wiki new file mode 100644 index 00000000..794504d8 --- /dev/null +++ b/documentation/18.11/solutions/text-processing/eiffelparse/eiffelparse-tutorial.wiki @@ -0,0 +1,784 @@ +[[Property:title|EiffelParse Tutorial]] +[[Property:weight|0]] +[[Property:uuid|b5861080-e5fd-dbb8-bf89-452915b3483e]] +==OVERVIEW== + +Parsing is the task of analyzing the structure of documents such as programs, specifications or other structured texts. + +Many systems need to parse documents. The best-known examples are compilers, interpreters and other software development tools; but as soon as a system provides its users with a command language, or processes input data with a non-trivial structure, it will need parsing facilities. + +This chapter describes the EiffelParse library, which you can use to process documents of many different types. It provides a simple and flexible parsing scheme, resulting from the full application of object-oriented principles. + +Because it concentrates on the higher-level structure, the EiffelParse library requires auxiliary mechanisms for identifying a document's lexical components: words, numbers and other such elementary units. To address this need it is recommended, although not required, to complement EiffelParse with the EiffelLex library studied in the previous chapter. + +Figure 1 shows the inheritance structure of the classes discussed in this chapter. + +[[Image:figure1]] + +Figure 1: Parse class structure + +==WHY USE THE EIFFELPARSE LIBRARY== + +Let us fist look at the circumstances under which you may want - or not want - to use the EiffelParse library. + +===The EiffelParse library vs. parser generators=== + +Parsing is a heavily researched area of computing science and many tools are available to generate parsers. In particular, the popular Yacc tool, originally developed for Unix, is widely used to produce parsers. + +In some cases Yacc or similar tools are perfectly adequate. It is also sometimes desirable to write a special-purpose parser for a language, not relying on any parser generator. Several circumstances may, however, make the Parse library attractive: +* The need to interface the parsing tasks with the rest of an object-oriented system (such as a compiler or more generally a "document processor" as defined below) in the simplest and most convenient way. +* The desire to apply object-oriented principles as fully as possible to all aspects of a system, including parsing, so as to gain the method's many benefits, in particular reliability, reusability and extendibility. +* The need to tackle languages whose structure is not easily reconciled with the demands of common parser generator, which usually require the grammar to be LALR (1). (The EiffelParse library uses a more tolerant LL scheme, whose only significant constraint is absence of left-recursivity; the library provides mechanisms to detect this condition, which is easy to correct.) +* The need to define several possible semantic treatments on the same syntactic structure. + +The last reason may be the most significant practical argument in favor of using EiffelParse. Particularly relevant is the frequent case of a software development environment in which a variety of tools all work on the same basic syntactic structure. For example an environment supporting a programming language such as Pascal or Eiffel may include a compiler, an interpreter, a pretty-printer, software documentation tools (such as Eiffel's short and flat-short facilities), browsing tools and several other mechanisms that all need to perform semantic actions on software texts that have the same syntactic structure. With common parser generators such as Yacc, the descriptions of syntactic structure and semantic processing are inextricably mixed, so that you normally need one new specification for each tool. This makes design, evolution and reuse of specifications difficult and error-prone. + +In contrast, the EiffelParse library promotes a specification style whereby syntax and semantics are kept separate, and uses inheritance to allow many different semantic descriptions to rely on the same syntactic stem. This will make EiffelParse particularly appropriate in such cases. + +===A word of caution=== + +At the time of publication the EiffelParse library has not reached the same degree of maturity as the other libraries presented in this book. It should thus be used with some care. You will find at the end of this chapter a few comments about the work needed to bring the library to its full realization. + +==AIMS AND SCOPE OF THE EIFFELPARSE LIBRARY== + +To understand the EiffelParse library it is necessary to appreciate the role of parsing and its place in the more general task of processing documents of various kinds. + +===Basic terminology=== + +First, some elementary conventions. The word '''document''' will denote the texts to be parsed. The software systems which perform parsing as part of their processing will be called '''document processors'''. + +Typical document processors are compilers, interpreters, program checkers, specification analyzers and documentation tools. For example the EiffelStudio environment contains a number of document processors, used for compiling, documentation and browsing. + +===Parsing, grammars and semantics=== + +Parsing is seldom an end in itself; rather, it serves as an intermediate step for document processors which perform various other actions. + +Parsing takes care of one of the basic tasks of a document processor: reconstructing the logical organization of a document, which must conform to a certain '''syntax''' (or structure), defined by a '''grammar'''. + +{{note|The more complete name '''syntactic grammar''' avoids any confusion with the ''lexical'' grammars discussed in the [[EiffelLex Tutorial]]. By default, "grammar" with no further qualification will always denote a syntactic grammar. A syntactic grammar normally relies on a lexical grammar, which gives the form of the most elementary components - the tokens - appearing in the syntactic structure. }} + +Once parsing has reconstructed the structure of a document, the document processor will perform various operations on the basis of that structure. For example a compiler will generate target code corresponding to the original text; a command language interpreter will execute the operations requested in the commands; and a documentation tool such as the short and flat-short commands for Eiffel will produce some information on the parsed document. Such operations are called '''semantic actions'''. One of the principal requirements on a good parsing mechanism is that it should make it easy to graft semantics onto syntax, by adding semantic actions of many possible kinds to the grammar. + +The EiffelParse library provides predefined classes which handle the parsing aspect automatically and provide the hooks for adding semantic actions in a straightforward way. This enables developers to write full document processors - handling both syntax and semantics - simply and efficiently. + +As noted at the beginning of this chapter, it is possible to build a single syntactic base and use it for several processors (such as a compiler and a documentation tool) with semantically different goals, such as compilation and documentation. In the EiffelParse library the semantic hooks take the form of deferred routines, or of routines with default implementations which you may redefine in descendants. + +==LIBRARY CLASSES== + +The EiffelParse library contains a small number of classes which cover common document processing applications. The classes, whose inheritance structure was shown at the beginning of this chapter, are: +* [[ref:libraries/parse/reference/construct_chart|CONSTRUCT]] , describing the general notion of syntactical construct. +* [[ref:libraries/parse/reference/aggregate_chart|AGGREGATE]] , describing constructs of the "aggregate" form. +* [[ref:libraries/parse/reference/choice_chart|CHOICE]] , describing constructs of the "choice" form. +* [[ref:libraries/parse/reference/repetition_chart|REPETITION]] , describing constructs of the "repetition" form. +* [[ref:libraries/parse/reference/terminal_chart|TERMINAL]] , describing "terminal" constructs with no further structure. +* [[ref:libraries/parse/reference/keyword_chart|KEYWORD]] , describing how to handle keywords. +* [[ref:libraries/parse/reference/l_interface_chart|L_INTERFACE]] , providing a simple interface with the lexical analysis process and the Lex library. +* [[ref:libraries/parse/reference/input_chart|INPUT]] , describing how to handle the input document. + +==EXAMPLES== +The EiffelStudio delivery includes (in the examples/library/parse subdirectory) a simple example using the EiffelParse Library classes. The example is a processor for "documents" which describe computations involving polynomials with variables. The corresponding processor is a system which obtains polynomial specifications and variable values from a user, and computes the corresponding polynomials. +This example illustrates the most important mechanisms of the EiffelParse Library and provides a guide for using the facilities described in this chapter. The components of its grammar appear as illustrations in the next sections. + +==CONSTRUCTS AND PRODUCTIONS== + +A set of documents possessing common properties, such as the set of all valid Eiffel classes or the set of all valid polynomial descriptions, is called a '''language'''. + +In addition to its lexical aspects, the description of a language includes both syntactic and semantic properties. The grammar - the syntactic specification - describes the structure of the language (for example how an Eiffel class is organized into a number of clauses); the semantic specification defines the meaning of documents written in the language (for example the run-time properties of instances of the class, and the effect of feature calls). + +To discuss the EiffelParse library, it is simpler to consider "language' as a purely syntactic notion; in other words, a language is simply the set of documents conforming to a certain syntactic grammar (taken here to include the supporting lexical grammar). Any semantic aspect will be considered to belong to the province of a specific document processor for the language, although the technique used for specifying the grammar will make it easy to add the specification of the semantics, or several alternative semantic specifications if desired. + +This section explains how you may define the syntactic base - the grammar. + +===Constructs=== + +A grammar consists of a number of '''constructs''', each representing the structure of documents, or document components, called the '''specimens''' of the construct. For example, a grammar for Eiffel will contain constructs such as Class, Feature_clause and Instruction. A particular class text is a specimen of construct Class. + +Each construct will be defined by a '''production''', which gives the structure of the construct's specimens. For example, a production for Class in an Eiffel grammar should express that a class (a specimen of the Class construct) is made of an optional Indexing part, a Class_header, an optional Formal_generics part and so on. The production for Indexing will indicate that any specimen of this construct - any Indexing part - consists of the keyword '''indexing''' followed by zero or more specimens of Index_clause. + +Although some notations for syntax descriptions such as BNF allow more than one production per construct, the EiffelParse library relies on the convention that every construct is defined by '''at most one''' production. Depending on whether there is indeed such a production, the construct is either '''non-terminal''' or '''terminal''': +* A non-terminal construct (so called because it is defined in terms of others) is specified by a production, which may be of one of three types: aggregate, choice and repetition. The construct will accordingly be called an aggregate, choice or repetition construct. +* A terminal construct has no defining production. This means that it must be defined outside of the syntactical grammar. Terminals indeed come from the '''lexical grammar'''. Every terminal construct corresponds to a token type (regular expression or keyword) of the lexical grammar, for which the parsing duty will be delegated to lexical mechanisms, assumed in the rest of this chapter to be provided by the Lex library although others may be substituted if appropriate. + + +All specimens of terminal constructs are instances of class [[ref:libraries/parse/reference/terminal_chart|TERMINAL]] . A special case is that of keyword constructs, which have a single specimen corresponding to a keyword of the language. For example, if is a keyword of Eiffel. Keywords are described by class [[ref:libraries/parse/reference/keyword_chart|KEYWORD]] , an heir of [[ref:libraries/parse/reference/terminal_chart|TERMINAL]] . + +The rest of this section concentrates on the parsing-specific part: non-terminal constructs and productions. Terminals will be studied in the discussion of how to interface parsing with lexical analysis. + +===Varieties of non-terminal constructs and productions=== + +An aggregate production defines a construct whose specimens are obtained by concatenating ("aggregating") specimens of a list of specified constructs, some of which may be optional. For example, the production for construct Conditional in an Eiffel grammar may read: + +Conditional [=] if Then_part_list [Else_part] end + + +This means that a specimen of Conditional (a conditional instruction) is made of the keyword if, followed by a specimen of Then_part_list, followed by zero or one specimen of Else_part (the square brackets represent an optional component), followed by the keyword end. + +{{note|This notation for productions uses conventions similar to those of the book ''Eiffel: The Language''. Keywords are written in '''boldface italics''' and stand for themselves. Special symbols, such as the semicolon, are written in double quotes, as in ";". The [=] symbol means "is defined as" and is more accurate mathematically than plain =, which, however, is often used for this purpose (see "Introduction to the Theory of Programming Languages", Prentice Hall, 1991, for a more complete discussion of this issue). }} + +A choice production defines a construct whose specimens are specimens of one among a number of specified constructs. For example, the production for construct Type in an Eiffel grammar may read: + +Type [=] Class_type | Class_type_expanded | Formal_generic_name | Anchored | Bit_type + + +This means that a specimen of Type is either a specimen of Class_type, or a specimen of Class_type_expanded etc. + +Finally, a repetition production defines a construct whose specimens are sequences of zero or more specimens of a given construct (called the '''base''' of the repetition construct), separated from each other by a '''separator'''. For example, the production for construct Compound in an Eiffel grammar may read + +Compound [=] {Instruction ";" ...} + + +This means that a specimen of Compound is made of zero or more specimens of Instruction, each separated from the next (if any) by a semicolon. + +These three mechanisms - aggregate, choice and repetition - suffice to describe the structure of a wide array of practical languages. Properties which cannot be handled by them should be dealt with through '''semantic actions''', as explained below. + +===An example grammar=== + +The example directory included in the delivery implements a processor for a grammar describing a simple language for expressing polynomials. A typical "document" in this language is the line + +x; y: x * (y + 8 - (2 * x)) + +The beginning of the line, separated from the rest by a colon, is the list of variables used in the polynomial, separated by semicolons. The rest of the line is the expression defining the polynomial. + +Using the conventions defined above, the grammar may be written as: + +Line [=] Variables ":" Sum +Variables [=] {Identifier ";" ...} +Sum [=] {Diff "+" ...} +Diff [=] {Product "-" ...} +Product [=] {Term " * " ...} +Term [=] Simple_var Int_constant Nested +Nested [=] "(" Sum ")" + + +This grammar assumes a terminal Identifier, which must be defined as a token type in the lexical grammar. The other terminals are keywords, shown as strings appearing in double quotes, for example "+". + +==PARSING CONCEPTS== + +The EiffelParse library supports a parsing mechanism based on the concepts of object-oriented software construction. + +===Class CONSTRUCT=== + +The deferred class [[ref:libraries/parse/reference/construct_chart|CONSTRUCT]] describes the general notion of construct; instances of this class and its descendants are specimens of the constructs of a grammar. + +Deferred though it may be, [[ref:libraries/parse/reference/construct_chart|CONSTRUCT]] defines some useful general patterns; for example, its procedure process appears as:
+ + parse + if parsed then + semantics + end + +
+where procedures parse and semantics are expressed in terms of some more specific procedures, which are deferred. This defines a general scheme while leaving the details to descendants of the class. + +Such descendants, given in the library, are classes [[ref:libraries/parse/reference/aggregate_chart|AGGREGATE]] , [[ref:libraries/parse/reference/choice_chart|CHOICE]] , [[ref:libraries/parse/reference/repetition_chart|REPETITION]] and [[ref:libraries/parse/reference/terminal_chart|TERMINAL]] . They describe the corresponding types of construct, with features providing the operations for parsing their specimens and applying the associated semantic actions. + +===Building a processor=== + +To build a processor for a given grammar, you write a class, called a '''construct class''', for every construct of the grammar, terminal or non-terminal. The class should inherit from [[ref:libraries/parse/reference/aggregate_chart|AGGREGATE]] , [[ref:libraries/parse/reference/choice_chart|CHOICE]] , [[ref:libraries/parse/reference/repetition_chart|REPETITION]] or [[ref:libraries/parse/reference/terminal_chart|TERMINAL]] depending on the nature of the construct. It describes the production for the construct and any associated semantic actions. + +To complete the processor, you must choose a "top construct" for that particular processor, and write a root class. In accordance with the object-oriented method, which implies that "roots" and "tops" should be chosen last, these steps are explained at the end of this chapter. + +The next sections explain how to write construct classes, how to handle semantics, and how to interface parsing with the lexical analysis process. All these tasks rely on a fundamental data abstraction, the notion of '''abstract syntax tree'''. + +===Abstract syntax trees=== + +The effect of processing a document with a processor built from a combination of construct classes is to build an abstract syntax tree for that document, and to apply any requested semantic actions to that tree. + +The syntax tree is said to be abstract because it only includes important structural information and does not retain the concrete information such as keywords and separators. Such concrete information, sometimes called "syntactic sugar", serves only external purposes but is of no use for semantic processing. + +The combination of Eiffel techniques and libraries yields a very simple approach to building and processing abstract syntax trees. Class [[ref:libraries/parse/reference/construct_chart|CONSTRUCT]] is a descendant of the Data Structure Library class [[ref:libraries/base/reference/two_way_tree_chart|TWO_WAY_TREE]] , describing a versatile implementation of trees; so, as a consequence, are [[ref:libraries/parse/reference/construct_chart|CONSTRUCT's]] own descendants. The effect of parsing any specimen of a construct is therefore to create an instance of the corresponding construct class. This instance is (among other things) a tree node, and is automatically inserted at its right place in the abstract syntax tree. + +As noted in the discussion of trees, class [[ref:libraries/base/reference/two_way_tree_chart|TWO_WAY_TREE]] makes no formal distinction between the notions of tree and tree node. So you may identify the abstract syntax tree with the object (instance of [[ref:libraries/parse/reference/construct_chart|CONSTRUCT]] ) representing the topmost construct specimen in the structure of the document being analyzed. + +===The production function=== + +A construct class describes the syntax of a given construct through a function called production, which is a direct representation of the corresponding production. This function is declared in CONSTRUCT as + + production: LINKED_LIST [CONSTRUCT] + -- Right-hand side of the production for the construct + deferred + end + + +Function production remains deferred in classes [[ref:libraries/parse/reference/aggregate_chart|AGGREGATE]] , [[ref:libraries/parse/reference/choice_chart|CHOICE]] and [[ref:libraries/parse/reference/repetition_chart|REPETITION]] . Every effective construct class that you write must provide an effecting of that function. It is important for the efficiency of the parsing process that every effective version of production be a once function. Several examples of such effectings are given below. + +Classes [[ref:libraries/parse/reference/aggregate_chart|AGGREGATE]] , [[ref:libraries/parse/reference/choice_chart|CHOICE]] , [[ref:libraries/parse/reference/repetition_chart|REPETITION]] and [[ref:libraries/parse/reference/terminal_chart|TERMINAL]] also have a deferred function construct_name of type STRING, useful for tracing and debugging. This function should be effected in every construct class to return the string name of the construct, such as "INSTRUCTION" or "CLASS" for construct classes in a grammar of Eiffel. For efficiency reasons, the construct_name function should also be a once function. The form of such a function will always be the same, as illustrated by the following example which may appear in the construct class INSTRUCTION in a processor for Eiffel: + + construct_name: STRING + -- Symbolic name of the construct + once + Result := "INSTRUCTION" + end + + +The examples of the next few sections, which explain how to write construct classes, are borrowed from the small "Polynomial" language mentioned above, which may be found in the examples directory in the ISE Eiffel delivery. + +==PREPARING GRAMMARS== + +Having studied the EiffelParse library principles, let us see how to write grammar productions for various kinds of construct. The main task is to write the production function for each construct class. + +The production function for a descendant of [[ref:libraries/parse/reference/aggregate_chart|AGGREGATE]] will describe how to build a specimen of the corresponding function from a sequence of specimens of each of the constituent constructs. Writing this function from the corresponding production is straightforward. + +As an example, consider the production function of class LINE for the Polynomial example language. The corresponding production is
+ +Line [=] Variables ":" Sum + +
+where Variables and Sum are other constructs, and the colon ":" is a terminal. This means that every specimen of Line consists of a specimen of Variables, followed by a colon, followed by a specimen of Sum. + +Here is the corresponding production function as it appears in class LINE: + + production: LINKED_LIST [CONSTRUCT] + local + var: VARIABLES + sum: SUM + once + create Result.make + Result.forth + create var.make + put (var) + keyword (":") + create sum.make + put (sum) + end + + +As shown by this example, the production function for an aggregate construct class should declare a local entity (here var and sum) for each non-keyword component of the right-hand side, the type of each entity being the corresponding construct class (here VARIABLES and SUM). + +The body of the function should begin with + + create Result.make + Result.forth + +to create the object containing the result. Then for each non-keyword component, represented by the local entity component (this applies to var and sum in the example), there should be a sequence of two instructions, of the form + + create component.make + put (component) + + +For any keyword of associated string ''symbol'', such as the colon ":" in the example, there should be a call to + + keyword (symbol) + + +The order of the various calls to put (for non-keywords) and keyword (for keywords) must be the order of the components in the production. Also, every create component.make instruction must occur before the corresponding call to put (symbol). + +All components in the above example are required. In the general case an aggregate production may have optional components. To signal that a component component of the right-hand side is optional, include a call of the form + + component.set_optional + + +This call may appear anywhere after the corresponding create component instruction. The recommended place is just after the call to put, as in + + create component + put (symbol) + component.set_optional + + +===Choices=== + +The production function for a descendant of CHOICE will describe how to build a specimen of the corresponding function as a specimen of one of the alternative constructs. + +As an example, consider the production function of class TERM for the Polynomial example language. The corresponding production is + +Term [=] Simple_var Poly_integer Nested + +
+where Simple_var, Poly_integer and Nested are other constructs. This means that every specimen of Term consists of one specimen of any one of these three constructs. Here is the corresponding production function as it appears in class TERM: + + production: LINKED_LIST [CONSTRUCT] + local + id: SIMPLE_VAR + val: POLY_INTEGER + nest: NESTED + once + create Result.make + Result.forth + createid.make + put (id) + create val.make + put (val) + create nest.make + put (nest) + end + + +As shown by this example, the production function for a choice construct class must declare a local entity - here id, val and nest - for each alternative component of the right-hand side. The type of each entity is the corresponding construct class - here SIMPLE_VAR, POLY_INTEGER and NESTED. + +The body of the function must begin by + + create Result.make + Result.forth + + +Then for each alternative component represented by a local entity component (in the example this applies to id, val and nest) there should be two instructions of the form + + create component.make + put (component) + + +{{caution|The order of the various calls to put is irrelevant in principle. When a document is parsed, however, the choices will be tried in the order given; so if you know that certain choices occur more frequently than others it is preferable to list them first to speed up the parsing process. }} + +===Repetitions=== + +The production function for a descendant of [[ref:libraries/parse/reference/repetition_chart|REPETITION]] will describe how to build a specimen of the corresponding function as a sequence or zero or more (or, depending on the grammar, one or more) specimens of the base construct. The class must also effect a feature separator of type STRING, usually as a constant attribute. (This feature is introduced as deferred in class [[ref:libraries/parse/reference/repetition_chart|REPETITION]] .) + +As an example, consider the construct Variables in the Polynomial example language. The right-hand side of the corresponding production is
+ +Variables [=] {Identifier ";" ...} + +
+where Identifier is another construct, and the semicolon ";" is a terminal. This means that every specimen of Variables consists of zero or more specimens of Identifier, separated from each other (if more than one) by semicolons. + +Here are the corresponding production function and separator attribute as they appear in class VARIABLES: + + production: LINKED_LIST [IDENTIFIER] + local + base: VAR + once + create Result.make + Result.forth + create base.make + put (base) + end + + separator: STRING = ";" + + + +As shown by this example, function production is built along the same ideas as for aggregates and choices, except that here only one component, base, is required; its type must be the class corresponding to the construct serving as the base of the repetition, VAR in the example. + +==INTERFACE TO LEXICAL ANALYSIS== + +One more type of construct class remains to be discussed: terminal construct classes. Since terminal constructs serve to elevate lexical tokens (regular expressions and keywords) to the dignity of syntactical construct, we must first take a look at how the EiffelParse library classes collaborate with their counterparts in the EiffelLex library. + +===The notion of lexical interface class=== + +To parse a document, you need to get tokens from a lexical analyzer. This is achieved by making some construct classes, in particular those describing terminals, descendants of one of the lexical classes. + +The best technique is usually to write a class covering the lexical needs of the language at hand, from which all construct classes that have some lexical business will inherit. Such a class is called a lexical interface class. + +Lexical interface classes usually follow a common pattern. To take advantage of this uniformity, the EiffelParse library includes a deferred class L_INTERFACE which describes that pattern. Specific lexical interface classes may be written as descendants of L_INTERFACE. + +L_INTERFACE is a simple deferred class, with a deferred procedure obtain_analyzer. It is an heir of METALEX. +===Obtaining a lexical analyzer=== + +An effective descendant of [[ref:libraries/parse/reference/l_interface_chart|L_INTERFACE]] must define procedure obtain_analyzer so that it records into the lexical analyzer the regular expressions and keywords of the language at hand. In writing obtain_analyzer you may use any one of three different techniques, each of which may be the most convenient depending on the precise context, to obtain the required lexical analyzer: +* You may build the lexical analyzer by defining its regular expressions one by one, using the procedures described in the presentation of METALEX, in particular put_expression and put_keyword. +* You may use use procedure retrieve_analyzer from METALEX to retrieve an analyzer which a previous session saved into a file. +* Finally, you may write a lexical grammar file (or reuse an existing one) and process it on the spot by using procedure read_grammar from METALEX. + + +===A lexical interface class=== + +An example of a lexical interface class is POLY_LEX for the Polynomial example language. Here is the complete text of that class: + +indexing + description: "Lexical interface class for the Polynomial language" + +class + POLY_LEX + +inherit + L_INTERFACE + + CONSTANTS + undefine + consistent, + copy, + is_equal, + setup + end + +feature {NONE} + + obtain_analyzer + -- Create lexical analyzer for the Polynomial language + do + ignore_case + keywords_ignore_case + build_expressions + build_keywords + set_separator_type (blanks) + end + + build_expressions + -- Define regular expressions + -- for the Polynomial language + do + put_expression (special_expression, special, "Special") + put_expression ("*('a'..'z')", simple_identifier, "Simple_identifier") + put_expression ("+('0'..'9')", integer_constant, "Integer_constant") + put_expression ("+('\t'|'\n'|' ')", blanks, "Blanks") + end + + special_expression: STRING + -- Regular expression describing Special + once + create Result.make (80) + Result.append ("('\050'..'\057')|") + Result.append ("('\072'..'\076')|") + Result.append ("'['|']'|'|'|'{'|'}'|%"->%"|%":=%"") + end + + build_keywords + -- Define keywords (special symbols) + -- for the Polynomial language + do + put_keyword ("+", special) + put_keyword ("-", special) + put_keyword (";", special) + put_keyword (":", special) + put_keyword ("(", special) + put_keyword (")", special) + put_keyword ("*", special) + end +end + + +This class illustrates the straightforward scheme for writing lexical interface classes. It introduces constants such as Special to represent the regular expressions supported, and effects procedure obtain_analyzer. The role of this procedure is to define lexical conventions (here through calls to ignore_case and keywords_ignore_case), to record the regular expressions (through calls to put_expression, packaged in a procedure build_expressions for clarity), and records the keywords (through calls to put_keyword, packaged in build_keywords). + +All the classes of a document processor that need to interact with the lexical analysis should inherit from a lexical interface class such as POLY_LEX. This is true in particular of the root class of a processor, as discussed below. + +===More on terminal constructs=== + +Terminal construct classes are examples of classes that need to interact with the lexical analysis, and should thus inherit from the lexical interface class. + +Class TERMINAL includes a deferred function token_type of type INTEGER. Every effective descendant of TERMINAL should effect this feature as a constant attribute, whose value is the code for the associated regular expression, obtained from the lexical interface class. As every other construct class, such a descendant should also effect construct_name as a once function. For example, in the Polynomial language, class INT_CONSTANT has the following text: + +class + INT_CONSTANT + +inherit + TERMINAL + + CONSTANTS + +feature + + token_type: INTEGER + do + Result := integer_constant + end + +feature {NONE} + + construct_name: STRING + once + Result := "INT_CONSTANT" + end +end + + +==SPECIFYING THE SEMANTICS== + +As mentioned at the beginning of this chapter, parsing is usually done not for itself but as a way to perform some semantic processing. The EiffelParse Library classes define the general framework for grafting such semantics onto a syntactical stem. + +===Semantic procedures=== + +The principal procedures for defining semantic actions are pre_action and post_action. These are features of class CONSTRUCT. Procedure pre_action describes the actions to be performed before a construct has been recognized; post_action, the actions to be performed after a construct has been recognized. + +As defined in CONSTRUCT, both pre_action and post_action do nothing by default. Any construct class which is a descendant of CONSTRUCT may redefine one or both so that they will perform the semantic actions that the document processor must apply to specimens of the corresponding construct. These procedures are called automatically during processing, before and after the corresponding structures have been parsed. + +For TERMINAL, only one semantic action makes sense. To avoid any confusion, post_action is renamed action in that class and pre_action is renamed unused_pre_action to indicate that it is irrelevant. + +Often, the semantic procedures need to compute various elements of information. These may be recorded using appropriate attributes of the corresponding construct classes. + +{{note|Readers familiar with the theory of parsing and compiling will see that this scheme, using the attributes of Eiffel classes, provides a direct implementation of the "attribute grammar" mechanism. }} + +===Polynomial semantics=== + +As an example let us examine the semantics of the Product construct for the polynomial language. It is a repetition construct, with Term as the base construct; in other words a specimen of Product is a sequence of one or more terms, representing the product term1 * term2 ... * termn. Here is the post_action procedure in the corresponding class PRODUCT: + + + post_action + local + int_value: INTEGER + do + if not no_components then + from + child_start + if not child_after then + int_value := 1 + end + until + child_after + loop + child.post_action + nt_value := int_value * info.child_value + child_forth + end + info.set_child_value (int_value) + end + end + + +Here each relevant construct class has an attribute info used to record the semantic information associated with polynomials and their components, such as child_value, an INTEGER. The post_action takes care of computing the product of all child_values for the children. First, of course, post_action must recursively be applied to each child, to compute its own child_value. + +{{note|Recall that an instance of CONSTRUCT is also a node of the abstract syntax tree, so that all the TWO_WAY_TREE features such as child_value, child_start, child_after and many others are automatically available to access the syntactical structure. }} + +===Keeping syntax and semantics separate=== + +For simple examples such as the Polynomial language, it is convenient to use a single class to describe both the syntax of a construct (through the production function and associated features) and its semantics (action routines and associated features). + +For more ambitious languages and processors, however, it is often preferable to keep the two aspects separate. Such separation of syntax and semantics, and in particular the sharing of the same syntax for different processors with different semantic actions, is hard or impossible to obtain with traditional document processing tools such as Yacc on Unix. Here is how to achieve it with the EiffelParse library: +* First write purely '''syntactic classes''', that is to say construct classes which only effect the syntactical part (in particular function production). As a consequence, these classes usually remain deferred. The recommended convention for such syntactic classes is to use names beginning with S_, for example S_INSTRUCTION or S_LOOP. +* Then for each construct for which a processor defines a certain semantics, define another class, called a '''semantic class''', which inherits from the corresponding syntactic class. The recommended convention for semantic classes is to give them names which directly reflect the corresponding construct name, as in INSTRUCTION or LOOP. + + +To build a semantic class in in step 2 it is often convenient to use multiple inheritance from a syntactic class and a "semantics-only" class. For example in a processor for Eiffel class INSTRUCTION may inherit from both IS_INSTRUCTION and from a semantics-only class INSTRUCTION_PROPERTIES which introduces the required semantic features. + +One of the advantages of this scheme is that it makes it easy to associate two or more types of processing with a single construct, by keeping the same syntactic class (such as IS_INSTRUCTION) but choosing a different pure-semantics class each time. + +As noted earlier in this chapter, this is particularly useful in an environment where different processors need to perform differents actions on specimens of the same construct. In an Eiffel environment, for example, processors that manipulate classes and other Eiffel construct specimens may include a compiler, an interpreter, a flattener (producing the flat form), a class abstracter (producing the short or flat-short form), and various browsing tools such as those provided by Eiffel Software. + +For obvious reasons of convenience and ease of maintenance, it is desirable to let these processors share the same syntactic descriptions. The method just described, relying on multiple inheritance, achieves this goal. + +==HOW PARSING WORKS== + +Classes AGGREGATE, CHOICE, TERMINAL and REPETITION are written in such a way that you do not need to take care of the parsing process. They make it possible to parse any language built according to the rules given - with one limitation, left recursion, discussed below. You can then concentrate on writing the interesting part - semantic processing. + +To derive the maximum benefit from the EiffelParse library, however, it is useful to gain a little more insight into the way parsing works. Let us raise the veil just enough to see any remaining property that is relevant to the building of parsers and document processors. + +===The parsing technique=== + +The EiffelParse library relies on a general approach known as '''recursive descent''', meaning that various choices will be tried in sequence and recursively to recognize a certain specimen. + +If a choice is attempted and fails (because it encounters input that does not conform to what is expected), the algorithm will try remaining choices, after having moved the input cursor back to where it was before the choice that failed. This process is called '''backtracking'''. It is handled by the parsing algorithms in an entirely automatic fashion, without programmer intervention. + +===Left recursion=== + +Recursive descent implies the danger of infinite looping when parsing is attempted for left-recursive productions of the form
+ +A [=] A ... + +
+or, more generally, cases in which the left recursion is indirect, as in
+ +A [=] B ... +B [=] C ... +... +L [=] A ... + + + +Direct left recursion is easy to avoid, but indirect recursion may sneak in in less trivial ways. + +To determine whether the production for a construct is directly or indirectly left-recursive, use the query left_recursion from class CONSTRUCT. + +===Backtracking and the commit procedure=== + +Another potential problem may arise from too much backtracking. In contrast with left recursion, this is a performance issue, not a threat to the correctness of the parsing algorithm. Automatic backtracking is in fact essential to the generality and flexibility of the recursive descent parsing algorithm; but too much of it may degrade the efficiency of the parsing mechanism. + +Two techniques are available to minimize backtracking. One, mentioned above, is to organize the production functions for choice construct classes so that they list the most frequent cases first. The other is to use the commit procedure in the production functions for aggregate constructs. + +A call to commit in an aggregate A is a hint to the parser, which means: + +:''If you get to this point in trying to recognize a specimen of A as one among several possible choices for a choice construct C, and you later fail to obtain an A, then forget about other choices for C: you won't be able to find a C here. You may go back to the next higher-level choice before C - or admit failure if there is no such choice left.'' + +Such a hint is useful when you want to let the parser benefit from some higher-level knowledge about the grammar, which is not directly deducible from the way the productions have been written. + +Here is an example. The production function for NESTED in the Polynomial language, which attempts to parse specimens of the form
+(s) +where ''s'' is a specimen of SUM, is written as + + production: LINKED_LIST [CONSTRUCT] + local + expression: SUM + once + create Result.make + Result.forth + keyword ("(") + commit + create expression.make + put (expression) + keyword (")") + end + + + +The commit after the recognition of the keyword "(" is there to use the following piece of higher-level knowledge: + +:''No choice production of the grammar that has NESTED as one of its alternatives has another alternative construct whose specimens could begin with an opening parenthesis "(".'' + + +Because of this property, if the parser goes so far as to recognize an opening parenthesis as part of parsing any construct C for which NESTED is an alternative, but further tokens do not match the structure of NESTED specimens, then we will have failed to recognize not only a NESTED but also a C. + +{{note|Some readers will have recognized commit as being close to the Prolog "cut" mechanism. }} + +In this example, NESTED is used in only one right-hand side production: the choice production for TERM, for which the other alternatives are SIMPLE_VAR and POLY_INTEGER, none of whose specimens can include an opening parenthesis. + +The use of commit assumes global knowledge about the grammar and its future extensions, which is somewhat at odds with the evolutionary approach suggested by the Eiffel method. Applied improperly, this mechanism could lead to the rejection of valid texts as invalid. Used with care, however, it helps in obtaining high-performance parsing without impairing too much the simplicity of preparing parsers and other document processors. + +==BUILDING A DOCUMENT PROCESSOR== + +We are ready now to put together the various elements required to build a document processor based on the EiffelParse library. + +===The overall picture=== + +The documents to be processed will be specimens of a certain construct. This construct is called the '''top construct''' for that particular processing. + +{{caution|Be sure to note that with the EiffelParse library there is no room for a concept of top construct of a '''grammar''': the top construct is only defined with respect to a particular processor for that grammar.
+Attempting to define the top of a grammar would be contrary to the object-oriented approach, which de-emphasizes any notion of top component of a system.
+Different processors for the same grammar may use different top constructs. }} + +A document processor will be a particular system made of construct classes, complemented by semantic classes, and usually by other auxiliary classes. One of the construct classes corresponds to the top construct and is called the '''top construct class'''. + +{{note|This notion of top construct class has a natural connection to the notion of root class of a system, as needed to get executable software. The top construct class could indeed be used as root of the processor system. In line with the previous discussion, however, it appears preferable to keep the top construct class (which only depends on the syntax and remains independent of any particular processor) separate from the system's root class. With this approach the root class will often be a descendant of the top construct class.
+This policy was adopted for the Polynomial language example as it appears in the delivery: the processor defined for this example uses LINE as the top construct class; the root of the processor system is a class PROCESS, which inherits from LINE. }} + +===Steps in the execution of a document processor=== + +As any root class of a system, the root of a document processor must have a creation procedure which starts the execution. Here the task of this class is the following: +# Define an object representing the input document to be processed; this will be an instance of class INPUT. +# Obtain a lexical analyzer applicable to the language, and connect it with the document. +# Select an input file, containing the actual document to be processed. +# Process the document: in other words, parse it and, if parsing is successful, apply the semantics. +# To execute these steps in a simple and convenient fashion, it is useful to declare the root class as a descendant of the lexical interface class. The root class, being an heir to the top construct class, will also be a descendant of CONSTRUCT. + + +===Connecting with lexical analysis=== + +To achieve the effect of steps [[#step_e1|1]] and [[#step_e2|2]] , a simple call instruction suffices: just call the procedure build, inherited from L_INTERFACE using as argument document, a feature of type INPUT, obtained from METALEX (the lexical analyzer generator class) through L_INTERFACE. The call, then, is just: + + build (document) + + +Although you may use this line as a recipe with no need for further justification, it is interesting to see what build does. Feature document describes the input document to be processed; it is introduced as a Once function in class CONSTRUCT to ensure that all instances of CONSTRUCT share a single document - in other words, that all processing actions apply to the same document. The text of build is: + + build (doc: INPUT) + -- Create lexical analyzer and set doc + -- to be the input document. + require + document_exists: doc /= void + do + metalex_make + obtain_analyzer + make_analyzer + doc.set_lexical (analyzer) + end + + +The call to obtain_analyzer defines the regular grammar for the language at hand. Recall that obtain_analyzer is deferred in L_INTERFACE; its definition for the POLY_LEX example was given above. The call to make_analyzer freezes the regular grammar and produces a usable lexical analyzer, available through the attribute analyzer obtained from METALEX. Finally, the call to set_lexical, a procedure of class INPUT, ensures that all lexical analysis operations will use analyzer as the lexical analyzer. + +===Starting the actual processing=== + +The call build ( document takes care of steps [[#step_e1|1]] and [[#step_e2|2]] of the root's creation procedure. Step [[#step_e3|3]] selects the file containing the input document; this is achieved through the call
+ + document.set_input_file (some_file_name) + +
+where set_input_file, from class INPUT, has a self-explanatory effect. + +Finally, step [[#step_e4|4]] (processing the document) is simply a call to procedure process, obtained from [[ref:libraries/parse/reference/construct_chart|CONSTRUCT]] . Recall that this procedure simply executes
+ + parse + if parsed then + semantics + end + +
+ +===The structure of a full example=== + +The polynomial example provides a simple example of a full document processor, which you may use as a guide for your own processors. The root class of that example is PROCESS. Its creation procedure, make, follows the above scheme precisely; here is its general form: + + root_line: LINE + + make + local + text_name: STRING + do + create root_line.make + build (root_line.document) + + ... Instructions prompting the user for the name of the + file to be parsed, and assigning it to text_name ... + + root_line.document.set_input_file (text_name) + root_line.process + end + + +Although it covers a small language, this example may serve as a blueprint for most applications of the EiffelParse library. + +==FUTURE WORK== + +It was mentioned at the beginning of this chapter that further work is desirable to make the EiffelParse library reach its full bloom. Here is a glimpse of future improvements. + +===Expressions=== + +Many languages include an expression construct having the properties of traditional arithmetic expressions: +* An expression is a succession of basic operands and operators. +* The basic operands are lexical elements, such as identifiers and constants. +* Operators are used in prefix mode (as in ''- a'') or infix mode (as in ''b - a''). +* Each operator has a precedence level; precedence levels determine the abstract syntactic structure of expressions and consequently their semantics. For example the abstract structure of ''a + b * c'' shows this expression to be the application of the operator ''+'' to ''a'' and to the application of the operator ''*'' to ''b'' and ''c''. That this is the correct interpretation of the instruction follows from the property that ''*'' has a higher precedence ("binds more tightly") than ''+''. +* Parentheses pairs, such as ( ) or [ ], can be used to enforce a structure different from what the precedence rules would imply, as in ''(a + b) * c''. +* Some infix operators may be applied to more than two arguments; in this case it must be clear whether they are right-associative (in other words, ''a ^ b ^ c'' means ''a ^ (b ^ c)'', the conventional interpretation if ^ denotes the power operator) or left-associative. + + +It is of course possible to apply the EiffelParse library in its current state to support expressions, as illustrated by this extract from the Polynomial grammar given in full above: + +Variables [=] {Identifier ";" ...} +Sum [=] {Diff "+" ...} +Diff [=] {Product "-" ...} +Product [=] {Term "*" ...} + + +The problem then is not expressiveness but efficiency. For such expressions the recursive descent technique, however well adapted to the higher-level structures of a language, takes too much time and generates too many tree nodes. Efficient bottom-up parsing techniques are available for this case. + +The solution is straightforward: write a new heir EXPRESSION to class CONSTRUCT. The preceding discussion of expressions and their properties suggests what kinds of feature this class will offer: define a certain terminal as operator, define a terminal as operand type, set the precedence of an operator, set an operator as left-associative or right-associative and so on. Writing this class based on this discussion is indeed a relatively straightforward task, which can be used as a programming exercise. + +Beyond the addition of an EXPRESSION class, some changes in the data structures used by EiffelParse may also help improve the efficiency of the parsing process. + +===Yooc=== + +To describe the syntax of a language, it is convenient to use a textual format such as the one that has served in this chapter to illustrate the various forms of production. The correspondence between such a format and the construct classes is straightforward; for example, as explained above, the production
+ +Line [=] Variables ":" Sum + +
+will yield the class + +class + LINE + +inherit + AGGREGATE + +feature + production: LINKED_LIST [CONSTRUCT] + local + var: VARIABLES + sum: SUM + once + create Result.make + Result.forth + create var.make + put (var) + keyword (":") + create sum.make + put (sum) + end + + ... + +end + + +This transformation of the textual description of the grammar into its equivalent Eiffel form is simple and unambiguous; but it is somewhat annoying to have to perform it manually. + +A tool complementing the EiffelParse library and known as YOOC ("Yes! an Object-Oriented Compiler", a name meant as an homage to the venerable Yacc) has been planned for future releases of EiffelParse. Yooc, a translator, will take a grammar specification as input and transform it into a set of parsing classes, all descendants of CONSTRUCT and built according to the rules defined above. The input format for syntax specification, similar to the conventions used throughout this chapter, is a variant of LDL (Language Description Language), a component of the ArchiText structural document processing system. + +===Further reading=== + +The following article describes some advanced uses of the EiffelParse library as well as a Yooc-like translator called PG: Per Grape and Kim Walden: Automating the Development of Syntax Tree Generators for an Evolving Language, in Proceedings of TOOLS 8 (Technology of Object-Oriented Languages and Systems), Prentice Hall, 1992, pages 185-195. + + + + + + + + + diff --git a/documentation/18.11/solutions/text-processing/eiffelparse/index.wiki b/documentation/18.11/solutions/text-processing/eiffelparse/index.wiki new file mode 100644 index 00000000..08a2f26d --- /dev/null +++ b/documentation/18.11/solutions/text-processing/eiffelparse/index.wiki @@ -0,0 +1,11 @@ +[[Property:title|EiffelParse]] +[[Property:weight|5]] +[[Property:uuid|0984d15a-6ee9-3bd4-71d6-31df2987af3a]] +==EiffelParse Library== + +Type: Library
+Platform: Any
+ +Eiffel classes for building parsers. + + diff --git a/documentation/18.11/solutions/text-processing/eiffelparse/parse-sample/eiffel-polynomial-parser.wiki b/documentation/18.11/solutions/text-processing/eiffelparse/parse-sample/eiffel-polynomial-parser.wiki new file mode 100644 index 00000000..03df76bf --- /dev/null +++ b/documentation/18.11/solutions/text-processing/eiffelparse/parse-sample/eiffel-polynomial-parser.wiki @@ -0,0 +1,23 @@ +[[Property:title|Eiffel polynomial parser]] +[[Property:weight|0]] +[[Property:uuid|63f0e737-4ad7-c574-3bbc-05e005815785]] +In the directory '''$ISE_EIFFEL/examples/parse''' you will find a system that implements a processor for a grammar describing a simple language for expressin polynomials. A typical document in this language is the line + +x;y: x * (y + 8 - (2 * x)) + +The beginning of the line, separated from the rest by a colon, is the list of variables used in the polynomial, separated by semicolons. The rest of the line is the expression defining the polynomial. The grammar can be described with the following grammar: + +LINE = VARIABLES ":" SUM +VARIABLES = VAR .. ";" +SUM = DIFF .. "+" +DIFF = PRODUCT .. "-" +PRODUCT = TERM .. "*" +TERM = SIMPLE_VAR | INT_CONSTANT | NESTED +NESTED = "(" SUM ")" +This grammar assumes a terminal '''VAR''', which must be defined as a token type in the lexical grammar. The other terminals are keywords, shown as strings appearing in the double quotes, for example "+". +When compiling the example, the executable '''process(.exe)''' is created. When executing the program, it will prompt for the name of a file with a polynomial description, reads a polynomial from the given file, prompts for integer values of the variables, and evaluates the polynomial. + + + + + diff --git a/documentation/18.11/solutions/text-processing/eiffelparse/parse-sample/index.wiki b/documentation/18.11/solutions/text-processing/eiffelparse/parse-sample/index.wiki new file mode 100644 index 00000000..d2b033b7 --- /dev/null +++ b/documentation/18.11/solutions/text-processing/eiffelparse/parse-sample/index.wiki @@ -0,0 +1,8 @@ +[[Property:title|Parse Sample]] +[[Property:weight|2]] +[[Property:uuid|ad48d4f5-a113-65f7-15fc-8c8fd3f5c284]] +* [[Eiffel polynomial parser|Eiffel polynomial parser]] + + + + diff --git a/documentation/18.11/solutions/text-processing/index.wiki b/documentation/18.11/solutions/text-processing/index.wiki new file mode 100644 index 00000000..ea316e64 --- /dev/null +++ b/documentation/18.11/solutions/text-processing/index.wiki @@ -0,0 +1,6 @@ +[[Property:title|Text processing]] +[[Property:weight|-6]] +[[Property:uuid|e74b5b47-d87d-2eb0-49ba-981dae52d338]] +== Text processing (lexical analysis and parsing) solutions== + + diff --git a/documentation/18.11/solutions/web-technology/EiffelWeb-framework.wiki b/documentation/18.11/solutions/web-technology/EiffelWeb-framework.wiki new file mode 100644 index 00000000..f54a307e --- /dev/null +++ b/documentation/18.11/solutions/web-technology/EiffelWeb-framework.wiki @@ -0,0 +1,14 @@ +[[Property:uuid|5D7CBC54-D97A-4400-9335-9C8FB3CBE004]] +[[Property:weight|0]] +[[Property:title|EiffelWeb framework]] +[[Property:link_title|EiffelWeb]] + += The EiffelWeb Framework (EWF) = + +The EiffelWeb Framework provides a common framework to build easily web server application in Eiffel (portable on various connectors and platforms). + +* Project on github: [https://github.com/EiffelWebFramework/EWF] +* Associated website [http://www.eiffelweb.org/] +* Latest documentation [https://github.com/EiffelWebFramework/EWF/blob/master/docs/workbook/workbook.md] +* Gitter.im room [https://gitter.im/EiffelWebFramework/EWF] +* Forum [https://groups.google.com/forum/#!forum/eiffel-web-framework] diff --git a/documentation/18.11/solutions/web-technology/eiffelweb/eiffelweb-class-reference.wiki b/documentation/18.11/solutions/web-technology/eiffelweb/eiffelweb-class-reference.wiki new file mode 100644 index 00000000..26fd6263 --- /dev/null +++ b/documentation/18.11/solutions/web-technology/eiffelweb/eiffelweb-class-reference.wiki @@ -0,0 +1,5 @@ +[[Property:title|EiffelWeb Class Reference]] +[[Property:weight|1]] +[[Property:uuid|70bb6b4d-7b0f-6317-4c2b-618a80ef042d]] +==View the [[ref:libraries/web/reference/index|EiffelWeb Class Reference]]== + diff --git a/documentation/18.11/solutions/web-technology/eiffelweb/eiffelweb-sample/eiffelweb-basic-sample.wiki b/documentation/18.11/solutions/web-technology/eiffelweb/eiffelweb-sample/eiffelweb-basic-sample.wiki new file mode 100644 index 00000000..d133344c --- /dev/null +++ b/documentation/18.11/solutions/web-technology/eiffelweb/eiffelweb-sample/eiffelweb-basic-sample.wiki @@ -0,0 +1,40 @@ +[[Property:title|EiffelWeb Basic Sample]] +[[Property:weight|0]] +[[Property:uuid|da8f72cb-0ecd-464a-a558-cbf7d24301e3]] +This sample shows how to retrieve and display information from a basic form on a web page. + + +{{note|This sample requires a web server supporting CGI in order to be run. Both the Internet Information Services web server from Microsoft and the GNU Apache server may be used. }} + + +==Compiling== + +To compile the example: +* Launch EiffelStudio. +* Click '''Add project''' +* Browse to ''$ISE_EIFFEL\examples\web\basic\''. +* Choose ''web.ecf'' +* Choose the location where the project will be compiled, by default the same directory containing the configuration file. +* Click '''OK'''. + +==Installing== + +You should copy the file ''web_demo.exe'' in the ''cgi_bin'' directory of your web server and the file ''sample.html'' in a directory on the web server. + +==Running== + +To run the example, access the page ''sample.html'' that you copied on the web server with a web browser (typically ''http://localhost/sample.html''). Fill in the text field with a username and click ''Submit''. You should see a page displaying the name you just entered. Although not earth-shattering, this sample shows the basis for building more complex forms processing in Eiffel. + +==Under the Hood== + +This basic sample has just one class SAMPLE which inherits from CGI_INTERFACE. SAMPLE implements execute which retrieves the name entered in the form and creates a new HTML page with it. + + + +See the EiffelWeb class reference for the class interfaces. + + + + + + diff --git a/documentation/18.11/solutions/web-technology/eiffelweb/eiffelweb-sample/index.wiki b/documentation/18.11/solutions/web-technology/eiffelweb/eiffelweb-sample/index.wiki new file mode 100644 index 00000000..b150b498 --- /dev/null +++ b/documentation/18.11/solutions/web-technology/eiffelweb/eiffelweb-sample/index.wiki @@ -0,0 +1,9 @@ +[[Property:title|EiffelWeb Sample]] +[[Property:weight|2]] +[[Property:uuid|8d863248-ab60-bf4b-cfd0-f79c63309a1b]] +The [[EiffelWeb Basic Sample|basic]] sample will get you started on the development of forms processing in Eiffel. + + + + + diff --git a/documentation/18.11/solutions/web-technology/eiffelweb/eiffelweb-tutorial/eiffelweb-content-introduction.wiki b/documentation/18.11/solutions/web-technology/eiffelweb/eiffelweb-tutorial/eiffelweb-content-introduction.wiki new file mode 100644 index 00000000..cb7b7a55 --- /dev/null +++ b/documentation/18.11/solutions/web-technology/eiffelweb/eiffelweb-tutorial/eiffelweb-content-introduction.wiki @@ -0,0 +1,35 @@ +[[Property:title|EiffelWeb Content Introduction]] +[[Property:weight|0]] +[[Property:uuid|df90086d-4265-4451-06bf-5e6e0603036e]] +==CGI Applications== + +The way a CGI application communicates with the Web browser is simple: when the user presses a button on an HTML form, with an associated action (such as ''Submit''), the browser starts the application whose path is indicated inside the HTML form declaration. It sends data corresponding to the HTTP request and to the input form information in the usual file descriptor ''In'', stores within environment variables the transaction environment of the request, and waits for the application message, expected in its ''Out'' canal. The ''In'' and '' Out ''canals are accessible via the class CGI_IN_AND_OUT.
+
+HTML forms are an easy way to collect user entries in a web page, which are sent by the browser to the CGI application. A simple example of a form is: + +
+ + + + + +
+ + + +When the user presses the submit button, the browser will launch the application located at ''/cgi-bin/convert.exe'' on the server, will use the HTTP Post protocol, and will store among others the environment variable ''Celsius'' with the value entered by the user. + +==Advantages of using EiffelWeb== + +With EiffelWeb, you can: +* Design object-oriented systems +* Access and use the Eiffel libraries +* Increase maintainability because your code is reusable and readable +* Deal with complexity because you use a language particularly efficient in the Business Modeling. +* Use one/a few big Eiffel Web applications, which allow for an easier maintenance and provide better code readability and reusability than having a huge number of scripts. +* Use the ''Design by Contract'' methodology, thanks to the debugging facilities provided by EiffelWeb. + + + + + diff --git a/documentation/18.11/solutions/web-technology/eiffelweb/eiffelweb-tutorial/index.wiki b/documentation/18.11/solutions/web-technology/eiffelweb/eiffelweb-tutorial/index.wiki new file mode 100644 index 00000000..aba636ca --- /dev/null +++ b/documentation/18.11/solutions/web-technology/eiffelweb/eiffelweb-tutorial/index.wiki @@ -0,0 +1,9 @@ +[[Property:title|EiffelWeb Tutorial]] +[[Property:weight|0]] +[[Property:uuid|e2b93aea-ec1b-5897-0b0a-adc5681a1dcb]] +The Common Gateway Interface (CGI) emerged as the first way to present dynamically generated information on the World Wide Web. It allows the computer to process forms filled by the user and return appropriate information.
+ +EiffelWeb was developed by Eiffel Software to provide Eiffel developers access to the CGI technology. The library makes it possible to write Eiffel systems that interact directly with the Web. + + + diff --git a/documentation/18.11/solutions/web-technology/eiffelweb/eiffelweb-tutorial/processing-requests.wiki b/documentation/18.11/solutions/web-technology/eiffelweb/eiffelweb-tutorial/processing-requests.wiki new file mode 100644 index 00000000..f2e668e7 --- /dev/null +++ b/documentation/18.11/solutions/web-technology/eiffelweb/eiffelweb-tutorial/processing-requests.wiki @@ -0,0 +1,54 @@ +[[Property:title|Processing Requests]] +[[Property:weight|1]] +[[Property:uuid|f265e0d8-ca0e-8902-712c-1102b2916e9c]] +EiffelWeb provides a complete set of features and interface which helps building a wide range of possible requests. + +==Basic CGI Handling== + +===Accessing Environment Variables=== + +Much of the information needed by CGI applications is made available via environment variables. Programs using EiffelWeb can access this information through the class CGI_ENVIRONMENT.
+These variables are usually used for the following purposes: +* Getting information about the server itself +* Checking the client browser +* Restricting Access for specified Domains +* Ensuring User Authentication and Identifications +* Dealing with Cookies + +===Accessing Input Values=== + +The browser sends in the ''In'' a stream containing the data relative to the user entry and selection at the applications starts. EiffelWeb stores each data element and its associated name within a Hash-Table, the feature form_data of class CGI_INTERFACE. You can access their values from your code with the interface defined in class CGI_FORMS, which allows you to retrieve text entries, to know whether a button was pressed or not, etc. + +===Sending answers to the browser=== + +The response has to contain an HTTP header in order to be understood by the browser. Depending on the nature of the reply, an HTML page, a simple re-direction, an error notification, you will select different features and options. Your application must send at least a response header, indicating the status of the request if known. You may want to attach to it the text you wish to send back to the user. This text is usually written in HTML, so that it will display nicely on the user's browser; you can use for this purpose the class HTML_PAGE. You may then send the header followed by your text using the features send_to_browser of classes CGI_RESPONSE_HEADER and HTML_PAGE. + +{{note|You may not write into a file before you have sent the answer to the browser. }} + +===Dealing with Cookies=== + +You can access the cookies corresponding to a specific URL/domain thanks to the feature cookies, of class CGI_ENVIRONMENT. It is a hash-table, in which all the data with associated names as keys are stored. + +To store a cookie on a machine, you can use the feature set_cookies, of class CGI_RESPONSE_HEADER. + +==Advanced Topics== + +===EiffelWeb and Security=== + +The information the server sends back may be confidential. Follow these steps to protect the page content: +# Create an HTML page, for example by using class HTML_PAGE. +# Store this page somewhere, with a random name. +# Create an instance of class CGI_RESPONSE_HEADER and choose the secure redirect option. Then call send_to_browser. + +===Complex Headers=== + +The Eiffel-Web application has the possibility to send a selection of different HTTP headers. They can be found in class CGI_RESPONSE_HEADER. In particular, it is advised to generate a status for each request, the value of the most common ones may be found in class [[ref:libraries/web/reference/cgi_common_status_types_chart|CGI_COMMON_STATUS_TYPES]] . + +===Debugging facilities=== + +Design by Contract is one of the greatest strengths of the Eiffel programming language. When you usually run your application from EiffelStudio, you are notified when an assertion is violated and the tool offers different options in order to be able to find out its sources (feature and class tools, object inspectors, etc). However this cannot be applied to an EiffelWeb application, since it has to be run on the server.
+Therefore, EiffelWeb provides its own facilities for debugging. To test your classes at run-time, all you need to do is to set the Boolean feature is_debug_mode to True in your root class (which should inherit from CGI_INTERFACE). When your application crashes (because of an assertion or a bug), the exception trace will be displayed on the screen. + + + + diff --git a/documentation/18.11/solutions/web-technology/eiffelweb/index.wiki b/documentation/18.11/solutions/web-technology/eiffelweb/index.wiki new file mode 100644 index 00000000..5848c3d4 --- /dev/null +++ b/documentation/18.11/solutions/web-technology/eiffelweb/index.wiki @@ -0,0 +1,12 @@ +[[Property:link_title|Obsolete EiffelWeb]] +[[Property:title|Obsolete EiffelWeb]] +[[Property:weight|1]] +[[Property:uuid|b8a31d00-8ecb-7e32-df14-d92c91019826]] +==EiffelWeb Library== + +Type: Library
+Platform: Any
+ +Eiffel classes that facilitate processing CGI web forms. + + diff --git a/documentation/18.11/solutions/web-technology/index.wiki b/documentation/18.11/solutions/web-technology/index.wiki new file mode 100644 index 00000000..bc0ac509 --- /dev/null +++ b/documentation/18.11/solutions/web-technology/index.wiki @@ -0,0 +1,6 @@ +[[Property:title|Web technology]] +[[Property:weight|-7]] +[[Property:uuid|2b54659c-c982-239b-a9d9-003f3868c49f]] +== Web technology solutions== + +