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

Author:halw

Browse Source 
Date:2008-12-01T22:45:08.000000Z


git-svn-id: https://svn.eiffel.com/eiffel-org/trunk@112 abb3cda0-5349-4a8f-a601-0c33ac3a8c38
This commit is contained in:
halw
2008-12-01 22:45:08 +00:00
parent 7312cec21e
commit bba0936e07
11 changed files with 282 additions and 252 deletions
Download Patch File Download Diff File Expand all files Collapse all files

2
documentation/current/eiffelstudio/software-installation/software-installation-eiffelstudio/index.wiki
View File

@@ -1,4 +1,4 @@
[[Property:title|Software Installation for EiffelStudio 6.2]] [[Property:title|Software Installation for EiffelStudio 6.3]]
[[Property:link_title|Software Installation for EiffelStudio]] [[Property:link_title|Software Installation for EiffelStudio]]
[[Property:weight|0]] [[Property:weight|0]]
[[Property:uuid|b92cecd4-4a0c-e2f5-b63e-5d01d39ba990]] [[Property:uuid|b92cecd4-4a0c-e2f5-b63e-5d01d39ba990]]

30
documentation/current/solutions/concurrent-computing/eiffelthread/eiffelthread-tutorial/once-features-multithreaded-mode.wiki
View File

@@ -22,25 +22,25 @@ Moreover, an Eiffel programmer should be able to have an alternative between a o
Here is what you will do to implement a once per process feature: Here is what you will do to implement a once per process feature:
<code> <code>
class class
TEST_ONCE_PER_PROCESS TEST_ONCE_PER_PROCESS
feature -- Access feature -- Access
object_per_thread: OBJECT is object_per_thread: OBJECT
-- Once per thread. -- Once per thread.
once once
create Result.make create Result.make
end end
object_per_process: OBJECT is object_per_process: OBJECT
-- New 'object' (once per process) -- New 'object' (once per process)
-- that could be shared between threads -- that could be shared between threads
-- without reinitializing it. -- without reinitializing it.
indexing indexing
once_status: global once_status: global
once once
create Result.make create Result.make
end end
end -- class TEST_ONCE_PER_PROCESS end -- class TEST_ONCE_PER_PROCESS
</code> </code>

116
documentation/current/solutions/concurrent-computing/eiffelthread/eiffelthread-tutorial/thread-library-overview.wiki
View File

