mirror of
https://github.com/EiffelSoftware/eiffel-org.git
synced 2025-12-06 14:52:03 +01:00
merged 18.07 into trunk
git-svn-id: https://svn.eiffel.com/eiffel-org/trunk@2102 abb3cda0-5349-4a8f-a601-0c33ac3a8c38
This commit is contained in:
eiffel-org
@@ -1,3 +1,5 @@
|
||||
[[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]]
|
||||
@@ -27,7 +29,7 @@ create
|
||||
feature {NONE} -- Initialization
|
||||
|
||||
make (a: INTEGER)
|
||||
-- Initialize Current with `a'.
|
||||
-- Initialize Current with `a`.
|
||||
do
|
||||
end
|
||||
|
||||
@@ -48,7 +50,7 @@ end</e>
|
||||
|
||||
If expressions are very long, break them on conjunctions as in:
|
||||
<e>if
|
||||
expr1 or else
|
||||
expr1 and then
|
||||
expr2
|
||||
then
|
||||
...
|
||||
@@ -80,7 +82,10 @@ else
|
||||
...
|
||||
end</e>
|
||||
|
||||
* For punctuation, we always have a space before '''(''' and a space after ''')''', ''',''', ''':''', or ''';''':
|
||||
* For punctuation, we always have
|
||||
** a space before, and no after `(`
|
||||
** no space before, and space after `)` `,` `:` or `;`
|
||||
|
||||
<e>require
|
||||
a_tag: query (a, b, c) or other_query (c, d)
|
||||
local
|
||||
|
||||
@@ -1,3 +1,5 @@
|
||||
[[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]]
|
||||
@@ -61,3 +63,6 @@ Command line argument value for option 'h' is: gamma
|
||||
</code>
|
||||
|
||||
|
||||
{{SeeAlso|[[Execution_profiles|How to run with arguments]]}}
|
||||
|
||||
|
||||
|
||||
@@ -1,3 +1,5 @@
|
||||
[[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]]
|
||||
@@ -6,7 +8,7 @@ EiffelStudio comes with a rich set of examples that you can use to learn how to
|
||||
|
||||
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 contributed by people like you who use Eiffel daily to solve real problems.
|
||||
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.
|
||||
|
||||
@@ -14,7 +16,7 @@ Program chrestomathies vary widely. At one end of the spectrum [http://99-bottle
|
||||
|
||||
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 to 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.)
|
||||
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].
|
||||
|
||||
|
||||
@@ -1,15 +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 <code>out</code> method that can be used to get a text version of the object. For a lot of class, this method return internal informations that are not really useful for the end user. But for every <code>NUMERIC</code> class, the <code>out</code> method return a text representation of the number that the <code>NUMERIC</code> object represents.
|
||||
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.
|
||||
|
||||
<code>
|
||||
print_integer(a_integer:INTEGER)
|
||||
-- Print the value of `a_integer'
|
||||
print_integer (a_integer: INTEGER)
|
||||
-- Print the value of `a_integer`.
|
||||
do
|
||||
print(a_integer.out + "%N")
|
||||
print (a_integer.out + "%N")
|
||||
end
|
||||
</code>
|
||||
|
||||
Note that for more advance convertion, you can also used convertion class like <code>FORMAT_DOUBLE</code>.
|
||||
Note that for more advanced conversion, you can also use a conversion class like `FORMAT_DOUBLE`.
|
||||
@@ -1,13 +1,13 @@
|
||||
[[Property:modification_date|Fri, 07 Sep 2018 12:13:00 GMT]]
|
||||
[[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 what you can do.
|
||||
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 what the code will look like.
|
||||
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.
|
||||
|
||||
<code>
|
||||
removing_stopped (a_list: LIST [MY_CLASS])
|
||||
|
||||
@@ -1,7 +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 can be used to know how to used some very specific mechanics in Eiffel. Those how-tos are small by design and can be used to show very fundamental mechanisms for beginners or more advance mechanisms.
|
||||
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.
|
||||
|
||||
|
||||
|
||||
|
||||
@@ -1,3 +1,5 @@
|
||||
[[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]]
|
||||
@@ -34,7 +36,7 @@ The testing support classes are distributed with EiffelStudio and exist in the '
|
||||
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:
|
||||
|
||||
<code lang=text>
|
||||
View --> Tools --> Testing Tool </code>
|
||||
View --> Tools --> AutoTest </code>
|
||||
|
||||
|
||||
==Test classes and tests==
|
||||
|
||||
@@ -1,6 +1,27 @@
|
||||
[[Property:modification_date|Fri, 06 Jul 2018 13:21:44 GMT]]
|
||||
[[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 <eiffel>ARRAY [READABLE_STRING_GENERAL]</eiffel> with elements <eiffel>"abc"</eiffel> and <eiffel>"def"</eiffel> of type <eiffel>STRING_8</eiffel>.
|
||||
|
||||
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 <eiffel>ARRAY [STRING_8]</eiffel>.
|
||||
|
||||
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.
|
||||
@@ -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.
|
||||
@@ -1,11 +1,11 @@
|
||||
[[Property:modification_date|Thu, 06 Sep 2018 15:10:13 GMT]]
|
||||
[[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 or resources on how to unleash the power of Eiffel. It is organized as a set of '''books''':
|
||||
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.
|
||||
@@ -17,7 +17,7 @@ This is the Eiffel documentation site, with a wealth or resources on how to unle
|
||||
** [[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:
|
||||
* [[Solutions]]. EiffelStudio comes with numerous libraries, packages, and tools. The Solutions book includes:
|
||||
** Libraries: data structures, graphics, networking...
|
||||
** Packages
|
||||
** Tools
|
||||
|
||||
@@ -1,16 +1,18 @@
|
||||
[[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 arereturned. The Base libraries support three important categories - stacks, queues, and priority queues:
|
||||
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 at end of queue), item (retrieve the oldest element, non-destructively), remove (remove the oldest element), is_empty (test for empty queue). <br/>
|
||||
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). <br/>
|
||||
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 (<eiffel>count</eiffel>).
|
||||
* [[ref:libraries/base/reference/bounded_stack_chart|BOUNDED_STACK]] : stacks implemented as arrays. For such stacks, the maximum number of items (<eiffel>capacity</eiffel>) is set at creation time.
|
||||
|
||||
@@ -1,3 +1,5 @@
|
||||
[[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]]
|
||||
@@ -38,8 +40,8 @@ then a class <eiffel>SPECIAL_PROMOTION</eiffel> of a text processing system may
|
||||
until
|
||||
customers.exhausted
|
||||
loop
|
||||
if recent_purchases.has (customers.item>) then
|
||||
target_list.put (customers.item>)
|
||||
if recent_purchases.has (customers.item) then
|
||||
target_list.put (customers.item)
|
||||
end
|
||||
customers.forth
|
||||
end</code>
|
||||
@@ -55,49 +57,54 @@ To get a first grasp of how one can work with the Iteration library, let us look
|
||||
|
||||
==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]] , the class defining iteration mechanisms on linear (sequential) structures.
|
||||
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.
|
||||
<code>
|
||||
until_do
|
||||
-- Apply action to every item of target,
|
||||
-- up to but excluding first one satisfying test.
|
||||
-- (Apply to full list if no item satisfies test.)
|
||||
require
|
||||
traversable_exists: target /= Void
|
||||
do
|
||||
from
|
||||
target.start
|
||||
invariant
|
||||
''invariant_value''
|
||||
until
|
||||
target.exhausted or else test
|
||||
loop
|
||||
action
|
||||
target.forth
|
||||
end
|
||||
ensure
|
||||
achieved: target.exhausted or else test
|
||||
invariant_satisfied: ''invariant_value''
|
||||
end</code>
|
||||
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
|
||||
|
||||
The precise form of the procedure in the class relies on a call to another procedure, until_continue, and on inherited assertions. Here everything has been unfolded for illustration purposes. <br/>
|
||||
This procedure will traverse the linear structure identified by target and apply the procedure calledaction on every item up to but excluding the first one satisfying test. <br/>
|
||||
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
|
||||
</code>
|
||||
|
||||
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]]. <br/>
|
||||
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. <br/>
|
||||
The class similarly offers <eiffel>do_all</eiffel>, <eiffel>do_while</eiffel>, <eiffel>do_for</eiffel>, <eiffel>do_if</eiffel> and other procedures representing the common control structures. It also includes functions such as <eiffel>exists</eiffel> and <eiffel>forall</eiffel>, corresponding to the usual quantifiers. <br/>
|
||||
These iteration schemes depend on the procedure <eiffel>action</eiffel>, defining the action to be applied to successive elements, and on the function <eiffel>test</eiffel>, defining the boolean query to be applied to these elements. These features are declared in class [[ref:libraries/base/reference/iterator_chart|ITERATOR]] (the highest-level deferred class of the Iteration library); here is <eiffel>test</eiffel>:
|
||||
<code>
|
||||
test: BOOLEAN
|
||||
-- Test to be applied to item at current position in
|
||||
-- target (default: value of item_test on item)
|
||||
require
|
||||
traversable_exists: target /= Void
|
||||
not_off: not target.off
|
||||
These iteration schemes depend on the procedure <eiffel>action</eiffel>, defining the action to be applied to successive elements, and on the function <eiffel>test</eiffel>, 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 <eiffel>test</eiffel>
|
||||
function intended to be used with iteration over a data structure whose elements are <code>STRING</code>s.
|
||||
<code>
|
||||
test (a_item: STRING): BOOLEAN
|
||||
-- Test to be applied to a_item
|
||||
do
|
||||
Result := item_test (target.item>)
|
||||
ensure
|
||||
not_off: not target.off
|
||||
end</code>
|
||||
Result := a_item.count > 0
|
||||
end
|
||||
</code>
|
||||
|
||||
This indicates that the value of the boolean function <eiffel>test</eiffel> will be obtained by applying <eiffel>item_test</eiffel> to the item at the current position in the target structure. In [[ref:libraries/base/reference/iterator_chart|ITERATOR]] , function <eiffel>item_test</eiffel> always return ; descendant classes will redefine it so as to describe the desired test. Similarly, <eiffel>action</eiffel> is declared in class [[ref:libraries/base/reference/iterator_chart|ITERATOR]] as a call to <eiffel>item_action</eiffel>. Descendants will redefine <eiffel>item_action</eiffel>, which as initially declared in [[ref:libraries/base/reference/iterator_chart|ITERATOR]] is a procedure with a null body. <br/>
|
||||
Going through <eiffel>item_action</eiffel> and <eiffel>item_test</eiffel> provides an extra degree of flexibility. Normally the action and test performed at each step apply to <eiffel>target</eiffel> <code> . </code><eiffel>item></eiffel>, so that it suffices to redefine the <eiffel>item_features</eiffel>. This is the case with all examples studied in this chapter. In a more general setting, however, you might need to redefine <eiffel>action</eiffel> and <eiffel>test</eiffel> themselves.
|
||||
This indicates that the value of the boolean function <eiffel>test</eiffel> will be obtained by verifying that <eiffel>a_item</eiffel> is an empty string or not.
|
||||
|
||||
==An example use of iteration==
|
||||
|
||||
@@ -119,10 +126,7 @@ class
|
||||
TEXT_PROCESSOR
|
||||
|
||||
inherit
|
||||
LINEAR_ITERATOR [PARAGRAPH]
|
||||
redefine
|
||||
item_action, item_test
|
||||
end
|
||||
LINEAR_ITERATOR [PARAGRAPH]
|
||||
|
||||
feature
|
||||
|
||||
@@ -131,12 +135,12 @@ feature
|
||||
-- the first one that has been modified.
|
||||
do
|
||||
set (t)
|
||||
until_do
|
||||
until_do (agent item_action, agent item_test)
|
||||
end
|
||||
|
||||
feature {NONE}
|
||||
|
||||
item_test (p PARAGRAPH): BOOLEAN
|
||||
item_test (p: PARAGRAPH): BOOLEAN
|
||||
-- Has p been modified?
|
||||
do
|
||||
Result := p.modified
|
||||
@@ -154,9 +158,9 @@ Thanks to the iteration mechanism, the procedure <eiffel>resize_paragraphs</eiff
|
||||
* To set its argument <code>t</code> as the iteration target, it uses procedure <eiffel>set</eiffel>. (This procedure is from class [[ref:libraries/base/reference/iterator_chart|ITERATOR]] which passes it on to all iterator classes.)
|
||||
* Then it simply calls <eiffel>until_do</eiffel> as defined above.
|
||||
|
||||
Procedure <eiffel>item_action</eiffel> is redefined to describe the operation to be performed on each successive element. Function <eiffel>item_test</eiffel> is redefined to describe the exit test. <br/>
|
||||
Procedure <eiffel>item_action</eiffel> is defined to describe the operation to be performed on each successive element. Function <eiffel>item_test</eiffel> is defined to describe the exit test. <br/>
|
||||
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. <br/>
|
||||
What is interesting here is that the redefinitions of <eiffel>item_test</eiffel> and <eiffel>item_action</eiffel> 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.
|
||||
What is interesting here is that the definitions of <eiffel>item_test</eiffel> and <eiffel>item_action</eiffel> 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=
|
||||
|
||||
@@ -200,8 +204,8 @@ Of course the data structure class used in connection with a given iterator clas
|
||||
|
||||
Class [[ref:libraries/base/reference/iterator_chart|ITERATOR]] defines the features that apply to all forms of iterator. <br/>
|
||||
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] <br/>
|
||||
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 <eiffel>SOME_ITERATOR</eiffel> [<eiffel>ACTUAL_TYPE</eiffel>] the target can only be of type <eiffel>SOME_TRAVERSABLE</eiffel> [<eiffel>ACTUAL_TYPE</eiffel>] for the same <eiffel>ACTUAL_TYPE</eiffel>, where <eiffel>SOME_TRAVERSABLE</eiffel> is the traversal class matching <eiffel>SOME_ITERATOR</eiffel> 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. <br/>
|
||||
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:
|
||||
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 <eiffel>SOME_ITERATOR</eiffel> [ <eiffel>ACTUAL_TYPE</eiffel>] the target can only be of type <eiffel>SOME_TRAVERSABLE</eiffel> [<eiffel>ACTUAL_TYPE</eiffel>] for the same <eiffel>ACTUAL_TYPE</eiffel>, where <eiffel>SOME_TRAVERSABLE</eiffel> is the traversal class matching <eiffel>SOME_ITERATOR</eiffel> 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. <br/>
|
||||
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:
|
||||
<code>
|
||||
set (s: like target)
|
||||
-- Make s the new target of iterations.
|
||||
@@ -214,44 +218,10 @@ Each of the proper descendants of [[ref:libraries/base/reference/iterator_chart|
|
||||
target /= Void
|
||||
end</code>
|
||||
|
||||
Next [[ref:libraries/base/reference/iterator_chart|ITERATOR]] introduces the routines describing the elementary action and test that will be applied to items of the iteration targets:
|
||||
<code>
|
||||
action
|
||||
-- Action to be applied to item at current position in
|
||||
-- target.
|
||||
-- (default: item_action on item at current position.)
|
||||
-- Note: for iterators to work properly, redefined
|
||||
-- versions of this feature should not change the
|
||||
-- traversable structure.
|
||||
require
|
||||
traversable_exists: target /= Void
|
||||
not_off: not target.off
|
||||
invariant_satisfied: invariant_value
|
||||
do
|
||||
item_action (target.item>)
|
||||
ensure
|
||||
not_off: not target.off
|
||||
invariant_satisfied: invariant_value
|
||||
end
|
||||
|
||||
test: BOOLEAN
|
||||
-- Test to be applied to item at current position in
|
||||
-- target (default: value of item_test on item)
|
||||
require
|
||||
traversable_exists: target /= Void
|
||||
not_off: not target.off
|
||||
do
|
||||
Result := item_test (target.item>)
|
||||
ensure
|
||||
not target.off
|
||||
end</code>
|
||||
|
||||
These routines rely on two others, <eiffel>item_action</eiffel> and <eiffel>item_test</eiffel>, which both take an argument of type G, the formal generic parameter. The reason, already noted above, is that in a vast majority of cases the iterated action and test solely depend, at each step of the traversal, on the item (of type G) at the current position. To define an iteration process, then, it suffices to redefine<eiffel> item_action</eiffel> and <eiffel>item_test</eiffel> in a descendant of the appropriate iteration class. Only in complex cases will it be necessary to redefine <eiffel>action</eiffel> and <eiffel>test</eiffel> themselves. <br/>
|
||||
If you encounter such a case, note the caveat about action changing the target's structure. Understandably enough, an iterator that attempts to change the data structure while traversing it may engage in strange behavior. No such risk exists if you only redefine <eiffel>item_action</eiffel>, which may change the contents of items but not the structure itself. <br/>
|
||||
Another feature introduced in [[ref:libraries/base/reference/iterator_chart|ITERATOR]] is the query <eiffel>invariant_value</eiffel>, 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. <br/>
|
||||
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:
|
||||
* <eiffel>for_all</eiffel> will return true if all items of the target structure satisfy test.
|
||||
* <eiffel>exists</eiffel> will return true if at least one item satisfies test.
|
||||
* <eiffel>there_exists</eiffel> 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:
|
||||
* <eiffel>do_all</eiffel> applies <eiffel>action</eiffel> to all items.
|
||||
@@ -260,31 +230,12 @@ The other routines are commands which will traverse the target structure and app
|
||||
* <eiffel>do_until</eiffel>, to all items up to and including the first one that satisfies test.
|
||||
* <eiffel>while_do</eiffel> and <eiffel>do_while</eiffel>, to all items up to the first one that does not satisfy test. (This can also be achieved with <eiffel>until_do</eiffel> or <eiffel>do_until </eiffel> by choosing the opposite test.)
|
||||
|
||||
All 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 no argument. Information about the target of iteration comes from feature <eiffel>target</eiffel>, set by procedure <eiffel>set</eiffel>; information about what needs to be done for each item of the target structure comes from <eiffel>item_action</eiffel> and <eiffel>item_test</eiffel>.
|
||||
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 <eiffel>action</eiffel> argument that must be of type <eiffel>PROCEDURE [G]</eiffel> or an argument <eiffel>test</eiffel> of type <eiffel>FUNCTION [G, BOOLEAN]</eiffel>. Some have both. Information about the target of the iterations comes from feature <eiffel>target</eiffel>, set by procedure <eiffel>set</eiffel>; information about what needs to be done for each item of the target structure comes from the argument <eiffel>action</eiffel> 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. <br/>
|
||||
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]] . Here for example is the effecting of <eiffel>do_if</eiffel>:
|
||||
<code>
|
||||
do_if
|
||||
-- Apply action to every item of target satisfying
|
||||
-- test.
|
||||
do
|
||||
from
|
||||
target.start
|
||||
invariant
|
||||
invariant_value
|
||||
until
|
||||
target.exhausted
|
||||
loop
|
||||
if test then
|
||||
action
|
||||
end
|
||||
forth
|
||||
end
|
||||
end</code>
|
||||
|
||||
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 <code>until_do</code>.<br/>
|
||||
This routine text relies on features <eiffel>start</eiffel>, <eiffel>forth</eiffel> and <eiffel>exhausted</eiffel> which, together with <eiffel>off</eiffel>, 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
|
||||
<code>
|
||||
off: BOOLEAN
|
||||
@@ -297,8 +248,8 @@ This routine text relies on features <eiffel>start</eiffel>, <eiffel>forth</eiff
|
||||
|
||||
and similarly for the others. <br/>
|
||||
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:
|
||||
* <eiffel>search (b :BOOLEAN)</eiffel> moves the iteration to the first position satisfying test if <code>b</code> is true, or not satisfying test if <code>b</code> is false. This use of a boolean argument to switch between two opposite semantics is not part of the recommended style, and you will find few if any other examples in the Base libraries. Here, however, it was deemed preferable to the alternative, which would have involved four separate procedures (if together with <eiffel>search</eiffel> we consider <eiffel>continue_search</eiffel> discussed next).
|
||||
* 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 <eiffel>do_for</eiffel> <code> ( starting , number , step :INTEGER). </code>
|
||||
* <eiffel>search (test: FUNCTION [G, BOOLEAN]; b: BOOLEAN)</eiffel> moves the iteration to the first position satisfying <code>test</code> if both <code>test</code> and <code>b</code> have the same value (both <eiffel>True</eiffel> or both <eiffel>False</eiffel>).
|
||||
* 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 <eiffel>do_for</eiffel> <code> (action: PROCEDURE [G]; starting , number , step: INTEGER). </code>
|
||||
* 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: <eiffel>continue_until</eiffel>, <eiffel>until_continue</eiffel>, <eiffel>continue_while</eiffel>, <eiffel>while_continue</eiffel>, <eiffel>continue_search</eiffel>, <eiffel>continue_for</eiffel>.
|
||||
|
||||
==Two-way iteration==
|
||||
@@ -309,69 +260,77 @@ An alternative design would have kept just one set of features and added two fea
|
||||
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 <code> Feature </code> clause only contains the declarations of two features, <eiffel>finish</eiffel> and <eiffel>back</eiffel>. <br/>
|
||||
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:
|
||||
<code>
|
||||
class
|
||||
TWO_WAY_CHAIN_ITERATOR [G]
|
||||
class TWO_WAY_CHAIN_ITERATOR [G] inherit
|
||||
|
||||
inherit
|
||||
LINEAR_ITERATOR [G]
|
||||
redefine
|
||||
target
|
||||
select
|
||||
start,
|
||||
forth,
|
||||
do_all,
|
||||
until_do,
|
||||
do_until,
|
||||
do_if,
|
||||
do_for,
|
||||
search,
|
||||
forall,
|
||||
exists,
|
||||
until_continue,
|
||||
continue_until,
|
||||
continue_for,
|
||||
continue_search
|
||||
end
|
||||
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_if as do_if_back,
|
||||
do_for as do_for_back,
|
||||
search as search_back,
|
||||
forall as forall_back,
|
||||
exists as exists_back,
|
||||
until_continue as until_continue_back,
|
||||
continue_until as continue_until_back,
|
||||
continue_for as continue_for_back,
|
||||
continue_search as continue_search_back
|
||||
redefine
|
||||
target
|
||||
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
|
||||
|
||||
feature -- Status report
|
||||
create
|
||||
set
|
||||
|
||||
target: BI_LINEAR [G]
|
||||
-- The structure to which iteration features will
|
||||
-- apply
|
||||
feature -- Access
|
||||
|
||||
target: CHAIN [G]
|
||||
|
||||
feature -- Cursor movement
|
||||
|
||||
finish
|
||||
-- Move cursor of target to last position.
|
||||
do
|
||||
target.finish
|
||||
end
|
||||
finish
|
||||
-- Move cursor of `target' to last position.
|
||||
do
|
||||
target.finish
|
||||
end
|
||||
|
||||
back
|
||||
-- Move cursor of `target' backward one position.
|
||||
do
|
||||
target.back
|
||||
end
|
||||
|
||||
back
|
||||
-- Move cursor of target backward one position.
|
||||
do
|
||||
target.back
|
||||
end
|
||||
end
|
||||
</code>
|
||||
|
||||
|
||||
@@ -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!).
|
||||
@@ -1,23 +1,25 @@
|
||||
[[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 donwloaded 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.
|
||||
|
||||
|
||||
|
||||
[[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.
|
||||
|
||||
|
||||
|
||||
|
||||
@@ -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|<br/>
|
||||
[[Software_Installation_for_EiffelStudio|Software Installation for EiffelStudio]] <br/>
|
||||
}}
|
||||
|
||||
|
||||
* '''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)
|
||||
|
||||
<code lang="shell">
|
||||
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
|
||||
</code>
|
||||
|
||||
* '''Use the estudio command to check that EiffelStudio is installed and where it is''
|
||||
<code lang="shell">
|
||||
which estudio
|
||||
</code>
|
||||
{{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.
|
||||
<code lang="shell">
|
||||
ec -version
|
||||
</code>
|
||||
{{note|You should see something like ISE EiffelStudio version 18.07.10.1981 GPL Edition - linux-x86-64 }}
|
||||
|
||||
* '''Check/Install PostgreSQL'''
|
||||
|
||||
<code lang="shell">
|
||||
-- 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
|
||||
</code>
|
||||
|
||||
* '''Install and Check ODBC Driver Manager and ODBC Driver for PostgreSQL'''
|
||||
<code lang="shell">
|
||||
|
||||
-- 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
|
||||
</code>
|
||||
|
||||
* '''Configure PostgreSQL and ODBC Driver'''
|
||||
|
||||
<code lang="shell">
|
||||
-- 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
|
||||
|
||||
</code>
|
||||
|
||||
* '''Configure the Database name, username and password to use the Postgres ODBC Driver'''
|
||||
<code lang="shell">
|
||||
-- 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.
|
||||
</code>
|
||||
|
||||
* '''Test the ODBC to PostgreSQL connection by running the isql command'''
|
||||
<code lang="shell">
|
||||
Read the /etc/odbc.ini.
|
||||
|
||||
isql -v PODBC
|
||||
encoding name too long
|
||||
+---------------------------------------+
|
||||
| Connected! |
|
||||
| |
|
||||
| sql-statement |
|
||||
| help [tablename] |
|
||||
| quit |
|
||||
| |
|
||||
+---------------------------------------+
|
||||
|
||||
</code>
|
||||
|
||||
* '''Compile C code of the Eiffel library store:'''
|
||||
|
||||
<code>cd $YOUR_INSTALLATION_PATH/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''' }}
|
||||
|
||||
* '''Open EiffelStudio eSQL example and run it'''
|
||||
The example is located on `$ISE_EIFFEL/examples/store/esql/`
|
||||
|
||||
<code lang="shell">
|
||||
-- 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>
|
||||
</code>
|
||||
|
||||
@@ -1,3 +1,5 @@
|
||||
[[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]]
|
||||
@@ -57,8 +59,7 @@ The following example shows an attempt to do an SQL Injection attack, but as we
|
||||
end
|
||||
</code>
|
||||
|
||||
As you can observe in the previous example the binding to map the variable name <code>:datetime</code> to their value is done
|
||||
using feature <code> BD_SELECTION.set_map_name</code> and the API is responsible to do the necessary encoding.
|
||||
As you can observe in the previous example the binding to map the variable name <code>:datetime</code> to their value is done using feature <code> BD_SELECTION.set_map_name</code> 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.
|
||||
|
||||
File diff suppressed because it is too large
Load Diff
@@ -1,3 +1,5 @@
|
||||
[[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]]
|
||||
@@ -27,9 +29,9 @@ This sample contains the following class:
|
||||
|
||||
|
||||
{{seealso|<br/>
|
||||
EV_VIEWPORT <br/>
|
||||
EV_SPIN_BUTTON <br/>
|
||||
[[ref:libraries/vision2/reference/ev_button_chart|EV_BUTTON]] <br/>
|
||||
[[ref:libraries/vision2/ev_viewport_chart.html|EV_VIEWPORT]] <br/>
|
||||
[[ref:libraries/vision2/ev_spin_button_chart.html|EV_SPIN_BUTTON]] <br/>
|
||||
[[ref:libraries/vision2/reference/ev_button_chart|EV_BUTTON]] <br/>
|
||||
}}
|
||||
|
||||
|
||||
|
||||
Reference in New Issue
Block a user