[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Jonas Lindqvist
Subject: Re: [help-GIFT] gift-write-feature-descs segfaults... (is the GIFT broken?)
Date: Mon, 28 Aug 2006 08:02:48 +0200

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.


Attachment: smime.p7s
Description: S/MIME cryptographic signature

reply via email to

[Prev in Thread] Current Thread [Next in Thread]