@@ -9,23 +9,24 @@ The class of the thread object you want to create should inherit the <eiffel>THR
Your thread is represented by a class which inherits from <eiffel>THREAD</eiffel> (deferred class). <br/> Your thread is represented by a class which inherits from <eiffel>THREAD</eiffel> (deferred class). <br/>
<code> <code>
class class
MY_THREAD MY_THREAD
inherit inherit
THREAD THREAD
... ...
feature feature
execute is execute
-- define the deferred feature from THREAD. -- define the deferred feature from THREAD.
do do
... ...
end end
...
end -- class MY_THREAD ...
end -- class MY_THREAD
</code> </code>
@@ -33,11 +34,13 @@ Creating a thread is like creating an Eiffel object:
<code> <code>
my_thread: MY_THREAD my_thread: MY_THREAD
-- MY_THREAD inherits from THREAD and defines -- MY_THREAD inherits from THREAD and defines
-- the deferred procedure `execute' -- the deferred procedure `execute'
create my_thread ...
create my_thread
</code> </code>
@@ -45,7 +48,8 @@ Creating a thread is like creating an Eiffel object:
To run the thread, use the feature <eiffel>launch</eiffel> from <eiffel>THREAD</eiffel>. }} To run the thread, use the feature <eiffel>launch</eiffel> from <eiffel>THREAD</eiffel>. }}
<code> my_thread.launch</code> <code>
my_thread.launch</code>
On the Eiffel side, the procedure <eiffel>execute</eiffel> will be launched. This procedures deferred in class <eiffel>THREAD</eiffel>, you have to define it in <eiffel>MY_THREAD</eiffel>. On the Eiffel side, the procedure <eiffel>execute</eiffel> will be launched. This procedures deferred in class <eiffel>THREAD</eiffel>, you have to define it in <eiffel>MY_THREAD</eiffel>.
@@ -66,22 +70,28 @@ The implementation of the class <eiffel>MUTEX</eiffel> is mapped on the C standa
* Declaration of the mutex: * Declaration of the mutex:
<code> my_mutex: MUTEX</code> <code>
my_mutex: MUTEX</code>
* Creation of mutex: * Creation of mutex:
<code> create my_mutex.make</code> <code>
create my_mutex.make</code>
* Locking the mutex: * Locking the mutex:
<code> my_mutex.lock</code> <code>
my_mutex.lock</code>
* Unlocking the mutex: * Unlocking the mutex:
<code> my_mutex.unlock</code> <code>
my_mutex.unlock</code>
* <eiffel>try_lock</eiffel>: if it is not locked yet, lock the mutex and return True, otherwise it returns False. * <eiffel>try_lock</eiffel>: if it is not locked yet, lock the mutex and return True, otherwise it returns False.
<code> my_mutex.try_lock</code> <code>
my_mutex.try_lock</code>
* Is my mutex initialized? * Is my mutex initialized?
<code> my_mutex.is_set</code> <code>
my_mutex.is_set</code>
{{note|on Windows: The <eiffel>MUTEX</eiffel> objects on Windows are recursive while they are not on Unix. A recursive mutex can be locked twice by the same thread. }} {{note|on Windows: The <eiffel>MUTEX</eiffel> objects on Windows are recursive while they are not on Unix. A recursive mutex can be locked twice by the same thread. }}
@@ -96,19 +106,24 @@ Like <eiffel>MUTEX</eiffel>, the features of this class are mapped on the C thre
* Declaration of the semaphore : * Declaration of the semaphore :
<code> my_sem: SEMAPHORE</code> <code>
my_sem: SEMAPHORE</code>
Creation of semaphore: initialize semaphore with nb_tokens, it requires nb_tokens > = 0 Creation of semaphore: initialize semaphore with nb_tokens, it requires nb_tokens > = 0
<code> create my_sem.make (nb_tokens)</code> <code>
create my_sem.make (nb_tokens)</code>
* Wait for a token: * Wait for a token:
<code> my_sem.wait</code> <code>
my_sem.wait</code>
* Give back a token: * Give back a token:
<code> my_sem.post</code> <code>
my_sem.post</code>
* <eiffel>try_wait</eiffel>, similar to try_lock from <eiffel>MUTEX</eiffel>, if a token is available, take it and return <code> True </code>, otherwise return <code> False </code>. * <eiffel>try_wait</eiffel>, similar to try_lock from <eiffel>MUTEX</eiffel>, if a token is available, take it and return <code> True </code>, otherwise return <code> False </code>.
<code> my_sem.try_wait</code> <code>
my_sem.try_wait</code>
{{caution|Be sure that a semaphore does not wait for a token when it is disposed }} {{caution|Be sure that a semaphore does not wait for a token when it is disposed }}
@@ -119,38 +134,44 @@ This class allows to use condition variables in Eiffel. An instance of class <ei
* Declaration of the condition variable * Declaration of the condition variable
<code> my_cond: CONDITION_VARIABLE</code> <code>
my_cond: CONDITION_VARIABLE</code>
* Creation: * Creation:
<code> create my_cond.make</code> <code>
create my_cond.make</code>
* Wait for a signal (send by <eiffel>signal</eiffel>). You need to use a mutex. * Wait for a signal (send by <eiffel>signal</eiffel>). You need to use a mutex.
<code> <code>
my_mutex: MUTEX my_mutex: MUTEX
create my_mutex.make ...
create my_mutex.make
</code> </code>
<code>my_mutex </code> must be locked by the calling thread so as <eiffel>wait</eiffel> can be called. <eiffel>wait</eiffel> atomically unlocks <code> my_mutex </code> and waits for the condition variable <code> my_mutex </code> to receive a signal. As soon as it received a signal, ''<code>my_cond </code>'' locks ''<code>my_mutex </code>'' <code>my_mutex</code> must be locked by the calling thread so as <eiffel>wait</eiffel> can be called. <eiffel>wait</eiffel> atomically unlocks <code> my_mutex </code> and waits for the condition variable <code> my_mutex </code> to receive a signal. As soon as it received a signal, ''<code>my_cond </code>'' locks ''<code>my_mutex </code>''
<code> <code>
my_mutex.lock my_mutex.lock
-- You must lock `my_mutex' before calling wait. -- You must lock `my_mutex' before calling wait.
my_cond.wait (my_mutex) my_cond.wait (my_mutex)
-- Here the critical code to execute when `my_cond' received a signal. -- Here the critical code to execute when `my_cond' received a signal.
my_mutex.unlock my_mutex.unlock
-- Unlock the mutex at the end of the critical section. -- Unlock the mutex at the end of the critical section.
</code> </code>
* Send a signal one thread blocked on the condition variable `my_cond'. * Send a signal one thread blocked on the condition variable `my_cond'.
<code> my_cond.signal</code> <code>
my_cond.signal</code>
* Send a signal to all the threads blocked on the condition variable `my_cond'. * Send a signal to all the threads blocked on the condition variable `my_cond'.
<code> my_cond.broadcast</code> <code>
my_cond.broadcast</code>
{{caution|Be sure that a condition variable is unblocked when it is disposed. }} {{caution|Be sure that a condition variable is unblocked when it is disposed. }}
@@ -167,11 +188,12 @@ class <eiffel>THREAD_ATTRIBUTES</eiffel>: defines the attributes of an Eiffel Th
* <eiffel>join_all</eiffel>: the calling thread waits for all other threads to finished (all its children). * <eiffel>join_all</eiffel>: 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 <eiffel>join</eiffel> of class <eiffel>THREAD_CONTROL</eiffel> (inherited by <eiffel>THREAD</eiffel>): * A parent thread can wait for the termination of a child process through the feature <eiffel>join</eiffel> of class <eiffel>THREAD_CONTROL</eiffel> (inherited by <eiffel>THREAD</eiffel>):
<code> <code>
thr: MY_THREAD thr: MY_THREAD
... ...
thr.launch
... thr.launch
thr.join ...
thr.join
</code> </code>

