lucene-pylucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andi Vajda <>
Subject Re: Problems passing PyLucene objects to jcc-wrapped bobo-browse api
Date Tue, 18 May 2010 17:04:40 GMT

On Tue, 18 May 2010, Christian Heimes wrote:

> Setup
> =====
> I'm running the tests on an Ubuntu 10.04 X86_64 box with Python 2.6.5, Sun 
> Java 1.6.0_20, GCC 4.4.3 and patched setuptools 0.6c11 (all 64bit).
> JCC:
> $ svn co 
> jcc_3x
> $ cd jcc_3x
> $ JCC_JDK=/usr/lib/jvm/java-6-sun python2.6 build
> $ JCC_JDK=/usr/lib/jvm/java-6-sun python2.6 install
> Small issue: The install target always rewrites the jcc.config module. This 
> is a problem when I install JCC with "sudo python2.6 install" since 
> it's not trivial to keep the environment variable JCC_JDK across a sudo call. 
> How do you like the idea to bind the creation of jcc.config to the build or 
> build_ext target?

That makes sense. Consider it a bug that it doesn't.

> $ cd ../pylucene-2.9.2-1
> $ make ANT=ant PYTHON=python2.6 JCC="python2.6 -m jcc.__main__ --shared" 
> $ make ANT=ant PYTHON=python2.6 JCC="python2.6 -m jcc.__main__ --shared" 
> NUM_FILES=2 install
> Suggestion: How about providing sensible defaults for ANT, PYTHON, NUM_FILES 
> and JCC? It's annoying that I have to type the arguments over and over again. 
> ;)

The Makefile has about a dozen sets of defaults for a variety of platforms. 
Pick the one closest to your setup, uncomment it (and change it if needed).
Then you don't have to enter these on the command line.

> Issues
> ======
> - I have to follow a strict order (first import lucene, than 
> lucene.initVM(export=True), finally import bobobrowse). When I try to import 
> bobobrowse before the call to initVM(export=True), the import fails with 
> unresolved symbols. Have you tried to add as a dependency to 
> I believe a dependency should make the dlopen() call 
> obsolete.

This is how I solved this on Windows. I'll try to see if the same trick 
works on Linux. If it does, then the export=True parameter would become 
unnecessary. Still, unless the dynamic loader can find on its own 
(and it should be via some -rpath tricks), loading the --import'ed module 
first might still be a good idea.

> - With "--import lucene" JCC gets the class_ attribute of all types wrong, 
> that are part of the bobobrowse package. It either shows java.lang.Object as 
> class_ or the first lucene class in the hierarchy. Without "--import lucene" 
> it works as expected.

I don't have this problem with my simple program.
My SillyAnalyzer class extends Lucene's Analyzer.
foo.Analyzer is the one imported from lucene.

   >>> import lucene, foo
   >>> lucene.initVM()
   <jcc.JCCEnv object at 0x1004100d8>
   >>> foo.initVM(".")
   <jcc.JCCEnv object at 0x100410180>
   >>> foo.SillyAnalyzer.helloWorld()
   Hello World
   >>> foo.SillyAnalyzer.class_
   <Class: class bar.SillyAnalyzer>
   >>> foo.Analyzer.class_
   <Class: class org.apache.lucene.analysis.Analyzer>

I'd very much like to try to reproduce your problems with your software.
Is there any way I can get your stuff and build it here ?
It would be much easier to debug this if we worked with the same stuff.

> - I've run into a rather strange bug with our custom builds of Python 2.6. It 
> differs from the stock build of Ubuntu in two ways. The python2.6 binary is 
> linked against (Ubuntu's python2.6 binary has libpython2.6.a 
> statically linked in) and I've set the environment variable LD_RUN_PATH which 
> causes the linker to add a "library rpath" to all ELF binaries. I wasn't able 
> to find the reason for the issue so far. Any hints are appreciated.

You didn't describe the "rather strange bug" or am I missing something ?


View raw message