lucy-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Torsten Curdt <tcu...@vafer.org>
Subject Re: [lucy-dev] building withOUT perl
Date Wed, 06 Jul 2011 22:22:28 GMT
>> Hm. So there would be a dedicated release dist per language binding.
>
> Not necessarily.
>
> There has to be a dedicated "downstream" release for each *packaging system*
> we might target -- such as CPAN, rubygems.org or PyPI -- because each insists
> on certain conventions regarding directory layout and metadata.
>
> I don't see why we would need a dedicated release dist for any language
> without an associated packaging system, though.  You can just build from the
> canonical Apache release artifacts, which is equivalent to building from a
> checkout of svn trunk.  That option is of course available for any supported
> binding language, regardless of the presence or absence of supplementary
> downstream dists.

I was more thinking along the lines of... what is a release of lucy then?
Does it contain the obj-c code, the ruby gem, python module, ... whatever?
Or how are user obtaining and using it?

>> > We're not quite at a place where adding a new binding is a turnkey process.
>> > Once our next release is done, I'm going to go back to working on
>> > <https://issues.apache.org/jira/browse/LUCY-142>, "Port Clownfish compiler
to
>> > C".  We're whittling down the barriers, inch by inch.
>>
>> Uff ... that sounds like quite a task.
>
> A lot of it is done.  It's also something I'm really enjoying working on.  :)

That's great then :-D

>> The perl/xs is the one and only "example-lang" implementation at this
>> stage IIUC?
>
> Correct.  There's now some code in trunk/ruby as well -- but it's in its
> earliest stages.

Yeah - there does not seem to be much more than a Rakefile.

> Perhaps follow along while the Ruby bindings get implemented over the next few
> months.

Will definitely lurk. Would be great to get the first non-perl language out.

>  Aside from Dave Balmain, the people who grok Clownfish and understand
> the rationale behind it the best appear to be those who have a significant
> amount of experience with Perl's C API, such as Peter, Joe and Nate.  I hope
> that once Clownfish is more cleanly separated from Perl and from Lucy's search
> functionality that others without such expertise will find it more
> approachable.

That would be great.

cheers,
Torsten

Mime
View raw message