You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lucy.apache.org by Nick Wellnhofer <we...@aevum.de> on 2013/12/15 15:36:52 UTC

[lucy-dev] Todo list for Clownfish release

Lucifers,

I’d like to compile a list of things that still have to be done before we can release Clownfish as a separate product (and probably Lucy 0.4 in the process). Here are my plans:

* Explicit dependencies for Clownfish parcels

CFC parcels should declare their dependencies on other parcels in the .cfp JSON files. Currently, the dependencies are inferred by looking at all the .cfh files of a parcel. This works nicely but with an explicit list, we can avoid to process every .cfh file in the include directories. It would also be nice to have versioned dependencies.

* Better handling of C flags in the build process

The generated C code can be compiled without C99 flags. Also, the flags for CFP_ defines should be added automatically.

* Review Clownfish API

The Clownfish API needs to be reviewed. Public methods should be identified.

* Finish Clownfish documentation

Most of the documentation should already be there but it still needs to be reviewed. Only the Clownfish compiler is still undocumented. I started a branch “cfc-pod” quite a while ago which tries to generate some documentation from the docucomments in the C headers.

* Separate tests

The test suites should be separated from the main binaries. This shouldn’t be too hard for the C library but I’ve been racking my brain finding a nice way to do this for the Perl bindings. I somehow want to avoid to create a completely separate project tree for the test suites but I don’t see a way around that.

Do you have any comments or additions?

Nick


Re: [lucy-dev] Todo list for Clownfish release

Posted by Nick Wellnhofer <we...@aevum.de>.
On Dec 16, 2013, at 04:58 , Marvin Humphrey <ma...@rectangular.com> wrote:

> Perhaps we might triage away these items for later?
> 
>> * Better handling of C flags in the build process

I already started to work on this but currently I’m blocking on the Lucy/Clownfish separation of the Perl build.

>> * Explicit dependencies for Clownfish parcels

I think this would be nice to have before release, at least in a rudimentary form. For example, if the necessary Clownfish headers for a project aren’t found, the following happens right now:

    $ make
    cfc --source=../core --dest=autogen --header=cfc_header
    No class found for type 'String'
    make: *** [autogen] Error 1

This doesn’t really help to figure out what went wrong. If we had explicit dependencies, the Clownfish compiler would notice that Clownfish.cfp is required but missing and print a better error message:

    Parcel ‘Clownfish’ not found in Clownfish include directories:
    (list of include directories)

We could also run cfc in a ‘probe’ mode during configuration which simply checks for the .cfp file of a parcel and all its dependencies:

    cfc --probe-parcel Clownfish

If this fails, we could point the user to the INSTALL file. For now, it might be enough to implement probes for a single parcel without dependency checks. This should be really easy.

>> * Separate tests

Yes, this can be put off.

> Here are some items I suggest we add to the TODO list:
> 
> *   Develop a plan for how we'll evolve the API after launch.  (Language Spec
>    for Clownfish?  Backwards compatibility?  Avoiding bloat characteristic of
>    Apache-style governance?  Clownfish Enhancement Proposals approved by the
>    PMC a la Python PEPs?)
> *   Develop a marketing strategy.  (Website?  Whitepaper?  Conference talks?
>    Logo?  Incubator?  Who is the target market and how will we reach out?)
> *   Review the lucy-dev list archives for technical concerns and open a bunch
>    of tickets.
> *   Clownfish Tutorial.

+1 to all of these.

Nick


Re: [lucy-dev] Todo list for Clownfish release

Posted by Marvin Humphrey <ma...@rectangular.com>.
On Sun, Dec 15, 2013 at 6:36 AM, Nick Wellnhofer <we...@aevum.de> wrote:

> I’d like to compile a list of things that still have to be done before we
> can release Clownfish as a separate product (and probably Lucy 0.4 in the
> process).

Great stuff, thank you for coming up with the list!

> Do you have any comments or additions?

Perhaps we might triage away these items for later?

    > * Better handling of C flags in the build process
    > * Explicit dependencies for Clownfish parcels
    > * Separate tests

I think these are more urgent:

    > * Review Clownfish API
    > * Finish Clownfish documentation

My rationale for getting the APIs reviewed is that we want them as simple and
perfected as possible before they get locked in and become costly to change
later.  The documentation is important because it makes Clownfish more
user-friendly and attractive to newcomers.

In contrast, for the other three, there is no controversy over how to resolve
them.  The C flag handling and separate tests are bugfixes.  The .cfp
dependency specification is a feature enhancement.

Another similar item I'd like to put off is fixing using dots as separators
instead of double colons.  I think everybody will hate double colons.  That's
a nice excuse to break back compat later. ;)

Here are some items I suggest we add to the TODO list:

*   Develop a plan for how we'll evolve the API after launch.  (Language Spec
    for Clownfish?  Backwards compatibility?  Avoiding bloat characteristic of
    Apache-style governance?  Clownfish Enhancement Proposals approved by the
    PMC a la Python PEPs?)
*   Develop a marketing strategy.  (Website?  Whitepaper?  Conference talks?
    Logo?  Incubator?  Who is the target market and how will we reach out?)
*   Review the lucy-dev list archives for technical concerns and open a bunch
    of tickets.
*   Clownfish Tutorial.

I'll soon be stepping down from the Incubator PMC Chair position which has
occupied a lot of my time over the last six months.  It's been intense, but
I've accomplished everything that I set out to, and it feels good to have
given back to Apache and the Incubator.  With that behind me, I'm excited to
rev up my contributions here once again!

Marvin Humphrey