4
documentation/current/solutions/dates-and-times/eiffeltime/eiffeltime-tutorial/duration.wiki
View File

@@ -117,7 +117,7 @@ Features <eiffel>set_day</eiffel>, <eiffel>set_month</eiffel>, and <eiffel>set_y
<eiffel>DATE_TIME_DURATION</eiffel> is client of <eiffel>DATE_DURATION</eiffel> and <eiffel>TIME_DURATION</eiffel>. Most of the common features described in <eiffel>DATE_DURATION</eiffel> are present in the class. The class deals with its attributes date and time in the same way as <eiffel>DATE_TIME</eiffel>. <eiffel>DATE_TIME_DURATION</eiffel> is client of <eiffel>DATE_DURATION</eiffel> and <eiffel>TIME_DURATION</eiffel>. Most of the common features described in <eiffel>DATE_DURATION</eiffel> are present in the class. The class deals with its attributes date and time in the same way as <eiffel>DATE_TIME</eiffel>.
There are, as in <eiffel>DATE_DURATION</eiffel>, 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 <eiffel>DATE_TIME_DURATION</eiffel>. They have to deal with the attributes time. There are, as in <eiffel>DATE_DURATION</eiffel>, definite and non-definite durations. It is the date part which gives the definite non-definite status. Features <eiffel>canonical</eiffel> and <eiffel>to_canonical</eiffel> are present in <eiffel>DATE_TIME_DURATION</eiffel>. They have to deal with the attributes time.
====Creation==== ====Creation====
@@ -133,7 +133,7 @@ There are still several ways to create an instance:
====Comparison==== ====Comparison====
The rules are the same than those for <eiffel>DATE_DURATION</eiffel>. Features <eiffel><</eiffel>, <eiffel>></eiffel>,<eiffel><=</eiffel>, and <eiffel>>=</eiffel> are available. If both instances are definite, numbers of days are compared. If one of them is non-definite, the result is False. The rules are the same than those for <eiffel>DATE_DURATION</eiffel>. Features <eiffel><</eiffel>, <eiffel>></eiffel>, <eiffel><=</eiffel>, and <eiffel>>=</eiffel> 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==== ====Element change====

30
documentation/current/solutions/networking/eiffelnet/eiffelnet-tutorial/overview-eiffelnet-mechanisms.wiki
View File

