headers
Olly Betts | 1 May 2006 16:56
Favicon
Gravatar

Re: PHP Latest

I think I've now done everything we need for wrapping Xapian, apart from
handling method names which clash with PHP reserved words (e.g empty, clone).
However, for a general SWIG solution a few more things are still missing.

Here's the latest version:

http://www.oligarchy.co.uk/xapian/patches/swig-php-gen-oo-wrappers9.patch
http://www.oligarchy.co.uk/xapian/patches/xapian9.phps
http://www.oligarchy.co.uk/xapian/patches/xapian_wrap9.cc

On Fri, Apr 21, 2006 at 04:45:45AM +0100, Olly Betts wrote:
> TODO:
> 
> * Use parameter names instead of $argN.

Done - we now build parameters by joining the different possible names
in overloaded variants with "_or_".  An unnamed parameter is called
"argN" (e.g. "int foo(int)" -> "function foo($arg0)").

> * Handle a parameter called $this gracefully.
> * Check a duplicate parameter name is handled OK, and fix if not.

Both done, and so is $r - any parameter name which clashes with a
previous name just gets underscores appended until it no longer clashes.

> * Handle any non-covariant class return value without swig_wrap_return.

Done.

> * Perhaps handle covariant class return by checking against the known
(Continue reading)

Permalink | Reply | 0 comments |
headers
Thomas Waldmann | 6 May 2006 13:02
Picon
Picon

Paid summer project: advanced integration of Xapian into MoinMoin wiki

Dear list readers,

I just wanted to tell that the MoinMoin wiki project is taking part in Google's
"Summer of Code 2006" and one of the project students might get paid for an
advanced integration of Xapian into MoinMoin wiki, exploiting what Xapian can do.

Required: you must be a university student, have Xapian knowledge and know
Python (MoinMoin is coded in Python).

You will have good mentoring by Richard Boulton (Xapian developer, thanks
again!) and Thomas Waldmann (MoinMoin developer) and high chances to get
accepted if your profile matches the task well.

See: http://moinmoin.wikiwikiweb.de/GoogleSoc2006

You need to be fast. The deadline for student applications is on May 8, 2006
17:00 Pacific Daylight Time - so don't wait until last minute.

If you want to contact me, please only use the wiki or email - I am usually NOT
reading this list.

If you personally don't match this task, but you know someone not reading this
list who does, please forward this to him.

Thanks,

Thomas
Permalink | Reply | 0 comments |
headers
Patrick Mézard | 9 May 2006 11:58
Picon

xapian-compact fails to rename iamflint.tmp for win32/cygwin builds

Hello,

Any call to xapian-compact compiled for Win32/Cygwin ultimately fails 
when it tries to rename/replace iamflint.tmp with the final version. The 
reason is you cannot rename an opened file with Win32/Cygwin libc.

To correct this, just close the output ofstream (xapian-compact.cc(534)) 
like:
"""
ofstream output(dest.c_str());
if (!output.write(buf, input.gcount())) {
	cerr << argv[0] << ": error writing '" << dest << "': "
	 << strerror(errno) << endl;
	exit(1);
}
output.close(); //Added
"""

Regards,

--
Patrick Mézard
Permalink | Reply | 1 comment |
headers
Olly Betts | 9 May 2006 16:26
Favicon
Gravatar

Re: xapian-compact fails to rename iamflint.tmp for win32/cygwin builds

On Tue, May 09, 2006 at 11:58:16AM +0200, Patrick M?zard wrote:
> To correct this, just close the output ofstream (xapian-compact.cc(534)) 
> like:

Thanks, I'll commit that once I've checked it builds.

Cheers,
    Olly
Permalink | Reply | 0 comments |
headers
Daniel Ménard | 10 May 2006 12:08
Picon

Documentation for the PHP OO wrapper

I finally had a chance to spend some time on Olly's idea about 
generating documentation for the object-oriented PHP wrapper
http://www.oligarchy.co.uk/xapian/patches/xapian9.phps

