FedoraForum.org - Fedora Support Forums and Community
Page 8 of 8 FirstFirst ... 6 7 8
Results 106 to 110 of 110
  1. #106
    Join Date
    Oct 2010

    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.

  2. #107
    Join Date
    Oct 2010

    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
    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
    	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
    	std::map<std::string, std::vector<DiscoverWeakPointer> > objects;
    	DiscoveryMgr() {}
    	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:
    	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.

  3. #108
    Join Date
    Oct 2010

    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.

  4. #109
    Join Date
    Oct 2010

    Re: VICI: A Software Development Project


    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:
    		<PlugIn prog='adminTest'>
    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
    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.

  5. #110
    Join Date
    Oct 2010

    Re: VICI: A Software Development Project

    For those that have been following this thread, you may have noticed its gone a bit quiet lately. I am taking a short break as I have been distracted by another interesting problem.

    I noticed that there are some interesting comments on SlashDot concerning visual programming languages: https://ask.slashdot.org/story/17/06...ng-flow-charts

Page 8 of 8 FirstFirst ... 6 7 8

Similar Threads

  1. Web Development Software
    By Pepperonie in forum Using Fedora
    Replies: 2
    Last Post: 5th May 2007, 10:56 PM
  2. Development software for Linux
    By jo3 in forum Using Fedora
    Replies: 9
    Last Post: 15th June 2006, 03:28 PM
  3. Software Development
    By handshakeit in forum Using Fedora
    Replies: 0
    Last Post: 5th October 2005, 08:40 AM

Tags for this Thread

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts