incubator-lucy-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marvin Humphrey <mar...@rectangular.com>
Subject Re: [lucy-dev] Ruby CFBind glue code
Date Sun, 15 Jan 2012 19:40:26 GMT
On Sat, Jan 14, 2012 at 10:17:01AM -0800, Nathan Kurz wrote:
> On Mon, Jan 9, 2012 at 1:12 PM, Marvin Humphrey <marvin@rectangular.com> wrote:
> > In Lucy's Perl bindings, these routines live in trunk/perl/xs/XSBind.*.
> > Eventually, this content should move under clownfish/, but for now, I think it
> > makes sense for the Ruby files to live at trunk/ruby/src/CFBind.*.
> 
> What's the rationale on waiting to move these to be under Clownfish?

FWIW, it's possible to move them now.  

Currently all C files under trunk/clownfish/ are part of the CFC compiler and
get linked into the monolithic Clownfish::CFC shared object -- which is used
while building Lucy, but not installed.  In contrast, all C files under
trunk/perl/ get linked into the monolithic Lucy shared object, along with
everything under trunk/core/.  Moving the XSBind.*/CFBind.* files under
trunk/clownfish/ would make things a little more complicated in the near term.

At some point in the future, we will be compiling a Clownfish shared object
which will consist of Clownfish::Obj, Clownfish::CharBuf, Clownfish::Hash,
etc.  It will be a dependency for Lucy, so unlike Clownfish::CFC, it will be
installed.  The content currently in XSBind.*/CFBind.* ultimately belongs
there.

The rationale for waiting is that whatever the merits of this refactoring
effort, it's probably not going to get us Ruby bindings any sooner.

> It will certainly work for Logan, but my instinct is that it will be
> easier to get other Ruby programmers involved if they can treat the CF
> bindings as a given, rather than something they have to wrestle with.

+1

> I'd suggest moving them now, and then moving the Perl bindings over as
> soon as the model is established.  Right now Clownfish is a
> significant hurdle to new programmers, and compartmentalizing might
> help overcome this.

OK, we can start by moving all classes under Lucy::Object:: underneath
Clownfish::, with the possible exceptions of I32Array and BitVector which
arguably belong under Lucy::Util::.

For esoteric technical reasons[1], I advocate leaving the files within core/
and trunk/perl/ (and soon trunk/ruby/) until we can actually compile a
seperate Clownfish shared object.  At that point, we can migrate everything
under trunk/clownfish/.

Marvin Humphrey

[1] We'll have to solve some symbol exporting issues that we've been able to
    cheat on so far by compiling everything into a monolithic shared object.
    We'll also have to decide what to do about Serialize() and Deserialize(),
    which currently use Lucy::Store::InStream and Lucy::Store::OutStream --
    will they move too? Will we refactor serialization?  Etc.


Mime
View raw message