Kelm, Peter ST/HZA-TG | 4 May 19:03 2009

Python 3.0 patch for Xapian 1.0.11 - Where to send to?

Hello,

I managed to patch xapian-1.0.11 for use with Python 3.0.1 so that the python test suite works - except one
test ("NumberValueRangeProcessor" call, lines 293-296 in "smoketest.py").

Platform: Windows
Versions used: Xapian 1.0.11 (with flax makefiles), swigwin 1.3.39, Python 3.0.1

Although I know that Python 3 support is not planned for 1.0.x. Nevertheless, where can I send this to for
review/inclusion? The ticket at http://trac.xapian.org/ticket/346 notes one behaviour "failure in
line 35" that is resolved with this patch.

BTW: I could not get 1.0.12 to work on Windows with the flac makefiles...

Peter

Peter Kelm
ST/HZA-TG

Schaeffler KG
Industriestraße 1-3
91074 Herzogenaurach (Germany)

Tel. +49 9132 82-3388  *  Mobil +49 162 2549202  *  Fax +49 9132 82-453388
mailto:peter.kelm <at> schaeffler.com  *  http://www.ina.de

Sitz Herzogenaurach
Registergericht: AG Fürth HRA 2681

Diese Information ist für den Gebrauch durch die Person oder die Firma/Organisation bestimmt, die in der
(Continue reading)

Olly Betts | 5 May 06:43 2009

Re: Python 3.0 patch for Xapian 1.0.11 - Where to send to?

On Mon, May 04, 2009 at 07:03:02PM +0200, Kelm, Peter  ST/HZA-TG wrote:
> I managed to patch xapian-1.0.11 for use with Python 3.0.1 so that the
> python test suite works - except one test ("NumberValueRangeProcessor"
> call, lines 293-296 in "smoketest.py").
> 
> Platform: Windows
> Versions used: Xapian 1.0.11 (with flax makefiles), swigwin 1.3.39, Python 3.0.1

Thanks for your enthusiasm, but I should note that for this to be useful
to us, it needs to:

(a) work with the autotools-based build system, since that is what
builds the source tarballs for releases.

(b) not simply upgrade everything to use a newer version of SWIG, or
at least if it does, someone needs to go through and very carefully
check that the changes to the SWIG-generated code for other languages
(including Python 2.x) are safe (i.e. harmless or beneficial).  We've
had issues with changes in newer SWIG versions breaking things before,
and 1.0.x is firmly in maintenance mode now.  Having recently done
this for updating trunk's version of SWIG which was already
substantially newer than that in 1.0.x, I'm pretty certain that we're
better off either using a different SWIG version for Python (or Python 3
even) or backporting relevant patches to the version of SWIG we're
using.

(c) Fix trunk first - the policy is that we don't make changes in 1.0.x
without making them on trunk first (unless the issue being addressed is
no longer relevant on trunk for some reason).  In this case, fixing
trunk first is also a lot easier, as point (b) doesn't apply there.
(Continue reading)

Kelm, Peter ST/HZA-TG | 5 May 15:09 2009

str.h warning in MSVC 9.0

Hello,

MSVC complains about line 74 in "xapian-core/common/str.h":

inline std::string str(bool value) { return std::string('0' | value, 1);
}

with the message:

"warning C4806: '|' : unsafe operation: no value of type 'bool' promoted
to type 'char' can equal the given constant"

I believe the intention is to do the following - or am I missing
something?

inline std::string str(bool value) { return std::string(value ? '1' :
'0'); }

Regards,

Peter
Olly Betts | 5 May 15:37 2009

Re: str.h warning in MSVC 9.0

On Tue, May 05, 2009 at 03:09:58PM +0200, Kelm, Peter  ST/HZA-TG wrote:
> MSVC complains about line 74 in "xapian-core/common/str.h":
> 
> inline std::string str(bool value) { return std::string('0' | value, 1);
> }

Well, the parameters are swapped in the constructor here (I'll fix
that), but I don't see that explaining the warning.

> with the message:
> 
> "warning C4806: '|' : unsafe operation: no value of type 'bool' promoted
> to type 'char' can equal the given constant"

This warning makes no sense to me.  Why should value have to be able to
be equal to '0' for this code to be "safe"?  

Unless anyone can explain why this code is a problem, I propose we just
add 4806 to the list of MSVC warnings to be ignored.

> I believe the intention is to do the following - or am I missing
> something?
> 
> inline std::string str(bool value) { return std::string(value ? '1' :
> '0'); }

