Author:halw

Date:2009-01-11T21:19:41.000000Z


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

documentation/current/eiffelstudio/eiffelstudio-guided-tour/command-line-compiler.wiki

@@ -5,7 +5,7 @@
 Along with compilation from within EiffelStudio, it is possible to start compilation from a command line (shell). This is useful in particular to recompile your system automatically as part of a script.
 
 To use the command-line compiler -- <code>ec</code> for Eiffel Compilation -- execute 
-<code>
+<code lang=text>
 ec option & [class_name] [feature_name]
 </code>
 

documentation/current/eiffelstudio/eiffelstudio-guided-tour/computing-project-metrics.wiki

@@ -28,9 +28,9 @@ We may distinguish between '''product''' ''' metrics''', which measure propertie
 
 Any metric should be relevant: related to some interesting property of the processes or products being measured, such as cost, estimated number of bugs, ease of maintenance...A '''metric theory''' is a set of metric definitions accompanied with a set of convincing arguments to show that the metrics are relevant. Neither EiffelStudio nor this manual provide a metric theory. 
 
-The numbers yielded by measures are meaningless unless we describe what they refer to. Every metric is relative to a certain '''unit''', specified as part of its definition. For example the unit for a metric that counts classes, such as <code> Classes </code>, is called <code> class </code>. 
+The numbers yielded by measures are meaningless unless we describe what they refer to. Every metric is relative to a certain '''unit''', specified as part of its definition. For example the unit for a metric that counts classes, such as <code>Classes</code>, is called <code lang=text>class</code>. 
 
-EiffelStudio provides a set of predefined units. Some simply serve to count occurrences of certain construct specimens in the software; examples include <code> group </code>, <code> class </code>, <code> feature </code>, <code> line </code>, <span>...</span> The metric <code> ratio </code> describes metrics whose values are divisions, for example "average number of classes per cluster", obtained by dividing the number of classes by the number of classes. 
+EiffelStudio provides a set of predefined units. Some simply serve to count occurrences of certain construct specimens in the software; examples include <code>group</code>, <code lang=text>class</code>, <code lang=text>feature</code>, <code>line</code>, <span>...</span> The metric <code>ratio</code> describes metrics whose values are divisions, for example "average number of classes per cluster", obtained by dividing the number of classes by the number of classes. 
 
 A metric can be computed over a scope, this scope is defined using a domain. In a domain 
 </div>

documentation/current/eiffelstudio/eiffelstudio-guided-tour/debugging-and-run-time-monitoring.wiki

@@ -27,7 +27,7 @@ Target a Development Window to the class <code> TESTROOT </code> and pick-and-dr
 
 [[Image:index-83]]
 
-This shows that so far you have enabled only one breakpoint. For a finer degree of control, let's look at the feature's flat form. Pick-and-drop <code> make </code> to the Context Tool -- from the Context Tool itself, since its name appears there, or the Editing Tool); this sets the Context to the <code> Feature </code> Tab. Select the <code> Flat </code> view if that wasn't the last one used: 
+This shows that so far you have enabled only one breakpoint. For a finer degree of control, let's look at the feature's flat form. Pick-and-drop <code>make</code> to the Context Tool -- from the Context Tool itself, since its name appears there, or the Editing Tool); this sets the Context to the <code lang=text>Feature</code> Tab. Select the <code>Flat</code> view if that wasn't the last one used: 
 
 [[Image:index-84]]
 
@@ -37,7 +37,7 @@ By (left) clicking on a breakpoint mark, you toggle it between enabled and not s
 
 [[Image:index-85]]
 
-The breakpoint mark for the routine's third instruction, <code> create  </code> <code> o2 </code>, is red but not filled; this means it is set but not enabled. You can obtain this by right-clicking on the mark and choosing <code> Disable breakpoint </code> on the menu that comes up. Any potential breakpoint will be in one of three states: not set; enabled; set but disabled. 
+The breakpoint mark for the routine's third instruction, <code>create o2</code>, is filled but not red; this means it is set but not enabled. You can obtain this by right-clicking on the mark and choosing <code>Disable breakpoint</code> on the menu that comes up. Any potential breakpoint will be in one of three states: not set; enabled; set but disabled. 
 
 You can see the list of enabled and disabled breakpoints by clicking the <code>Output</code> Tab, or the <code>Display info</code> button in the Project Toolbar. 
 
