Re: [help-GIFT] gift-write-feature-descs segfaults... (is the GIFT broken?)

[Jonas Lindqvist]

David Squire wrote:
> I was not intending to suggest run-time tests as a replacement for  
> compile-time error catches. But I still think that a full build and  
> test should be done before a commit... of course we should have a  
> "make test" for this.

A "test" makefile target would be great.

> > For example, using the latest CVS version of the GIFT, I was able  
> > to run gift-add-collection on a collection, and query it for a  
> > random set of images. No problem. However, whenever asking for any  
> > similar images, it failed.
> Well of course I meant an actual similarity query. From my point of  
> view getting random images is not really a query (though that is  
> how it appears in MRML and the code). Originally (before MRML) I  
> did this in the interface, not by querying.

:-) Yes, of course... My example was a rather over-simplified way of  
illustrating that some parts may work when others don't.
Testing that we get *a* result doesn't really prove that the images  
in the result are at all similar to the query image(s). But then  
again, it's better than nothing.

I'm not sure if it's doable in the GIFT, but it could be handy to be  
able to break out parts of the code to be used in some sort of "unit  
tests", to assure that image A is still quite similar to image B but  
not to image C, etc. The sources could be distributed with a handful  
of images that can be used for the unit-tests. With a controlled set  
of images we could also test that the server produces a predictable  
result over and over again. (Apart from the random stuff).
But this is obvious of course...
Unfortunately I don't know enough about the inner workings of the  
GIFT to be of any help on this.
(But I would love having tests like this, when playing with the code)


> > > > Yes, normally C screams and yells at you, but the gift was written
> > > > without function prototypes, so the compiler cant tell, until  
> > > > link time.
> >
> > Well, it didn't even complain when linking...
> > -Wmissing-prototypes could be used to at least get a compiler  
> > warning, but I'm not sure why the linker didn't speak up.
>
> Perhaps dynamic linking? Just guessing here.

The Gnu Compiler Collection is capable of some really strange things,  
and the GIFT uses some features that I'm not used to.
The answer is surely hidden in the parameters, so I guess I should  
check there...
Normally, the dynamic linking is done when linking to shared objects,  
but when linking the different object files created within the same  
"project", they are statically linked to a binary (executable or  
library). I know that GCC can do some really late binding of the  
object files when using ObjC, but in this case all symbols should be  
present in the executable binary. (The "missing" function was not in  
a lib, but in a different source/object file in the same "project").
My guess is that there is a linker flag present or missing, causing  
the linker not to complain about missing symbols.

/Jonas

smime.p7s
Description: S/MIME cryptographic signature