That won't compile as there is no such std::string constructor.

Cheers,
    Olly
(Continue reading)

Olly Betts | 5 May 15:57 2009

Re: str.h warning in MSVC 9.0

On Tue, May 05, 2009 at 02:37:01PM +0100, Olly Betts wrote:
> Unless anyone can explain why this code is a problem, I propose we just
> add 4806 to the list of MSVC warnings to be ignored.

This is the documentation for that warning:

http://msdn.microsoft.com/en-us/library/fx3e68bw(VS.80).aspx

There's no relational operator involved here, so this warning seems to
be misfiring.

I've committed a fix for the swapped parameters to trunk as r12618.
I doubt it will fix the warning unless it is some sort of interaction
with code in an inlined std::string constructor, but it would be
useful to have that confirmed.

Cheers,
    Olly
James Aylett | 5 May 16:55 2009

Re: str.h warning in MSVC 9.0

On Tue, May 05, 2009 at 02:57:05PM +0100, Olly Betts wrote:

> http://msdn.microsoft.com/en-us/library/fx3e68bw(VS.80).aspx
> 
> There's no relational operator involved here, so this warning seems to
> be misfiring.

I'm going to take a guess and say it may be firing because it's
turning ('0' | value) into ('0'==true | value) or similar internally.

J

--

-- 
  James Aylett

  talktorex.co.uk - xapian.org - uncertaintydivision.org
Olly Betts | 5 May 17:10 2009

Re: str.h warning in MSVC 9.0

On Tue, May 05, 2009 at 03:55:09PM +0100, James Aylett wrote:
> On Tue, May 05, 2009 at 02:57:05PM +0100, Olly Betts wrote:
> 
> > http://msdn.microsoft.com/en-us/library/fx3e68bw(VS.80).aspx
> > 
> > There's no relational operator involved here, so this warning seems to
> > be misfiring.
> 
> I'm going to take a guess and say it may be firing because it's
> turning ('0' | value) into ('0'==true | value) or similar internally.

That would be a bogus transformation though, as this is a *bitwise* or.

Cheers,
    Olly
Eric Sellin | 5 May 17:19 2009

Re: str.h warning in MSVC 9.0


inline std::string str(bool value) {
  return value? "1": "0";
}

...and be done with it :)

E.

On Tue, 2009-05-05 at 16:10 +0100, Olly Betts wrote:
> On Tue, May 05, 2009 at 03:55:09PM +0100, James Aylett wrote:
> > On Tue, May 05, 2009 at 02:57:05PM +0100, Olly Betts wrote:
> > 
> > > http://msdn.microsoft.com/en-us/library/fx3e68bw(VS.80).aspx
> > > 
> > > There's no relational operator involved here, so this warning seems to
> > > be misfiring.
> > 
> > I'm going to take a guess and say it may be firing because it's
> > turning ('0' | value) into ('0'==true | value) or similar internally.
> 
> That would be a bogus transformation though, as this is a *bitwise* or.
> 
> Cheers,
>     Olly
> 
> _______________________________________________
> Xapian-devel mailing list
> Xapian-devel <at> lists.xapian.org
> http://lists.xapian.org/mailman/listinfo/xapian-devel
(Continue reading)

James Aylett | 5 May 17:34 2009

Re: str.h warning in MSVC 9.0

On Tue, May 05, 2009 at 04:10:30PM +0100, Olly Betts wrote:

> > > There's no relational operator involved here, so this warning seems to
> > > be misfiring.
> > 
> > I'm going to take a guess and say it may be firing because it's
> > turning ('0' | value) into ('0'==true | value) or similar internally.
> 
> That would be a bogus transformation though, as this is a *bitwise* or.

D'oh. You're absolutely right. Ok, I have no idea.

J

--

-- 
  James Aylett

  talktorex.co.uk - xapian.org - uncertaintydivision.org
Olly Betts | 5 May 17:43 2009

Re: str.h warning in MSVC 9.0

On Tue, May 05, 2009 at 04:19:59PM +0100, Eric Sellin wrote:
> 
> inline std::string str(bool value) {
>   return value? "1": "0";
> }
> 
> ...and be done with it :)

The code generated by that variant was less good in my tests when I
implemented these functions, and I'm not going to choose worse code just
to placate a bogus warning which is of marginal value even when working
correctly.  We can just turn it off globally and really be done with it.

Cheers,
    Olly

Gmane