lucy-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marvin Humphrey <>
Subject Re: [lucy-dev] OFFSET globals
Date Wed, 25 Apr 2012 21:40:09 GMT
On Wed, Apr 25, 2012 at 1:10 PM, Nathan Kurz <> wrote:
> On Tue, Apr 24, 2012 at 4:32 PM, Marvin Humphrey <> wrote:
>> The general solution is certainly for the upstream author to signal ABI
>> breakage via version number changes.  What I don't know how to do is automatic
>> detection of accidental or irresponsible ABI breakage -- we *have* to rely on
>> author-supplied version numbers.
> I'm catching up here, but I'm still feeling lost.  I've been reading
> the recent messages that I only skimmed, and browsing through the
> Clownfish source, but it feels like I'm still lacking some steps.

One technique which helps a little is to run the following commands from
within trunk/perl and then look at the files that CFC generates in ./autogen:

   perl Build.PL
   ./Build clownfish

The CFC source code is visually difficult to parse because C format strings
and sprintf invocations suck readability-wise.  The generated code is easier
to grok.

(It would be easier still if we had a smaller project to run CFC on.  Maybe a
single-parcel sample project with 3 or 4 .cfh files under clownfish/sample
would help.  But we still need to break out Lucy::Object* into Clownfish::*
for that to work...)

> I'm having trouble matching up the discussion here
> <>
> to the C code.

Not all of the proposals in that email have been implemented yet, FWIW.  The
method access macros have been updated, and the capitalization conventions for
method typedefs have been changed.  However, the capitalization conventions
for methods have not changed, and method-implementation functions have not
been changed to static visibility.

> I think I understand the finished layout, but is there an overview of how
> the bootstrapping works?

Here's how it works in the final product:

    1. gets loaded.
    2. invokes XSLoader::load() to load the DSO.
    3. The lucy_Lucy_bootstrap() function (which is defined in
       autogen/source/lucy_boot.c) gets invoked as part of the XS
       loading process.
    4. lucy_Lucy_bootstrap() runs lucy_bootstrap_parcel(), which is defined in
       autogen/source/parcel.c.  [After lucy_bootstrap_parcel() returns, it
       runs some hacks which preserve KinoSearch compatibility and then does
       some Perl-specific initialization of @ISA variables.]
    5. lucy_bootstrap_parcel() is where all the VTable bootstrapping stuff
       happens -- so that's probably what you want to look at.  After the
       VTable bootstrapping happens, the last thing lucy_bootstrap_parcel()
       does is run lucy_init_parcel() (which is defined in core/Lucy.c).
       lucy_init_parcel() runs 3 class-specific init functions:
       lucy_Bool_init_class(), lucy_Hash_init_class(), and

Hope that helps.

> It's sadly ironic, but it would be really helpful to have a better
> search tool for the Lucy source and mailing lists.   The Apache online
> tools for browsing the list archives and version control are clumsy,
> and Google has evolved so that I can no longer depend on it.  I
> realize it's as much my task as anyone else's, but using Lucy to
> improve the Apache tools might be a great way to showcase the project.

I tend to use for searching the Lucy lists.  It's
powered by Lucene, and the interface is pretty nice.

It would be a lot of work to get to the point where we have something which
matches or improves on -- most of it front-end web work rather
than Lucy-specific index design.  Between Apache's own archives (which I use
in conjunction with the shortener at when I want to embed durable
links in public emails which will be archived or issue-tracker comments) and, it's hard to justify such an undertaking.

Marvin Humphrey

View raw message