@@ -51,7 +51,7 @@ To execute, you will use the following Run buttons in the Project toolbar, or th
 
 The buttons are shown here in full bloom, but at any times some of them will be grayed out. <code>Terminate</code> is only active when execution has started and not terminated; <code>Interrupt</code> is only active when the execution is active (not stopped at a breakpoint). 
 
-The <code> Debug </code> menu entries will also remind you of shortcuts: F10 for <code> Step-by-step </code>, F11 for <code> Step into routine </code>, Shift-F11 for <code> Step out of routine </code>, CTRL-F5 for <code> Run without breakpoints </code>, F5 for <code> Run with breakpoints </code>, CTRL-Shift-F5 for <code> Interrupt </code>, Shift-F5 for <code> Terminate </code>. 
+The <code>Debug</code> menu entries will also remind you of shortcuts: F10 for <code>Step-by-step</code>, F11 for <code>Step into routine</code>, Shift-F11 for <code>Step out of routine</code>, <code>CTRL-F5</code> for <code>Run without breakpoints</code>, F5 for <code>Run with breakpoints</code>, <code>CTRL-Shift-F5</code> for <code>Interrupt</code>, Shift-F5 for <code>Terminate</code>. 
 
 Start execution of the compiled system by clicking <code>Run with breakpoints</code>. The display automatically switches to accommodate supplementary tools providing debugging information. Execution stops on the breakpoint that you have enabled on the first instruction of procedure <code>make</code>: 
 
@@ -59,7 +59,7 @@ Start execution of the compiled system by clicking <code> Run with breakpoints <
 
 The pane at the bottom left indicates that execution has stopped in <code>make</code>. The Context shows the flat form of that routine, with a new icon to indicate the stop point which execution has reached. At the bottom right is a new tool, the '''Object Editor''', which shows the content of current object and (later) related objects. At the moment you can see that: 
 * The current object is an instance of class <code>TESTROOT</code>. 
-* The class (as you could also see from its text in a Development Window) has two attributes <code> o1 </code> and <code> o2 </code>, for which the corresponding fields in the current object are both void; this is as expected since you haven't yet executed the two creation instructions <code> create </code> <code>  { </code> <code> HEIR </code> <code> }  </code> <code>  o1 </code> and <code> create </code> <code>  o2 </code>, as they come after the breakpoint. 
+* The class (as you could also see from its text in a Development Window) has two attributes <code>o1</code> and <code>o2</code>, for which the corresponding fields in the current object are both void; this is as expected since you haven't yet executed the two creation instructions <code>create {HEIR} o1</code> and <code>create o2</code>, as they come after the breakpoint. 
 * Along with attributes, an Eiffel class may have '''once functions''', executed at most once -- the first time they are called -- in a given session, and from then on always returning the same value. Here the once function <code>io</code> has not yet been called, but when it is it will return an object of type <code>STD_FILES</code>. 
 
 The execution-time objects that you may display in an Object Editor are our latest kind of EiffelStudio "development object", along with classes, features, explanations, clusters; notice the distinctive icon, a rectangular mesh shape suggestive of an object's division into fields. It appears colored for actual objects and gray for Void references such as <code>operating_environment.</code> 
@@ -70,7 +70,7 @@ Click twice on <code> Step-by-step </code> (or press the function key F10 twice)
 
 [[Image:index-88]]
 
-The last instruction that you executed is <code> create  </code> <code> { </code> <code> HEIR </code> <code> } </code> <code>  o1 </code>, meaning create an object and attach it to <code> o1 </code>, but instead of using the declared type <code> PARENT </code> of <code> o1 </code> use its proper descendant <code> HEIR </code>. As a result, the entry for <code> o1 </code> in the Object Tool no longer shows <code> Void </code> but an object of type <code> HEIR </code>. Note that all objects are identified by their addresses in hexadecimal; such an address is by itself meaningless, but enables you to see quickly whether two object references are attached to the same object. The addresses you see as you run the Guided Tour will -- except for some unlikely coincidence -- be different from the ones appearing here. 
+The last instruction that you executed is <code>create {HEIR} o1</code>, meaning create an object and attach it to <code>o1</code>, but instead of using the declared type <code>PARENT</code> of <code>o1</code> use its proper descendant <code>HEIR</code>. As a result, the entry for <code>o1</code> in the Object Tool no longer shows <code>Void</code> but an object of type <code>HEIR</code>. Note that all objects are identified by their addresses in hexadecimal; such an address is by itself meaningless, but enables you to see quickly whether two object references are attached to the same object. The addresses you see as you run the Guided Tour will -- except for some unlikely coincidence -- be different from the ones appearing here. 
 
 Note that since the garbage collector compacts memory and hence may move objects around, the address of a given object is not guaranteed to remain the same throughout a session.
 
