[Xapian-discuss] Python bindings

[James Aylett]

On Fri, Jun 17, 2005 at 11:39:48PM +0100, Olly Betts wrote:

> I quickly narrowed the breakage down to between 0.8.5.1 and 0.9.0, and
> (after a lot of recompiling different versions) to this change:
> 
> @@ -669,13 +678,14 @@
>          %extend {
>             /** Constructs a query from a vector of terms merged with the specified operator */
>             Query(Query::op op,
> -                 const std::vector<std::string>* subqs,
> -                 termpos window = 0) {
> -                   Xapian::Query * query=new Xapian::Query(op, subqs->begin(),subqs->end());
> -                   if (window) query->set_window(window);
> +                 std::vector<std::string>* subqs,
> +                 termpos parameter = 0) {
> +                   Xapian::Query * query=new Xapian::Query(op, subqs->begin(),subqs->end(), parameter);
>                     return query;
>             }
>         }
> +       /** Apply the specified operator to a single Xapian::Query object. */
> +       Query(Query::op op_, Xapian::Query q);
>  #endif
> 
>         /** Constructs a new empty query object */
> 
> I wondered at the removal of "const", so I tried adding it back in.  SWIG
> moans that it can't find typemap entries (or something):

Yeah, I had problems with that - I think the SWIG STL typemaps are
incomplete wrt some const variants.

> *BUT* the bindings do compile and simplesearch.py appears to work and build
> queries as it should!  Yet if I "#ifndef SWIGPYTHON" out the %extend block,
> it doesn't work.

I'm unable to investigate this myself, as I'm still getting build
errors with g++ 3.0:

----------------------------------------------------------------------
cc1plus: warnings being treated as errors
In file included from
/s1/james/projects/xapian/xapian/xapian-core/common/match.h:32,
                 from
		 /s1/james/projects/xapian/xapian/xapian-core/common/multimatch.h:27,
                 from
		 /s1/james/projects/xapian/xapian/xapian-core/api/omenquire.cc:38:
/s1/james/projects/xapian/xapian/xapian-core/common/stats.h: In member
function
   `void Xapian::Weight::Internal::my_termfreq_is(const std::string&,
   unsigned
   int)':
/s1/james/projects/xapian/xapian/xapian-core/common/stats.h:308:
warning: declaration
   of `tname' shadows previous local
/s1/james/projects/xapian/xapian/xapian-core/common/stats.h: In member
function
   `void Xapian::Weight::Internal::my_reltermfreq_is(const
   std::string&,
   unsigned int)':
/s1/james/projects/xapian/xapian/xapian-core/common/stats.h:319:
warning: declaration
   of `tname' shadows previous local
/s1/james/projects/xapian/xapian/xapian-core/common/stats.h: In member
function
   `doccount Xapian::Weight::Internal::get_total_termfreq(const
   std::string&)
   const':
/s1/james/projects/xapian/xapian/xapian-core/common/stats.h:351:
warning: declaration
   of `tname' shadows previous local
/s1/james/projects/xapian/xapian/xapian-core/common/stats.h: In member
function
   `doccount Xapian::Weight::Internal::get_total_reltermfreq(const
   std::string&) const':
/s1/james/projects/xapian/xapian/xapian-core/common/stats.h:366:
warning: declaration
   of `tname' shadows previous local
----------------------------------------------------------------------

Is it possible this is a problem with a version of automake or
similar? I'm building in maintainer mode, so all of that is being run
(actually, I've also bootstrapped recently).

> James: you made this change - any idea what's going on here?

The change is just to support the new API, where we don't set a window
but rather a parameter (IIRC). And I'm pretty certain that that /has/
worked for me at some stage.

It would be worth someone who has a fully-built SVN trunk xapian-core
and xapian-bindings altering simple* to give full exception stack
trace (import traceback; traceback.print_exc() should do it) on this
error, as there's detail missing from the error message which would be
helpful in tracking down what's happening here. About 90% of
maintenance of the Python bindings seems to be sorting out
disambiguation of the constructor overloading ...

J

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