@@ -22,20 +22,20 @@ In network-style client-server communication, the mechanism will be dissymmetric
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. 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: 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]] [[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: 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]] [[Image:fig-3]]
Note that the hierarchy as shown is not complete; in particular the full structure uses classes STREAM (of which the <code> STREAM_ </code> classes are heirs) and <code> DATAGRAM </code> 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 [2]. Note that the hierarchy as shown is not complete; in particular the full structure uses classes STREAM (of which the <code> STREAM_ </code> classes are heirs) and <code> DATAGRAM </code> 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 <code>IO_MEDIUM</code>, socket classes have most of their features in common with files. The most important property of this inheritance hierarchy is that it shows how sockets fit within the overall structure. Thanks to the common ancestor <code>IO_MEDIUM</code>, 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. 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: On the first distinction:
* If the communicating systems run on the same machine, you may use one of the <code> UNIX_ </code> classes. * If the communicating systems run on the same machine, you may use one of the <code>UNIX_ </code> classes.
* For systems that run on different machines, you must use one of the <code> NETWORK_ </code> classes. This will also work if the systems are on the same machine, but less efficiently since communication may go through the network. * For systems that run on different machines, you must use one of the <code>NETWORK_ </code> 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 <code> UNIX_ </code> 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 <code> UNIX_FILE </code> in EiffelBase, for a class describing files that behave in the Unix style even though they may be implemented on non-Unix machines.) The use of the word <code>UNIX_ </code> 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 <code>UNIX_FILE</code> 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: 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 <code>STREAM_</code> 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 stream socket, as provided by the <code>STREAM_</code> 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.
@@ -43,11 +43,12 @@ The second distinction reflects two modes of socket communication: stream commun
===Sending and receiving simple values=== ===Sending and receiving simple values===
<code>IO_MEDIUM</code> has all the basic input and output facilities applying to objects of basic types, as also offered in FILE(see the specification of<code> FILE</code> in reference [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 <code>IO_MEDIUM</code> has all the basic input and output facilities applying to objects of basic types, as also offered in FILE(see the specification of<code> FILE</code> 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' is one of the socket classes shown on the preceding figures, any of the above calls will be valid:
<code> <code>
my_socket.putstring ("Some text") my_socket.readint; my_last_integer := my_socketllastint my_socket.putstring ("Some text")
my_socket.readint
my_last_integer := my_socket.lastint
</code> </code>
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. 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.
@@ -58,7 +59,7 @@ In many cases, what you will want to send and receive is not just simple values
The basic mechanism enabling a system to send objects through EiffelNet is also the basic mechanism for storing objects into a file: class <code>STORABLE</code> from EiffelBase. The basic mechanism enabling a system to send objects through EiffelNet is also the basic mechanism for storing objects into a file: class <code>STORABLE</code> from EiffelBase.
As documented in [2], <code>STORABLE</code> provides features to store and retrieve complete object structures. There are three storage procedures, called under the respective forms As documented in [ [[Bibliography|2]] ], <code>STORABLE</code> provides features to store and retrieve complete object structures. There are three storage procedures, called under the respective forms
<code> <code>
struct1.basic_store (iom1) struct1.basic_store (iom1)
struct1.general_store (iom1) struct1.general_store (iom1)
@@ -67,7 +68,7 @@ As documented in [2], <code>STORABLE</code> provides features to store and retri
Assuming that the type of ''iom1 ''is <code>IO_MEDIUM</code> or a conforming type such as [[ref:libraries/base/reference/file_chart|FILE]] or one of the <code>_SOCKET</code> classes, and that the type of ''struct1'' conforms to <code>STORABLE</code> ''.''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 <code>IO_MEDIUM</code>. The current version of EiffelBase, however, supports the more general properties described here. Assuming that the type of ''iom1 ''is <code>IO_MEDIUM</code> or a conforming type such as [[ref:libraries/base/reference/file_chart|FILE]] or one of the <code>_SOCKET</code> classes, and that the type of ''struct1'' conforms to <code>STORABLE</code> ''.''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 <code>IO_MEDIUM</code>. 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 [1] and [2]: 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" {| border="1"
|- |-
| Whenever a routine of class <code>STORABLE</code> stores an object into an external file, it stores with it the dependents of that object. | Whenever a routine of class <code>STORABLE</code> stores an object into an external file, it stores with it the dependents of that object.
@@ -84,7 +85,8 @@ The three storage procedures differ in their degree of generality:
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 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 <code>STORABLE</code>: The scheme for accessing an object structure produced by one of these three procedures is the following, used in a descendant of class <code>STORABLE</code>:
<code> struct2 ?= retrieved (iom2)</code> <code>
struct2 ?= retrieved (iom2)</code>
Here ''iom2'' must be of a type conforming to <code>IO_MEDIUM</code>. The assignment attempt ?= 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 type of ''struct2''; if not, the assignment will assign to ''struct2'' a void reference. Here ''iom2'' must be of a type conforming to <code>IO_MEDIUM</code>. The assignment attempt ?= 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 type of ''struct2''; if not, the assignment will assign to ''struct2'' a void reference.
@@ -99,7 +101,7 @@ Their main use is for a system that relies on datagram communication. As noted a
===Associating commands with events=== ===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: 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 <code>POLL_COMMAND</code>, an heir of the EiffelBase class <code> COMMAND </code> with, in particular, the procedure ''execute''. * The actions are represented by class <code>POLL_COMMAND</code>, an heir of the EiffelBase class <code>COMMAND</code> with, in particular, the procedure ''execute''.
* Using <code>MEDIUM_POLLER</code>, you can specify that a certain command (an instance of <code>POLL_COMMAND</code>) must be executed whenever a certain medium becomes available for the appropriate operation (read, write, handling of out-of-bounds cases). * Using <code>MEDIUM_POLLER</code>, you can specify that a certain command (an instance of <code>POLL_COMMAND</code>) must be executed whenever a certain medium becomes available for the appropriate operation (read, write, handling of out-of-bounds cases).
* Using <code>POLL_MASK</code>, you can set a mask to select the sockets or files on which your instance of <code>MEDIUM_POLLER</code> is working. * Using <code>POLL_MASK</code>, you can set a mask to select the sockets or files on which your instance of <code>MEDIUM_POLLER</code> is working.

2
documentation/current/solutions/networking/eiffelnet/eiffelnet-tutorial/what-eiffelnet.wiki
View File

@@ -26,7 +26,7 @@ Familiarity with the basic concepts of client-server computing will also be help
===Organization of this manual=== ===Organization of this manual===
[[Clients and servers|Section 2]] discusses the notion of client and server. [[An overview of EiffelNet Mechanisms|Section 3]] presents an overview of EiffelNet's facilities. [[The predefined level|Section 4]] describes the predefined level: a set of high-level classes that provide a complete framework, covering the most common uses and limiting the developer's work to the strict minimum. Sections [[Introduction to the examples|5]] to [[A more complex example|10]] 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). [[Clients and servers|Section 11]] is a short bibliography. [[Clients and servers]] discusses the notion of client and server. [[An overview of EiffelNet Mechanisms]] presents an overview of EiffelNet's facilities. [[The predefined level]] describes the predefined level: a set of high-level classes that provide a complete framework, covering the most common uses and limiting the developer's work to the strict minimum. 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]].

