Codegeneration - Revision history

Karellen at 04:52, 10 July 2020

2020-07-10T04:52:51Z

← Older revision		Revision as of 04:52, 10 July 2020
Line 676:		Line 676:
	Of course, there is a cost to this in terms of both maintenance and build complexity.		Of course, there is a cost to this in terms of both maintenance and build complexity.

	~~[[Category:Codegeneration]]~~
	[[Category:Development]]		[[Category:Development]]

NedBot: Robot: Substituting template: Name

2014-06-05T20:29:39Z

Robot: Substituting template: Name

NedBot: Bot: Automated text replacement (- XBMC + {{name}} )

2014-06-05T01:01:01Z

Bot: Automated text replacement (- XBMC + {{name}} )

NedBot: Bot: automated adding of 'enclose="div"' to syntaxhighlight

2014-03-14T06:41:32Z

Bot: automated adding of 'enclose="div"' to syntaxhighlight

Show changes

NedBot: Bot: Automated text replacement (-class="wikitable" +class="prettytable" & -Available Tags +Available tags & - +)

2014-03-14T05:49:13Z

Bot: Automated text replacement (-class="wikitable" +class="prettytable" & -Available Tags +Available tags & -<source +<syntaxhighlight & -</source> +</syntaxhighlight>)

Show changes

Martijn at 13:03, 4 September 2013

2013-09-04T13:03:02Z

← Older revision		Revision as of 13:03, 4 September 2013
Line 1:		Line 1:
	{{~~frodo updated~~}}		{{mininav\|[[Development]]}}

	As of XBMC v12 Frodo, the python interface has changed from the existing hand coded one, with one whose code is '''generated''' as part of building XBMC. There are several advantages to this approach including:		As of XBMC v12 Frodo, the python interface has changed from the existing hand coded one, with one whose code is '''generated''' as part of building XBMC. There are several advantages to this approach including:

>NedBot: Robot: Cosmetic changes

2013-04-27T14:46:42Z

Robot: Cosmetic changes

← Older revision		Revision as of 14:46, 27 April 2013
Line 173:		Line 173:
	</source>		</source>

	*If someone get's the bright idea to name an Python accessible api function so that it matches a C++ keyword, you can fix this using the %rename directive. The following allows the method XBMCAddon::xbmcvfs::deleteFile() to be called from Python as 'xbmcvfs.delete':		* If someone get's the bright idea to name an Python accessible api function so that it matches a C++ keyword, you can fix this using the %rename directive. The following allows the method XBMCAddon::xbmcvfs::deleteFile() to be called from Python as 'xbmcvfs.delete':

	<source lang="cpp">		<source lang="cpp">

Ned Scott at 00:32, 29 January 2013

2013-01-29T00:32:03Z

← Older revision		Revision as of 00:32, 29 January 2013
Line 1:		Line 1:
	{{frodo}}		{{frodo updated}}
			As of XBMC v12 Frodo, the python interface has changed from the existing hand coded one, with one whose code is '''generated''' as part of building XBMC. There are several advantages to this approach including:
	~~An upcoming release~~ of XBMC ~~will change~~ the python interface from the existing hand coded one, with one whose code is '''generated''' as part of building XBMC. There are several advantages to this approach including:

	# More flexible and straightforward means of managing the API. The API will be defined in terms of a C++ library independent of the fact that it can be called from a scripting language.		# More flexible and straightforward means of managing the API. The API will be defined in terms of a C++ library independent of the fact that it can be called from a scripting language.

>Mavijana at 14:34, 25 January 2013

2013-01-25T14:34:22Z

← Older revision		Revision as of 14:34, 25 January 2013
Line 32:		Line 32:

	<source lang="cpp">		<source lang="cpp">
	~~inlne~~ void test() { CLog::Log(LOGDEBUG,"In new test method\n"); }		inline void test() { CLog::Log(LOGDEBUG,"In new test method\n"); }
	</source>		</source>

>Jcarroll: /* Current requirements/restrictions */

2012-09-13T03:42:45Z

Current requirements/restrictions

