mirrors/eiffel-org
1
0
Fork 0
mirror of https://github.com/EiffelSoftware/eiffel-org.git synced 2025-12-06 23:02:28 +01:00
Code Issues Packages Projects Releases Wiki Activity

merge changed from 18.11 into trunk.

Browse Source 
git-svn-id: https://svn.eiffel.com/eiffel-org/trunk@2151 abb3cda0-5349-4a8f-a601-0c33ac3a8c38
This commit is contained in:
jfiat
2019-05-19 11:13:05 +00:00
parent 3a7702582d
commit 2c8d6d6f35
17 changed files with 180 additions and 129 deletions
Download Patch File Download Diff File Expand all files Collapse all files

15
documentation/trunk/solutions/concurrent-computing/SCOOP_tutorial.wiki
View File

@@ -1,7 +1,16 @@
[[Property:modification_date|Fri, 30 Nov 2018 20:17:44 GMT]]
[[Property:modification_date|Sun, 20 Jan 2019 12:52:42 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!).
[[Property:link_title|SCOOP Tutorial (hands-on): a small concurrent email system]]
This tutorial comes with a full-fledged example: a simple email client system. It is hands-on, inviting you to look at the code of the sequential version of the system, then guiding you step-by-step to make it concurrent, and hence much nicer to use.
The Eiffel compiler helps you through out: at each step of the transformation from sequential to concurrent, the error messages tell you what remains to be done.
For reading convenience the tutorial is in PDF format. It includes all the links to the code to be downloaded.
Read the tutorial by clicking [https://www.eiffel.org/files/uploads/scoop_tutorial_%282%29.pdf this link].
You should also note the [https://learning.acm.org/webinars/coop ACM webinar on SCOOP] which relies on this example to provide a general introduction to SCOOP.

3
documentation/trunk/solutions/concurrent-computing/index.wiki
View File

@@ -1,4 +1,4 @@
[[Property:modification_date|Tue, 20 Nov 2018 12:44:24 GMT]]
[[Property:modification_date|Sat, 19 Jan 2019 20:11:49 GMT]]
[[Property:publication_date|Tue, 20 Nov 2018 12:44:24 GMT]]
[[Property:link_title|Concurrency]]
[[Property:title|Concurrency]]
@@ -18,6 +18,7 @@ In most programming languages, the way to obtain threaded applications is to rel
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:
* [[SCOOP_tutorial|SCOOP tutorial (hands-on)]]: build a small concurrent email system, step by step.
* 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.

8
documentation/trunk/solutions/database-access/eiffelstore/EiffelStore-ODBC-with-PostgreSQL.wiki
View File

@@ -1,4 +1,4 @@
[[Property:modification_date|Thu, 18 Oct 2018 15:19:06 GMT]]
[[Property:modification_date|Tue, 05 Feb 2019 11:19:29 GMT]]
[[Property:publication_date|Mon, 24 Sep 2018 12:04:18 GMT]]
[[Property:uuid|6F78A05A-2054-4150-84FC-1D8663CA76E6]]
[[Property:weight|5]]
@@ -6,7 +6,7 @@
[[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. }}
{{note|For this documentation, tests used Ubuntu 18.04 64 bits and EiffelStudio 18.07 64 bits / Debian 9 and EiffelStudio 18.11 64 bits. }}
* '''Install EiffelStudio'''
From here on, $YOUR_INSTALLATION_PATH denotes the path name of the EiffelStudio installation.
@@ -143,9 +143,9 @@ encoding name too long
* '''Compile C code of the Eiffel library store:'''
<code>cd $YOUR_INSTALLATION_PATH/library/store/dbms/rdbms/odbc/Clib finish_freezing -library</code>
<code>cd $ISE_EIFFEL/library/store/dbms/rdbms/odbc/Clib; finish_freezing -library</code>
{{note|On debian at least before finish_freezing log in as superuser doing a '''sudo -i''' }}
{{note|On debian at least before finish_freezing log in as superuser doing a '''sudo -i''' depending on the right and user setted for $ISE_EIFFEL/Eiffel_18.07 directory }}
* '''Open EiffelStudio eSQL example and run it'''
The example is located on `$ISE_EIFFEL/examples/store/esql/`

10
documentation/trunk/solutions/gui-building/eiffelbuild/eiffelbuild-reference/builder-window.wiki
View File

@@ -1,26 +1,28 @@
[[Property:modification_date|Sat, 06 Apr 2019 15:49:27 GMT]]
[[Property:publication_date|Sat, 06 Apr 2019 15:49:27 GMT]]
[[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.
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 <eiffel>EV_BUTTON</eiffel> will be displayed in here using an <eiffel>EV_BUTTON</eiffel>. 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. <br/>
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. <br/>
{{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.
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 descendants 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 <eiffel>EV_VERTICAL_BOX</eiffel>, and an <eiffel>EV_HORIZONTAL_BOX</eiffel> (Excluding the <eiffel>EV_TITLED_WINDOW</eiffel> [[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:
The properties of the [[EiffelBuild Notation|objects]] in your 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.

6
documentation/trunk/solutions/platform-specifics/microsoft-windows/net/eiffel-net-language/eiffel-net/inheritance.wiki
View File

@@ -1,3 +1,5 @@
[[Property:modification_date|Sat, 12 Jan 2019 18:39:06 GMT]]
[[Property:publication_date|Sat, 12 Jan 2019 18:34:23 GMT]]
[[Property:title|Inheritance]]
[[Property:weight|3]]
[[Property:uuid|7e4cb7ba-fda6-8eac-3e27-bbb8fafd8673]]
@@ -120,7 +122,7 @@ inherit
extend,
force,
is_inserted
redefine
redefine
duplicate,
linear_representation
select
@@ -200,7 +202,7 @@ So, in this example the implementation for <code>linear_representation</code>, f
remove
</code>
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 <code>select</code> to provide the dynamic binding system with an unambiguous choice of features in the presence of polymorphic attachment.
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. Just understand at this point that it is sometimes necessary to use <code>select</code> 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.