Sophie

Sophie

distrib > Mageia > 6 > x86_64 > by-pkgid > 16e298361edb3000a9b1c7b2dae804b9 > files > 914

apt-mga-1.4.6-1.mga6.x86_64.rpm

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta http-equiv="Content-Type" content="text/xhtml;charset=UTF-8"/>
<meta http-equiv="X-UA-Compatible" content="IE=9"/>
<meta name="generator" content="Doxygen 1.8.13"/>
<meta name="viewport" content="width=device-width, initial-scale=1"/>
<title>apt: Todo List</title>
<link href="tabs.css" rel="stylesheet" type="text/css"/>
<script type="text/javascript" src="jquery.js"></script>
<script type="text/javascript" src="dynsections.js"></script>
<link href="doxygen.css" rel="stylesheet" type="text/css" />
</head>
<body>
<div id="top"><!-- do not remove this div, it is closed by doxygen! -->
<div id="titlearea">
<table cellspacing="0" cellpadding="0">
 <tbody>
 <tr style="height: 56px;">
  <td id="projectalign" style="padding-left: 0.5em;">
   <div id="projectname">apt
   &#160;<span id="projectnumber">1.4.6</span>
   </div>
   <div id="projectbrief">commandline package manager</div>
  </td>
 </tr>
 </tbody>
</table>
</div>
<!-- end header part -->
<!-- Generated by Doxygen 1.8.13 -->
<script type="text/javascript" src="menudata.js"></script>
<script type="text/javascript" src="menu.js"></script>
<script type="text/javascript">
$(function() {
  initMenu('',false,false,'search.php','Search');
});
</script>
<div id="main-nav"></div>
</div><!-- top -->
<div class="header">
  <div class="headertitle">
