effort

[Peter Karman <pe...@peknet.com>]

I have some time. How can I help?

-- 
Peter Karman  .  http://peknet.com/  .  peter@peknet.com

Re: effort

[Nathan Kurz <na...@verse.com>]

On Fri, Nov 20, 2009 at 8:19 PM, Marvin Humphrey <ma...@rectangular.com> wrote:
> The goal is to have you and Nate to acquire a sense of mastery over the
> Charmonizer layer, while reducing the effort that others will have to expend
> in the future to acquire the same sense of mastery.

I've been running busy this week, but will try to get to my tiny chunk
over the weekend.  Seems like a good plan in general.

--nate

Re: [Lucy] Re: effort

[Marvin Humphrey <ma...@rectangular.com>]

On Sun, Nov 22, 2009 at 09:55:13PM -0600, Peter Karman wrote:

> > Task # 2:

> I'd be happy to work on this next, as long as it won't step on the other
> refactoring going on.

Go for it.

There's other stuff I want to do in Charmonizer, but I got the biggest piece
out of the way and I'll go work elsewhere for a while.  

The METAQUOTE-removal stuff that Nate's doing is pretty localized to specific
code blocks.  If conflicts occur, they won't be hard to resolve.

Marvin Humphrey

Re: [Lucy] Re: effort

[Peter Karman <pe...@peknet.com>]

Marvin Humphrey wrote on 11/20/09 10:19 PM:

> Task # 2:
> 
>     Again in core Lucy, function names in .c files always use "short names"
>     whenever the "LUCY_USE_SHORT_NAMES" macro is in effect -- e.g. we use
>     "Sort_mergesort" rather than "lucy_Sort_mergesort".  
>     
>     Within Charmonizer, we should be consistent about using short names
>     everywhere the "CHAZ_USE_SHORT_NAMES" macro is in effect, but currently
>     there are lots of places that we don't -- e.g. we use "chaz_Test_plan"
>     rather than "Test_plan" within charmonizer/src/Charmonizer/Test.charm:
> 
>      void
>     -chaz_Test_plan(TestBatch *batch)
>     +Test_plan(TestBatch *batch)
>      {
>          printf("1..%u\n", batch->num_tests);
>      }
> 
>     To see a list of offenders, run the following command from trunk/:
> 
>     find charmonizer/src -print | grep "\.c" | grep -v svn | xargs grep chaz_[A-Z]
> 

I'd be happy to work on this next, as long as it won't step on the other
refactoring going on.


-- 
Peter Karman  .  http://peknet.com/  .  peter@peknet.com

Re: [Lucy] Re: [Lucy] Re: [Lucy] Re: effort

[Peter Karman <pe...@peknet.com>]

Marvin Humphrey wrote on 11/20/09 11:35 PM:
> On Fri, Nov 20, 2009 at 09:23:14PM -0800, Marvin Humphrey wrote:
> 
>>> Or would you prefer I create a JIRA ticket, etc.?
>> Please open a JIRA issue.  When you submit patches via JIRA, your intentions
>> with the donation to the ASF are clear 
> 
> Well, I suppose your intentions were pretty clear regardless.  Perhaps I could
> just have committed this, because by sending the patch to the list with the
> obvious intent of including it in the project you grant an implied license
> for use to the ASF.  
>     
> But I'm just mimicing what the other lucene.apache.org projects do: almost
> everything, and everything not originating with a committer that has a CLA
> (Contributor License Agreement) on file with Apache, goes through JIRA.
> 

No worries. When in Rome and all that.


-- 
Peter Karman  .  http://peknet.com/  .  peter@peknet.com

Re: [Lucy] Re: [Lucy] Re: effort

[Marvin Humphrey <ma...@rectangular.com>]

On Fri, Nov 20, 2009 at 09:23:14PM -0800, Marvin Humphrey wrote:

> > Or would you prefer I create a JIRA ticket, etc.?
> 
> Please open a JIRA issue.  When you submit patches via JIRA, your intentions
> with the donation to the ASF are clear 

Well, I suppose your intentions were pretty clear regardless.  Perhaps I could
just have committed this, because by sending the patch to the list with the
obvious intent of including it in the project you grant an implied license
for use to the ASF.  
    
But I'm just mimicing what the other lucene.apache.org projects do: almost
everything, and everything not originating with a committer that has a CLA
(Contributor License Agreement) on file with Apache, goes through JIRA.

Marvin Humphrey

Re: [Lucy] Re: [Lucy] Re: [Lucy] Re: effort

[Peter Karman <pe...@peknet.com>]

Marvin Humphrey wrote on 11/20/09 11:23 PM:
> On Fri, Nov 20, 2009 at 11:04:28PM -0600, Peter Karman wrote:
> 
>> Patch attached.
> 
> Groovy.  That was fast.  :)
> 

speed possible only because there were good tests already in place. I sleep
better and code faster when there is good test coverage. ;)


-- 
Peter Karman  .  http://peknet.com/  .  peter@peknet.com

Re: [Lucy] Re: [Lucy] Re: effort

[Marvin Humphrey <ma...@rectangular.com>]

On Fri, Nov 20, 2009 at 11:04:28PM -0600, Peter Karman wrote:

> Patch attached.

Groovy.  That was fast.  :)

