Fedora Linux Support Community & Resources Center
  #106  
Old 22nd January 2017, 12:48 PM
ocratato Offline
Registered User
 
Join Date: Oct 2010
Location: Canberra
Posts: 2,484
linuxfirefox
Re: VICI: A Software Development Project

Common Code and Testing

Up to now the VICI project has consisted of a collection of semi-independent sub-projects. It has a common library for low level infrastructure (such as reading XML files) and others for overall configuration and the interfaces between the projects, but mostly each sub-project has been developed relatively independently.

An inevitable side effect of this approach is that some things will be duplicated. For example the "About" dialog needs to be provided by each GUI program. If each sub-project develops their own version the overall appearance of VICI will appear confused.

One approach to this is to provide a strict set of design guidelines so that each instance will appear similar. Another approach is to provide a common library containing various bits and pieces that will be used in multiple sub-projects. The common library has the obvious advantages of less code duplication (and hence less maintenance), but it does introduce a dependency between the sub-projects.

I have decided to add a small common GUI library. It has an "About" dialog, a small helper class that makes editing the entries in Qt's list widgets a lot less stupid, and wrappers for the main window and dialog classes that provide a hook for the GUI Test Harness to find the widgets.

Testing ... Oops

Using the new GUI Test Harness to get it to interact with GUI programs seems to be working as planned. However, the whole point is to manoeuvre the GUI program into a state so that the test harness can check the state of the program's internal objects, but I seem to have overlooked the mechanism for the test case objects to actually find the program objects.

My initial idea was to use something similar to the way the asynchronous testing works - a pointer to a function was to be used to register the objects that we want to test. This pointer would be initialised to an empty function during normal operations and an actual function for registering the object during testing. The function pointer would be called during the constructors for the application objects.

Unfortunately, this doesn't work since the test harness may be in a plug-in that is not loaded until all the application objects have been initialised. The function pointer would always be pointing to the empty function when it was needed.
__________________
Has anyone seriously considered that it might be turtles all the way down?
That's very old fashioned thinking.
The current model is that it's holographic nested virtualities of turtles, all the way down.
Reply With Quote
  #107  
Old 23rd January 2017, 01:04 PM
ocratato Offline
Registered User
 
Join Date: Oct 2010
Location: Canberra
Posts: 2,484
linuxfirefox
Re: VICI: A Software Development Project

Object Discovery

As mentioned in the previous post the test case objects need some means of getting a reference to the objects that they are supposed to test. To support this I have added a discovery facility to the infrastructure library.

The requirements are:
  • Objects get to determine if they can be discovered. This means we can minimise the performance penalty by only handling a few important objects.
  • Objects are to be found by class name. A vector of pointers to objects of the class is returned. (Usually it will just be one entry, but this caters for other uses.)
  • We don't want to get pointers to objects that have been deleted.
  • It should work even if there is nothing asking for the objects. This is necessary since the test cases may be in a plug-in that may or may not be loaded.
  • The discoverable objects should require a bare minimum of extra code.

The discovery code has the following interface
Code:
struct DiscoverPointer
{
	void * addr;
	DiscoverPointer() : addr(nullptr) {}
	DiscoverPointer(void *a) : addr(a) {}
};

typedef std::shared_ptr< DiscoverPointer > DiscoverSharedPointer;
typedef std::weak_ptr< DiscoverPointer > DiscoverWeakPointer;

// A mixin class that makes its owner discoverable
class Discoverable
{
protected:
	DiscoverSharedPointer discover;
};

// the manager that keeps the list of discoverable objects
// and is responsible for supplying a list of pointers given a class name

class DiscoveryMgr
{
private:
	std::map<std::string, std::vector<DiscoverWeakPointer> > objects;
	DiscoveryMgr() {}
public:
	static DiscoveryMgr & instance();

	void save(const char *prettyName, DiscoverSharedPointer);
	void fetch(csr name, std::vector<void *> & results);
};

// This macro should be placed at the start of the constructor.
#define DISCOVERABLE \
	VICI::cfi::DiscoveryMgr::instance().save( __PRETTY_FUNCTION__, \
			(discover.reset( new VICI::cfi::DiscoverPointer( this )), discover) );
To make a class discoverable it inherits from Discoverable, and includes the DISCOVERABLE macro in its constructor.

The save function does a bit editing on the __PRETTY_FUNCTION__ to get the class name and stores the discover structure in a map.

The fetch function finds the class name and checks to ensure that the weak shared pointer is still valid.

To get a reference to a discoverable object the test case does the following:
Code:
	vector< void * > objs;
	DiscoveryMgr::instance().fetch("VICI::Syntax::SyntaxImpl", objs);
	if ( objs.size() > 0)
	{
		syntax = static_cast<Syntax::SyntaxImpl *>(objs[0]);
	}
While this works, and enables work to continue on the testing, I will probably revisit it later to add a template version of DiscoverPointer so that it is a bit more type safe.
__________________
Has anyone seriously considered that it might be turtles all the way down?
That's very old fashioned thinking.
The current model is that it's holographic nested virtualities of turtles, all the way down.
Reply With Quote
  #108  
