Development discussion about Xapian, an Open Source Probabilistic Information Retrieval library

Mark Hammond | 1 Apr 13:46

RE: Re: [Xapian-commits] 7990: trunk/xapian-core/trunk/xapian-core/bin/ trunk/xapian-core/tests/harness/

Olly writes:
> And after some fettling it now builds under mingw too, though I'm
> cross-compiling so haven't tried running the testsuite yet.  Hopefully
> it still works with MSVC...

Its looking pretty good!  A socklen_t definition got lost, so we need:

+#ifdef _MSC_VER
+typedef int socklen_t;
+#endif

Added to safewinsock2.h.

And while we are on the topic :)  I believe its unrelated to the recent
patches, but debug builds with assertions enabled are failing for me with:

queryparser.cc
queryparser.cc(163) : error C2451: conditional expression of type
'Xapian::Internal::RefCntPtr<T>' is illegal
        with
        [
            T=Xapian::QueryParser::Internal
        ]
        No user-defined-conversion operator available that can perform this
conversion, or the operator cannot be called

I'm not experienced enough with std smart pointers to know what the correct
check is.

> The only real problem so far is that libtool can't see a DLL for

(Continue reading)

James Aylett | 1 Apr 14:32

Re: Error handling in the bindings

On Thu, Mar 08, 2007 at 06:57:20PM +0000, Olly Betts wrote:
> > 1. Is it okay to require Python for maintainer mode builds of Xapian-core?
> 
> If you're on Linux or FreeBSD or similar it's OK since chances are
> you'll have both installed already, but vendor Unix flavours often
> don't.  The sourceforge compile farm had perl everywhere but not
> python, for example.

+1 -- most of the most usable distros (including Mac OS X) come with
python installed, but a lot of more hard core ones don't. Solaris
still only guarantees Perl (and I doubt that will change), and I've
run into Debian-based distros (particularly for VMWare) that basically
give you netkit and let you install anything you want, so again you'll
just get Perl.

Perl does the job. It's bad enough having to have dot, which I've
always had difficulty installing...

J

--

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

Richard Boulton | 1 Apr 14:34

Re: Re: [Xapian-commits] 7990: trunk/xapian-core/trunk/xapian-core/bin/ trunk/xapian-core/tests/harness/

Mark Hammond wrote:
> Its looking pretty good!  A socklen_t definition got lost, so we need:
> 
> +#ifdef _MSC_VER
> +typedef int socklen_t;
> +#endif
> 
> Added to safewinsock2.h.

Done.

> And while we are on the topic :)  I believe its unrelated to the recent
> patches, but debug builds with assertions enabled are failing for me with:
> 
> queryparser.cc
> queryparser.cc(163) : error C2451: conditional expression of type
> 'Xapian::Internal::RefCntPtr<T>' is illegal
>         with
>         [
>             T=Xapian::QueryParser::Internal
>         ]
>         No user-defined-conversion operator available that can perform this
> conversion, or the operator cannot be called
> 
> I'm not experienced enough with std smart pointers to know what the correct
> check is.

The error message with GCC is:
/home/richard/private/Working/xapian/xapian-core/queryparser/queryparser.cc:163: 
error: could not convert

(Continue reading)

Mark Hammond | 1 Apr 16:05

RE: Re: [Xapian-commits]7990: trunk/xapian-core/trunk/xapian-core/bin/trunk/xapian-core/tests/harness/

Richard writes:
> I've got everything working again on
> Linux - let us know how you do on windows.

It's all working fine for me - thanks!  I've a few outstanding patches from
xapian-maintainer-tools/win32msvc, but I'll add them to bugzilla over the
next few days.

Cheers,

Mark

Olly Betts | 1 Apr 16:30

Re: Re: [Xapian-commits] 7990: trunk/xapian-core/trunk/xapian-core/bin/ trunk/xapian-core/tests/harness/

