Author:halw

Date:2011-02-23T00:38:37.000000Z


git-svn-id: https://svn.eiffel.com/eiffel-org/trunk@779 abb3cda0-5349-4a8f-a601-0c33ac3a8c38

documentation/current/eiffelstudio/eiffelstudio-reference/compiler/command-line/eiffelstudio-using-command-line-options.wiki

@@ -39,7 +39,7 @@ The table below lists the available ''options'', the arguments they require, and
 |- 
 | -finalize
 | 
-| Produce a finalized system. See below.
+| Produce a finalized system. See note below.
 |- 
 | -precompile
 | 

documentation/current/eiffelstudio/eiffelstudio-reference/compiler/melting-ice-technology.wiki

@@ -1,10 +1,23 @@
 [[Property:title|Melting Ice Technology]]
 [[Property:weight|-15]]
 [[Property:uuid|17c5cf39-2bb3-67e4-11e3-2b6d021e5df1]]
-EiffelStudio relies on Melting Ice Technology, the proprietary compilation mechanism of Eiffel Software, which offers three forms of compilation:
+=Types of compilation provided by Melting Ice=
-*  ''melting'' for making a few changes. The fastest of the mechanisms, typically taking a few seconds after small changes. Melting time is proportional to the size of the changed parts and affected classes, while the time needed to freeze or finalize is partly proportional to the size of the whole system. As long as you do not include new external C/C++ code, a C/C++ compiler is not required. However, execution speed is not optimal. The generated executable is debuggable. 
+
-*  ''freezing'' generates C code from the active system, and then compiles it into machine code; you must have a C/C++ compiler installed. You need to use this option if you add new agents or external C/C++ calls. Unless you add external code, you can re-freeze every couple of days. The rest of the time, you can melt your software to receive immediate feedback. The speed is still slower than when finalizing, but the generated executable is still debuggable. 
+EiffelStudio relies on Melting Ice Technology, the proprietary compilation mechanism of Eiffel Software, which offers three forms of compilation: '''melting''', '''freezing''', and '''finalizing'''.
-*  ''finalizing'' delivers a production version (intermediate or final) of your software. It can be used to measure its performance in operational conditions. Finalization performs extensive time and space optimizations that enable Eiffel to match the efficiency of C/C++; it also creates a stand-alone C package that you can use for cross-platform development. Because of all the optimizations involved, finalizing takes the most time, and the generated executable is not debuggable. 
+
+==Melting==
+
+Melting is used for making a few changes during typical development activity. The fastest of the mechanisms, typically taking a few seconds after small changes. Melting time is proportional to the size of the changed parts and affected classes, while the time needed to freeze or finalize is partly proportional to the size of the whole system. As long as you do not include new external C/C++ code, a C/C++ compiler is not required. However, execution speed is not optimal. The generated executable is debuggable. 
+
+==Freezing==
+
+Freezing generates C code from the active system, and then compiles it into machine code; you must have a C/C++ compiler installed. You need to use this option if you add new agents or external C/C++ calls. Unless you add external code, you can re-freeze every couple of days. The rest of the time, you can melt your software to receive immediate feedback. The speed is still slower than when finalizing, but the generated executable is still debuggable. 
+
+==Finalizing==
+
+Finalizing delivers a production version (intermediate or final) of your software. It can be used to measure its performance in operational conditions. Finalization performs extensive time and space optimizations that enable Eiffel to match the efficiency of C/C++; it also creates a stand-alone C package that you can use for cross-platform development. Because of all the optimizations involved, finalizing takes the most time, and the generated executable is not debuggable. 
+
+=Additional detail=
 
 Melting and freezing generate an executable in the EIFGENs|target_name|W_code subdirectory of the project directory. The executable is composed of a standard executable file named after the system, and of a < ''system name''>.melted file, which is called the Eiffel update file. Although it is recommended to finalize the system when running it from outside EiffelStudio (since the performance is better), it is possible to launch a melted/frozen executable. However, the Eiffel update file is necessary, the executable alone will not run. 
 

documentation/current/solutions/concurrent-computing/concurrent-eiffel-scoop/scoop-examples/dining-savages.wiki

@@ -10,14 +10,19 @@
 
 =Description=
 
