[bug-GIFT] gift 0.1.8/cvs24.may compilation bugs.

[I. Wronsky]

Hi. I tried to compile gnu GIFT 0.1.8 on RH7.2 + rawhide gcc 3.1-1.

Unfortunately, it didn't work. I meddled for some hours. I got it
to compile, but gift-add-collection.pl always failed in the end. 
I took your 24.may cvs version and tried again. This time the
result was better. ;) Here's the log of my findings and 
what I did in order to make it *pass the compilation*. I 
don't submit actual diffs as these are probably not 
correct solutions, but just (educated) guesses. They might
break the compilation on some other version of the compiler.

In the following "A => B" means "change A to B".

autoconf from ./bootstrap-cvs.sh whines
        configure.in:137: warning: Cannot check for file existence when cross
        compiling
        configure.in:142: warning: Cannot check for file existence when cross
        compiling
        configure.in:146: warning: Cannot check for file existence when cross
        compiling
        configure.in:151: warning: Cannot check for file existence when cross
        compiling
        configure.in:257: warning: Cannot check for file existence when cross
        compiling
        configure.in:383: warning: AC_TRY_RUN called without default to allow
        cross comp
        
        I'm certainly *NOT* cross compiling. I don't have a faintest
        idea what causes this. Never seen this before from autoconf. 
        Whining skipped.
        
*.h : 
        <iostream.h> => <iostream>
        <fstream.h> => <fstream>

include/gift-config.h
        "const" was defined as ""! wft?! that define didn't affect all of
        the header files! the result was that .cc and .h didn't in someplaces 
        match at all. I thought the compiler was broken. Workaround:
        remove that #define line.

Encountered several files causing the same trouble: if you define a
default value for a function argument in ".h", it seems g++ 3.1 does 
not allow to define it in the ".cc" file as well. Solution: remove
the offending initializations from ".cc" files.

        CXMLElement.cc : toXML(... int inNiveau=0) => (... int inNiveau)
        CAlgorithm::addChild(... inAttributeList=0) => (... inAttributeList)
        CAlgorithm::Calgorithm(... inAttributeList=0) => (... inAttributeList)
        CQueryTreeNode::addChild(... inWeight=1) => (... inWeight)
        CWFBestFullyWeighted::CWFBestFullyWeighted(... =1) => (...)
        CWFBestProbabilistic::CWFBestProbabilistic(... =1) => (...)
        CWFClassicalIDF::CWFClassicalIDF -""-
        CWFBinaryTerm::CWFBinaryTerm -""-
        CWFStandardTF::CFWStandardTF -""-
        CWFCoordinationLevel::CWFCoordinationLevel -""-
        CWFProbability::CWFProbability -""-

        error example:

        CWFProbability.cc:58: default argument given for parameter 1 of `
           CWFProbability::CWFProbability(const CAcInvertedFile* = 0,
           CQueryNormalizer*    = 0, CQueryNormalizer* = 0)'
           ../../libGIFTQuInvertedFile/include/CWFProbability.h:56: after 
previous 
           specification in `CWFProbability::CWFProbability(const 
CAcInvertedFile*
            = 0,    CQueryNormalizer* = 0, CQueryNormalizer* = 0)'

CQHierarchy.cc, CSessionManager.cc : 
        add #include <iterator>

CPersistentVector.h/void CPersistentVector<T>::init(..)
        constant_void_fun<T> f(inDefaultValue);
                => 
        constant_void_fun(f(inDefaultValue));

        Disclaimer: I don't know what the thing above does or should do, and
        I couldn't find an explanation from the net with reasonable amount
        of trouble. Seems like nonstandard piece of .. to me.

At this point gift can be compiled. Here's some additional stuff.

scripts/perl/gift-add-collection.pl
        $lIndexPrefix.="/" unless($lIndexPefix=~m[/$]);
                =>
        $lIndexPrefix.="/" unless($lIndexPrefix=~m[/$]);

CAcIFFileSystem.cc
        tries to open "gift-auxiliary-1" for writing in *current*
        directory. If user doesn't have write access, no go.

libGIFTAcURL2FTS.cc
        crashes on line 199 if image file has odd letters in 
        filename

Thats it. Finally, I wondered a bit about Charmer and appletviewer,
installed apache and at last got the thumbnails visible. 

After all this tweaking, my opinion is as follows: if you 
wish GIFT/mrml to catch on and perhaps get support/patches from 
the open source community, you should make the evaluation of
the system easier. Plain "./configure; make; make install"
should make it ready to rock, without additional meddling
with java, installing apaches or kludging source code. 
I understand its hard to be compatible with all unix
flavors when you have a hybrid of four programming 
languages, many of them bleeding edge, but consider 
a scientific or home user. If she is about to test her 
own CBIR idea or just examine how the system works 
on her own dataset, perhaps a whole evening of 
tweaking is too much overhead. Some will probably just hack
their own scripts together in the old fashioned way
to get on with it and forget about GIFT. On the other hand, 
if GIFT were stable and operational from the start, 
people would perhaps adapt it happily and contribute stuff. 
I know as a developer that its much more intriguing 
to add new features and such, but if anything is to 
be "THE open source CBIRS", heavy emphasis should 
be put on stability, clarity and possibility to evaluate
the system quickly. For one thing, I'd suggest replacing 
the charmer client with some actual java application 
(to get rid of apache and the thumbnail problem - the
less dependencies and oddities, the better!), do 
a quick text shell client or port the KDE client to 
the more universal GTK environment. Of course in the 
end things like this are "trivial", but they should be 
handled gracefully in order to get into the more 
serious development of actual cbir related stuff, 
like feature extraction, matching, perhaps learning, etc. 

Just my three cents really. ;) Don't lose any hair on this. And
anyway, thanks for GIFT. There is certainly a need for an open 
source CBIR system, as almost every single university / corporation
seems to have its own annoying closed source / commercial package, 
which for any outsider is equivalent to some academic papers and 
perhaps a lame web demo. Its evident that in the fields of computer 
vision and CBIR simple greed has stalled algorithmic development,
a development for which it is almost mandatory that the proposals 
can be carefully considered in practice for their shortcomings 
to be fully understood and noted. In the end the thing that 
matters in CBIR is its applicability in real world tasks, 
where success can only be measured through empirical evaluation. 
Most reported results base themselves on datasets which might
be sterile and inaccurate in representing the diversity present
in any real world image recognition task. The lack of a good, 
generally accepted open source framework to consider and 
compare these methods with, has probably made the independent, 
empirical evaluation of many ideas practically impossible, as 
there might not be resources for reimplementation. A system
like GIFT might make one uniform test bench for the past 
and future approaches.

In this light I most sincerely hope your system will catch on. ;)


 - I. W.
 

ps. "downloads" link at "www.mrml.net" was broken. First "client" link
(in the text) in "http://www.gnu.org/software/gift/"; was broken as well. 
Result: Charmer 0.2b couldn't be downloaded. Luckily I got it from a
third party.