>Another way to approach it might be to postprocess Doxygen's XML output
>(which would allow mechanical changes to match PHP syntax).
>  
>
I wrote an xslt script to test the idea (It is one of the first I write, 
so there are surely a lot of "bad things" in it, don't hesitate to point 
them !).
You can grab the xslt file from here (28 Kb) :
http://www.bdsp.tm.fr/aed/xapian/wrapperDoc/doc.xslt

It produces a all-in-one html file (331Kb) :
http://www.bdsp.tm.fr/aed/xapian/wrapperDoc/index.html

(Don't mind about disliking the look of the result : it is done with a 
css stylesheet included in the file and can easily be changed. ;-))

The only reason for having a standalone result file is that I don't know 
how to produce multiple outputs from a stylesheet, but I think that it 
can be an advantage : easy to download, to print, to mail and so on.

Generating this doc from a Xapian distribution requires three steps :
1. ask Doxygen to produce xml output (as a quick test, I directly 
modified "xapian-core/docs/doxygen_api_conf", setting GENERATE_XML to 
"YES" and ran "doxygen doxygen_api_conf", but the way to go is probably 
: change the ".in" file, ./configure --enable-maintainer-mode, make docs 
or something like that). The xml output is generated in "docs/apidoc/xml/".
(Continue reading)

Permalink | Reply | 501 comments |
headers
Olly Betts | 10 May 2006 19:32
Favicon
Gravatar

Re: Documentation for the PHP OO wrapper

On Wed, May 10, 2006 at 12:08:45PM +0200, Daniel M?nard wrote:
> >Another way to approach it might be to postprocess Doxygen's XML output
> >(which would allow mechanical changes to match PHP syntax).
>
> I wrote an xslt script to test the idea (It is one of the first I write, 
> so there are surely a lot of "bad things" in it, don't hesitate to point 
> them !).

I don't know xslt, so I can't comment on that really.

> It produces a all-in-one html file (331Kb) :
> http://www.bdsp.tm.fr/aed/xapian/wrapperDoc/index.html

It looks pretty good.  I suspect __construct should probably be
described as "new <CLASSNAME>" since that's how the user will call it.

> I'm not very happy with the result because I had to hard code some 
> Xapian names in the xslt file, which was not what I wanted (maintenance 
> issue).

I think it's inevitably going to be somewhat inelegant because the
process of mapping the names has a number of special cases.  It should
be easier to maintain a mapping that to try to maintain parallel PHP
docs by hand - that's likely to result in more errors.  But it's a
problem that we're trying to duplicate knowledge contained in the SWIG
xapian.i and php/util.i files, as well as in SWIG itself to some extent.

> Generating a better doc require that the xslt file "knows" more about 
> what is specific to the wrapper but adding more and more tests and 
> conditions in the xslt file is probably not an option.
(Continue reading)

Permalink | Reply | 501 comments |
headers
Olly Betts | 11 May 2006 01:05
Favicon
Gravatar

ruby bindings odds and ends

In the Ruby bindings, set_X and get_X are renamed to remove the get/set,
so MSet::get_matches_estimated() becomes a read-only property (if I have
my terminology right) of the Ruby MSet class called matches_estimated.
This matches how a Ruby programmer would expect a class to be designed.

I was looking through the getters and setters list.  I wonder if a few
entries shouldn't be there, (the comment says it was auto-generated, so
I'm guessing it currently simply includes every method matching set_* or
get_*).

The ones I'm thinking of are those set_ methods which don't take exactly
one parameter, and perhaps those get_ methods which take parameters.

For example, Enquire::set_sort_by_relevance doesn't take any parameters,
while Enquire::set_sort_by_value takes two (the second is optional,
but it allows you to reverse the sort order which is a common thing to
want to do).  Neither of these methods is really a setter method in
the usual sense.  They're just methods with names which happen to start
"set_".

But I'm no Ruby programmer so I don't feel qualified to make this call
myself...

I'm also wondering if we should avoid wrapping C++ methods which are
deprecated (since there's no previous version of the Ruby bindings to
remain compatible with and those methods will be removed at some point,
possibly in 1.0 which should happen fairly soon).  This isn't a Ruby
specific thought - I think it makes sense generally.

And lastly, for most languages, there's an extra Enquire method -
(Continue reading)