-The problem of the dining savages (an obvious allusion to the classic dining philosophers) is based on the arguably tasteless analogy of a number of members of a primitive culture, hereinafter called the "savages", are sharing a meal from a single pot. The players are the savages themselves, a cook, and the pot. The pot contains a certain number of servings of savage sustenance (the nature of which will be left to your imagination). Each of the savages can freely remove a serving from the pot so long as the pot is not empty. So before taking a serving, a savage must check to make sure the pot is not empty. In the case in which the pot is empty, the savage must wake up the cook to refill the pot, after which the feast continue. The savages, then, can eat only when the pot is not empty, and the cook can fill the pot only when the pot is empty.
+The problem of the dining savages (an allusion to the classic dining philosophers) is based on the arguably tasteless analogy of a number of members of a primitive culture, hereinafter called the "savages", sharing a meal from a single pot. The primary abstractions are the savages themselves, a cook, and the pot. The pot contains a certain number of servings of savage sustenance (the nature of which will be left to your imagination). Each of the savages can freely remove a serving from the pot so long as the pot is not empty. So before taking a serving, a savage must check to make sure the pot is not empty. In the case in which the pot is empty, the savage must wake up the cook to refill the pot, after which the feast continue. The savages, then, can eat only when the pot is not empty, and the cook can fill the pot only when the pot is empty.
 
 
 =Highlights=
 
-The primary shared resource here is the pot, represented by class <code>POT</code>. <code>POT</code> has queries <code>is_empty</code> and <code>is_full</code> that can be used by savages (modeled by class <code>SAVAGE</code>) and the cook (class <code>COOK</code>). <code>POT</code> also has a feature to allow refilling of the pot. This feature is exported only to <code>COOK</code>. Another feature, this one exported only to <code>SAVAGE</code> allows the removal of a serving from the pot.
+The primary shared resource here is the pot, represented by class <code>POT</code>, which is accessed by the savages and by the cook. <code>POT</code> has queries <code>is_empty</code> and <code>is_full</code> that can be used by savages (modeled by class <code>SAVAGE</code>) and the cook (class <code>COOK</code>). <code>POT</code> also has a feature to allow refilling of the pot. This feature is exported only to <code>COOK</code>. Another feature, this one exported only to <code>SAVAGE</code> allows the removal of a serving from the pot.
+
+In the root class, you can adjust the number of savages, the size (in servings) of the pot, and how hungry the savages are. The hunger index indicates how many times a savage will take a serving from the pot and eat it before becoming sated. So if the pot holds 20 servings and there are 5 savages with hunger index of 4, then the pot will become empty just as the last savage takes his last serving, meaning that the pot will not require refilling. In the same scenario, if the hunger index were 10, then 50 servings total would be required, resulting in the need for the cook to be notified to refill the pot 2 times ... and 10 servings leftover ... presumably for tomorrow's breakfast.
+
+The root class creates the pot, then the cook, then some number of savages. As the savages are created, their lives are launched. To occupy themselves, they repeatedly check the pot, take a serving, and eat. They give this all up once they have eaten the number of servings prescribed by their hunger index. During the check of the pot, if the pot is empty, a separate call is made to the cook requesting that the pot be refilled, and the savage goes on about the business of removing a serving from the pot. It is possible that when the savage then tries to get a serving from the pot, the pot will still be empty. In this case the precondition on <code>get_serving_from_pot</code> will cause the savage to wait until such time as the pot is no longer empty.
+
+Whenever the cook is requested to refill the pot, the <code>{COOK}.cook</code> procedure is called. The procedure takes as an argument the pot which is declared of course as separate. So access to the pot must be guaranteed before <code>cook</code> can execute. The <code>cook</code> procedure has a precondition that causes it to wait if the pot is not currently empty.
 
-In the root class, you can adjust the number of savages, the size (in servings) of the pot, and how hungry the savages are. The hunger index indicates how many times a savage will take a serving from the pot and eat it before being sated. So if the pot holds 20 servings and there are 5 savages with hunger index of 4, then the pot will become empty just as the last savage takes his last serving, meaning that the pot will not require refilling. In the same scenario, if the hunger index were 10, then 50 servings total would be required, resulting in the need for the cook to be notified to refill the pot 2 times ... and 10 servings leftover ... presumably for tomorrow's breakfast.