Excellent. We'll be changing information about PyLucene in the upcoming Lucene in Action 2.0 edition then. How is the performance now comapred to the SWIG version?
Otis ----- Original Message ---- From: Andi Vajda <[EMAIL PROTECTED]> To: [email protected] Sent: Wednesday, March 29, 2006 4:50:59 PM Subject: Re: [pylucene-dev] PyLucene no longer uses SWIG On Wed, 29 Mar 2006, [EMAIL PROTECTED] wrote: > How come you decided to move away from SWIG? I was under the impression > that SWIG makes it easy to keep a port in sync with the original and doesn't > require "manual rewrites" in another language. > Hi Otis, Several reasons: - SWIG keeps changing and with every new release breaks PyLucene. SWIG 1.3.29's breaking of PyLucene was the last straw. - SWIG is mostly in the way because it doesn't understand Java's GC and because it provides a runtime type system around the C++ objects it's wrapping that is redundant with Java's. - Over the past year, I've written a lot of C code against the Python C API and I realized that the code generated by SWIG was needlessy thick and rather suboptimal. SWIG generated about 2,000 lines of python and 60,000 lines of C++ from PyLucene's SWIG file. I replaced this with 0 lines of Python and 20,000 lines of C++. Simple object creation is three times faster. - By writing the wrappers manually I have an easier time integrating the Lucene API into Python, and an easier time making it more pythonic. - The Java Lucene API is fairly stable, playing manual catch-up isn't that bad. Now that all the macros and patterns are in place, I can write a new or updated Java Lucene API wrapper as fast (or faster) as a SWIG wrapper especially if the new API involves a new type combination. Andi.. > > ----- Original Message ---- > From: Andi Vajda <[EMAIL PROTECTED]> > To: [email protected] > Sent: Wednesday, March 29, 2006 3:57:44 PM > Subject: [pylucene-dev] PyLucene no longer uses SWIG > > > As of release 2.0, on the PyLucene development trunk, SWIG is no longer used. > Instead, the Python object wrappers are implemented by hand using the Python C > type system. > > I uploaded a new PyLucene 2.0rc1-1 source tarball to: > http://downloads.osafoundation.org/PyLucene/src/PyLucene-src-2.0rc1-1.tar.gz > > The handwritten wrappers represent about 20,000 lines of C++ code, a lot of > boilerplate. Although macros are heavily used, the rather repetitive nature of > this code makes it easy to make copy/paste mistakes along the way. > > All PyLucene unit tests and samples are passing but I expect typos and > mistakes to still be lurking. If you find something wrong, it'll most likely > crash or report an InvalidArgsError that should be trivial to fix by following > the general argument passing patterns used with parseArg() and parseArgs(). > Please report these bugs and/or submit patches to fix them. > > I also removed a number of Java Lucene deprecated methods as this is the main > purpose of the upcoming Java Lucene 2.0 release. I had to fix many unit tests > and samples along the way. Most of the changes had to do with using the new > Field() creation APIs and the new BooleanQuery clause adding APIs. > > Andi.. > > _______________________________________________ > pylucene-dev mailing list > [email protected] > http://lists.osafoundation.org/mailman/listinfo/pylucene-dev > > > > _______________________________________________ > pylucene-dev mailing list > [email protected] > http://lists.osafoundation.org/mailman/listinfo/pylucene-dev > _______________________________________________ pylucene-dev mailing list [email protected] http://lists.osafoundation.org/mailman/listinfo/pylucene-dev _______________________________________________ pylucene-dev mailing list [email protected] http://lists.osafoundation.org/mailman/listinfo/pylucene-dev