@@ -82,13 +82,13 @@ Now try pick-and-dropping that same object, the instance of <code> HEIR </code>,
 
 In the same way that you can drop a <span>feature</span> pebble into a tool that expects a class, you can also drop an <span>object</span> pebble, which will be understood as denoting the object's generating class. 
 
-Because the Context Tool is showing a class, it has switched to the default format for classes, <code> Ancestors </code>, and is showing the ancestors of <code> HEIR </code>. Click the <code> Feature </code> Tab of the Context Tool to set it back to feature information for the continuation of our debugging session. No feature is currently displayed. 
+Because the Context Tool is showing a class, it has switched to the default format for classes, <code>Ancestors</code>, and is showing the ancestors of <code>HEIR</code>. Click the <code lang=text>Feature</code> Tab of the Context Tool to set it back to feature information for the continuation of our debugging session. No feature is currently displayed. 
 </div><div> 
 ==Stepping into and out of a routine==
 
-Click <code> Step-by-step </code> once more to advance just before the call <code> o1 </code> <span>.</span> <code> display </code>. 
+Click <code>Step-by-step</code> once more to advance just before the call <code>o1.display</code>. 
 
-Choosing <code> Step-by-step </code> again would execute the next step in the current routine, the call <code> o1 </code> <span>. </span> <code> display </code>, treating the entire execution of <code> display </code> from class <code> HEIR </code> as a single operation. Assume instead that you want to go <span>into</span> that routine and follow the details of its execution. For one thing, you might not know that it's a routine of class <code> HEIR </code>, since <code> o1 </code> is declared of type <code> PARENT </code> and it's only through polymorphism, <code> o1 </code> being dynamically of type <code> HEIR </code> at this point, and through dynamic binding, that the execution ends up calling a routine from <code> HEIR </code>. Of course here it's obvious because of the wording of the <code> create </code> a few lines up, but in many cases, especially all those for which polymorphism and dynamic binding are <span>really</span> interesting, the exact type won't be immediately clear from the neighboring software text. 
+Choosing <code>Step-by-step</code> again would execute the next step in the current routine, the call <code>o1.display</code>, treating the entire execution of <code>display</code> from class <code>HEIR</code> as a single operation. Assume instead that you want to go <span>into</span> that routine and follow the details of its execution. For one thing, you might not know that it's a routine of class <code>HEIR</code>, since <code>o1</code> is declared of type <code>PARENT</code> and it's only through polymorphism, <code>o1</code> being dynamically of type <code>HEIR</code> at this point, and through dynamic binding, that the execution ends up calling a routine from <code>HEIR</code>. Of course here it's obvious because of the wording of the <code>create</code> a few lines up, but in many cases, especially all those for which polymorphism and dynamic binding are <span>really</span> interesting, the exact type won't be immediately clear from the neighboring software text. 
 
 Click the <code>Step into routine</code> button (or press F11). This brings execution to the beginning of the appropriate <code>display</code> routine in class <code>HEIR</code>. 
 
@@ -102,7 +102,7 @@ You may now click the <code> Terminate </code> button (Shift-F5) to end executio
 </div><div> 
 ==Other debugging capabilities==
 
-In this little application nothing runs long enough to give you the time to interrupt it. In a longer-running application you may want to interrupt execution, <span>without</span> necessarily terminating it, while it's running (not stopped on a breakpoint). This is the purpose of the <code> Interrupt </code> button (CTRL-Shift-F5). It will interrupt execution at the closest potential breakpoint position, letting you -- as when execution stops because of an exception -- take advantage of all the debugging and browsing facilities to see what's going on inside the program. You may then restart execution -- with or without breakpoints, single-stepping, out of the current routine, into the next routine -- by choosing the appropriate Run button 
+In this little application nothing runs long enough to give you the time to interrupt it. In a longer-running application you may want to interrupt execution, <span>without</span> necessarily terminating it, while it's running (not stopped on a breakpoint). This is the purpose of the <code>Interrupt</code> button (<code>CTRL-Shift-F5</code>). It will interrupt execution at the closest potential breakpoint position, letting you -- as when execution stops because of an exception -- take advantage of all the debugging and browsing facilities to see what's going on inside the program. You may then restart execution -- with or without breakpoints, single-stepping, out of the current routine, into the next routine -- by choosing the appropriate Run button 
 
 In debugging sessions for more advanced applications, you will also find self-explanatory mechanisms enabling you, in addition to what we have seen, to examine all the objects on the "call stack": arguments and local entities of the current routine, its caller, caller's caller and so on.
 

