lucene-pylucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andi Vajda <va...@apache.org>
Subject Re: Problems passing PyLucene objects to jcc-wrapped bobo-browse api
Date Mon, 17 May 2010 02:35:49 GMT

On Thu, 13 May 2010, Andi Vajda wrote:

> On Fri, 14 May 2010, Christian Heimes wrote:
>
>> Thanks for the suggestion, Andi! I'll try your suggestion on Monday. I hope 
>> it's sufficient to create a working version of lucene + bobo-browse in 
>> order to provide my co-worker Julian a foundation for his work on 
>> bobo-browse. But I fear that it's not going to work. I carefully excluded 
>> any jar file from the bobobrowse egg that is already part of pylucene 
>> (--classpath instead of --include or --jar). The lucene class are probably 
>> wrapped because bobo-browse references the classes in its jar file.
>> 
>> By the way I've created the Makefile for bobo-browse based on your Makefile 
>> for pylucene. With your template and your good work it was trivial to 
>> create the Python bindings. Thanks ;)
>> 
>> I've an idea how you can solve the inter-package issue. Is it possible to 
>> create some kind of type interference for JCC types that point to the same 
>> Java class (e.g. lucene.Query.class_ == bobobrowse.Query.class_)?
>
> Ah, I see now the bigger problem. What you're really after in the case where 
> bobo would cause its own lucene wrappers to be generated is the ability to 
> import them from the lucene extension instead. For this, the symbols would 
> need to be exported and the C++ headers generated by jcc during the pylucene 
> build included in the lucene egg. I think this could be done. Give me a few 
> days to think about this... say via a new --import jcc commmand line option.

I added support for a new jcc command line option called --import which 
accepts the name of another jcc-built extension such as 'lucene'.

This is checked into the new branch_3x pylucene branch [1] which mirrors the 
new lucene branch_3x branch that reflects the recent changes in the lucene 
svn tree with regards to backwards compatibility changes.

The new JCC in that branch now installs all header files it generates for a 
--shared extension into the extension's egg under an 'include' directory.
Therefore you must rebuild pylucene with this latest JCC first to try this 
out.

When an extension is imported via jcc's --import command line flag, its 
header files are scanned so that the importing extension reuses the code 
from the imported extension instead of generating wrappers for these classes 
again.

This works quite well on Mac OS X where the dynamic linker finds the 
code objects (methods) for the imported classes for the imported extension 
at runtime without any problems provided the jcc-imported extensions are 
imported into python first.

On Linux, there's got to be a way to make this work but I haven't found how 
yet. I seem to be having trouble with linking to the Python Type objects. On 
Windows, I expect this to be even more difficult.

I don't know what operating system you're on. If you're on Mac OS X, please 
try this out and let me know if it solves your problem. I intend to work on 
the required Linux linker tricks next.

I created a simple test case that extends Lucene's Analyzer class but in 
another extension that is built by thus importing lucene. The command line 
to build it looks like this:
python -m jcc.__main__ --classpath `pwd` --python foo --import lucene bar.SillyAnalyzer --shared
--build --install

Andi..

[1] http://svn.apache.org/repos/asf/lucene/pylucene/branches/branch_3x/

Mime
View raw message