xapian-bindings for python doesn't compile on OSX Tiger

This is the output of the 'make' command for the python bindings (0.9.2).
xapian-core compiles fine.

aiolia:~/Desktop/2005-08-01/xapian-bindings-0.9.2 dialtone$ make
make  all-recursive
Making all in python
make  all-recursive
Making all in docs
Making all in examples
make[5]: Nothing to be done for `all'.
make[5]: Nothing to be done for `all-am'.
/bin/sh ../libtool --tag=CXX --mode=link g++ -Wall -Wno-unused \
-Wno-uninitialized -g -O2 -I/usr/local/include   -o _xapian.la \
-rpath /Library/Frameworks/Python.fr [cut]
g++  -o .libs/_xapian.so -bundle  .libs/xapian_wrap.o  \
                              /usr/local/lib/libxapian.dylib
/usr/bin/ld: Undefined symbols:
_PyArg_ParseTuple
_PyCFunction_Type
_PyCObject_FromVoidPtr
_PyCObject_Import
_PyDict_GetItemString
_PyDict_SetItemString
_PyErr_Clear
_PyErr_Fetch
_PyErr_Format
_PyErr_Occurred
_PyErr_SetString
_PyExc_IOError
_PyExc_IndexError

Re: xapian-bindings for python doesn't compile on OSX Tiger

On Sun, Jul 31, 2005 at 11:41:03PM +0000, Valentino Volonghi aka
Dialtone wrote:

> This is the output of the 'make' command for the python bindings (0.9.2).
> xapian-core compiles fine.

[snip]

Which version of Python is it using?

Cheers,
James

--

-- 
/--------------------------------------------------------------------------\
  James Aylett                                                  xapian.org
  james <at> tartarus.org                               uncertaintydivision.org

Re: xapian-bindings for python doesn't compile on OSXTiger

James Aylett <james-xapian <at> tartarus.org> writes:

> 
> On Sun, Jul 31, 2005 at 11:41:03PM +0000, Valentino Volonghi aka
> Dialtone wrote:
> 
> > This is the output of the 'make' command for the python bindings (0.9.2).
> > xapian-core compiles fine.
> 
> [snip]
> 
> Which version of Python is it using?

Python 2.4.

I solved it by adding

-undefined dynamic_lookup 

to the module_cmds_CXX variable in the main configure script in xapian-bindings.
Everything works perfectly.

Re: Custom weight factors - pushing the relevancyranking how we want it

Have done some work on implementing pagerank in xapian, the part missing is 
some way to assign a custom weight to a document. The data needed to 
calculate pagerank is held in an external database meaning that changes to 
xapian would be minimal; MatchBiasFunctor and something along the lines of 
this would probably do.

//Mikael

class ValueBiasFunctor : public MatchBiasFunctor {
 private:
  Xapian::Database _db;
  Xapian::valueno _valueno;
  Xapian::weight _max_weight;
  int _max_value;

 public:
  ValueBiasFunctor(const Xapian::Database &db, Xapian::valueno valueno) :
   _db(db), _valueno(valueno), _max_weight(15), _max_value(65535) {}

  ValueBiasFunctor(const Xapian::Database &db, Xapian::valueno valueno, 
Xapian::weight max_weight, int max_value) :
   _db(db), _valueno(valueno), _max_weight(max_weight), 
_max_value(max_value) {}

  Xapian::weight get_maxweight() {
   return _max_weight;
  }