← Older revision		Revision as of 03:42, 13 September 2012
Line 59:		Line 59:
	* The codegenerator cannot (yet) handle overloaded methods or functions.		* The codegenerator cannot (yet) handle overloaded methods or functions.
	* The codegenerator doesn't handle operator overloading and all defined operators will simply be ignored - '''EXCEPT''' for the following situation:		* The codegenerator doesn't handle operator overloading and all defined operators will simply be ignored - '''EXCEPT''' for the following situation:
	* For python you can define a "comparator" (NOT a "rich comparator") if you define three operators:		* For python you can define a "comparator" (NOT a "rich comparator") if you define these three operators on your API class (you cannot use global operator definitions):
	# bool operator ==(const T&)		# bool operator ==(const T&)
	# bool operator >(const T&)		# bool operator >(const T&)

← Older revision		Revision as of 20:29, 5 June 2014
Line 1:		Line 1:
	{{mininav\|[[Development]]}}		{{mininav\|[[Development]]}}

	As of ~~{{name}}~~ v12 Frodo, the python interface has changed from the existing hand coded one, with one whose code is '''generated''' as part of building XBMC. There are several advantages to this approach including:		As of XBMC v12 Frodo, the python interface has changed from the existing hand coded one, with one whose code is '''generated''' as part of building XBMC. There are several advantages to this approach including:

	# More flexible and straightforward means of managing the API. The API will be defined in terms of a C++ library independent of the fact that it can be called from a scripting language.		# More flexible and straightforward means of managing the API. The API will be defined in terms of a C++ library independent of the fact that it can be called from a scripting language.
	# Provide a means of merging different APIs into a single API accessed through different means. It would be nice to define the API independent of the means of access.		# Provide a means of merging different APIs into a single API accessed through different means. It would be nice to define the API independent of the means of access.
	# Tackle some longstanding stability issues resulting from the mixing of Python mechanisms with ~~{{name}}~~ mechanisms. These are typically deadlocks.		# Tackle some longstanding stability issues resulting from the mixing of Python mechanisms with XBMC mechanisms. These are typically deadlocks.
	# Smaller source codebase to manage		# Smaller source codebase to manage
	# Provide a basis to support other scripting language.		# Provide a basis to support other scripting language.
Line 19:		Line 19:
	=== How to use the codegenerator ===		=== How to use the codegenerator ===

	Now the ability to extend the API should be much simpler. You simply write C++ code and make sure that it gets incorporated in the appropriate module file. The directories within ~~{{name}}~~ are organized as follows:		Now the ability to extend the API should be much simpler. You simply write C++ code and make sure that it gets incorporated in the appropriate module file. The directories within XBMC are organized as follows:

	* xbmc/interfaces/legacy contains the C++ code that represents the current (now, legacy) API.		* xbmc/interfaces/legacy contains the C++ code that represents the current (now, legacy) API.
Line 99:		Line 99:
	</syntaxhighlight>		</syntaxhighlight>

	==== Cross-language Polymorphism in ~~{{name}}~~ ====		==== Cross-language Polymorphism in XBMC ====

	Unfortunately, it's not all that simple in XBMC. Since ~~{{name}}~~ is a complicated multi-threaded application, and since Python requires absolute control over the threading context, you cannot simply invoke a method on a reference to the base class and expect the Python child class to execute without any problems. You must make sure you're already in a Python thread that's running your script in order for this to work.		Unfortunately, it's not all that simple in XBMC. Since XBMC is a complicated multi-threaded application, and since Python requires absolute control over the threading context, you cannot simply invoke a method on a reference to the base class and expect the Python child class to execute without any problems. You must make sure you're already in a Python thread that's running your script in order for this to work.

	Fortunately, there are facilities in the Addon library to make this somewhat painless, but you do need to explicitly take advantage of them.		Fortunately, there are facilities in the Addon library to make this somewhat painless, but you do need to explicitly take advantage of them.
Line 213:		Line 213:
	== An Example ==		== An Example ==

	This is a walkthrough of a simple example to show how this works and how it can be extended in the future. Let's say we have the following simple API function in ~~{{name}}~~ that we want available to python. Since this is actually a piece of the current API's module 'XBMC,' let's say this is the complete contents of the file "ModuleXbmc.h":		This is a walkthrough of a simple example to show how this works and how it can be extended in the future. Let's say we have the following simple API function in XBMC that we want available to python. Since this is actually a piece of the current API's module 'XBMC,' let's say this is the complete contents of the file "ModuleXbmc.h":

	<syntaxhighlight lang="cpp" enclose="div">		<syntaxhighlight lang="cpp" enclose="div">
Line 668:		Line 668:
	==== Why not simply use SWIG? ====		==== Why not simply use SWIG? ====

	We spent a long time trying to get direct SWIG output of Python to work correctly. There are several issues that became intractable. For example, the SWIG code when run inside of ~~{{name}}~~ could be very unstable. See [http://sourceforge.net/tracker/index.php?func=detail&aid=3119817&group_id=1645&atid=101645 this bug report].		We spent a long time trying to get direct SWIG output of Python to work correctly. There are several issues that became intractable. For example, the SWIG code when run inside of XBMC could be very unstable. See [http://sourceforge.net/tracker/index.php?func=detail&aid=3119817&group_id=1645&atid=101645 this bug report].

	On top of that the SWIG output code is incredibly large and complex. This is because it needs to satisfy the general case and so must be complete.		On top of that the SWIG output code is incredibly large and complex. This is because it needs to satisfy the general case and so must be complete.

	With the addition of the Groovy code-generation we have complete control over the actual code that's generated. As a result the generated code is specific to ~~{{name}}~~ and can be tuned the way we need it to be.		With the addition of the Groovy code-generation we have complete control over the actual code that's generated. As a result the generated code is specific to XBMC and can be tuned the way we need it to be.

	Of course, there is a cost to this in terms of both maintenance and build complexity.		Of course, there is a cost to this in terms of both maintenance and build complexity.

← Older revision		Revision as of 01:01, 5 June 2014
Line 1:		Line 1:
	{{mininav\|[[Development]]}}		{{mininav\|[[Development]]}}

	As of ~~XBMC~~ v12 Frodo, the python interface has changed from the existing hand coded one, with one whose code is '''generated''' as part of building XBMC. There are several advantages to this approach including:		As of {{name}} v12 Frodo, the python interface has changed from the existing hand coded one, with one whose code is '''generated''' as part of building XBMC. There are several advantages to this approach including:

	# More flexible and straightforward means of managing the API. The API will be defined in terms of a C++ library independent of the fact that it can be called from a scripting language.		# More flexible and straightforward means of managing the API. The API will be defined in terms of a C++ library independent of the fact that it can be called from a scripting language.
	# Provide a means of merging different APIs into a single API accessed through different means. It would be nice to define the API independent of the means of access.		# Provide a means of merging different APIs into a single API accessed through different means. It would be nice to define the API independent of the means of access.
	# Tackle some longstanding stability issues resulting from the mixing of Python mechanisms with ~~XBMC~~ mechanisms. These are typically deadlocks.		# Tackle some longstanding stability issues resulting from the mixing of Python mechanisms with {{name}} mechanisms. These are typically deadlocks.
	# Smaller source codebase to manage		# Smaller source codebase to manage
	# Provide a basis to support other scripting language.		# Provide a basis to support other scripting language.
Line 19:		Line 19:
	=== How to use the codegenerator ===		=== How to use the codegenerator ===

	Now the ability to extend the API should be much simpler. You simply write C++ code and make sure that it gets incorporated in the appropriate module file. The directories within ~~XBMC~~ are organized as follows:		Now the ability to extend the API should be much simpler. You simply write C++ code and make sure that it gets incorporated in the appropriate module file. The directories within {{name}} are organized as follows:

	* xbmc/interfaces/legacy contains the C++ code that represents the current (now, legacy) API.		* xbmc/interfaces/legacy contains the C++ code that represents the current (now, legacy) API.
Line 99:		Line 99:
	</syntaxhighlight>		</syntaxhighlight>

	==== Cross-language Polymorphism in ~~XBMC~~ ====		==== Cross-language Polymorphism in {{name}} ====

	Unfortunately, it's not all that simple in XBMC. Since ~~XBMC~~ is a complicated multi-threaded application, and since Python requires absolute control over the threading context, you cannot simply invoke a method on a reference to the base class and expect the Python child class to execute without any problems. You must make sure you're already in a Python thread that's running your script in order for this to work.		Unfortunately, it's not all that simple in XBMC. Since {{name}} is a complicated multi-threaded application, and since Python requires absolute control over the threading context, you cannot simply invoke a method on a reference to the base class and expect the Python child class to execute without any problems. You must make sure you're already in a Python thread that's running your script in order for this to work.

	Fortunately, there are facilities in the Addon library to make this somewhat painless, but you do need to explicitly take advantage of them.		Fortunately, there are facilities in the Addon library to make this somewhat painless, but you do need to explicitly take advantage of them.
Line 213:		Line 213:
	== An Example ==		== An Example ==

	This is a walkthrough of a simple example to show how this works and how it can be extended in the future. Let's say we have the following simple API function in ~~XBMC~~ that we want available to python. Since this is actually a piece of the current API's module 'XBMC,' let's say this is the complete contents of the file "ModuleXbmc.h":		This is a walkthrough of a simple example to show how this works and how it can be extended in the future. Let's say we have the following simple API function in {{name}} that we want available to python. Since this is actually a piece of the current API's module 'XBMC,' let's say this is the complete contents of the file "ModuleXbmc.h":

	<syntaxhighlight lang="cpp" enclose="div">		<syntaxhighlight lang="cpp" enclose="div">
Line 668:		Line 668:
	==== Why not simply use SWIG? ====		==== Why not simply use SWIG? ====

	We spent a long time trying to get direct SWIG output of Python to work correctly. There are several issues that became intractable. For example, the SWIG code when run inside of ~~XBMC~~ could be very unstable. See [http://sourceforge.net/tracker/index.php?func=detail&aid=3119817&group_id=1645&atid=101645 this bug report].		We spent a long time trying to get direct SWIG output of Python to work correctly. There are several issues that became intractable. For example, the SWIG code when run inside of {{name}} could be very unstable. See [http://sourceforge.net/tracker/index.php?func=detail&aid=3119817&group_id=1645&atid=101645 this bug report].

	On top of that the SWIG output code is incredibly large and complex. This is because it needs to satisfy the general case and so must be complete.		On top of that the SWIG output code is incredibly large and complex. This is because it needs to satisfy the general case and so must be complete.

	With the addition of the Groovy code-generation we have complete control over the actual code that's generated. As a result the generated code is specific to ~~XBMC~~ and can be tuned the way we need it to be.		With the addition of the Groovy code-generation we have complete control over the actual code that's generated. As a result the generated code is specific to {{name}} and can be tuned the way we need it to be.

	Of course, there is a cost to this in terms of both maintenance and build complexity.		Of course, there is a cost to this in terms of both maintenance and build complexity.