documentation/current/eiffelstudio/eiffelstudio-guided-tour/executing-system-within-and-without-eiffelstudio.wiki

@@ -8,9 +8,12 @@ To complete this study of the compilation process let's see a few more propertie
 
 Our example system is very simple and has no need for execution arguments. In more advanced cases you may want to pass values to the execution, such as a numeric parameter or a file name, so that you can have different executions without changing and recompiling the software.
 
-In the Eiffel text, you can access such run-time arguments through the Kernel Library class <code> ARGUMENTS </code>. There is another technique -- using the arguments to the root creation procedure -- but using <code> ARGUMENTS </code> is the most general way. Any class of your system can inherit from <code> ARGUMENTS </code> and use queries <code> argument_count </code> to know the number of arguments passed to the execution, and <code> argument </code> <code> ( </code> <code> i </code> <code> ) </code>, for <code> i </code> between 1 and <code> argument_count </code> to access the <code> i </code> -th element. Class <code> ARGUMENTS </code> has more features; since you have Eiffelstudio up, you can check the details if you wish (use the contract form). 
+In the Eiffel text, you can access such run-time arguments through the Kernel Library class <code>ARGUMENTS</code>. There is another technique -- using the arguments to the root creation procedure -- but using <code>ARGUMENTS</code> is the most general way. Any class of your system can inherit from <code>ARGUMENTS</code> and use queries <code>argument_count</code> to know the number of arguments passed to the execution, and <code>argument (i)</code>, for <code>i</code> between 1 and <code>argument_count</code> to access the <code>i</code>-th element. Class <code>ARGUMENTS</code> has more features; since you have Eiffelstudio up, you can check the details if you wish (use the contract form). 
 
-There are 2 ways to specify execution arguments from within EiffelStudio. The first is through the <code> Project </code> <code> --> </code> <code> Project Settings </code> <code> --> </code> <code> Debug/Profile </code> <code> --> </code> <code> Program Execution </code> tab. The second is through the argument dialog which can be opened by right-clicking on any of the debugging or program execution buttons on the main toolbar. The latter is more convenient for quick and easy access to execution arguments. 
+There are 2 ways to specify execution arguments from within EiffelStudio. The first is through the menu path
+<code lang=text>
+Project --> Project Settings --> Debug/Profile --> Program Execution</code> 
+The second is through the argument dialog which can be opened by right-clicking on any of the debugging or program execution buttons on the main toolbar. The latter is more convenient for quick and easy access to execution arguments. 
 </div><div> 
 ==Executing from EiffelStudio==
 
@@ -19,20 +22,25 @@ We have seen how to execute a compiled system from within EiffelStudio: choose o
 ==Executing a finalized system outside of EiffelStudio==
 
 A finalized system can be executed on any computer of the appropriate platform; it doesn't need EiffelStudio. The executable version is in the directory
-<code>	project_directory/EIFGENs/target_name/F_code</code>
+<code lang=text>
+project_directory/EIFGENs/target_name/F_code</code>
 
-where <code> project_directory </code> is the project's directory and <code>target_name</code> ist the name of the target. The name of the executable file is <code> system_name </code> <code> .exe </code>, where <code> system_name </code> is the name that you have assigned to your system in the project settings (reflected in the ECF file). 
+where <code>project_directory</code> is the project's directory and <code>target_name</code> ist the name of the target. The name of the executable file is 
+<code>
+system_name.exe</code> 
+where <code>system_name</code> is the name that you have assigned to your system in the project settings (reflected in the ECF file). 
 
-The target of the Guided Tour system is <code> classic </code> and the name is <code> simple </code>, so you can locate <code> simple </code> <span>.</span> <code> exe </code> in <code> EIFGENs/classic/F_code </code> for your project, and run it stand-alone if you like. 
+The target of the Guided Tour system is <code>classic</code> and the name is <code>simple</code>, so you can locate <code>simple.exe</code> in <code lang=text>EIFGENs/classic/F_code</code> for your project, and run it stand-alone if you like. 
 
 If you run the system from a command line, and it requires arguments (<code>simple</code> doesn't), you will provide the appropriate arguments after the command name: 
-<code>	system_name.exe ... arg ...</code>
+<code>
+system_name.exe ... arg ...</code>
 
 Because various platforms have different conventions, "relative paths" referenced in your system will mean something different under Unix/Linux, where they relate to the directory from which the command is launched, and under Windows, where they relate to the application's directory.
 </div><div> 
 ==Executing a frozen or melted system outside of EiffelStudio==
 
-A system compiled in "Workbench mode" -- frozen or melted -- is normally meant for execution within EiffelStudio, not for outside delivery, since it is not optimized. If you need to execute it outside of EiffelStudio, make sure that you have access to the <code> system_name </code> <span>.</span> <code> melted </code> file in <code> project_directory </code> <code> /EIFGENs/target_name/W_code </code>. 
+A system compiled in "Workbench mode" -- frozen or melted -- is normally meant for execution within EiffelStudio, not for outside delivery, since it is not optimized. If you need to execute it outside of EiffelStudio, make sure that you have access to the <code>system_name.melted</code> file in <code>project_directory</code> <code lang=text>/EIFGENs/target_name/W_code</code>. 
 </div><div> 
 ==Moving on==
 

documentation/current/eiffelstudio/eiffelstudio-guided-tour/graphics-based-design.wiki

@@ -36,7 +36,7 @@ For the rest of this discussion we assume <code> INVALID </code> is hidden.
 
 We are now going to add a class graphically to our system. This means you don't have to worry about creating and initializing a file; EiffelStudio will take care of the details.
 
-The useful button here is <code> New class </code>. 
+The useful button here is <code lang=text>New class</code>. 
 
 This button is a pebble, meant to be dropped into the diagram. Drop it somewhere above the bubble for <code>TESTROOT</code>; the exact place doesn't matter, but it has to be within the area of the cluster <code>root_cluster</code> because we'll want our class to part of it. You're asked to name the class: 
 
@@ -78,7 +78,7 @@ Let's add <code> HEIR2 </code> to the system by making <code> TESTROOT </code> a
 
 [[Image:index-125]]
 
-This technique gives you many option and in fact is a convenient way to build your classes, whether at the analysis, design or implementation level. Here, fill the fields as follows. For the top choice, keep the default, <code> Attribute </code>; we'll give class <code> TESTROOT </code> an attribute of type <code> HEIR2 </code>. For its feature category, keep the choice currently displayed, <code> Access </code>. For its name, replace the default, <code> new_feature </code>, by the name <code> my_heir </code>. In the <code> invariant </code> clause, choose 
+This technique gives you many option and in fact is a convenient way to build your classes, whether at the analysis, design or implementation level. Here, fill the fields as follows. For the top choice, keep the default, <code lang=text>Attribute</code>; we'll give class <code>TESTROOT</code> an attribute of type <code>HEIR2</code>. For its feature category, keep the choice currently displayed, <code>Access</code>. For its name, replace the default, <code>new_feature</code>, by the name <code>my_heir</code>. In the <code>invariant</code> clause, choose 
 <code>
     my_heir_not_void: my_heir /= Void
 </code>
@@ -91,7 +91,7 @@ The diagram -- shown below after a slight move of the bubble for <code> TESTROOT
 
 Now pick-and-drop the class bubble <code>TESTROOT</code> to the top Editing Tool to see how the class has been modified. The situation here is different from what we saw earlier with <code>HEIR2</code>, which had been generated from scratch by the diagram. Here <code>TESTROOT</code> existed before, in text form; so the diagram mechanisms have had to preserve the existing feature and feature clauses, and add the elements corresponding to what you have specified through the diagram mechanisms. Here is the beginning of class <code>TESTROOT</code> in its updated form. 
 
-Note how EiffelStudio has generated both the attribute and the associated "set" procedure, <code> set_my_heir </code>, complete with a precondition -- deduced from the invariant you have specified, <code> Void /= my_heir </code> -- and a postcondition. The unlabeled Feature clause of the existing class has been kept; the new features have been entered into clauses labeled <code> Access </code> and <code> Element change </code>, observing the Eiffel standard for common feature clauses in libraries. 
+Note how EiffelStudio has generated both the attribute and the associated "set" procedure, <code>set_my_heir</code>, complete with a precondition -- deduced from the invariant you have specified, <code>my_heir /= Void</code> -- and a postcondition. The unlabeled Feature clause of the existing class has been kept; the new features have been entered into clauses labeled <code>Access</code> and <code>Element change</code>, observing the Eiffel standard for common feature clauses in libraries. 
 
 If you look at the end of the class, you will see an <code>invariant</code> clause listing the invariant that you have entered. 
 </div><div> 
@@ -106,7 +106,7 @@ The change will be very simple. We'll make <code> TESTROOT </code> a client of <
 
 without further ado, as this is just a simple check.
 
-{{note|If you are concerned about the correctness of the class, you may wish to update its creation procedure <code> make </code> to add a creation instruction <code> create </code> <code>  my_heir </code>. Without it the just added invariant would be violated upon creation. }}
+{{note|If you are concerned about the correctness of the class, you may wish to update its creation procedure <code>make</code> to add a creation instruction <code>create my_heir</code> . Without it the just added invariant would be violated upon creation. }}
 
 Nothing happens yet to the diagram. This is normal: EiffelStudio doesn't update the diagram every time you type some text (which, for one thing, might be syntactically incorrect, or invalid). You need to recompile first. Click the <code>Compile</code> button. Then on the Context Tool click <code>Diagram</code>; the new relation appears: 
 
@@ -118,11 +118,11 @@ If the label <code> other </code> of that relation doesn't appear in the exact p
 
 Earlier on, we saw how to create a class from the EiffelStudio diagram, letting EiffelStudio take care of creating and initializing the file. Similarly, you can create a new cluster graphically, and let EiffelStudio create the corresponding directory.
 
-To create a cluster, you can go through <code> Project </code> <code> --> </code> <code> Project settings </code>, or you can click the little Cluster Creation button at the top of the Cluster Tree. Click this button. The resulting dialog asks you for the cluster name, and the existing cluster (non-precompiled) of which you want to make it a subcluster, here leaving only one choice:
+To create a cluster, you can go through <code lang=text>Project --> Project settings</code>, or you can click the little Cluster Creation button at the top of the Cluster Tree. Click this button. The resulting dialog asks you for the cluster name, and the existing cluster (non-precompiled) of which you want to make it a subcluster, here leaving only one choice:
 
 [[Image:index-130]]
 
-Instead of the <code> NEW_CLUSTER </code> default name, type <code> my_cluster </code>; select the only possible supercluster, <code> root_cluster </code>, and click <code> Create </code> at the bottom of the dialog. 
+Instead of the <code>NEW_CLUSTER</code> default name, type <code>my_cluster</code>; select the only possible supercluster, <code>root_cluster</code>, and click <code lang=text>Create</code> at the bottom of the dialog. 
 
 Recompile the project and bring up the cluster diagram again. It shows the subcluster:
 
@@ -138,7 +138,7 @@ This graphical manipulation has caused a structural change: class <code> HEIR2 <
 
 [[Image:index-132]]
 
-If you like, you can also look into the project directory -- using the Windows Explorer, or <code> cd </code> and <code> ls </code> on Unix/Linux -- and check that it now has a subdirectory <code> my_cluster </code> with a file <code> heir2 </code> <span>. </span> <code> e </code> containing the text of class <code> HEIR2 </code>. 
+If you like, you can also look into the project directory -- using the Windows Explorer, or <code>cd</code> and <code>ls</code> on Unix/Linux -- and check that it now has a subdirectory <code>my_cluster</code> with a file <code>heir2.e</code> containing the text of class <code>HEIR2</code>. 
 
 Clearly, it's much more convenient to use EiffelStudio for such manipulations than to move files around manually.
 </div><div> 

documentation/current/eiffelstudio/eiffelstudio-guided-tour/handling-syntax-and-validity-errors.wiki

@@ -20,7 +20,7 @@ Syntax and validity errors will be detected by the compilation process. For sema
 </div><div> 
 ==A syntax error==
 
-To see what happens for a syntax error, replace the keyword <code>is</code> by <code>ist</code> in the first line of routine <code>display</code> of class <code>PARENT</code> (click the position immediately after the <code>s</code> and type a <code>t</code>.). Save the file by clicking the Save button or using CTRL- <code>S</code> and then compile the system. 
+To see what happens for a syntax error, replace the keyword <code>is</code> by <code>ist</code> in the first line of routine <code>display</code> of class <code>PARENT</code> (click the position immediately after the <code>s</code> and type a <code>t</code>.). Save the file by clicking the Save button or using <code>CTRL-S</code> and then compile the system. 
 
 [[Image:index-75]]
 
@@ -30,7 +30,7 @@ You may wonder why the syntax error messages are not a little more verbose than
 </div><div> 
 ==A validity error==
 
-A validity error is a violation of one of the validity constraints given in <span> [http://www.eiffel.com/doc/ Eiffel: The Language]  </span>. Every such constraint is identified by a four-letter code of the form <code>V</code> <code>XXX</code> (the first letter is always <code>V</code>). 
+A validity error is a violation of one of the validity constraints given in <span> [http://www.eiffel.com/doc/ Eiffel: The Language]  </span>. Every such constraint is identified by a four-letter code of the form <code>VXXX</code> (the first letter is always <code>V</code>). 
 
 A validity error will produce a precise error message, which includes the validity code. Although short, the error message is usually sufficient to find out what the error is. If not, you can get the complete rule, straight from the book.
 
@@ -50,7 +50,7 @@ As the error message indicates, you have (shame on you) violated the validity ru
 
 One of the interesting properties of the error message is that everything in color is '''clickable''': class name, feature name, but also the error code. This means that you can start a Pick-and-Drop on any of these elements to find out more. 
 
-For example, to see the exact context of the error, pick-and-drop the name of the affected feature, <code>display</code> -- appearing on the fifth non-blank line, after <code>Feature:</code> -- and pick-and-drop it to the top Text window. (As you remember this means: right-click on it and release; move the mouse to the text window, without clicking any button; right-click again. During the move the cursor shows a cross, the symbol for features.) This displays the erroneous feature: 
+For example, to see the exact context of the error, pick-and-drop the name of the affected feature, <code>display</code> -- appearing on the fifth non-blank line, after <code lang=text>Feature:</code> -- and pick-and-drop it to the top Text window. (As you remember this means: right-click on it and release; move the mouse to the text window, without clicking any button; right-click again. During the move the cursor shows a cross, the symbol for features.) This displays the erroneous feature: 
 
 [[Image:index-78]]
 
@@ -70,7 +70,7 @@ As is often the case when dropping into a specific hole, you don't need to shoot
 
 The result is to display the complete text of the violated rule, straight from the pages of <span> [http://www.eiffel.com/doc/ Eiffel: The Language]  </span>. 
 
-The rule has several clauses, numbered. Since the error message showed the error code as <code>VUAR(1)</code>, the violated clause is the first; this convention of showing the clause number in parentheses applies to all multi-clause validity constraints. 
+The rule has several clauses, numbered. Since the error message showed the error code as <code lang=text>VUAR(1)</code>, the violated clause is the first; this convention of showing the clause number in parentheses applies to all multi-clause validity constraints. 
 
 To correct the error the easiest is to go back to class <code>TESTROOT</code> and reinstate the comment symbol <code>--</code> (two consecutive dashes) on the erroneous line. Save and compile to continue with a valid system. 
 </div>

documentation/current/eiffelstudio/eiffelstudio-guided-tour/how-eiffelstudio-compiles.wiki

@@ -20,7 +20,7 @@ EiffelStudio offers several forms of compilation, which you can see in the entri
 *  '''Melt''': quick incremental recompilation, doesn't optimize code for changed parts. 
 *  '''Freeze''': incremental recompilation, not as fast as Melt, but generates more efficient code for changed parts. 
 *  '''Finalize''': recompile entire system, generating highly optimized code. 
-*  '''Precompile''' (available both in the <code> Project </code> menu and through <code> Tools </code> <code> --> </code> <code> Precompilation wizard </code>), to process an entire library, on which many systems can then rely without having to compile it. 
+*  '''Precompile''' (available both in the <code>Project</code> menu and through <code lang=text>Tools --> Precompilation wizard</code>), to process an entire library, on which many systems can then rely without having to compile it. 
 
 You'll quickly learn to use each of these modes to suit your needs.
 </div><div> 
@@ -36,7 +36,9 @@ EiffelStudio's '''Melting Ice Technology''' reconciles the following goals:
 The idea of the melting ice is based on the observation that, for the practicing software developer, the crucial day-to-day compilation problem is not how to process an entire system but how best to process a '''changed system''', of which an earlier state had previously been processed. 
 
 The change may be big or small; the system may be big or small. ("Small system" here means up to a few tens of thousands of lines.) This gives four possible cases, of which only one is really critical:
-{| 
+
+
+{| border="1"
 |- 
 | 
 | '''Small System'''
@@ -51,14 +53,14 @@ The change may be big or small; the system may be big or small. ("Small system"
 | 
 |}
 
+
 If the system is small, as in both of the left column entries, speed of recompilation with a good compiler will be acceptable.
 
 In the bottom-right box, the developers have spent days or weeks changing many classes in a large system, so they will not resent having to wait a little to see the results of the recompilation, as long as the time remains reasonable. In EiffelStudio this corresponds, as we'll see shortly, to <span>finalization</span>, which is in fact fairly fast anyway, but not as fast as the incremental modes. 
 
 In the day-to-day, minute-by-minute practice of building and modifying software, the case that recurs by far the most often -- and can cause most frustration -- is the one marked xxx: you change only a small share of a big system. Then the result should come quickly enough. More precisely:
 
-{{note|'''Melting Ice Principle '''<br/>
-The time to re-process a system after a change should be a function of the logical size of the change, not of the size of the system. }}
+{{definition|Melting Ice Principle|The time to re-process a system after a change should be a function of the logical size of the change, not of the size of the system. }}
 
 ''The "logical size" of a change may be different from its physical size because a small physical change in a class may have consequences in many others. Imagine for example that you add a feature to class '' <code>ANY</code>'', although this is an extreme case and won't normally happen. Since every class is a descendant of '' <code>ANY</code>'', the logical change may affect the entire system.'' 
 
@@ -77,7 +79,9 @@ The roles of the four compilation modes follow from this analysis:
 ==Properties of the compilation modes==
 
 The following table summarizes the differences between the four compilation modes:
-{| 
+
+
+{| border="1"
 |- 
 | 
 | '''Regenerate C Code?'''
@@ -99,12 +103,17 @@ The following table summarizes the differences between the four compilation mode
 | No
 | No
 |- 
+
+
 | '''Precompile'''
+
+
 | Yes
 | No
 | Yes
 |}
 
+
 During the production and modification of your software, you will usually alternate between melting and freezing, since both of these modes are incremental. Most of the time, you will simply '''melt''', since melting satisfies the Melting Ice Principle: the time to get back to a working system is very short -- proportional to the size of the changes. Note in particular that the unit of melting is the smallest possible one: each feature of a class -- attribute or routine -- may be melted separately. 
 
 The main difference between melting and '''freezing''' is that freezing implies re-generating C code for the changed elements, and hence relinking the system as well. In contrast, when you melt changes, you do not change any C code: it remains frozen. 
@@ -154,7 +163,10 @@ Only two operations, noted above, <span>require</span> freezing: the addition of
 
 Except for the addition of external routines or agents, freezing is never strictly necessary. It is indeed possible to use melting throughout a development, never requesting a freeze after the first compilation. But as the melted-to-frozen ratio grows, you may detect a certain degradation in the performance of the system (determined by how big a share of your system is melted, not how many times you melt it). After a while, then, you may want to refreeze. Like melting, freezing is incremental: only those parts of a system that have been logically changed will be recompiled; as with melting, the determination of what needs to be recompiled is entirely performed by the environment, without any manual intervention on the developer's part.
 
-The principal difference is that freezing takes longer than melting. Because of this you are requested to confirm the first time you freeze. Freeze the example system by choosing the menu entry <code> Project </code> <code> --> </code> <code> Freeze </code>. You get the following dialog: 
+The principal difference is that freezing takes longer than melting. Because of this you are requested to confirm the first time you freeze. Freeze the example system by choosing the menu entry
+<code lang=text>
+Project --> Freeze</code>
+You get the following dialog: 
 
 [[Image:index-142]]
 
@@ -182,6 +194,9 @@ As long as you continue changing, melting and freezing your system, the workbenc
 
 Note that cross-development does not <span>require</span> finalization, since you can cross-compile a frozen version. In practice, however, the finalized version is usually the preferred form for porting a C package because of the performance advantage. 
 
-Finalize the example system now by selecting the menu entry <code> Project </code> <code> --> </code> <code> Finalize </code>. Here too you will be asked to confirm, although the dialog enables you to suppress that confirmation for later attempts, and you may skip C compilation. You will note that finalization is longer than freezing, but still remains quite reasonable thanks to the extensive optimization of the Eiffel compilation process and the structure of the generated C code. 
+Finalize the example system now by selecting the menu entry 
+<code lang=text>
+Project --> Finalize</code>
+Here too you will be asked to confirm, although the dialog enables you to suppress that confirmation for later attempts, and you may skip C compilation. You will note that finalization is longer than freezing, but still remains quite reasonable thanks to the extensive optimization of the Eiffel compilation process and the structure of the generated C code. 
 </div>
 

documentation/current/eiffelstudio/eiffelstudio-reference/browsing-tools/windows-tool/window-list.wiki

@@ -1,7 +1,7 @@
 [[Property:title|Window list]]
 [[Property:weight|1]]
 [[Property:uuid|95058f0f-7c1b-841d-03df-dde4494afaf4]]
-The window list is the main part of the [[Windows tool: Introduction|window tool]] . 
+The window list is the main part of the [[Windows tool|window tool]] . 
 
 [[Image:windows-tool]]