Mercurial > hg > audiodb
annotate tests/0017/run-test.sh @ 548:e18843dc0aea
Implement a rudimentary API for audioDB::liszt
The API is rudimentary because we've dropped support for the incremental
retrieval of tracks and their number of vectors (at the API level; the
SOAP and command-line support is still there -- no changes should be
visible). This is potentially bad for the large-scale databases, of
course; one million tracks will take of the order of 16MB of RAM, more
if I'm unlucky about how std::string.c_str() is implemented.
Both this liszt operation and querying (and sampling, forthcoming...)
would benefit from a `cursor-like' interface to retrieval results: for
an API like that, instead of getting a struct with the data there, you
get a cookie with which you can ask the database for successive results.
This would be neat for all sorts of reasons. In the meantime, at least
this change fixes SOAP memory leaks related to liszt.
Make liszt.o part of LIBOBJS rather than ordinary OBJS, so that the
liszt functionality is actually compiled into the library.
Add a test for this library functionality; also modify the command-line
test file to run the SOAP server on its own port.
author | mas01cr |
---|---|
date | Wed, 11 Feb 2009 12:38:03 +0000 |
parents | fe4dc39b2dd7 |
children |
rev | line source |
---|---|
mas01cr@252 | 1 #! /bin/bash |
mas01cr@96 | 2 |
mas01cr@96 | 3 . ../test-utils.sh |
mas01cr@96 | 4 |
mas01cr@96 | 5 if [ -f testdb ]; then rm -f testdb; fi |
mas01cr@96 | 6 |
mas01cr@96 | 7 ${AUDIODB} -d testdb -N |
mas01cr@96 | 8 |
mas01cr@96 | 9 # tests that the lack of -l when the query sequence is shorter doesn't |
mas01cr@96 | 10 # segfault. |
mas01cr@96 | 11 |
mas01cr@96 | 12 intstring 2 > testfeature |
mas01cr@96 | 13 floatstring 0 1 >> testfeature |
mas01cr@96 | 14 floatstring 1 0 >> testfeature |
mas01cr@96 | 15 |
mas01cr@96 | 16 ${AUDIODB} -d testdb -I -f testfeature |
mas01cr@96 | 17 |
mas01cr@96 | 18 # sequence queries require L2NORM |
mas01cr@96 | 19 ${AUDIODB} -d testdb -L |
mas01cr@96 | 20 |
mas01cr@96 | 21 start_server ${AUDIODB} 10017 |
mas01cr@96 | 22 |
mas01cr@96 | 23 echo "query point (0.0,0.5)" |
mas01cr@96 | 24 intstring 2 > testquery |
mas01cr@96 | 25 floatstring 0 0.5 >> testquery |
mas01cr@96 | 26 |
mas01cr@96 | 27 # FIXME: this actually revealed a horrible failure mode of the server: |
mas01cr@96 | 28 # since we were throwing exceptions from the constructor, the |
mas01cr@96 | 29 # destructor wasn't getting called and so we were retaining 2Gb of |
mas01cr@96 | 30 # address space, leading to immediate out of memory errors for the |
mas01cr@96 | 31 # /second/ call. We fix that by being a bit more careful about our |
mas01cr@96 | 32 # exception handling and cleanup discipline, but how to test...? |
mas01cr@96 | 33 |
mas01cr@96 | 34 expect_client_failure ${AUDIODB} -c localhost:10017 -d testdb -Q sequence -f testquery |
mas01cr@96 | 35 expect_client_failure ${AUDIODB} -c localhost:10017 -d testdb -Q sequence -f testquery -n 1 |
mas01cr@96 | 36 |
mas01cr@96 | 37 check_server $! |
mas01cr@96 | 38 |
mas01cr@96 | 39 echo "query point (0.5,0.0)" |
mas01cr@96 | 40 intstring 2 > testquery |
mas01cr@96 | 41 floatstring 0.5 0 >> testquery |
mas01cr@96 | 42 |
mas01cr@96 | 43 expect_client_failure ${AUDIODB} -c localhost:10017 -d testdb -Q sequence -f testquery |
mas01cr@96 | 44 expect_client_failure ${AUDIODB} -c localhost:10017 -d testdb -Q sequence -f testquery -n 1 |
mas01cr@96 | 45 |
mas01cr@96 | 46 check_server $! |
mas01cr@96 | 47 |
mas01cr@96 | 48 # see if the server can actually produce any output at this point |
mas01cr@96 | 49 ${AUDIODB} -c localhost:10017 -d testdb -Q sequence -l 1 -f testquery -n 1 > testoutput |
mas01cr@96 | 50 echo testfeature 0 0 1 > test-expected-output |
mas01cr@96 | 51 cmp testoutput test-expected-output |
mas01cr@96 | 52 |
mas01cr@96 | 53 stop_server $! |
mas01cr@96 | 54 |
mas01cr@96 | 55 exit 104 |