Our aim was to get Xapian 1.0.0 out this month (April 2007). We aren't quite going to manage that, but the wonders of a self-imposed deadline mean we're now getting really close. The main things left to do are some work on indexing and query parsing (which I'm currently in the middle of) and some work on the Python bindings (which Richard is working on). The core library has an extensive test suite, and the bindings each have test suites with varying degress of coverage, and these are currently all passing except for a problem with the (newly supported) remote backend in the MSVC build which is being investigated. But it would be great to have some real world testing to shake out any lurking problems now, rather than 2 days after we release 1.0.0! So I'd like to encourage you all to download snapshot tarballs from SVN trunk and try your applications with them: http://www.oligarchy.co.uk/xapian/trunk/ Note that unfortunately flint databases from 0.9.X aren't compatible with SVN trunk (I'd like to provide a "flint upgrade" utility, but I want to get 1.0.0 out first) so for now build a fresh database when testing the snapshots. Flint is now the default database, so "XAPIAN_PREFER_FLINT" is no longer required). I'm about to leave for a long weekend, but send any feedback in to the list and I'll read it on Tuesday. Cheers, Olly
We have a long weekend until Wednesday and I'm on a business trip until Thursday but I will try it with the full dataset at Friday. (cygwin) 2007/4/27, Olly Betts <olly@survex.com>:> Our aim was to get Xapian 1.0.0 out this month (April 2007). We aren't > quite going to manage that, but the wonders of a self-imposed deadline > mean we're now getting really close. > > The main things left to do are some work on indexing and query parsing > (which I'm currently in the middle of) and some work on the Python > bindings (which Richard is working on). > > The core library has an extensive test suite, and the bindings each have > test suites with varying degress of coverage, and these are currently > all passing except for a problem with the (newly supported) remote > backend in the MSVC build which is being investigated. But it would be > great to have some real world testing to shake out any lurking problems > now, rather than 2 days after we release 1.0.0! > > So I'd like to encourage you all to download snapshot tarballs from SVN > trunk and try your applications with them: > > http://www.oligarchy.co.uk/xapian/trunk/ > > Note that unfortunately flint databases from 0.9.X aren't compatible > with SVN trunk (I'd like to provide a "flint upgrade" utility, but I > want to get 1.0.0 out first) so for now build a fresh database when > testing the snapshots. Flint is now the default database, so > "XAPIAN_PREFER_FLINT" is no longer required). > > I'm about to leave for a long weekend, but send any feedback in to the > list and I'll read it on Tuesday.-- Reini Urban http://phpwiki.org/ http://murbreak.at/ http://spacemovie.mur.at/ http://helsinki.at/
Hi, On 4/28/07, Olly Betts <olly@survex.com> wrote:> So I'd like to encourage you all to download snapshot tarballs from SVN > trunk and try your applications with them: > > http://www.oligarchy.co.uk/xapian/trunk/ > > Note that unfortunately flint databases from 0.9.X aren't compatible > with SVN trunk (I'd like to provide a "flint upgrade" utility, but I > want to get 1.0.0 out first) so for now build a fresh database when > testing the snapshots. Flint is now the default database, so > "XAPIAN_PREFER_FLINT" is no longer required). > > I'm about to leave for a long weekend, but send any feedback in to the > list and I'll read it on Tuesday. >Sorry for the late reply, I was away last week. I have just tried the SVN 8400 snapshots and found two issues with RPM packaging. - omega.spec needs to be patched (see end of this email) because the source is now tarballed as xapian-omega. - shouldn't the bindings be numbered 0.9.10_svnXXX instead of 0.9.10.1_svnXXX ? This messes up dependencies. I'll try the current snapshots during the week and report any problem I run into. Cheers. Fabrice --- omega.spec 2007-04-28 18:30:56.000000000 +0800 +++ omega.spec 2007-05-06 12:46:21.000000000 +0800 @@ -15,7 +15,7 @@ Requires: xapian-core-libs = %{version}, webserver BuildRequires: xapian-core-devel = %{version} BuildRequires: autoconf automake libtool -Source0: http://www.oligarchy.co.uk/xapian/%{version}/omega-%{version}.tar.gz +Source0: http://www.oligarchy.co.uk/xapian/%{version}/%{name}-%{version}.tar.gz Buildroot: %{_tmppath}/%{name}-%{version}-%{release}-root %description @@ -23,7 +23,7 @@ library to index and search collections of documents. %prep -%setup -q -n omega-%{version} +%setup -q %build # FC6 (at least) has a patched libtool which knows not to set rpath for @@ -41,7 +41,7 @@ %makeinstall # CGI application mkdir -p %{buildroot}/var/www/cgi-bin/ -mv %{buildroot}%{_libdir}/omega/bin/omega %{buildroot}/var/www/cgi-bin +mv %{buildroot}%{_libdir}/xapian-omega/bin/omega %{buildroot}/var/www/cgi-bin # Create /var directories mkdir -p %{buildroot}%{contentdir}/omega/data mkdir -p %{buildroot}%{contentdir}/omega/cdb
Jean-Francois Dockes
2007-May-06 13:35 UTC
[Xapian-discuss] Re: 1.0 news, and a call for testing
Hello, I've compiled/linked Recoll with the snapshot, and I see no specific problem (but I did not do a huge amount of testing). I second Fabrices's suggestion for a specific 'database format changed' exception (Recoll still uses quartz by default anyway). Is there somewhere a document describing what's new for application developpers in the 1.0 xapian-core API ? Especially, there is a mention on the wiki of a "new unicode/utf-8 API in xapian-core". What's this ? Do the stemmers now take utf-8 ? I am quite certain that this information passed in messages through my mailbox, but a small abstract with pointers to the detailed information (include files accepted...) would certainly be appreciated. Regards, J.F. Dockes
On 5/8/07, Richard Boulton <richard@lemurconsulting.com> wrote:> Fabrice Colin wrote: > > Is this enough to point in the right direction ? Let me know if you need > > more information. > > Yes, that helped a lot, thanks. I've now reproduced this and have a fix > - I just need to get a regression test written, and then I'll commit it. > The problem was due to a lock which is obtained in the constructor not > being freed when an exception is thrown: normally it would be unlocked > by the destructor, but this doesn't get called if the constructor fails. >Nice one !> However, I would suggest that when you handle this in your application, > you delete (or move to a backup location) the old database before > creating the new one, rather than relying on the overwrite mechanism to > work. It should work in this case, but I'd be uncomfortable with > guaranteeing that it will always be able to cope. >Okay. I will have to think about what this means in my case. Thanks ! Fabrice