> Or would you prefer I create a JIRA ticket, etc.?

Please open a JIRA issue.  When you submit patches via JIRA, your intentions
with the donation to the ASF are clear because you have to choose one of these
two radio buttons:

 [ ] Attachment not intended for inclusion
 [ ] Grant license to ASF for inclusion in ASF works (as per the Apache
     License §5) 

Also, it won't be a big deal in this case, but JIRA makes it easy to iterate
on multiple patches via its "Attach Files" feature.

Marvin Humphrey

Re: [Lucy] Re: [Lucy] Re: effort

[Peter Karman <pe...@peknet.com>]

Peter Karman wrote on 11/20/09 10:23 PM:
> Marvin Humphrey wrote on 11/20/09 10:19 PM:
> 
>> The two tasks I'd suggest are superficial style changes which will serve to
>> familiarize you with most of Charmonizer's modules.
>>
>> Task #1:
>>
>>     The core Lucy code base has adopted a naming convention taken from the Perl
>>     code base: the names of all static functions are prepended with "S_".
>>     Charmonizer predates the adoption of this convention; we should switch
>>     over to it:
>>
>>      /* Write the "_charm.h" file used by every probe.
>>       */
>>      static void
>>     -write_charm_h();
>>     +S_write_charm_h();
> 
> I'll work on this first. Boring is fine if it moves us all along. :)
> 

Patch attached.

Or would you prefer I create a JIRA ticket, etc.?



-- 
Peter Karman  .  http://peknet.com/  .  peter@peknet.com

Re: [Lucy] Re: effort

[Peter Karman <pe...@peknet.com>]

Marvin Humphrey wrote on 11/20/09 10:19 PM:

> 
> The two tasks I'd suggest are superficial style changes which will serve to
> familiarize you with most of Charmonizer's modules.
> 
> Task #1:
> 
>     The core Lucy code base has adopted a naming convention taken from the Perl
>     code base: the names of all static functions are prepended with "S_".
>     Charmonizer predates the adoption of this convention; we should switch
>     over to it:
> 
>      /* Write the "_charm.h" file used by every probe.
>       */
>      static void
>     -write_charm_h();
>     +S_write_charm_h();

I'll work on this first. Boring is fine if it moves us all along. :)

-- 
Peter Karman  .  http://peknet.com/  .  peter@peknet.com

Re: effort

[Marvin Humphrey <ma...@rectangular.com>]

On Fri, Nov 20, 2009 at 08:17:55PM -0600, Peter Karman wrote:

> I have some time. How can I help?

I'd say that the easiest place to make a difference right away would be
simplification of Charmonizer.  There are lots of other tasks you're qualified
to take on, but they require more up-front investment.  Furthermore, if you
grok Charmonizer, it will be slightly easier to grok other parts of Lucy.

Conceptually, Charmonizer is just "using C to configure C".  It's supposed to
be easy to understand.  

Any place where Charmonizer's architecture *isn't* easy to understand is a
design flaw.

The goal is to have you and Nate to acquire a sense of mastery over the
Charmonizer layer, while reducing the effort that others will have to expend
in the future to acquire the same sense of mastery.  

I don't expect that major changes will be necessary, but if you come up with
something and you can persuade us that it makes things easier to grok, so be
it.

The two tasks I'd suggest are superficial style changes which will serve to
familiarize you with most of Charmonizer's modules.

Task #1:

    The core Lucy code base has adopted a naming convention taken from the Perl
    code base: the names of all static functions are prepended with "S_".
    Charmonizer predates the adoption of this convention; we should switch
    over to it:

     /* Write the "_charm.h" file used by every probe.
      */
     static void
    -write_charm_h();
    +S_write_charm_h();

Task # 2:

    Again in core Lucy, function names in .c files always use "short names"
    whenever the "LUCY_USE_SHORT_NAMES" macro is in effect -- e.g. we use
    "Sort_mergesort" rather than "lucy_Sort_mergesort".  
    
    Within Charmonizer, we should be consistent about using short names
    everywhere the "CHAZ_USE_SHORT_NAMES" macro is in effect, but currently
    there are lots of places that we don't -- e.g. we use "chaz_Test_plan"
    rather than "Test_plan" within charmonizer/src/Charmonizer/Test.charm:

     void
    -chaz_Test_plan(TestBatch *batch)
    +Test_plan(TestBatch *batch)
     {
         printf("1..%u\n", batch->num_tests);
     }

    To see a list of offenders, run the following command from trunk/:

    find charmonizer/src -print | grep "\.c" | grep -v svn | xargs grep chaz_[A-Z]

If you aren't interested in working on Charmonizer, we'll still be able to
find things to do.  However, the things we need most right now are boring,
somewhat more difficult, and offer little immediate gratification.  Most of my
time these days goes into porting KS's test code to C and increasing test
coverage.  Simultaneously, I'm removing kludges and fixing known bugs.  If
there's a module you want to do that for, let me know.

If nothing has piqued your interest so far, please pick a part of Lucy that
interests you, without regard to whether it advances us towards our primary
goal of an initial Lucy release.  I'll iterate over proposed changes with you
until we arrive at a patch that's suitable for Lucy -- just as we've done in
the past with KS.

Cheers,

Marvin Humphrey