Plugins - Revision history

Hzwakenberg at 12:20, 30 July 2024

2024-07-30T12:20:56Z

Hzwakenberg: /* Java Generation */

2018-09-09T13:08:43Z

Java Generation

← Older revision		Revision as of 15:08, 9 September 2018
Line 72:		Line 72:
	=== Java Generation===		=== Java Generation===

−	NB: Liberty Eiffel currently does not provide a Java back-end.<BR> The information in this paragraph refers to ~~the legacy<BR> SmartEiffel system,~~ Liberty Eiffel's predecessor.	+	NB: Liberty Eiffel currently does not provide a Java back-end.<BR> The information in this paragraph refers to Liberty Eiffel's legacy predecessor.

	For the Java [[Glossary#BackEnd\|back-end]], the plugin sub-directory must be named <TT>java</TT>.		For the Java [[Glossary#BackEnd\|back-end]], the plugin sub-directory must be named <TT>java</TT>.

Dkearns: s/LibertyEiffel/Liberty Eiffel/

2016-06-16T11:28:05Z

s/LibertyEiffel/Liberty Eiffel/

← Older revision		Revision as of 13:28, 16 June 2016
Line 1:		Line 1:
	[[Category: Interfacing]]		[[Category: Interfacing]]
−	Plugins are a means to augment the capabilities of ~~LibertyEiffel~~, by incorporating libraries which have the color, smell, and taste of the standard libraries. In fact, it's an extension of the standard Eiffel mechanism, [[externals]].	+	Plugins are a means to augment the capabilities of Liberty Eiffel, by incorporating libraries which have the color, smell, and taste of the standard libraries. In fact, it's an extension of the standard Eiffel mechanism, [[externals]].

	The goal of plugins is independence from the [[Glossary#BackEnd\|back-end]]. This means that, potentially, the ''same'' library could be used simultaneously by [[compile_to_c]] and [[compile_to_jvm]]. Note that in the future we might want to provide other [[Glossary#BackEnd\|back-ends]]. In this case, the plugin system will become more important.		The goal of plugins is independence from the [[Glossary#BackEnd\|back-end]]. This means that, potentially, the ''same'' library could be used simultaneously by [[compile_to_c]] and [[compile_to_jvm]]. Note that in the future we might want to provide other [[Glossary#BackEnd\|back-ends]]. In this case, the plugin system will become more important.
Line 11:		Line 11:
	* the external side, which implements the plugin's interface for one or several [[Glossary#BackEnd\|back-ends]] (for example, C and Java).		* the external side, which implements the plugin's interface for one or several [[Glossary#BackEnd\|back-ends]] (for example, C and Java).

−	The Eiffel side is 100% Eiffel code, and it uses ''external'' features that allow crossing the barrier to the other side of the plugin. The barrier is managed by the ~~LibertyEiffel~~ compiler which associates external functions with the ''external'' features using configuration files furnished by the plugin.	+	The Eiffel side is 100% Eiffel code, and it uses ''external'' features that allow crossing the barrier to the other side of the plugin. The barrier is managed by the Liberty Eiffel compiler which associates external functions with the ''external'' features using configuration files furnished by the plugin.

	== Eiffel Side ==		== Eiffel Side ==
Line 32:		Line 32:

	* '''location''' indicates the directory where you store one or many of your plugins. This path can contain environment variables (either true system environment variables, or variables defined in the <TT>[Environment]</TT> section of your [[Configuration file\|configuration file]]).		* '''location''' indicates the directory where you store one or many of your plugins. This path can contain environment variables (either true system environment variables, or variables defined in the <TT>[Environment]</TT> section of your [[Configuration file\|configuration file]]).
−	For example, the standard ~~LibertyEiffel~~ libraries are defined by using the following ''location'':	+	For example, the standard Liberty Eiffel libraries are defined by using the following ''location'':
	location: "${sys}plugins"		location: "${sys}plugins"

Line 72:		Line 72:
	=== Java Generation===		=== Java Generation===

−	NB: ~~LibertyEiffel~~ currently does not provide a Java back-end.<BR> The information in this paragraph refers to the legacy<BR> SmartEiffel system, ~~LibertyEiffel~~'s predecessor.	+	NB: Liberty Eiffel currently does not provide a Java back-end.<BR> The information in this paragraph refers to the legacy<BR> SmartEiffel system, Liberty Eiffel's predecessor.

	For the Java [[Glossary#BackEnd\|back-end]], the plugin sub-directory must be named <TT>java</TT>.		For the Java [[Glossary#BackEnd\|back-end]], the plugin sub-directory must be named <TT>java</TT>.

Dkearns: Typos

2016-06-16T11:26:38Z

Typos

← Older revision		Revision as of 13:26, 16 June 2016
Line 1:		Line 1:
	[[Category: Interfacing]]		[[Category: Interfacing]]
−	Plugins are a means to augment ~~in a spectactular manner~~ the capabilities of LibertyEiffel, by incorporating libraries which have the color, smell, and taste of the standard libraries. In fact, it's an extension of the standard Eiffel mechanism, [[externals]].	+	Plugins are a means to augment the capabilities of LibertyEiffel, by incorporating libraries which have the color, smell, and taste of the standard libraries. In fact, it's an extension of the standard Eiffel mechanism, [[externals]].

	The goal of plugins is independence from the [[Glossary#BackEnd\|back-end]]. This means that, potentially, the ''same'' library could be used simultaneously by [[compile_to_c]] and [[compile_to_jvm]]. Note that in the future we might want to provide other [[Glossary#BackEnd\|back-ends]]. In this case, the plugin system will become more important.		The goal of plugins is independence from the [[Glossary#BackEnd\|back-end]]. This means that, potentially, the ''same'' library could be used simultaneously by [[compile_to_c]] and [[compile_to_jvm]]. Note that in the future we might want to provide other [[Glossary#BackEnd\|back-ends]]. In this case, the plugin system will become more important.
Line 31:		Line 31:
	([[library_class:INTEGER\|<TT>INTEGER</TT>]], [[library_class:BOOLEAN\|<TT>BOOLEAN</TT>]], etc.) or use [[library_class:POINTER\|<TT>POINTER</TT>]] (common usage: <TT>a_string.to_external</TT>).		([[library_class:INTEGER\|<TT>INTEGER</TT>]], [[library_class:BOOLEAN\|<TT>BOOLEAN</TT>]], etc.) or use [[library_class:POINTER\|<TT>POINTER</TT>]] (common usage: <TT>a_string.to_external</TT>).

−	* '''location''' indicates the directory where you store one or many of your plugins. This path can contain environment variables (either true system environment variables, or variables ~~definined~~ in the <TT>[Environment]</TT> section of your [[Configuration file\|configuration file]]).	+	* '''location''' indicates the directory where you store one or many of your plugins. This path can contain environment variables (either true system environment variables, or variables defined in the <TT>[Environment]</TT> section of your [[Configuration file\|configuration file]]).
	For example, the standard LibertyEiffel libraries are defined by using the following ''location'':		For example, the standard LibertyEiffel libraries are defined by using the following ''location'':
	location: "${sys}plugins"		location: "${sys}plugins"

Hzwakenberg: /* How does it work ? */

2016-03-05T11:54:05Z

How does it work ?

← Older revision		Revision as of 13:54, 5 March 2016
Line 11:		Line 11:
	* the external side, which implements the plugin's interface for one or several [[Glossary#BackEnd\|back-ends]] (for example, C and Java).		* the external side, which implements the plugin's interface for one or several [[Glossary#BackEnd\|back-ends]] (for example, C and Java).

−	The Eiffel side is 100% Eiffel code, and it uses ''external'' features that allow crossing the barrier to the other side of the plugin. The barrier is managed by ~~LibertyEiffel :~~ the compiler associates external functions with the ''external'' features using configuration files furnished by the plugin.	+	The Eiffel side is 100% Eiffel code, and it uses ''external'' features that allow crossing the barrier to the other side of the plugin. The barrier is managed by the LibertyEiffel compiler which associates external functions with the ''external'' features using configuration files furnished by the plugin.

	== Eiffel Side ==		== Eiffel Side ==

Hzwakenberg at 11:52, 5 March 2016

2016-03-05T11:52:40Z

← Older revision		Revision as of 13:52, 5 March 2016
Line 2:		Line 2:
	Plugins are a means to augment in a spectactular manner the capabilities of LibertyEiffel, by incorporating libraries which have the color, smell, and taste of the standard libraries. In fact, it's an extension of the standard Eiffel mechanism, [[externals]].		Plugins are a means to augment in a spectactular manner the capabilities of LibertyEiffel, by incorporating libraries which have the color, smell, and taste of the standard libraries. In fact, it's an extension of the standard Eiffel mechanism, [[externals]].

−	The goal of plugins is independence from the [[Glossary#BackEnd\|back-end]]. This means that, potentially, the ''same'' library could be used simultaneously by [[compile_to_c]] and [[compile_to_jvm]]. Note that in the future we want to provide other [[Glossary#BackEnd\|back-ends]]. In this case, the plugin system will become more important.	+	The goal of plugins is independence from the [[Glossary#BackEnd\|back-end]]. This means that, potentially, the ''same'' library could be used simultaneously by [[compile_to_c]] and [[compile_to_jvm]]. Note that in the future we might want to provide other [[Glossary#BackEnd\|back-ends]]. In this case, the plugin system will become more important.

	== How does it work ? ==		== How does it work ? ==

Hzwakenberg: /* Java Generation */

2014-09-07T18:03:43Z

Java Generation

← Older revision		Revision as of 20:03, 7 September 2014
Line 71:		Line 71:

	=== Java Generation===		=== Java Generation===
		+
		+	NB: LibertyEiffel currently does not provide a Java back-end.<BR> The information in this paragraph refers to the legacy<BR> SmartEiffel system, LibertyEiffel's predecessor.

	For the Java [[Glossary#BackEnd\|back-end]], the plugin sub-directory must be named <TT>java</TT>.		For the Java [[Glossary#BackEnd\|back-end]], the plugin sub-directory must be named <TT>java</TT>.

Hzwakenberg at 13:22, 7 September 2014

2014-09-07T13:22:38Z

← Older revision		Revision as of 15:22, 7 September 2014
Line 1:		Line 1:
		+	[[Category: Interfacing]]
	Plugins are a means to augment in a spectactular manner the capabilities of LibertyEiffel, by incorporating libraries which have the color, smell, and taste of the standard libraries. In fact, it's an extension of the standard Eiffel mechanism, [[externals]].		Plugins are a means to augment in a spectactular manner the capabilities of LibertyEiffel, by incorporating libraries which have the color, smell, and taste of the standard libraries. In fact, it's an extension of the standard Eiffel mechanism, [[externals]].

Hzwakenberg at 18:52, 5 September 2014

2014-09-05T18:52:11Z

← Older revision		Revision as of 20:52, 5 September 2014
Line 10:		Line 10:
	* the external side, which implements the plugin's interface for one or several [[Glossary#BackEnd\|back-ends]] (for example, C and Java).		* the external side, which implements the plugin's interface for one or several [[Glossary#BackEnd\|back-ends]] (for example, C and Java).

−	The Eiffel side is 100% Eiffel code, and it uses ''external'' features that allow crossing the barrier to the other side of the plugin. The barrier is managed by ~~SmartEiffel~~ : the compiler associates external functions with the ''external'' features using configuration files furnished by the plugin.	+	The Eiffel side is 100% Eiffel code, and it uses ''external'' features that allow crossing the barrier to the other side of the plugin. The barrier is managed by LibertyEiffel : the compiler associates external functions with the ''external'' features using configuration files furnished by the plugin.

	== Eiffel Side ==		== Eiffel Side ==

Hzwakenberg at 18:51, 5 September 2014

2014-09-05T18:51:17Z

← Older revision		Revision as of 20:51, 5 September 2014
Line 1:		Line 1:
		+	Plugins are a means to augment in a spectactular manner the capabilities of LibertyEiffel, by incorporating libraries which have the color, smell, and taste of the standard libraries. In fact, it's an extension of the standard Eiffel mechanism, [[externals]].
−	[[Category:Smarteiffel]]
−
−	Plugins are a means to augment in a spectactular manner the capabilities of SmartEiffel, by incorporating libraries which have the color, smell, and taste of the standard libraries. In fact, it's an extension of the standard Eiffel mechanism, [[externals]].

	The goal of plugins is independence from the [[Glossary#BackEnd\|back-end]]. This means that, potentially, the ''same'' library could be used simultaneously by [[compile_to_c]] and [[compile_to_jvm]]. Note that in the future we want to provide other [[Glossary#BackEnd\|back-ends]]. In this case, the plugin system will become more important.		The goal of plugins is independence from the [[Glossary#BackEnd\|back-end]]. This means that, potentially, the ''same'' library could be used simultaneously by [[compile_to_c]] and [[compile_to_jvm]]. Note that in the future we want to provide other [[Glossary#BackEnd\|back-ends]]. In this case, the plugin system will become more important.
Line 33:		Line 31:

	* '''location''' indicates the directory where you store one or many of your plugins. This path can contain environment variables (either true system environment variables, or variables definined in the <TT>[Environment]</TT> section of your [[Configuration file\|configuration file]]).		* '''location''' indicates the directory where you store one or many of your plugins. This path can contain environment variables (either true system environment variables, or variables definined in the <TT>[Environment]</TT> section of your [[Configuration file\|configuration file]]).
−	For example, the standard ~~SmartEiffel~~ libraries are defined by using the following ''location'':	+	For example, the standard LibertyEiffel libraries are defined by using the following ''location'':
	location: "${sys}plugins"		location: "${sys}plugins"

← Older revision		Revision as of 14:20, 30 July 2024
Line 1:		Line 1:
	[[Category: Interfacing]]		[[Category: Interfacing]]
−	Plugins are a means to augment the capabilities of Liberty Eiffel, by incorporating libraries which have the ~~color~~, smell, and taste of the standard libraries. In fact, it's an extension of the standard Eiffel mechanism, [[externals]].	+	Plugins are a means to augment the capabilities of Liberty Eiffel, by incorporating libraries which have the colour, smell, and taste of the standard libraries. In fact, it's an extension of the standard Eiffel mechanism, [[externals]].

	The goal of plugins is independence from the [[Glossary#BackEnd\|back-end]]. This means that, potentially, the ''same'' library could be used simultaneously by [[compile_to_c]] and [[compile_to_jvm]]. Note that in the future we might want to provide other [[Glossary#BackEnd\|back-ends]]. In this case, the plugin system will become more important.		The goal of plugins is independence from the [[Glossary#BackEnd\|back-end]]. This means that, potentially, the ''same'' library could be used simultaneously by [[compile_to_c]] and [[compile_to_jvm]]. Note that in the future we might want to provide other [[Glossary#BackEnd\|back-ends]]. In this case, the plugin system will become more important.
Line 11:		Line 11:
	* the external side, which implements the plugin's interface for one or several [[Glossary#BackEnd\|back-ends]] (for example, C and Java).		* the external side, which implements the plugin's interface for one or several [[Glossary#BackEnd\|back-ends]] (for example, C and Java).

−	The Eiffel side is 100% Eiffel code, and it uses ''external'' features that allow crossing the barrier to the other side of the plugin. The barrier is managed by the Liberty Eiffel compiler which associates external functions with the ''external'' features using configuration files furnished by the plugin.	+	The Eiffel side is 100% Eiffel code, and it uses ''external'' features that allow crossing the barrier to the other side of the plugin. The barrier is managed by the Liberty Eiffel compiler, which associates external functions with the ''external'' features using configuration files furnished by the plugin.

	== Eiffel Side ==		== Eiffel Side ==
Line 43:		Line 43:
	=== C Generation ===		=== C Generation ===

−	The C [[Glossary#BackEnd\|back-end]] uses a ~~sub-directory~~ of your plugin named <TT>c</TT>. ~~the~~ files used are:	+	The C [[Glossary#BackEnd\|back-end]] uses a subdirectory of your plugin named <TT>c</TT>. The files used are:

	* all the <TT>.c</TT> files, which are included in the compiler-generated C files		* all the <TT>.c</TT> files, which are included in the compiler-generated C files
Line 52:		Line 52:
	* the <TT>auto_init</TT> file, which contains a description of a possible initialization function called at the very start of the program		* the <TT>auto_init</TT> file, which contains a description of a possible initialization function called at the very start of the program
	* the <TT>cecil.se</TT> file, which is a [[cecil]] description automatically taken into account		* the <TT>cecil.se</TT> file, which is a [[cecil]] description automatically taken into account
−	* the <TT>compiler_options</TT> and the <TT>linker_options</TT> files which are passed verbatim to the underlying strata of compiling chain, usually a C compiler where they are parsed with a shell. They usually ~~contains~~ invocation of tools that gives the mutable correct flags to compile and link the library, i.e. pkg-config.	+	* the <TT>compiler_options</TT> and the <TT>linker_options</TT> files which are passed verbatim to the underlying strata of compiling chain, usually a C compiler, where they are parsed with a shell. They usually contain invocation of tools that gives the mutable correct flags to compile and link the library, i.e. pkg-config.

	The '''<TT>.c</TT> and <TT>.h</TT>''' files are included in alphabetic order.		The '''<TT>.c</TT> and <TT>.h</TT>''' files are included in alphabetic order.
Line 62:		Line 62:
	The '''<TT>auto_init</TT>''' file uses the same syntax as the [[configuration file]], but with yet other keys:		The '''<TT>auto_init</TT>''' file uses the same syntax as the [[configuration file]], but with yet other keys:
	* The default section (i.e. the first one, without a name between square brackets) contains one key, <TT>function</TT> which value gives the name of the initialization function to call at the start of the system		* The default section (i.e. the first one, without a name between square brackets) contains one key, <TT>function</TT> which value gives the name of the initialization function to call at the start of the system
−	* Any other section describes plugin dependencies. ~~The~~ must have two keys: <TT>location</TT> and <TT>module_name</TT> which have the same meaning as in the Eiffel alias. Those dependencies describe initialization order (initialize dependencies first).	+	* Any other section describes plugin dependencies. These must have two keys: <TT>location</TT> and <TT>module_name</TT> which have the same meaning as in the Eiffel alias. Those dependencies describe initialization order (initialize dependencies first).

	The '''<TT>cecil.se</TT>''' file is automatically included as it were specified by the <TT>-cecil</TT> option.		The '''<TT>cecil.se</TT>''' file is automatically included as it were specified by the <TT>-cecil</TT> option.
Line 68:		Line 68:
	For examples, you can examine the configurations files for Vision or ncurses. There is also a tutorial called '''mini_gtk''' (in the <TT>SmartEiffel/tutorial/plugin</TT> directory).		For examples, you can examine the configurations files for Vision or ncurses. There is also a tutorial called '''mini_gtk''' (in the <TT>SmartEiffel/tutorial/plugin</TT> directory).

−	'''Note''': when there are no arguments, names are generated without parentheses. This permits to attributes, variables and to macros. The absence of parentheses is not then a bug but a desired ~~behavior~~. In the case where one wants access to a function without an argument, it suffices to use a macro to replace a name without parentheses with the name of the function to call.	+	'''Note''': when there are no arguments, names are generated without parentheses. This permits to attributes, variables and to macros. The absence of parentheses is not then a bug but a desired behaviour. In the case where one wants access to a function without an argument, it suffices to use a macro to replace a name without parentheses with the name of the function to call.

	=== Java Generation===		=== Java Generation===
Line 74:		Line 74:
	NB: Liberty Eiffel currently does not provide a Java back-end.<BR> The information in this paragraph refers to Liberty Eiffel's legacy predecessor.		NB: Liberty Eiffel currently does not provide a Java back-end.<BR> The information in this paragraph refers to Liberty Eiffel's legacy predecessor.

−	For the Java [[Glossary#BackEnd\|back-end]], the plugin ~~sub-directory~~ must be named <TT>java</TT>.	+	For the Java [[Glossary#BackEnd\|back-end]], the plugin subdirectory must be named <TT>java</TT>.
	The compiler uses the following files :		The compiler uses the following files :