lucy-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marvin Humphrey <>
Subject Re: [Lucy] Incubator or out?
Date Sun, 27 Jun 2010 02:45:33 GMT
On Sat, Jun 26, 2010 at 04:03:25PM -0500, Peter Karman wrote:
> One thing that should attract more people is if we can get more than just Perl
> bindings implemented using Lucy. I'm thinking C, PHP, Ruby, Python, etc. To my
> knowledge, none of those languages have an IR library on the level of Lucy
> (which is why Lucy started), and if we can get a stable core to 1.0, we can
> attract capable developers from some of those communities. 

For what it's worth, writing bindings is a problem space I'm intensely
interested in.  If we can bring my other responsibilities down to a dull roar,
I'll be addressing some of these.  Ruby first.

Not that I would grouch if someone else volunteers!

> It might even be worth seeing if we could leverage SWIG.

The thing I don't like about SWIG for Perl at least is that it doesn't yield
idiomatic interfaces.  For Perl, I strongly prefer labeled parameters over
positional arguments when there are two or more arguments to a method, and
I've gone to considerable lengths to support labeled params with

Also, different languages have different conventions for method naming: Java
likes lowerCamelCase, Perl prefers underscore_separation, and so on.  One
reason that Clownfish uses method names with a combination of mixed
capitalization and underscores  -- e.g. Open_InStream -- is that method names
of both varieties can be automatically derived:

    my $clownfish_name  = 'Open_InStream';
    my $underscore_name = lc($clownfish_name);
    my $lowerCamelCase  = $clownfish_name;
    $lowerCamelCase =~ s/_//g;
    $lowerCamelCase =~ s/^(.)/lc($1)/e;

AFAIK, SWIG can't do that.

Nevertheless, it would be a Good Thing if someone starts hacking with SWIG to
provide support for a language that otherwise wouldn't be there.  "Progress
not perfection", as Mike McCandless likes to say.

> In any case, I like this proposal, Marvin. 


> Tell me how I can help.

I would consider it a major recruiting success if you end up on the Lucy PMC.

  * You have extensive experience with open source software.
  * You've been involved with KinoSearch and Lucy for several years.
  * You have extensive experience with a different IR library -- SWISH --
    which will enrich your perspective when voting on policy.
  * I've trusted you to roll KinoSearch releases and they have all gone
    perfectly.  I expect that we can trust you to certify Lucy releases to
    meet Apache's standards as well.
  * Your written communication skills are top-notch.
  * You have a good mix of impatience and diplomacy.
  * Your project management skills are superior.

There are other things that you do well too, like portability hacking.  But
the combination of traits above is not easy to find.  So contribute whatever
you want -- you're a valuable member of the community regardless -- but in my
perfect world, you are on the PMC.  We are going to need competent,
knowledgeable PMC members in order to govern ourselves effectively, and for
the project's health we need to ensure that I am dispensible on the PMC just
as I must be for the code base.

If that interests you, it would be great if you would familiarize yourself
with Apache institutions.  Consider subscribing to general@incubator:
<> -- the debates there are very
informative!  Browse through the documentation at
<>, though if you're like me, it will take a while
to sink in.  And if you can spare a moment or two over the next week, let's
collaborate on an Incubator proposal via the Lucy wiki.  (; I know this is a
busy time -- life happens! ;)

I told the Lucene PMC that we would present a plan for Lucy's graduation to
general@lucene by this upcoming Friday, July 2, based on the Incubator
proposal template.  Instead, I think we should provide them with a draft of an
actual incubator proposal along with a short custom-tailored justification.

The page is up at <>.  The
original template document is at
<>; it's a better read because
it has links.

Marvin Humphrey

View raw message