NumberValueRangeProcessor_apply not working in the PHP-bindings

[daniel]

The following returns an error, even though the right arguments have been passed:

$vrp = new XapianNumberValueRangeProcessor?(0, "\$", true); $vrp->apply((string)"240", (string)"500");

The error returned is: Fatal error: Type error in argument 2 of NumberValueRangeProcessor?_apply. Expected SWIGTYPE_p_stdstring in xapian.php on line 1217

line 1217 being: return NumberValueRangeProcessor?_apply($this->_cPtr,$begin,$end);

Have tried changing that line to say (string)$begin and (string)$end, same result.

[olly]

SWIG isn't handling passing the string parameter by non-const reference.

I think this will need custom wrapping.

This may not work for some (or all) of the other bindings either...

[olly]

We should try to fix this for 1.0.3 if possible.

[olly]

Fixed (for PHP at least) by patching SWIG and using the latest SWIG version to generate the bindings.

This is the regression testcase I added, which now passes:

$vrp = new XapianNumberValueRangeProcessor?(0, '$', true); $a = '$10'; $b = '20'; $vrp->apply($a, $b); if (Xapian::sortable_unserialise($a) != 10) {

print Xapian::sortable_unserialise($a)." != 10\n"; exit(1);

} if (Xapian::sortable_unserialise($b) != 20) {

print Xapian::sortable_unserialise($b)." != 20\n"; exit(1);

}

Leaving this bug open until I check if this works for all the other languages...

[olly]

Patch to smoketest.py to show this bug for Python

[olly]

Richard - this bug manifests for Python too. It looked to me like SWIG had suitable typemaps, but perhaps you need to %apply them or something. The fix for PHP was to add "in" and "argout" typemaps for string&.

I'll check the other languages tomorrow.

[richard]

Hmm. Unless I'm missing something, it's not possible for the python test you've written to work. In python, strings are immutable, so we can't change the value of the parameters "a" and "b" from inside the "vrp(a,b)" call, however we implement it.

We could make vrp() return the new values of a and b. Alternatively, we could just leave this as it is, since I'm not convinced it's actually useful to call a vrp() from Python.

[olly]

We shouldn't just leave it - if something doesn't work for a language, providing a wrapper for it is just a trap for API users.

But I think this has uses - if you wanted to write a VRP subclass in Python which was based on an existing VRP subclass then it's useful to be able to call operator() on the existing class.

In fact, if you want to write a VRP subclass in Python, you're probably going to want to be able to modify the strings passed in anyway...

[richard]

Committed a fix for python (call() now returns a 3-tuple, containing the slot num, the returned begin and the returned end).

[olly]

Postponing what's left of this to 1.0.4 in the interests of actually making a release.

[olly]

Since the use-case for this is to allow subclassing your own VRP in the language, and SWIG/PHP doesn't support such subclassing at present, I'm going to bump this to 1.1.0.