On Wed, Apr 25, 2012 at 2:40 PM, Marvin Humphrey <[email protected]> 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
