Contents
You are new to the whole project, and you just don't know where to start...
Here are a couple of pointers:
- Read the introduction to get an idea of what this is all about
- Follow the user guide
You can consult the glossary for a quick refresher on SAI terms.
You can refer to the SAI page for the latest
publications on SAI, its implementation and its applications.
The most recent and up-to-date description of SAI can be found in the following Technical Report: Software Architecture for Computer Vision: Beyond Pipes and Filters, by Alexandre R.J. François, IRIS Technical Report IRIS-03-420,University of Southern California, Los Angeles, July 2003.
FSF
Note that the following information is provided in the installation notes and in the file Install.txt that comes with both Fsf and FsfDbg distributions.
The following steps are necessary for a first time install:
- Patch your VC++ 6.0 compiler to make XTREE thread safe:
The STL include file XTREE must be replaced by a version fixing multithreading problems (can be found at: http://www.dinkumware.com/vc_fixes.html ). Failing to apply this patch will make applications crash when compiled in Release mode. Applications compiled in Debug mode seem to run fine without the patch.
- Download and unzip the Fsf and the FsfDbg packages:
Fsf is the Release version, FsfDbg is the debug version. They are separate packages and projects so as not to create any confusion when usiing the DLLs.Fsf\ and FsfDbg directories can be placed anywhere, e.g. C:\Fsf and C:\FsfDbg (used as an example hereafter).
- Update your environment variables so that the system can find the DLLs when trying to run a program that uses FSF:
Add the paths "C:\Fsf\Release" and "C:\FsfDbg\Debug" in your Path environment variable. To do so (in Windows 2000 or XP), open the Control Panel, launch the System tool, select the Advanced tab, and click on the Environment Variables... button. In the System Variables, select "Path" and click the Edit button. At the end of the current string, add exactly: ";C:\Fsf\Release;C:\FsfDbg\Debug". Make sure not to forget the first semi-colon, which separates the added strings from the existing ones. Press OK on all the dialogs to validate.
- Add the header and library directories in your Visual Studio environment so that the builder knows where to fing the fsf header files and library files:
In Visual C++, in the Tools menu, select Options... Select the Directories tab. In the directories for include files, add the path "C:\Fsf". In the directories for library files, add the paths "C:\Fsf\Release" and "C:\FsfDbg\Debug". Press OK to validate. The header files are assumed to be the same for the release and the debug version.
For a simple upgrade from a previous version (i.e. from version 4.0), simply rename or delete the Fsf and/or FsfDbg directories, and replace them with the ones for the new version (typically, unzip the new zip files).
Fsf 0.5 has been successfully tested on Windows 2000 and Windows XP. A port to Linux is currently under evaluation.
Fsf 0.5 has been successfully tested with Microsoft Visual C++ 6.0, with an update for the STL XTREE header file (see installation instructions). A gcc port is currently under evaluation.
Programming
Follow these steps:
- Create a new console application project (empty)
- Project settings:
- C++ Language: enable RTTI (for both Debug and Release configurations)
- C++ Code Generation: use run-time library Debug Multithreaded DLL (Debug configuration)
and Multithreaded DLL (Release configuration)
- C++ Precompiled headers: not using precompiled headers (for both Debug and Release configurations)
- C++ Preprocessor: define _AFXDLL (for both Debug and Release configurations)
- Link libraries: FsfDbg.lib (Debug configuration) or Fsf.lib (Release configuration); winmm.lib
Note: The MSVC Wizard specifies a large number of libraries to link with by default, none of which is actually needed for an MFSM application.
- Download module files from the Modules repository and/or create your own, and add them to the project
- Create a main cpp file for your project
- Implement the main() function (see user guide for how to setup the system, code your application graph and run it...)
Additionally, a few compiler directives to be included in all .cpp files help clean-up some useless messages and prevent some inconsistencies. Since MSVC requires that all .cpp files include stdafx.h, this header file is a good place to place these compiler directives. Cut and paste the following code at the end of stdafx.h :
#ifdef _MSC_VER //Detect Microsoft C++ compiler
//identifier was truncated to '255' characters in the debug information
#pragma warning( disable: 4786 )
//unreferenced formal parameter (Warning level 4)
#pragma warning( disable: 4100 )
//function not inlined (Warning level 4)
#pragma warning( disable: 4710 )
//RTTI needed by Fsf
#ifndef _CPPRTTI
#error RTTI required
#endif
#endif //_MSC_VER
STL triggers a number of warnings. They can be suppressed with a number of compiler directives (see previous question). Since MSVC requires that all .cpp files include stdafx.h, this header file is a good place to place these compiler directives.
Here is a tentative check list:
- Convert all time variables from DWORD to fsf::Time. A good starting point is to look for "DWORD" in all files, and replace the time variable types and names (for example, "DWORD dwTime" becomes "fsf::Time tTime"). Then look for "dwTime" and replace with "tTime". This should take care of most of the occurences. Note that these occur mainly in the declarations and definitions of specialized nodes.
- Update all time nodes from Int32Node to Int64Node. These will for example occur as pulse delay parameters for pulsar cells. Do not forget to make appropriate changes to initialization values to account for the change of unit (used to be ms, i.e. 10^-3 s, is now ns, i.e. 10^-9 s).
- Update all time operations to take into account change of unit.
The only code modifications required are related to the CSystem Singleton implementation, and consist in removing or modifying direct access to the obsolete global pointer to the single system instance, as well as explicit system allocation/deallocation:
- Remove all tests on the g_pSystem pointer (e.g. at the beginning of the RegisterFactories() functions)
- Replace all direct use of the g_pSystem pointer with a call to CSystem::GetInstance() (e.g. replace fsf::g_pSystem->GetTime() with fsf::CSystem::GetInstance()->GetTime())
- In application, remove code allocating the system (call to fsf::AllocateSystem()) and deallocating the system (call to fsf::FreeSystem())
Debug
There are two main reasons why the process method would not be called:
- the cell is not active (passive filtering fails: the parameters are not
found)
- the cell is not triggered (active filtering fails: no input data in the
active pulse)
So here are a couple of things to check:
- make sure your cells and sources are connected correctly,
- check the filters in the cells (both active and passive) and make sure
they match what is actually in the pulses (active and passive)
