Author:halw

Date:2009-11-11T18:50:11.000000Z


git-svn-id: https://svn.eiffel.com/eiffel-org/trunk@354 abb3cda0-5349-4a8f-a601-0c33ac3a8c38
This commit is contained in:
halw
2009-11-11 18:50:11 +00:00
parent 0cafe122f9
commit 0c3a7bc03b
7 changed files with 72 additions and 3 deletions

Binary file not shown.

After

Width:  |  Height:  |  Size: 9.8 KiB

View File

@@ -0,0 +1,3 @@
title=subversion-update-command-01
author=halw
path=content/subversion-update-command-01

Binary file not shown.

After

Width:  |  Height:  |  Size: 15 KiB

View File

@@ -0,0 +1,3 @@
title=subversion-update-in-tools-menu
author=halw
path=content/subversion-update-tools-menu

View File

@@ -6,11 +6,40 @@
==Overview==
By configuring external commands, you can set up EiffelStudio to execute commands for Subversion or other source code management (SCM) systems.
By configuring external commands, you can set up EiffelStudio to execute basic commands for Subversion or other source code management (SCM) systems. Source code management systems, sometimes called revision control or version control systems are often used as part of a software configuration management strategy to track and control changes to software and its supporting documents.
==Defining external commands==
You can define external commands by using the [[External commands editor dialog|external commands editor dialog]]. Then you can execute those commands through the '''Tools''' menu or with keyboard shortcuts.
===Defining a Subversion command===
Suppose that you want to add an external command to EiffelStudio to Subversion's ''update'' command (''update'' brings your working copy up-to-date with the repository). You can define a command with an appropriate name, say ''svn update'', as shown below.
[[Image:subversion-update-command-01|define svn update]]
The command line invokes Subversion and executes the ''update'' command. The placeholder '''$file_name''' substitutes the name of the file associated with the class currently targeted in the editor pane. So if you were editing class <code>MY_CLASS</code> which exists in file <code>my_class.e</code>, then that file name would be used in the Subversion update command executed.
Once the command is defined, it will be accessible through EiffelStudio's Tools menu, either by selecting it explicitly or by using its associated keyboard short cut, <code>Alt+0</code>, in the case of this example.
[[Image:subversion-update-in-tools-menu|Subversion update command in the tools menu]]
===The option to confirm execution of a command===
Now imagine that you want your command to Subversion to offer you a chance to back out of the deal before it executes. You can do this by adding a little more to the command line:
[[Image:subversion-update-command-02|Confirmable svn update command]]
Here the command line first asks for confirmation before executing the command.
When you execute this command you will see the confirmation prompt in EiffelStudio's [[Console tool|Console tool]]. If you choose to execute the command, then just press <code>return</code>. If you have second thoughts and want to cancel the command, then do so by clicking the Console tool's stop button ( [[Image:metrics-tool--debug-stop-icon|Stop command]] ).

View File

@@ -0,0 +1,32 @@
[[Property:title|Execution profiles]]
[[Property:weight|-13]]
[[Property:uuid|90e64e1c-b5fc-e150-9901-50daffaac893]]
While working on a project, you may want to launch it with one or more arguments, on specific working directory, and you may want to change the environment variables.
Those parameters are done by changing the execution profiles. For that you need to use the "Execution parameters" dialog.
*How to open this dialog?
** From the '''Execution, Execution parameters" menu.
** By right-clicking any of the buttons on the debugging/execution toolbar.
==Using the Execution parameters' dialog==
[[Image:argument-dialog]]
The dialog allows you to manage different execution profiles to specify parameters to be passed to the system at execution time.
Each profile allows to set a title, the '''arguments''', the '''working directory''', and you can also set your own '''environment variables'''.
To use a profile, just select it by clicking the corresponding line in the grid..
Once the appropriate execution profile is selected then the system can be run with those parameters using the Run button (If "Keep Dialog Open" is selected the dialog remains opened).<br/>
To run without any particular parameter select '''default''' 's profile.
If you click on "Run Workbench" or "Run Finalized", the system will be executed outside EiffelStudio (thus no debugging)..
{{tip|You can unset an environment variable FOO by adding the "&-FOO" to the environment variables, by prefixing with "&-", this marks the variable "FOO" to be removed. If you use "&-*", all variables will be removed (except the one you can still add after this "&-*"). }}

View File

@@ -20,7 +20,7 @@ Of course, you should remember from previous discussions that <code>l_x</code> m
When void-safety was first envisioned for Eiffel, it was intended that individual CAPs would be proven or certified and documented. This would produce a "catalog" of CAPs.
What happened instead is that the members of the Eiffel standards committee have been able to produce and publish as part of the [http://www.ecma-international.org/publications/standards/Ecma-367.htm standard] a definition of the nature of a CAP from which a determination can be made as to whether a particular code pattern is or is not a CAP.
What happened instead is that the members of the Eiffel standard committee have been able to produce and publish as part of the [http://www.ecma-international.org/publications/standards/Ecma-367.htm standard] a definition of the nature of a CAP from which a determination can be made as to whether a particular code pattern is or is not a CAP.
The definition in the standard document is not easily readable by most developers. So, in this documentation, you will see various examples of CAPs and the rationale behind them.
@@ -176,7 +176,9 @@ Another not-so-obvious CAP is related to the use of the logical implication:
In summary, CAPs provide void-safe protection for certain types of detachable expressions.
Possibly the characteristic of CAPs which is most important to developers is whether or not a particular CAP is supported by the compiler. In other words, if the compiler can provide assurance that a certain code pattern provides void-safe protection, then the developer has that pattern available as a CAP. Likewise, even if a pattern can be shown to be a CAP, but for some reason it is not supported by the compiler, then that pattern is not available as a CAP and the compiler will not allow its use.
Possibly the characteristic of CAPs which is most important to developers is whether or not a particular CAP is supported by the compiler. In other words, from the developers viewpoint, the only opinion that matters in the argument of whether a particular pattern constitutes a CAP is that of the compiler.
If the compiler can provide assurance that a certain code pattern provides void-safe protection, then the developer has that pattern available as a CAP. Likewise, even if a pattern can be shown to be a CAP, but for some reason it is not supported by the compiler, then that pattern is not available as a CAP and the compiler will not allow its use.