  Xapian::weight get_weight(Xapian::docid id) {
   return _max_weight * (atoi(_db.get_document(id).get_value(_valueno)) / 

uint4 in quartz/flint

We have:

----------------------------------------------------------------------
typedef unsigned long uint4;
----------------------------------------------------------------------

which on an LP64 system is a lie. If uint4 is used on disk (and it's
used in the btree implementation) then it would make the databases
unportable, which probably isn't a good idea (unless we already have
endianness issues, although even there, an ILP32 and an LP64 process
on the same machine should really be able to share databases, although
I haven't checked for alignment problems).

I'm also not sure why quartz_types.h / flint_types.h has a comment
about a double implementation in the following:

----------------------------------------------------------------------
/** An integer type which can store the sum of the lengths of the
documents
 *  in the database.
 *
 *  FIXME - change this to a double?
 */
typedef unsigned long long int flint_totlen_t;
----------------------------------------------------------------------

unsigned long long is dead right on both major data type sizes in use
at the moment. While double certainly takes up 64bits, I don't see why
an integer isn't the right choice. The comment comes from:

Database modification time

Hello list,

is there any way to retrieve the last modification time from
a Xapian::Database object?

 TIA Ralf Mattes

_______________________________________________
Xapian-devel mailing list
Xapian-devel <at> lists.xapian.org
http://lists.xapian.org/mailman/listinfo/xapian-devel

Re: uint4 in quartz/flint

On Fri, 2005-08-05 at 11:40 +0100, James Aylett wrote:
> I'm also not sure why quartz_types.h / flint_types.h has a comment
> about a double implementation in the following:
> 
> ----------------------------------------------------------------------
> /** An integer type which can store the sum of the lengths of the
> documents
>  *  in the database.
>  *
>  *  FIXME - change this to a double?
>  */
> typedef unsigned long long int flint_totlen_t;

For the record, since it looks like it was me who wrote that comment,
I'm not sure what the FIXME is going on about, and an integer type
sounds entirely the right thing here.  I'm afraid I can't remember what
I was thinking here...

--

-- 
Richard Boulton <richard <at> tartarus.org>

error building xapian

I'm getting the following error when trying to build xapian.  I've
tried versions 0.9.1 and 0.9.2, same error.  It's a x86 debian box,
gcc 4.0.1.  It builds fine on my gentoo amd64 box (gcc 3.4.3).

Any ideas?

Thanks,

Alex

make[3]: Leaving directory `/home/mcam/xapian-core-0.9.1/backends/flint'
Making all in inmemory
make[3]: Entering directory `/home/mcam/xapian-core-0.9.1/backends/inmemory'
if /bin/sh ../../libtool --tag=CXX --mode=compile g++ -DHAVE_CONFIG_H
-I. -I. -I../.. -I../../common -I../../include   -Wall -W
-Wredundant-decls -Wundef -Wshadow -Wpointer-arith -Wcast-qual
-Wcast-align -Wno-multichar -Wno-long-long -fno-gnu-keywords -g -O2
-MT inmemory_database.lo -MD -MP -MF ".deps/inmemory_database.Tpo" -c
-o inmemory_database.lo inmemory_database.cc; \
then mv -f ".deps/inmemory_database.Tpo"
".deps/inmemory_database.Plo"; else rm -f
".deps/inmemory_database.Tpo"; exit 1; fi
mkdir .libs
 g++ -DHAVE_CONFIG_H -I. -I. -I../.. -I../../common -I../../include
-Wall -W -Wredundant-decls -Wundef -Wshadow -Wpointer-arith
-Wcast-qual -Wcast-align -Wno-multichar -Wno-long-long
-fno-gnu-keywords -g -O2 -MT inmemory_database.lo -MD -MP -MF
.deps/inmemory_database.Tpo -c inmemory_database.cc  -fPIC -DPIC -o
.libs/inmemory_database.o
inmemory_database.h:139: error: ISO C++ forbids declaration of 'type

Re: uint4 in quartz/flint

On Fri, Aug 05, 2005 at 11:40:29AM +0100, James Aylett wrote:
> We have:
> 
> ----------------------------------------------------------------------
> typedef unsigned long uint4;
> ----------------------------------------------------------------------
> 
> which on an LP64 system is a lie. If uint4 is used on disk (and it's
> used in the btree implementation) then it would make the databases
> unportable, which probably isn't a good idea (unless we already have
> endianness issues, although even there, an ILP32 and an LP64 process
> on the same machine should really be able to share databases, although
> I haven't checked for alignment problems).

It's used to hold a quantity read (byte-by-byte) from disk.  So the
fact it may be MORE than 4 bytes isn't a portability problem, though it
is at best somewhat unaesthetic.

As far as I'm aware, databases are completely portable regardless of
endian or word size issues, or anything else.

> I'm also not sure why quartz_types.h / flint_types.h has a comment
> about a double implementation in the following:
> 
> ----------------------------------------------------------------------
> /** An integer type which can store the sum of the lengths of the
> documents
>  *  in the database.
>  *
>  *  FIXME - change this to a double?

Re: Database modification time

On Wed, Aug 10, 2005 at 03:26:00PM +0200, R. Mattes wrote:
> is there any way to retrieve the last modification time from
> a Xapian::Database object?

Not via the API.  For disk based databases, it's the latest modification
time of any "base" file in the database directory.  That's true for
quartz and flint (though it may change for flint).

Would an API method be useful (and if so, what for)?  It probably
wouldn't be too hard to return a time_t for the last modification time.

Cheers,
    Olly