Permalink | Reply | 6 comments |
headers
Paul Legato | 11 May 2006 01:51

Re: ruby bindings odds and ends

Olly Betts wrote:
> In the Ruby bindings, set_X and get_X are renamed to remove the get/set,
> so MSet::get_matches_estimated() becomes a read-only property (if I have
> my terminology right) of the Ruby MSet class called matches_estimated.
> This matches how a Ruby programmer would expect a class to be designed.

Yup, that's right (though Ruby calls them 'attributes'.)

foo.some_property = "bar" # method signature is def some_property=(value)
print foo.some_property  # method signature is def some_property()

> 
> I was looking through the getters and setters list.  I wonder if a few
> entries shouldn't be there, (the comment says it was auto-generated, so
> I'm guessing it currently simply includes every method matching set_* or
> get_*).
> 

They could probably stand some tweaking. I auto-generated them exactly
as you guessed, by grepping the C++ header files for get_ and set_
method declarations.

> The ones I'm thinking of are those set_ methods which don't take exactly
> one parameter, and perhaps those get_ methods which take parameters.
> 
> For example, Enquire::set_sort_by_relevance doesn't take any parameters,
> while Enquire::set_sort_by_value takes two (the second is optional,
> but it allows you to reverse the sort order which is a common thing to
> want to do).  Neither of these methods is really a setter method in
> the usual sense.  They're just methods with names which happen to start
(Continue reading)

Permalink | Reply | 1 comment |
headers
James Aylett | 11 May 2006 14:29

Re: ruby bindings odds and ends

On Thu, May 11, 2006 at 12:05:25AM +0100, Olly Betts wrote:

> And lastly, for most languages, there's an extra Enquire method -
> get_matching_terms() which just returns the matching terms as a list or
> array or similar.  I'm not sure why this one case gets special treatment
> really - I think it's mostly just a historical oddity.

It is - the aim should be language-specific iterator patterns so you
can treat the MSet in the appropriate way for the language. I don't
know which bindings languages actually support that at present
though... the idea is that get_matching_terms() is a *cheap*
alternative to getting this right, as it'll probably be easier to use
in the language than getting the wrapped MSetIterator, which doesn't
behave in the expected fashion without more work in the bindings.

J

--

-- 
/--------------------------------------------------------------------------\
  James Aylett                                                  xapian.org
  james <at> tartarus.org                               uncertaintydivision.org
Permalink | Reply | 3 comments |
headers
Olly Betts | 11 May 2006 16:07
Favicon
Gravatar

Re: ruby bindings odds and ends

On Thu, May 11, 2006 at 01:29:51PM +0100, James Aylett wrote:
> On Thu, May 11, 2006 at 12:05:25AM +0100, Olly Betts wrote:
> 
> > And lastly, for most languages, there's an extra Enquire method -
> > get_matching_terms() which just returns the matching terms as a list or
> > array or similar.  I'm not sure why this one case gets special treatment
> > really - I think it's mostly just a historical oddity.
> 
> It is - the aim should be language-specific iterator patterns so you
> can treat the MSet in the appropriate way for the language. I don't
> know which bindings languages actually support that at present
> though... the idea is that get_matching_terms() is a *cheap*
> alternative to getting this right, as it'll probably be easier to use
> in the language than getting the wrapped MSetIterator, which doesn't
> behave in the expected fashion without more work in the bindings.

This actually wraps a TermIterator not an MSetIterator (it wraps
Enquire::get_matching_terms_begin() and ..._end()) - the real oddity is
that none of the other sources of TermIterators get similar treatment.
I can understand that you probably don't want to suck the terms from
Database::allterms_begin() into an array but there are other places
which generally return a modest number of terms.

I suspect whoever added it just had a need to see the terms matching
each document in the MSet and found using the C++ iterators from
whatever language it was clumsy.

But as you say, we really want to wrap as whatever the native equivalent
of an iterator is where we can.  I believe that currently Python, C#, and
Ruby wrap as native-style iterators, and PHP5 should soon.  I think Java
(Continue reading)

Permalink | Reply | 2 comments |

Gmane