Summary

• Page properties (1 modified, 0 added, 0 removed)
• Objects (1 modified, 0 added, 0 removed)
  • Confluence.Code.ConfluencePageClass[0]

Details

Page properties

Content

...	...	@@ -28,14 +28,16 @@
28	28
29	29	The **Run As** command will search for a KiCo launch config for the project. If there is such a config, the selected file is only added to the list of model files that should be compiled. If there is none, a launch config is created by using the main file and environment the project has been created with. If the main file and environment information could not be found, dialogs will query it from the user.
30	30
31		-The **main file** of the launch config is used to set several file path variables, which can be used in several fields of the configuration, notably the shell commands to be executed, and wrapper code input. To use a variablethe syntax is **${**//variable_name//**}**. The variables that are set are
	31	+[[image:attach:launch_config_tabs.png]]
32	32
	33	+The **main file** of the launch config is used to set several file path variables, which can be used in several fields of the configuration, notably the shell commands to be executed, and wrapper code input. To use a variable, the syntax is **${**//variable_name//**}**. The variables that are set are
	34	+
33	33	* //main_name// : The file name, including its file extension (e.g. //MyModel.sct//)
34	34	* //main_path// : The project relative path (e.g. //src/MyModel.sct//)
35	35	* //main_loc// : The absolute file system path (e.g. ///home/me/workspace/MyProject/src/MyModel.sct//)
36	36	* //main_name_no_ext// : The file name without its file extension (e.g. //MyModel//)
37	37
38		-Further, similar variables for the compiled main path are set, that is, the main file in the directory of kieler generated files (see below)
	40	+Further, similar variables for the //compiled main file// are set, which is the main file in the directory of kieler generated files (see below)
39	39
40	40	* //compiled_main_name// : The file name, including its file extension (e.g. //MyModel.sct//)
41	41	* //compiled_//main_path : The project relative path (e.g. //kieler-gen/MyModel.sct//)
...	...	@@ -52,7 +52,7 @@
52	52
53	53	On the //Execute// tab, a list of **shell commands** can be added. They are typically used to further compile the KiCo and wrapper code output and afterwards deploy the result to the target platform. The commands are executed sequentially in order as they appear in the list, after the KiCo compilation and wrapper code generation finished successfully. If a command fails (returns a non-zero exit code), following commands will not be excuted. The name of commands have to be unique and must not contain a comma.
54	54
55		-[[image:attach:launch_config_tabs.png]]
	57	+
56	56
57	57	The standard streams of executed shell commands (stdin, stderr, stdout), as well as errors from the KiCo compilation and wrapper code generation, are printed to the **Console View**.
58	58
...	...	@@ -62,7 +62,7 @@
62	62
63	63	The list of shell commands are a simple mechanism to further compile and deploy code via command line tools. However, there are cases in which command line tools are not available or reasonable to use, for example because a different Eclipse launch configuration does a better job.
64	64
65		-In this case it is desirable that the KiCo launch config only compiles the model and another Eclipse launch config does the rest. This can be achieved via //launch groups//. They let you define a launch configuration, which starts other launch configurations sequentially. To illustrate this, another use-case for launch groups is that you have a Client-Server application and wants to start the client right after the server for debugging. Then you can create a launch config for the server and a launch config for the client. Afterwards you create a launch group with aforesaid configurations.
	67	+In this case it is desirable that the KiCo launch config only compiles the model and another Eclipse launch config does the rest. This can be achieved via //launch groups//. They let you define a launch configuration, which starts other launch configurations sequentially. To illustrate this, another use-case for launch groups is that you have a Client-Server application and want to start the client right after the server for debugging. Then you can create a launch config for the server and a launch config for the client. Afterwards you create a launch group with aforesaid configurations.
66	66
67	67	[[image:attach:launch_group.png]]
68	68
...	...	@@ -97,7 +97,7 @@
97	97
98	98	=== Paths for initial content ===
99	99
100		-The paths for main file origin accept an **absolute** file **path** as well as an **URL** with the platform protocol of Eclipse. An URL for the field has the form //plaftorm:/plugin/a.plugin.name/folder/in/the/plugin/file.txt//
	102	+The path of the main file origin accept an **absolute** file **path** as well as an **URL** with the platform protocol of Eclipse. An URL for the field has the form //plaftorm:/plugin/a.plugin.name/folder/in/the/plugin/file.txt//
101	101
102	102	The snippets origin works analog. It accepts an absolute directory path as well as an URL with the platform protocol which points to a directory. An URL for the field has the form //plaftorm:/plugin/a.plugin.name/folder/in/the/plugin//
103	103
...	...	@@ -105,9 +105,9 @@
105	105
106	106	== Project Wizards with Prom ==
107	107
108		-Prom provides project wizards, which can **create and initialize a project** with a **model file**, a **main file** and wrapper code **snippets**. The wizards for different model file types (e.g. SCChart project vs Esterel project) differ only in the initial content for these. Other initial content is choosen from the environment, which is selected on the first page of a Prom wizard. The project creation itself is done by another wizard, that is started from within the Prom wizard.
	110	+Prom provides project wizards, which can **create and initialize a project** with a **model file**, a **main file** and wrapper code **snippets**. The wizards for different model file types (e.g. SCChart project vs Esterel project) differ only in the initial content for the model file. Other initial content is choosen from the environment, which is selected on the first page of a Prom wizard. The project creation itself is done by another wizard, that is started from within the Prom wizard.
109	109
110		-If the //snippets directory// of an environment is a project relative path, the contents from the //snippets origin// will be copied to this location. If it is an absolute path, it is not copied to the project. Keeping snippets in a single, project indepentent folder, makes it easier to maintain them. For example it is possible to set an absolute path to a directory outside any project as directory for wrapper code snippets. This directory can then be easily maintained using a version control system. Furthermore, if an issue occurs, it has to be addressed only once, because the snippets are not copied to every new project.
	112	+If the //snippets directory// of an environment is a project relative path, the contents from the //snippets origin// will be copied to this location in the newly created project. If it is an absolute path, it is not copied to the project. Keeping snippets in a single, project indepentent folder, makes it easier to maintain them. For example it is possible to set an absolute path to a directory outside any project as directory for wrapper code snippets. This directory can then be easily maintained using a version control system. Furthermore, if an issue occurs, it has to be addressed only once, because the snippets are not copied to every new project.
111	111
112	112	For example to create a project to develop Minstorms running leJOS, one can choose the SCCharts project wizard. In this wizard, one can choose the Mindstorms NXJ environment and define what will be initialized in the project (model file, main file, snippets). Now when pressing the finish button, the related project wizard from the leJOS plugin will be started. When it finishes, the newly created project is initialized with an initial model file, main file and wrapper code snippets.
113	113
...	...	@@ -121,9 +121,9 @@
121	121
122	122	Therefore one can write **wrapper code snippets** for a target device. These can then be injected to a **template file** as part of a KiCo launch. What snippets are injected is defined using **annotations on inputs and outputs** directly in the model file.
123	123
124		-In SCT files, annotations are added as in java, with an at-sign e.g. //@LightSensor S3//. You can write implicit and explicit wrapper code annotations.
	126	+In SCT files, annotations are added as in java, with an at-sign e.g. //@Wrapper Clock, "500"//. You can write implicit and explicit wrapper code annotations.
125	125
126		-Explicit annotations have the form **{{code language="none"}}@Wrapper SnippetName arg1 arg2 ... argN{{/code}}**. An explicit wrapper annotation raises an error if the snippet does not exist, thus it is **recommened** to use the explicit **@Wrapper** annotation. Every other annotation is tried as wrapper code annotation as well, but will be ignored, if no such snippet could be found. Thus you can write the above explicit annotation as **@SnippetName arg1 arg2 ... argN**{{code language="none"}}{{/code}}, but there will be no error if the snippet with this name does not exist or could not be found e.g. because of a typo.
	128	+Explicit annotations have the form **{{code language="none"}}@Wrapper SnippetName, arg1, arg2, ..., argN{{/code}}**. An explicit wrapper annotation raises an error if the snippet does not exist, thus it is **recommened** to use the explicit **@Wrapper** annotation. Every other annotation is tried as wrapper code annotation as well, but will be ignored, if no such snippet could be found. Thus you can write the above explicit annotation as **@SnippetName arg1, arg2, ..., argN**{{code language="none"}}{{/code}}, but there will be no error if the snippet with this name does not exist or could not be found, for example because of a typo.
127	127
128	128	[[image:attach:wrapper_code_generation_scheme.png]]
129	129
...	...	@@ -131,8 +131,10 @@
131	131
132	132	**${model_name}** will be replaced with the name of the model.
133	133
134		-**${inits}** will be replaced with initialization code for components (<@init>...</@init> of a snippet definition). Initialization should occur before the tick loop of the model file.
	136	+**${declarations}** and** ${decls}** will be replaced with additional declarations of variables and functions (<@decl>...</@decl> of a snippet definition). Declarations should occur before the tick loop of the model file. In general they are not required for Java code but may be useful in C applications (e.g. for //extern// calls).
135	135
	138	+**${initializations}** and **${inits}** will be replaced with initialization code for components (<@init>...</@init> of a snippet definition). Initialization should occur before the tick loop of the model file.
	139	+
136	136	**${inputs}** will be replaced with code to set inputs for the model (<@input>...</@input> of a snippet definition). Setting model inputs should occur in the tick loop, before the tick function call.
137	137
138	138	**${outputs}** will be replaced with code to read outputs of the model. (<@output>...</@output> of a snippet definition). Reading outputs of the model should occur in the tick loop, after the tick function call.

Confluence.Code.ConfluencePageClass[0]

Id

...	...	@@ -1,1 +1,1 @@
1		-13763280
	1	+13763282

URL

...	...	@@ -1,1 +1,1 @@
1		-https://rtsys.informatik.uni-kiel.de/confluence//wiki/spaces/KIELER/pages/13763280/Project Creation, Initialization and Launch (Prom)
	1	+https://rtsys.informatik.uni-kiel.de/confluence//wiki/spaces/KIELER/pages/13763282/Project Creation, Initialization and Launch (Prom)