lucy-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nathan Kurz <n...@verse.com>
Subject Re: [lucy-dev] OFFSET globals
Date Wed, 25 Apr 2012 22:27:16 GMT
On Wed, Apr 25, 2012 at 2:40 PM, Marvin Humphrey <marvin@rectangular.com> wrote:
> 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.

Yes, that does work much better.  I don't have a working development
machine right now, and was just browsing the online source.   I'll try
to rectify that when I have time.

> (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...)

Yes, this would be a great thing to do.  It seems likely that
Clownfish will experience some breakage when we use it a second time.
But if we can get to three:
http://lcsd05.cs.tamu.edu/slides/keynote.pdf ("if you write three").

>> 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. Lucy.pm gets loaded.
>    2. Lucy.pm 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
>       lucy_Err_init_class().
>
> Hope that helps.

Yes, very helpful.  That's essentially what I determined, but I got
lost around S_bequeath_methods.  It's difficult reading through the
sprintf()'s.

Going one layer deeper to the object code level, which symbols are we
currently using? I think I found where the OFFSETS come in, but I
haven't figured out how overrides are signalled.

> It would be a lot of work to get to the point where we have something which
> matches or improves on markmail.org -- 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 s.apache.org when I want to embed durable
> links in public emails which will be archived or issue-tracker comments) and
> markmail.org, it's hard to justify such an undertaking.

Very hard to justify having you spend your time on it, but if someone
else wanted to get _very_ familiar with Lucy and simultaneously give
something back to Apache it would be a great way to promote the
project.  :)

--nate

Mime
View raw message