<div class="title">Todo List </div>  </div>
</div><!--header-->
<div class="contents">
<div class="textblock"><dl class="reflist">
<dt><a class="anchor" id="_todo000015"></a>Module <a class="el" href="group__acquire.xhtml">acquire</a>  </dt>
<dd>Acquire supports inserting an object into several queues at once, but it is not clear what its behavior in this case is, and no subclass of <a class="el" href="classpkgAcquire_1_1Item.xhtml" title="Represents the process by which a pkgAcquire object should retrieve a file or a collection of files...">pkgAcquire::Item</a> seems to actually use this capability.  </dd>
<dt><a class="anchor" id="_todo000033"></a>Member <a class="el" href="classAPT_1_1CacheSetHelper.xhtml#ae746b3086d53d0a5ad666675cb003ef2">CacheSetHelper::PackageFromString</a>  (<a class="el" href="classAPT_1_1PackageContainerInterface.xhtml">PackageContainerInterface</a> *const pci, <a class="el" href="classpkgCacheFile.xhtml">pkgCacheFile</a> &amp;Cache, std::string const &amp;pattern)</dt>
<dd>hm, hm, regexp/fnmatch incompatible?  </dd>
<dt><a class="anchor" id="_todo000036"></a>Member <a class="el" href="classCommandLine.xhtml#a9d8af7a43d9909e23d48528f9cf4f00e">CommandLine::DispatchArg</a>  (<a class="el" href="structCommandLine_1_1Dispatch.xhtml">Dispatch</a> *List, bool NoMatch=true)</dt>
<dd>merge on next ABI break  </dd>
<dt><a class="anchor" id="_todo000035"></a>Member <a class="el" href="classCommandLine.xhtml#ae95847c73c63fe09a42b29bb0525c14c">CommandLine::GetCommand</a>  (<a class="el" href="structCommandLine_1_1Dispatch.xhtml">Dispatch</a> const *const Map, unsigned int const argc, char const *const *const argv) APT_PURE</dt>
<dd>How like is it that an option parameter will be also a valid Match ?  </dd>
<dt><a class="anchor" id="_todo000041"></a>Member <a class="el" href="classdebDebPkgFileIndex.xhtml#a935ab14061bb7270f4166f5b4ef6cda1">debDebPkgFileIndex::ArchiveInfo_impl</a>  (<a class="el" href="classpkgCache_1_1VerIterator.xhtml">pkgCache::VerIterator</a> const &amp;Ver) const</dt>
<dd>use proper virtual-handling on next ABI break  </dd>
<dt><a class="anchor" id="_todo000042"></a>Member <a class="el" href="classdebReleaseIndex.xhtml#aeaf2e9db914b9ddb21625a6172e5882f">debReleaseIndex::Load</a>  (std::string const &amp;Filename, std::string *const ErrorText) APT_OVERRIDE</dt>
<dd>find better tag name  </dd>
<dt><a class="anchor" id="_todo000050"></a>Member <a class="el" href="classedspListParser.xhtml#a8a5b0770dc74cc79cd453d00021eb83b">edspListParser::ParseStatus</a>  (<a class="el" href="classpkgCache_1_1PkgIterator.xhtml">pkgCache::PkgIterator</a> &amp;Pkg, <a class="el" href="classpkgCache_1_1VerIterator.xhtml">pkgCache::VerIterator</a> &amp;Ver) APT_OVERRIDE</dt>
<dd>Using an overriding pin is wrong.  </dd>
<dt><a class="anchor" id="_todo000056"></a>Member <a class="el" href="classmetaIndex.xhtml#a2bb75536ec84bdc344cf07667b587107">metaIndex::IsArchitectureSupported</a>  (std::string const &amp;arch) const</dt>
<dd>make virtual on next abi break  </dd>
<dt><a class="anchor" id="_todo000037"></a>Member <a class="el" href="classMMap.xhtml#abf6208ba8fc33da8217ee57b919c1892">MMap::Map</a>  (<a class="el" href="classFileFd.xhtml">FileFd</a> &amp;Fd)</dt>
<dd>Writing to compressed fd's ?  </dd>
<dt><a class="anchor" id="_todo000055"></a>Member <a class="el" href="classAPT_1_1Progress_1_1PackageManagerFancy.xhtml#afdd3a4f5c1ff9a58b5588dd9da3ee4ec">PackageManagerFancy::GetTerminalSize</a>  ()</dt>
<dd>get from "child_pty" instead?  </dd>
<dt><a class="anchor" id="_todo000054"></a>Member <a class="el" href="classAPT_1_1Progress_1_1PackageManagerProgressDeb822Fd.xhtml#a585ae4dbdec6a715a3ea524952da63e8">PackageManagerProgressDeb822Fd::StartDpkg</a>  () APT_OVERRIDE</dt>
<dd>use SetCloseExec here once it taught about throwing  </dd>
<dt><a class="anchor" id="_todo000053"></a>Member <a class="el" href="classAPT_1_1Progress_1_1PackageManagerProgressFd.xhtml#a585ae4dbdec6a715a3ea524952da63e8">PackageManagerProgressFd::StartDpkg</a>  () APT_OVERRIDE</dt>
<dd>use SetCloseExec here once it taught about throwing  </dd>
<dt><a class="anchor" id="_todo000003"></a>Member <a class="el" href="classpkgAcqDiffIndex.xhtml#a3980b570ebaa4972bbe5218ba6d3e32b">pkgAcqDiffIndex::ParseDiffIndex</a>  (std::string const &amp;IndexDiffFile)</dt>
<dd>all of pdiff supports only .gz compressed patches  </dd>
<dt><a class="anchor" id="_todo000002"></a>Member <a class="el" href="classpkgAcqDiffIndex.xhtml#a79496027fb5023578c8726a103bea532">pkgAcqDiffIndex::pkgAcqDiffIndex</a>  (<a class="el" href="classpkgAcquire.xhtml" title="The core download scheduler. {{{. ">pkgAcquire</a> *const Owner, <a class="el" href="classpkgAcqMetaClearSig.xhtml" title="An item repsonsible for downloading clearsigned metaindexes {{{. ">pkgAcqMetaClearSig</a> *const TransactionManager, <a class="el" href="classIndexTarget.xhtml" title="Information about an index file. ">IndexTarget</a> const &amp;Target) APT_NONNULL(2</dt>
<dd>Magic number as an upper bound on pdiffs we will reasonably acquire  </dd>
<dt><a class="anchor" id="_todo000005"></a>Class <a class="el" href="classpkgAcqIndex.xhtml">pkgAcqIndex</a>  </dt>
<dd>Why does <a class="el" href="classpkgAcqIndex.xhtml" title="An acquire item that is responsible for fetching an index {{{ file (e.g., Packages or Sources)...">pkgAcqIndex</a> have protected members?  </dd>
<dt><a class="anchor" id="_todo000006"></a>Member <a class="el" href="classpkgAcqIndexDiffs.xhtml#a6822b4355d68d4683938302c3c4bee8b">pkgAcqIndexDiffs::available_patches</a>  </dt>
<dd>These are indexed by sha1sum; why not use some sort of dictionary instead of relying on ordering and stripping them off the front?  </dd>
<dt><a class="anchor" id="_todo000004"></a>Class <a class="el" href="classpkgAcqMetaSig.xhtml">pkgAcqMetaSig</a>  </dt>
<dd>Why protected members? </dd>
<dt><a class="anchor" id="_todo000001"></a>Member <a class="el" href="classpkgAcqMetaSig.xhtml#a3f0cc0b4b3be0867c4412bf15c3f7043">pkgAcqMetaSig::Failed</a>  (std::string const &amp;Message, <a class="el" href="structpkgAcquire_1_1MethodConfig.xhtml" title="Information about the properties of a single acquire method. {{{. ">pkgAcquire::MethodConfig</a> const *const Cnf) APT_OVERRIDE</dt>
<dd>this is used often (e.g. in pkgAcqIndexTrans) so refactor  </dd>
<dt><a class="anchor" id="_todo000016"></a>Class <a class="el" href="classpkgAcquire.xhtml">pkgAcquire</a>  </dt>
<dd>Why all the protected data items and methods?  </dd>
<dt><a class="anchor" id="_todo000021"></a>Member <a class="el" href="classpkgAcquire.xhtml#ab04e9ee398f825f50e4f1ea7eaf37f77">pkgAcquire::Configs</a>  </dt>
<dd>why a hand-managed config dictionary instead of std::map?  </dd>
<dt><a class="anchor" id="_todo000027"></a>Member <a class="el" href="structpkgAcquire_1_1MethodConfig.xhtml#add1daf6c866236479bdac390ed41f80a">pkgAcquire::MethodConfig::Next</a>  </dt>
<dd>Why not an STL container?  </dd>
<dt><a class="anchor" id="_todo000017"></a>Class <a class="el" href="classpkgAcquire_1_1Queue.xhtml">pkgAcquire::Queue</a>  </dt>
<dd>Why so many protected values?  </dd>
<dt><a class="anchor" id="_todo000026"></a>Member <a class="el" href="classpkgAcquire_1_1Queue.xhtml#abf4fe627ab803887ecd2a8af30f17147">pkgAcquire::Queue::Bump</a>  ()</dt>
<dd>Why both this and <a class="el" href="classpkgAcquire_1_1Queue.xhtml#a5b2dd956b1adc90b13d47e26121d5486" title="Send idle items to the worker process. ">Cycle()</a>? Are they expected to be different someday?  </dd>
<dt><a class="anchor" id="_todo000022"></a>Member <a class="el" href="classpkgAcquire_1_1Queue.xhtml#a2f4e8b582eeece0747d3fee5858b1a27">pkgAcquire::Queue::Items</a>  </dt>
<dd>why a by-hand list instead of an STL structure?  </dd>
<dt><a class="anchor" id="_todo000025"></a>Member <a class="el" href="classpkgAcquire_1_1Queue.xhtml#a76f3403ec41517cce48d96a5b1f54e1e">pkgAcquire::Queue::ItemStart</a>  (<a class="el" href="structpkgAcquire_1_1Queue_1_1QItem.xhtml" title="A single item placed in this queue. ">QItem</a> *Itm, unsigned long long Size)</dt>
<dd>Unimplemented. Implement it or remove?  </dd>
<dt><a class="anchor" id="_todo000023"></a>Member <a class="el" href="classpkgAcquire_1_1Queue.xhtml#ae49de4816f8591cf1ccb70329d4dcb8c">pkgAcquire::Queue::Workers</a>  </dt>
<dd><p class="startdd">This is plural because support exists in <a class="el" href="classpkgAcquire_1_1Queue.xhtml" title="A single download queue in a pkgAcquire object. {{{. ">Queue</a> for multiple workers. However, it does not appear that there is any way to actually associate more than one worker with a queue.</p>
<p class="enddd">Why not just use a std::set?  </p>
</dd>
<dt><a class="anchor" id="_todo000019"></a>Member <a class="el" href="classpkgAcquire.xhtml#a9e42b66f176afafc1c75e78289e80e76">pkgAcquire::Queues</a>  </dt>
<dd>why a hand-managed list of queues instead of std::list or std::set?  </dd>
<dt><a class="anchor" id="_todo000008"></a>Class <a class="el" href="classpkgAcquire_1_1Worker.xhtml">pkgAcquire::Worker</a>  </dt>
<dd>Like everything else in the Acquire system, this has way too many protected items. </dd>
<dt><a class="anchor" id="_todo000010"></a>Member <a class="el" href="classpkgAcquire_1_1Worker.xhtml#a006a979c4801f6b6ceb33cb3acd6dc89">pkgAcquire::Worker::Access</a>  </dt>
<dd>Doesn't this duplicate Config-&gt;Access?  </dd>
<dt><a class="anchor" id="_todo000011"></a>Member <a class="el" href="classpkgAcquire_1_1Worker.xhtml#a849bc65c54e1bcbe8a7f053ce2cec672">pkgAcquire::Worker::InReady</a>  </dt>
<dd>Is this right? It's a guess.  </dd>
<dt><a class="anchor" id="_todo000009"></a>Member <a class="el" href="classpkgAcquire_1_1Worker.xhtml#a70b012fdfb38bfe94b52924d45c5462d">pkgAcquire::Worker::NextQueue</a>  </dt>
<dd>This is always NULL; is it just for future use?  </dd>
<dt><a class="anchor" id="_todo000013"></a>Member <a class="el" href="classpkgAcquire_1_1Worker.xhtml#a27ee7762ef1caaf3ec8c3598c15e7886">pkgAcquire::Worker::OutQueue</a>  </dt>
<dd>Wouldn't a std::dequeue be more appropriate?  </dd>
<dt><a class="anchor" id="_todo000012"></a>Member <a class="el" href="classpkgAcquire_1_1Worker.xhtml#a0b8717fb6d062212c251900cee4e6004">pkgAcquire::Worker::OutReady</a>  </dt>
<dd>Is this right?  </dd>
<dt><a class="anchor" id="_todo000014"></a>Member <a class="el" href="classpkgAcquire_1_1Worker.xhtml#a26a68d57a249a042c1e32186ce2fce8b">pkgAcquire::Worker::RunMessages</a>  ()</dt>
<dd>Several message types lack separate handlers. </dd>
<dt><a class="anchor" id="_todo000020"></a>Member <a class="el" href="classpkgAcquire.xhtml#adfb69296d9a50a92927df7c30e56be2e">pkgAcquire::Workers</a>  </dt>
<dd>why a hand-managed list of workers instead of std::list or std::set?  </dd>
<dt><a class="anchor" id="_todo000018"></a>Class <a class="el" href="classpkgAcquireStatus.xhtml">pkgAcquireStatus</a>  </dt>
<dd>Why protected members?  </dd>
<dt><a class="anchor" id="_todo000028"></a>Member <a class="el" href="classpkgAcquireStatus.xhtml#a61c6f568f6582836223430d117a62e69">pkgAcquireStatus::MediaChange</a>  (std::string Media, std::string Drive)=0</dt>
<dd>This is a horrible blocking monster; it should be CPSed with prejudice.  </dd>
<dt><a class="anchor" id="_todo000062"></a>Member <a class="el" href="structpkgCache_1_1DescFile.xhtml#a924e1d37050236e62bcb18be0c5e5f0f">pkgCache::DescFile::Size</a>  </dt>
<dd>document <a class="el" href="structpkgCache_1_1DescFile.xhtml#a924e1d37050236e62bcb18be0c5e5f0f">pkgCache::DescFile::Size</a>  </dd>
<dt><a class="anchor" id="_todo000063"></a>Member <a class="el" href="structpkgCache_1_1Description.xhtml#a1f9f97296f6e716a703097d573fff263">pkgCache::Description::FileList</a>  </dt>
<dd>document <a class="el" href="structpkgCache_1_1Description.xhtml#a1f9f97296f6e716a703097d573fff263">pkgCache::Description::FileList</a>  </dd>
<dt><a class="anchor" id="_todo000060"></a>Member <a class="el" href="structpkgCache_1_1PackageFile.xhtml#a87b9212b05c48e953f3d476eee0a3595">pkgCache::PackageFile::Flags</a>  </dt>
<dd>document <a class="el" href="structpkgCache_1_1PackageFile.xhtml#a87b9212b05c48e953f3d476eee0a3595">PackageFile::Flags</a>  </dd>
<dt><a class="anchor" id="_todo000059"></a>Member <a class="el" href="structpkgCache_1_1PackageFile.xhtml#a89f262193bef3d4f8e249f835a9195dc">pkgCache::PackageFile::IndexType</a>  </dt>
<dd>enumerate at least the possible indexes  </dd>
<dt><a class="anchor" id="_todo000058"></a>Member <a class="el" href="structpkgCache_1_1ReleaseFile.xhtml#a87b9212b05c48e953f3d476eee0a3595">pkgCache::ReleaseFile::Flags</a>  </dt>
<dd>document <a class="el" href="structpkgCache_1_1PackageFile.xhtml#a87b9212b05c48e953f3d476eee0a3595">PackageFile::Flags</a>  </dd>
<dt><a class="anchor" id="_todo000061"></a>Member <a class="el" href="structpkgCache_1_1VerFile.xhtml#a924e1d37050236e62bcb18be0c5e5f0f">pkgCache::VerFile::Size</a>  </dt>
<dd>document <a class="el" href="structpkgCache_1_1VerFile.xhtml#a924e1d37050236e62bcb18be0c5e5f0f">pkgCache::VerFile::Size</a>  </dd>
<dt><a class="anchor" id="_todo000064"></a>Member <a class="el" href="classpkgCacheGenerator.xhtml#a69c67e48848ceba8d57db704c03875e8">pkgCacheGenerator::MakeStatusCache</a>  (<a class="el" href="classpkgSourceList.xhtml">pkgSourceList</a> &amp;List, <a class="el" href="classOpProgress.xhtml">OpProgress</a> *Progress, <a class="el" href="classMMap.xhtml">MMap</a> **OutMap, <a class="el" href="classpkgCache.xhtml">pkgCache</a> **OutCache, bool AllowMem=false)</dt>
<dd>deprecate the ignored AllowMem parameter  </dd>
<dt><a class="anchor" id="_todo000034"></a>Member <a class="el" href="classpkgCdrom.xhtml#a6d1bdb3f763da1f0a388888f206a50a6">pkgCdrom::Add</a>  (<a class="el" href="classpkgCdromStatus.xhtml">pkgCdromStatus</a> *log)</dt>
<dd>We ignore stat() errors here as we usually have only one of those in use  </dd>
<dt><a class="anchor" id="_todo000049"></a>Member <a class="el" href="classpkgDepCache.xhtml#a1ab9378572dc74fc8088fd690d494570">pkgDepCache::GetRootSetFunc</a>  ()</dt>
<dd>Is this the best place for this function? Perhaps the settings for mark-and-sweep should be stored in a single external class?  </dd>
<dt><a class="anchor" id="_todo000047"></a>Member <a class="el" href="classpkgDepCache.xhtml#aab6b1c53f7766ad618b80ebee701b60d">pkgDepCache::MarkInstall</a>  (PkgIterator const &amp;Pkg, bool AutoInst=true, unsigned long Depth=0, bool FromUser=true, bool ForceImportantDeps=false)</dt>
<dd>Should we handle or-group better here?  </dd>
<dt><a class="anchor" id="_todo000048"></a>Member <a class="el" href="classpkgDepCache_1_1Policy.xhtml#a6ab9cf0a0e662622e47d3fe99cafc817">pkgDepCache::Policy::IsImportantDep</a>  (DepIterator const &amp;Dep) const</dt>
<dd>this is a meant as a temporarly solution until the  </dd>
<dt><a class="anchor" id="_todo000046"></a>Member <a class="el" href="classpkgDPkgPM.xhtml#a807efc750fd999dcd0e3a1c90f5684ca">pkgDPkgPM::Go</a>  (<a class="el" href="classAPT_1_1Progress_1_1PackageManager.xhtml">APT::Progress::PackageManager</a> *progress) APT_OVERRIDE</dt>
<dd>workaround for dpkg bug, see our ./test-bug-740843-versioned-up-down-breaks test  </dd>
<dt><a class="anchor" id="_todo000045"></a>Member <a class="el" href="classpkgDPkgPM.xhtml#a367828235aced7bf124b0cd6827d9a2d">pkgDPkgPM::OpenLog</a>  ()</dt>
<dd>use a better string after freeze  </dd>
<dt><a class="anchor" id="_todo000043"></a>Member <a class="el" href="classpkgDPkgPM.xhtml#a6be54fa1743a469c0119ed27ee6e1087">pkgDPkgPM::ProcessDpkgStatusLine</a>  (char *line)</dt>
<dd><p class="startdd">this needs a muliarch testcase </p>
<p class="enddd">2: is "pkgname" here reliable with dpkg only sending us  </p>
</dd>
<dt><a class="anchor" id="_todo000057"></a>Member <a class="el" href="classpkgPackageManager.xhtml#a03c6f883f1372113b52ddbff519b81b6">pkgPackageManager::SmartUnPack</a>  (PkgIterator Pkg) APT_MUSTCHECK</dt>
<dd>merge on abi break  </dd>
<dt><a class="anchor" id="_todo000066"></a>Member <a class="el" href="classpkgPolicy.xhtml#a09125a1b5560d8c43c8e669560663a7d">pkgPolicy::pkgPolicy</a>  (<a class="el" href="classpkgCache.xhtml">pkgCache</a> *Owner)</dt>
<dd>make ExpressionMatches static to use it here easily  </dd>
<dt><a class="anchor" id="_todo000029"></a>Member <a class="el" href="classpkgProblemResolver.xhtml#a4e1bfb762b1ddbf737d74663852aeafa">pkgProblemResolver::ResolveInternal</a>  (bool const BrokenFix=false)</dt>
<dd><p class="startdd">we should undo the complete MarkInstall process here </p>
<p class="enddd">use DoUpgrade(Pkg) instead?  </p>
</dd>
<dt><a class="anchor" id="_todo000031"></a>Member <a class="el" href="classpkgSimulate.xhtml#ae1045dab60b1e9d7a4a9ab334f5c95d2">pkgSimulate::Go2</a>  (<a class="el" href="classAPT_1_1Progress_1_1PackageManager.xhtml">APT::Progress::PackageManager</a> *progress)</dt>
<dd>trick to avoid ABI break for virtual reimplementation; fix on next ABI break  </dd>
<dt><a class="anchor" id="_todo000067"></a>Member <a class="el" href="classpkgSrcRecords_1_1Parser.xhtml#a3197f435b17e87aaab7fe2e798444c03">pkgSrcRecords::Parser::BuildDepends</a>  (std::vector&lt; BuildDepRec &gt; &amp;BuildDeps, bool const &amp;ArchOnly, bool const &amp;StripMultiArch=true)=0</dt>
<dd>Add a parameter to specify which architecture to use for [wildcard] matching  </dd>
<dt><a class="anchor" id="_todo000065"></a>Member <a class="el" href="classpkgSystem.xhtml#abcebaae46433e8bfd54b6f93dd485331">pkgSystem::MultiArchSupported</a>  () const</dt>
<dd>these methods should be virtual  </dd>
<dt><a class="anchor" id="_todo000051"></a>Member <a class="el" href="classSigVerify.xhtml#a490c2d5199afc84532e9d4a41f2de667">SigVerify::CopyAndVerify</a>  (std::string CDROM, std::string Name, std::vector&lt; std::string &gt; &amp;SigList, std::vector&lt; std::string &gt; PkgList, std::vector&lt; std::string &gt; SrcList)</dt>
<dd><p class="startdd">delete any existing gpg file? </p>
<p class="enddd">delete any existing gpg file?  </p>
</dd>
<dt><a class="anchor" id="_todo000068"></a>Member <a class="el" href="classAPT_1_1StateChanges.xhtml#a6f5fc89488e7b1c1b0d68a586e23d7c1">StateChanges::Save</a>  (bool const DiscardOutput=false)</dt>
<dd>supported only since 1.17.7 in dpkg </dd>
</dl>
</div></div><!-- contents -->
<!-- start footer part -->
<hr class="footer"/><address class="footer"><small>
Generated by &#160;<a href="http://www.doxygen.org/index.html">
<img class="footer" src="doxygen.png" alt="doxygen"/>
</a> 1.8.13
</small></address>
</body>
</html>