Old 9th February 2017, 12:16 PM
ocratato Offline
Registered User
 
Join Date: Oct 2010
Location: Canberra
Posts: 2,484
linuxfirefox
Re: VICI: A Software Development Project

Phase 8 Completed

I have just uploaded vici-0.8.560 to SourceForge https://sourceforge.net/projects/ocratato-vici/

This release provides a more standard build process and a better test harness for GUI programs.

The next phase of development will provide the interface for entering commands and their parameters. Hopefully it won't take too long to develop.
__________________
Has anyone seriously considered that it might be turtles all the way down?
That's very old fashioned thinking.
The current model is that it's holographic nested virtualities of turtles, all the way down.
Reply With Quote
  #109  
Old 25th February 2017, 05:47 AM
ocratato Offline
Registered User
 
Join Date: Oct 2010
Location: Canberra
Posts: 2,484
linuxfirefox
Re: VICI: A Software Development Project

Configuration

Usually I write these posts after I have implemented something, but this time it is more of a planning session.

Some background
VICI uses an XML file to hold various bit of configuration data. A lot of those data items are the paths to things like data files or plug-in libraries. The location of those data and plug-in files changes depending on what stage we are considering. There are the following stages:
  1. The development project - this is where the code is written and unit tests are performed.
  2. The top project - this is for building and testing the entire suite of programs.
  3. Creating a distribution - the "make distcheck" command creates and tests the distribution.
  4. Checking the distribution - this is when the distribution has been installed into a test area and has been built but not installed. This is a "make check" that is done between "make" and "make install".
  5. Checking the installed distribution - this is a "make check" done after installation.
  6. The final stage - this is where the installed programs are used (or tested) without relying on the source, such as when it is installed from a pre-built RPM.

There are two ways that the system can handle these various paths. The simplest is to have alternate configuration files that are used for each stage. However, the configuration library (that reads and interprets the configuration file) is able to handle having multiple alternative paths which it checks in turn until it finds one. For example the configuration for a plug-in:
Code:
		<PlugIn prog='adminTest'>
			<name>admintest</name>
			<mode>autorun</mode>
			<path>$VICI/src/top/build/admin/TestProgram/.libs/libadmintest.so</path>
			<path>$VICI/lib/vici/plugin/libadmintest.so</path>
			<path>$VICI/src/admin/build/TestProgram/.libs/libadmintest.so</path>
		</PlugIn>
When attempting to load this plug-in it checks each path until it finds one.

The configuration library searches for the configuration file using various techniques. It can use a command line parameter, an environment variable, or search for particular files in the current directory, the user's home directory, or others. The first one found is used.

Currently the search path is
Code:
		"PECHD:"
		"-i:VICI_CONF:"
		"vici.xml:"
		".local/share/vici/vici.xml:"
		"$VICI/src/top/vici.xml:"
		"$VICI/share/vici/vici.xml:"
		"$VICI/vici.xml";
The first string is the key - in this case it means that the following entries are a command line parameter, -i, an environment variable, VICI_CONF, the file ./vici.xml, the file ~/.local/share/vici/vici.xml, and the remainder are direct paths.

The Problem
What is the optimum set of configuration files?

Each development project should have its own configuration file. This would allow the project to manage its own configuration and testing without disturbing other projects. Eclipse can be set up to provide parameters to the test programs so that should be used to ensure the local one is found. However, we want to ensure that configuration options are not overlooked in the full suite build so the "make check" tests should use an environment variable that points to top/vici-dev.xml which will be the config file for the top project.

The builds and tests in the top project will use top/vici-dev.xml via VICI_CONF. This version of the configuration file will point to files that have not been installed.

There will be a second configuration file, top/vici-test.xml. This version will point to files that have been installed and include all the entries necessary for testing. This will also be accessed using VICI_CONF

The final version, vici.xml, will be used by the programs once they are installed. The support for testing will be removed, or commented out. This will be found using the default location in share/vici.
__________________
Has anyone seriously considered that it might be turtles all the way down?
That's very old fashioned thinking.
The current model is that it's holographic nested virtualities of turtles, all the way down.
Reply With Quote
Reply

Tags
continued, development, project, software, vici

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump

Similar Threads
Thread Thread Starter Forum Replies Last Post
Web Development Software Pepperonie Using Fedora 2 5th May 2007 10:56 PM
Development software for Linux jo3 Using Fedora 9 15th June 2006 03:28 PM
Software Development handshakeit Using Fedora 0 5th October 2005 08:40 AM


Current GMT-time: 20:18 (Thursday, 30-03-2017)

TopSubscribe to XML RSS for all Threads in all ForumsFedoraForumDotOrg Archive
logo

All trademarks, and forum posts in this site are property of their respective owner(s).
FedoraForum.org is privately owned and is not directly sponsored by the Fedora Project or Red Hat, Inc.

Privacy Policy | Term of Use | Posting Guidelines | Archive | Contact Us | Founding Members

Powered by vBulletin® Copyright ©2000 - 2012, vBulletin Solutions, Inc.

FedoraForum is Powered by RedHat