On Sun, Apr 01, 2007 at 01:34:46PM +0100, Richard Boulton wrote:
> Mark Hammond wrote:
> >Its looking pretty good!  A socklen_t definition got lost, so we need:
> >
> >+#ifdef _MSC_VER
> >+typedef int socklen_t;
> >+#endif
> >
> >Added to safewinsock2.h.
> 
> Done.

We already have a mechanism for this (`SOCKLEN_T') which should be used
instead.  On UNIX, configure probes and generates config.h with a #define
of SOCKLEN_T to `int' or `socklen_t' as appropriate.

The hand-written config.h.win32 erroneously had "#define SOCKLEN_T
socklen_t" (which previously didn't matter of course) so I had fixed
that and removed the typedef.  I suspect Mark hadn't updated to the new
config.h.win32.

I've doubled-checked that the SOCKLEN_T define is now correct and
reverted this change.  Mark: please make sure that you're using the
latest msvc build files and if the problem is still there let's work out
why this isn't working as intended...

> which is a little more helpful - I've fixed this error, and another one 
> which popped up in omdebug.cc.  I've got everything working again on 
> Linux - let us know how you do on windows.

(Continue reading)

Olly Betts | 1 Apr 16:50

Re: Re: [Xapian-commits]7990: trunk/xapian-core/trunk/xapian-core/bin/trunk/xapian-core/tests/harness/

On Mon, Apr 02, 2007 at 12:05:44AM +1000, Mark Hammond wrote:
> Richard writes:
> > I've got everything working again on
> > Linux - let us know how you do on windows.
> 
> It's all working fine for me - thanks!  I've a few outstanding patches from
> xapian-maintainer-tools/win32msvc, but I'll add them to bugzilla over the
> next few days.

Interesting - does "make check" currently pass for you under MSVC?

I found that the WinsockInitializer mechanism just didn't work as
it currently is in SVN for TcpClient because the TcpClient constructor
creates the socket and passes it to initialise the parent class which
happens before the winsock_initializer member is initialised.

I've fixed this in my working copy by making the WinsockInitializer a
base class of TcpClient (and listing it before RemoteDatabase) and then
winsock gets initialised as intended.

Perhaps MSVC has a different class construction order, though I thought
this was mandated by the C++ standard.  Anyway, the base class approach
should work for MSVC too.  Essentially WinsockInitializer is now a
"mixin" class.

The testsuite now sort of works for mingw (with various tweaks that I
still need to tidy up and check in).

The problem is that tests seem to randomly fail to connect to the remote
backend, which I think must be down to timing issues with starting

(Continue reading)

Olly Betts | 1 Apr 17:24

Re: Re: [Xapian-commits] 7990: trunk/xapian-core/trunk/xapian-core/bin/ trunk/xapian-core/tests/harness/

On Sun, Apr 01, 2007 at 09:46:29PM +1000, Mark Hammond wrote:
> Olly writes:
> > The only real problem so far is that libtool can't see a DLL for
> > -lws2_32 so decides to statically link everything!  Is
> > winsock actually a DLL or a static library?
> 
> Its a DLL for me.  I've a 41k .lib file in the compiler/sdk 'lib' dir and a
> 83k dll in system32.  I'm surprised a static version of that library is
> available.

It may not be...

My Linux->mingw cross-compiler has:

/usr/i586-mingw32msvc/lib/libws2_32.a

But I'm not sure if that's "real" static library or just the import
library for the DLL (which of course I don't have on the compiling
system).  Actually, running "strings" on it I discover it contains
the string "WS2_32.DLL" so presumably it is the import library.

So I think libtool is getting this wrong - it sees a ".a" and can't
see a ".dll" so decides it only has a static version (under UNIX you
would just link against the ".dll" - there's no need to mess around
with import libraries).  Presumably a non-cross-build would see the
".dll" and be happy.  I'll report this to the libtool folks.

Cheers,
    Olly

(Continue reading)

Mark Hammond | 2 Apr 04:51

RE: Re: [Xapian-commits] 7990:trunk/xapian-core/trunk/xapian-core/bin/trunk/xapian-core/tests/harness/

Olly:
> We already have a mechanism for this (`SOCKLEN_T') which
> should be used
> instead.  On UNIX, configure probes and generates config.h
> with a #define
> of SOCKLEN_T to `int' or `socklen_t' as appropriate.
>
> The hand-written config.h.win32 erroneously had "#define SOCKLEN_T
> socklen_t" (which previously didn't matter of course) so I had fixed
> that and removed the typedef.  I suspect Mark hadn't updated
> to the new config.h.win32.

Oops - yes, my apologies, that is almost certainly what happened.  The trunk
now builds for me - thanks.

In my feeble defense though, the current win32 build process is fairly error
prone.  It requires you to manually copy files from one directory to
another, then start the build process, which itself then copies those files
into yet other directories.  This first manual step is easy to forget, and
would seem to work against a tinderbox type system working for windows
out-of-the-box.

Is there a reason for the intermediate 'xapian-core/win32' directory?  Is
there any reason we can't tweak the top-level makefile to copy the files
directly from xapian-maintainer-tools/win32msvc directory directly into the
xapian-core tree, and thereby allowing the make process to run directly from
the source of the makefiles?

And while on this topic, it did take me some time to work out how to get
started building on Windows.  I'd like to suggest a patch similar to the

(Continue reading)

Mark Hammond | 2 Apr 04:53

RE: Re: [Xapian-commits]7990: trunk/xapian-core/trunk/xapian-core/bin/trunk/xapian-core/tests/harness/

Olly writes:

> On Mon, Apr 02, 2007 at 12:05:44AM +1000, Mark Hammond wrote:
> > Richard writes:
> > > I've got everything working again on
> > > Linux - let us know how you do on windows.
> >
> > It's all working fine for me - thanks!  I've a few
> outstanding patches from
> > xapian-maintainer-tools/win32msvc, but I'll add them to
> bugzilla over the
> > next few days.
>
> Interesting - does "make check" currently pass for you under MSVC?
>
> I found that the WinsockInitializer mechanism just didn't work as
> it currently is in SVN for TcpClient because the TcpClient constructor
> creates the socket and passes it to initialise the parent class which
> happens before the winsock_initializer member is initialised.

It did work for me.  I'm a little confused by the above though - my patch
has the winsock initialization done via the construction of a static
module-level variable - the constructor initialized Winsock.  However, it
seems to me that TcpClient objects are always created via "new
TcpClient(...)", and the best I can tell, this is not done via the
initialization of a variable, but instead via code called via main() - so
its unclear to me how a TcpClient() was created before winsock was
initialized.

However, I really don't care enough to track this down :)  It *still* seems

(Continue reading)

Olly Betts | 2 Apr 05:01

Re: Re: [Xapian-commits]7990: trunk/xapian-core/trunk/xapian-core/bin/trunk/xapian-core/tests/harness/

On Sun, Apr 01, 2007 at 03:50:53PM +0100, Olly Betts wrote:
> On Mon, Apr 02, 2007 at 12:05:44AM +1000, Mark Hammond wrote:
> > It's all working fine for me - thanks!  I've a few outstanding patches from
> > xapian-maintainer-tools/win32msvc, but I'll add them to bugzilla over the
> > next few days.
> 
> Interesting - does "make check" currently pass for you under MSVC?

Still interested to know this!

> I found that the WinsockInitializer mechanism just didn't work as
> it currently is in SVN for TcpClient because the TcpClient constructor
> creates the socket and passes it to initialise the parent class which
> happens before the winsock_initializer member is initialised.
> 
> I've fixed this in my working copy by making the WinsockInitializer a
> base class of TcpClient (and listing it before RemoteDatabase) and then
> winsock gets initialised as intended.

This is now checked in.

> The problem is that tests seem to randomly fail to connect to the remote
> backend, which I think must be down to timing issues with starting
> xapian-tcpsrv versus trying to connect to it.  Under Unix we carefully
> wait until xapian-tcpsrv outputs "Listening" to avoid this problem.
> Perhaps adding a short "sleep" after starting xapian-tcpsrv will provide
> an acceptable workaround.

It doesn't appear to be timing issues.  It seems to be particular tests
which fail to connect.  The error isn't much help:

(Continue reading)

Group

gmane.comp.search.xapian.devel.

Project Web Page

Development discussion about Xapian, an Open Source Probabilistic Information Retrieval library

Search Archive

Page

1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 16

Articles in period: 153

April 2007

Language

Change language

Options

Current view: Threads only / Showing only 20 lines / Not hiding cited text.
Change to All messages, whole messages, or hide cited text.

Post a message
NNTP Newsgroup
Classic Gmane web interface
XML

XML

RSS Feed
List Information

About Gmane

Recent entries

How to count I/O consuming in OProfile while profiling xapian (30 Dec 10:09)
Xapian 1.2.8 core for Windows (23 Dec 10:17)
Looking for a project (23 Dec 08:39)
How to enable stemming with default_op set to OP_NEAR (15 Dec 00:16)
Bindings for a Scheme implementation? (1 Dec 13:30)
apply for attend xapian develope ! (25 Aug 16:55)
Compilation error (24 Aug 12:23)
Hi, (23 Aug 15:18)
GSoC Final Evaluations (19 Aug 03:49)
Interest in developement as a student (27 Jul 11:15)
How to add support of Chinese & Japanese (14 Jul 10:39)
GSoC Admin (12 Jul 17:51)
Compiling on Mac OS X (6 Jul 03:21)
xapian csharp bindings crash (25 Jun 17:37)
1.2.6 PHP bindings not building (22 Jun 17:45)
GNU GPL, really!? (9 Jun 03:15)
Introduction and Discussion for Learning to Rank Framework (7 Jun 08:54)
Conversion of all docs to RST (30 May 02:32)
Does OP_NEAR works with stemming? (27 May 21:59)
Xapian GSoC 2011 - Official Start of Coding (23 May 07:04)
Fwd: FLAG_PARTIAL and subset words (15 May 22:00)

Archives

2	January 2012
19	December 2011
4	September 2011
11	August 2011
14	July 2011
15	June 2011
37	May 2011
57	April 2011
93	March 2011
11	February 2011
9	January 2011
6	December 2010
2	October 2010
9	September 2010
5	August 2010
7	June 2010
4	April 2010
9	March 2010
5	February 2010
3	January 2010
3	November 2009
11	September 2009
6	August 2009
20	July 2009
4	June 2009
14	May 2009
22	April 2009
24	January 2009
4	December 2008
6	November 2008
16	October 2008
4	September 2008
8	August 2008
11	July 2008
8	June 2008
1	May 2008
21	April 2008
5	March 2008
9	February 2008
3	January 2008
11	December 2007
6	November 2007
19	October 2007
24	September 2007
2	August 2007
5	July 2007
30	June 2007
26	May 2007
146	April 2007
57	March 2007
44	February 2007
12	January 2007
32	December 2006
44	November 2006
23	October 2006
6	September 2006
20	August 2006
11	July 2006
34	June 2006
22	May 2006
70	April 2006
13	March 2006
4	February 2006
8	January 2006
17	December 2005
11	November 2005
2	October 2005
4	September 2005
22	August 2005
19	July 2005
19	June 2005
24	May 2005
9	April 2005
8	March 2005
11	February 2005
1	January 2005
41	December 2004
4	October 2004
17	September 2004
16	August 2004
17	June 2004
41	May 2004
4	April 2004
3	March 2004
16	January 2004
2	December 2003
27	November 2003
1	October 2003
15	August 2003
65	July 2003
29	June 2003
32	May 2003
25	April 2003
29	March 2003
37	February 2003
20	January 2003
25	December 2002

Design

Zawodny | Right Menu | Left Menu

Your Own Design

Paste the URL of your CSS below. Download CSS template