68
documentation/current/solutions/other-languages/cecil/cecil-interface-overview.wiki
View File

@@ -19,12 +19,12 @@ Generally, you should use these types when implementing external C functions bou
{{sample|Calling C external `foo' from Eiffel, which takes a pointer and an eiffel object of type OBJECT as arguments and returns an INTEGER. }} {{sample|Calling C external `foo' from Eiffel, which takes a pointer and an eiffel object of type OBJECT as arguments and returns an INTEGER. }}
<div> <div>
<code> <code>
c_foo (ptr: POINTER; obj: OBJECT): INTEGER is c_foo (ptr: POINTER; obj: OBJECT): INTEGER
external external
"C | %"your_file.h%"" "C | %"your_file.h%""
alias alias
"foo" "foo"
end end
</code> </code>
@@ -46,12 +46,12 @@ int foo (void *arg1, char c, FILE *file)
</code> </code>
</div><div>To match the signature, you must declare it in Eiffel as: </div><div>To match the signature, you must declare it in Eiffel as:
<code> <code>
c_foo (arg1: POINTER; c: CHARACTER; file: POINTER): INTEGER is c_foo (arg1: POINTER; c: CHARACTER; file: POINTER): INTEGER
external external
"C (void *, char, FILE *) : int | %""your_file.h%"" "C (void *, char, FILE *) : int | %""your_file.h%""
alias alias
"foo" "foo"
end end
</code> </code>
</div> </div>
Not doing this would generally produce warnings during the C compilation, and it could crash with some C compilers. Not doing this would generally produce warnings during the C compilation, and it could crash with some C compilers.
@@ -91,12 +91,12 @@ Use ''eif_access'' to pass an Eiffel object to an Eiffel routine or to return th
'''For example, in the following external:''' '''For example, in the following external:'''
<code> <code>
c_foo (ptr: POINTER; obj: OBJECT): INTEGER is c_foo (ptr: POINTER; obj: OBJECT): INTEGER
external external
"C | %""your_file.h%"" "C | %""your_file.h%""
alias alias
"foo" "foo"
end end
</code> </code>
@@ -191,18 +191,18 @@ Called within a C external, the function ''eif_adopt'' creates a user protection
In Eiffel: In Eiffel:
<div> <div>
<code> <code>
c_foo (ptr: POINTER; obj: OBJECT): INTEGER is c_foo (ptr: POINTER; obj: OBJECT): INTEGER
external external
"C | %"your_file.h%"" "C | %"your_file.h%""
alias alias
"foo" "foo"
end end
c_display_and_release_obj is c_display_and_release_obj
external external
"C | %"your_file.h%"" "C | %"your_file.h%""
alias alias
"display_and_release_obj" "display_and_release_obj"
end end
</code> </code>
</div> </div>
@@ -403,10 +403,10 @@ See also <eiffel>eif_access</eiffel>.
In Eiffel: In Eiffel:
<code> <code>
foo : STRING is foo : STRING
external external
"C | %"a file.h%"" "C | %"a file.h%""
end end
</code> </code>
In C: In C:

152
documentation/current/solutions/other-languages/eiffel-external-mechanism/obsolete-external-interfaces/c-externals-0.wiki
View File

@@ -108,19 +108,19 @@ For example, a C++ function
should have the Eiffel counterpart should have the Eiffel counterpart
<code> <code>
cpp_add (obj: POINTER; new_int: INTEGER) is cpp_add (obj: POINTER; new_int: INTEGER)
-- Encapsulation of member function add. -- Encapsulation of member function add.
external external
"C++ [IntArray %"intarray.h%"] (IntArray *, int)" "C++ [IntArray %"intarray.h%"] (IntArray *, int)"
end end
</code> </code>
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 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
<code> <code>
add (new_int: INTEGER) is add (new_int: INTEGER)
-- Encapsulation of member function add. -- Encapsulation of member function add.
do do
cpp_add (object_ptr, new_int) cpp_add (object_ptr, new_int)
end end
</code> </code>
where ''object_ptr'' is a secret attribute of type <eiffel>POINTER</eiffel>, initialized by the creation procedures of the class. To the Eiffel developer, <eiffel>add</eiffel> 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. where ''object_ptr'' is a secret attribute of type <eiffel>POINTER</eiffel>, initialized by the creation procedures of the class. To the Eiffel developer, <eiffel>add</eiffel> 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.
@@ -198,101 +198,101 @@ class IntArray {
Here is the result of applying Legacy++ to that class, which will serve as an illustration of both the C++ interface mechanisms and Legacy++: Here is the result of applying Legacy++ to that class, which will serve as an illustration of both the C++ interface mechanisms and Legacy++:
<code> <code>
indexing indexing
description: "Eiffel encapsulation of C++ class IntArray"; description: "Eiffel encapsulation of C++ class IntArray";
date: "$Date: 2006-10-12 03:18:50 +0200 (Thu, 12 Oct 2006) $"; date: "$Date: 2006-10-12 03:18:50 +0200 (Thu, 12 Oct 2006) $";
revision: "$Revision: 64319 $" revision: "$Revision: 64319 $"
class class
INTARRAY INTARRAY
inherit inherit
MEMORY MEMORY
redefine redefine
dispose dispose
end end
create create
make make
feature -- Initialization feature -- Initialization
make (size: INTEGER) is make (size: INTEGER)
-- Create Eiffel and C++ objects. -- Create Eiffel and C++ objects.
do do
object_ptr := cpp_new (size) object_ptr := cpp_new (size)
end end
feature-- Removal feature-- Removal
dispose is dispose
-- Delete C++ object. -- Delete C++ object.
do do
cpp_delete (object_ptr) cpp_delete (object_ptr)
end end
feature feature
output is output
-- Call C++ counterpart. -- Call C++ counterpart.
do do
cpp_output (object_ptr) cpp_output (object_ptr)
end end
add (new_int: INTEGER) is add (new_int: INTEGER)
-- Call C++ counterpart. -- Call C++ counterpart.
do do
cpp_add (object_ptr, new_int) cpp_add (object_ptr, new_int)
end end
feature {INTARRAY} feature {INTARRAY}
underscore_integers: POINTER is underscore_integers: POINTER
-- Value of corresponding C++ data member. -- Value of corresponding C++ data member.
do do
Result := underscore_integers (object_ptr) Result := underscore_integers (object_ptr)
end end
feature {NONE} -- Externals feature {NONE} -- Externals
cpp_new (size: INTEGER): POINTER is cpp_new (size: INTEGER): POINTER
-- Call single constructor of C++ class. -- Call single constructor of C++ class.
external external
"C++ [new IntArray %"INTARRAY.H%"] (EIF_INTEGER)" "C++ [new IntArray %"INTARRAY.H%"] (EIF_INTEGER)"
end end
cpp_delete (cpp_obj: POINTER) is cpp_delete (cpp_obj: POINTER)
-- Call C++ destructor on C++ object. -- Call C++ destructor on C++ object.
external external
"C++ [delete IntArray %"INTARRAY.H%"] ()" "C++ [delete IntArray %"INTARRAY.H%"] ()"
end end
cpp_output (cpp_obj: POINTER) is cpp_output (cpp_obj: POINTER)
-- Call C++ member function. -- Call C++ member function.
external external
"C++ [IntArray %"INTARRAY.H%"] ()" "C++ [IntArray %"INTARRAY.H%"] ()"
alias alias
"output" "output"
end end
cpp_add (cpp_obj: POINTER; new_int: INTEGER) is cpp_add (cpp_obj: POINTER; new_int: INTEGER)
-- Call C++ member function. -- Call C++ member function.
external external
"C++ [IntArray %"INTARRAY.H%"] (EIF_INTEGER)" "C++ [IntArray %"INTARRAY.H%"] (EIF_INTEGER)"
alias alias
"add" "add"
end end
cpp_underscore_integers (cpp_obj: POINTER): POINTER is cpp_underscore_integers (cpp_obj: POINTER): POINTER
-- Value of C++ data member -- Value of C++ data member
external external
"C++ [data_member IntArray %"INTARRAY.H%"]: EIF_POINTER" "C++ [data_member IntArray %"INTARRAY.H%"]: EIF_POINTER"
alias alias
"_integers" "_integers"
end end
feature {NONE} -- Implementation feature {NONE} -- Implementation
object_ptr: POINTER object_ptr: POINTER
end -- class INTARRAY end -- class INTARRAY
</code> </code>

28
documentation/current/solutions/other-languages/eiffel-external-mechanism/obsolete-external-interfaces/c-externals.wiki
View File

@@ -30,7 +30,7 @@ extern size_t one_param_return(FILE *f);</code>
Here is the corresponding Eiffel code: Here is the corresponding Eiffel code:
<code> <code>
c_no_param is c_no_param
-- Encapsulation of a C routine with no parameter. -- Encapsulation of a C routine with no parameter.
external external
"C | %"my_header.h%"" "C | %"my_header.h%""
@@ -38,7 +38,7 @@ Here is the corresponding Eiffel code:
"no_param" "no_param"
end end
c_one_param (i: INTEGER) is c_one_param (i: INTEGER)
-- Encapsulation of a C routine with one parameter. -- Encapsulation of a C routine with one parameter.
external external
"C (int) | %"my_header.h%"" "C (int) | %"my_header.h%""
@@ -46,7 +46,7 @@ Here is the corresponding Eiffel code:
"one_param" "one_param"
end end
c_no_param_return: INTEGER is c_no_param_return: INTEGER
-- Encapsulation of a C routine with no parameter -- Encapsulation of a C routine with no parameter
-- returning an INTEGER -- returning an INTEGER
external external
@@ -55,7 +55,7 @@ Here is the corresponding Eiffel code:
"no_param_return" "no_param_return"
end end
c_one_param_return (p: POINTER): INTEGER is c_one_param_return (p: POINTER): INTEGER
-- Encapsulation of a C routine with one parameter -- Encapsulation of a C routine with one parameter
-- returning an INTEGER -- returning an INTEGER
external external
@@ -82,7 +82,7 @@ Then, the corresponding Eiffel code will look like:
<code> <code>
menu_id: INTEGER is menu_id: INTEGER
-- `ID_MENU' C encapsulation. -- `ID_MENU' C encapsulation.
external external
"C [macro %"my_header.h%"] : EIF_INTEGER" "C [macro %"my_header.h%"] : EIF_INTEGER"
@@ -90,7 +90,7 @@ Then, the corresponding Eiffel code will look like:
"ID_MENU" "ID_MENU"
end end
menu_id_character: CHARACTER is menu_id_character: CHARACTER
-- `ID_MENU_CHARACTER' C encapsulation. -- `ID_MENU_CHARACTER' C encapsulation.
external external
"C [macro %"my_header.h%"] : EIF_CHARACTER" "C [macro %"my_header.h%"] : EIF_CHARACTER"
@@ -98,7 +98,7 @@ Then, the corresponding Eiffel code will look like:
"ID_MENU_CHARACTER" "ID_MENU_CHARACTER"
end end
i_th (p: POINTER; i: INTEGER): INTEGER is i_th (p: POINTER; i: INTEGER): INTEGER
-- Access the `i'-th element of `p', array of C EIF_INTEGER. -- Access the `i'-th element of `p', array of C EIF_INTEGER.
external external
"C [macro %"my_header.h%"] (EIF_INTEGER *, EIF_INTEGER): EIF_INTEGER" "C [macro %"my_header.h%"] (EIF_INTEGER *, EIF_INTEGER): EIF_INTEGER"
@@ -125,7 +125,7 @@ typdef struct point {
Then, the corresponding Eiffel code will look like: Then, the corresponding Eiffel code will look like:
<code> <code>
x (p: POINTER): INTEGER is x (p: POINTER): INTEGER
-- Access field x of struct pointed by `p'. -- Access field x of struct pointed by `p'.
external external
"C [struct %"my_header.h%"] (Point): EIF_INTEGER" "C [struct %"my_header.h%"] (Point): EIF_INTEGER"
@@ -133,7 +133,7 @@ Then, the corresponding Eiffel code will look like:
"x" "x"
end end
y (p: POINTER): INTEGER is y (p: POINTER): INTEGER
-- Access field y of struct pointed by `p'. -- Access field y of struct pointed by `p'.
external external
"C [struct %"my_header.h%"] (Point): EIF_INTEGER" "C [struct %"my_header.h%"] (Point): EIF_INTEGER"
@@ -141,7 +141,7 @@ Then, the corresponding Eiffel code will look like:
"y" "y"
end end
set_x (p: POINTER; v: INTEGER) is set_x (p: POINTER; v: INTEGER)
-- Set field x of struct pointed by `p'. -- Set field x of struct pointed by `p'.
external external
"C [struct %"my_header.h%"] (Point, int)" "C [struct %"my_header.h%"] (Point, int)"
@@ -149,7 +149,7 @@ Then, the corresponding Eiffel code will look like:
"x" "x"
end end
set_y (p: POINTER: v: INTEGER) is set_y (p: POINTER: v: INTEGER)
-- Set field y of struct pointed by `p' with `v'. -- Set field y of struct pointed by `p' with `v'.
external external
"C [struct %"my_header.h%"] (Point, int)" "C [struct %"my_header.h%"] (Point, int)"
@@ -171,13 +171,13 @@ Therefore if you want to call an external routine defined in a DLL supposed to b
<code> <code>
my_cdecl_routine (a: INTEGER): POINTER is my_cdecl_routine (a: INTEGER): POINTER
-- Encapsulation of a dll function with the `_cdecl' call mechanism. -- Encapsulation of a dll function with the `_cdecl' call mechanism.
external external
"C [dll32 %"my_dll.dll%"] (int): EIF_POINTER" "C [dll32 %"my_dll.dll%"] (int): EIF_POINTER"
end end
my_stdcall_routine (a: INTEGER): POINTER is my_stdcall_routine (a: INTEGER): POINTER
-- Encapsulation of a dll function with the `_stdcall' call mechanism. -- Encapsulation of a dll function with the `_stdcall' call mechanism.
external external
"C [dllwin32 %"my_dll.dll%"] (int): EIF_POINTER" "C [dllwin32 %"my_dll.dll%"] (int): EIF_POINTER"
@@ -207,7 +207,7 @@ In WEL, the encapsulation is written as:
<code> <code>
cwin_send_message (hwnd: POINTER; msg, wparam, param: INTEGER) is cwin_send_message (hwnd: POINTER; msg, wparam, param: INTEGER)
-- SDK SendMessage (without the result) -- SDK SendMessage (without the result)
external external
"C [macro %"wel.h%"] (HWND, UINT, WPARAM, LPARAM)" "C [macro %"wel.h%"] (HWND, UINT, WPARAM, LPARAM)"

85
documentation/current/solutions/other-languages/eiffel2java/eiffel2java-sample.wiki
View File

@@ -43,58 +43,59 @@ Value of `my_integer' after call to `my_method' is 2
===Code description=== ===Code description===
<code>(Eiffel Code) <code>(Eiffel Code)
class class
EIFFEL_TO_JAVA EIFFEL_TO_JAVA
inherit inherit
SHARED_JNI_ENVIRONMENT SHARED_JNI_ENVIRONMENT
create create
make make
feature -- Creation feature -- Creation
make is make
local local
class_test: JAVA_CLASS class_test: JAVA_CLASS
instance_of_class_test: JAVA_OBJECT instance_of_class_test: JAVA_OBJECT
fid: POINTER fid: POINTER
value: INTEGER value: INTEGER
j_args: JAVA_ARGS j_args: JAVA_ARGS
do do
--| Creation of the Java object --| Creation of the Java object
class_test := jni.find_class ("test") class_test := jni.find_class ("test")
create instance_of_class_test.create_instance (class_test, "()V", Void) create instance_of_class_test.create_instance (class_test, "()V", Void)
--| Access to a public attribute --| Access to a public attribute
fid := instance_of_class_test.field_id ("my_integer", "I") fid := instance_of_class_test.field_id ("my_integer", "I")
-- 'fid' contains the id of the field 'my_integer' -- 'fid' contains the id of the field 'my_integer'
-- 'value' contains the value of the field referenced -- 'value' contains the value of the field referenced
-- by 'fid' -- by 'fid'
value := instance_of_class_test.integer_attribute (fid) value := instance_of_class_test.integer_attribute (fid)
--| Access to a static attribute using directly the JAVA_CLASS --| Access to a static attribute using directly the JAVA_CLASS
fid := class_test.field_id ("my_static_integer", "I") fid := class_test.field_id ("my_static_integer", "I")
value := class_test.integer_attribute (fid) ... 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' --| Access to a static attribute using the attribute 'jclass'
-- Call to the void method referenced by 'fid' fid := instance_of_class_test.jclass.field_id ("my_static_integer", "I")
instance_of_class_test.void_method (fid, j_args) value := instance_of_class_test.jclass.integer_attribute (fid)
end -- make
--| 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</code> end -- class EIFFEL_TO_JAVA</code>

17
documentation/current/solutions/other-languages/eiffel2java/eiffel2java-tutorial.wiki
View File

@@ -10,14 +10,15 @@ The Java interface allows you to call Java routines or attributes from your Eiff
===Requirements=== ===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] ) * 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 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.. * The environment variables should be setup correctly. See $ISE_EIFFEL\library\Eiffel2Java\README.txt for information how to do this.
===Borland users=== ===Borland users===
On Windows, the JDK includes a set of C libraries which have been compiled for the Microsoft C compiler. Before being able to use the JDK from Eiffel you need to perform the following operation: On Windows, the JDK includes a set of C libraries which have been compiled for the Microsoft C compiler. Before being able to use the JDK from Eiffel you need to perform the following operation:
# In $JDK_HOME\lib, rename javai.lib into javai.lib.microsoft # In $JDK_HOME\lib, rename javai.lib into javai.lib.microsoft
# From the DOS command prompt and in the directory $JDK_HOME\lib, launch the following command <br/> # From the DOS command prompt and in the directory $JDK_HOME\lib, launch the following command <br/>
<code>%ISE_EIFFEL%\bcc55\bin\implib javai.lib..\bin\javai.dll</code> <code lang=text>
%ISE_EIFFEL%\bcc55\bin\implib javai.lib..\bin\javai.dll</code>
===Limitations=== ===Limitations===
@@ -143,17 +144,21 @@ When you want to call a Java method or access a field, you need to specify its s
|} |}
The signature for a Java class has the following form: The signature for a Java class has the following form:
<code>L fully-qualified-class;</code> <code lang=text>
L fully-qualified-class;</code>
For example, class String: For example, class String:
<code>Ljava/lang/String;</code> <code lang=text>
Ljava/lang/String;</code>
The signature for a method has the following form: The signature for a method has the following form:
<code>(arguments-types) returned-types</code> <code lang=text>
(arguments-types) returned-types</code>
For example, the signature of a method that takes as arguments an integer and a string and return void is: For example, the signature of a method that takes as arguments an integer and a string and return void is:
<code>(ILjava/lang/String;)V</code> <code lang=text>
(ILjava/lang/String;)V</code>