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/07/31 20:57:34 UTC
[lucy-dev] Clownfish C blocks and parcel headers
Hello lucy-dev,
Travis CI discovered another build failure:
https://travis-ci.org/theory/lucy/jobs/9451089
The reason is that the order of #includes in the autogenerated file callbacks.h is random, and for this build, the first included file seems to be Lucy/Test/Store/TestFolderCommon.h. The corresponding .cfh file happens to start with a Clownfish "C block" which relies on the forward declarations in lucy_parcel.h which has not been included yet. I can see the following solutions:
1. Generate an #include directive for every .cfh parcel definition.
2. Always include the parcel.h files for all dependencies of a generated header file first.
I prefer the first solution. Thoughts?
Nick
Re: [lucy-dev] Clownfish C blocks and parcel headers
Posted by "David E. Wheeler" <da...@justatheory.com>.
On Aug 1, 2013, at 12:35 AM, Nick Wellnhofer <we...@aevum.de> wrote:
> This should work but I prefer the more general fix that I made in commit cb609f42. There might be other C blocks which could cause similar problems.
I pushed the latest changes, up to cb609f42, and now all the build pass on Travis CI.
https://travis-ci.org/theory/lucy/builds/9734794
Woo!
Best,
David
Re: [lucy-dev] Clownfish C blocks and parcel headers
Posted by Nathan Kurz <na...@verse.com>.
On Wed, Jul 31, 2013 at 4:10 PM, Marvin Humphrey <ma...@rectangular.com> wrote:
> * When the need for a feature arises, first we find a way to hack in support
> for it using a C block.
> * Once a feature has proved its utility, see if it makes sense to implement
> it in the header language proper.
I think that's a wonderful philosophy, both here and more generally.
Having an 'official' unofficial way of doing things as a sandbox for
development is a design concept that seems underexplored.
--nate
Re: [lucy-dev] Clownfish C blocks and parcel headers
Posted by Marvin Humphrey <ma...@rectangular.com>.
On Wed, Jul 31, 2013 at 3:35 PM, Nick Wellnhofer <we...@aevum.de> wrote:
> On Jul 31, 2013, at 23:50 , Marvin Humphrey <ma...@rectangular.com> wrote:
>
>> C blocks are a heinous hack that I wish we could do without. For now, they're
>> an essential safety valve for a few features that are too complex to
>> implement directly in the Clownfish header language, but a part of me would
>> like to have them undocumented in the initial release in the faint hope that
>> we could get away with removing them eventually. I anticipate that
>> supporting them will constrain our ability to evolve Clownfish.
>
> I would certainly be nice to get rid of C blocks, but I think every
> non-trivial Clownfish project will need them.
I suspect you're right about that. Perhaps it would be better to invert my
thinking and conceptualize C blocks as the first line of defense against
adding complexity to the Clownfish header language:
* When the need for a feature arises, first we find a way to hack in support
for it using a C block.
* Once a feature has proved its utility, see if it makes sense to implement
it in the header language proper.
> The problem is that the order
> of declarations and definitions is important in header files and C blocks
> provide a straight-forward way guarantee this order.
The way I see it, supporting C blocks gives us things such as preprocessor
macros and conditionals; full inline function definitions; and typedef, struct
and union declarations. Maybe we want to add some of those later, but its nice
that we don't have to rush out syntax for them yet.
> This should work but I prefer the more general fix that I made in commit
> cb609f42. There might be other C blocks which could cause similar problems.
OK, works for me. (We'll probably want to watch that we don't lard up those
parcel.h files now!) Thanks for attending to the problem.
Marvin Humphrey
Re: [lucy-dev] Clownfish C blocks and parcel headers
Posted by Nick Wellnhofer <we...@aevum.de>.
On Jul 31, 2013, at 23:50 , Marvin Humphrey <ma...@rectangular.com> wrote:
> C blocks are a heinous hack that I wish we could do without. For now, they're
> an essential safety valve for a few features that are too complex to
> implement directly in the Clownfish header language, but a part of me would
> like to have them undocumented in the initial release in the faint hope that
> we could get away with removing them eventually. I anticipate that
> supporting them will constrain our ability to evolve Clownfish.
I would certainly be nice to get rid of C blocks, but I think every non-trivial Clownfish project will need them. The problem is that the order of declarations and definitions is important in header files and C blocks provide a straight-forward way guarantee this order.
> I think the fix in this particular case is minimal. This ought to do it,
> right?
>
> --- a/core/Lucy/Test/Store/TestFolderCommon.cfh
> +++ b/core/Lucy/Test/Store/TestFolderCommon.cfh
> @@ -17,7 +17,7 @@
> parcel TestLucy;
>
> __C__
> -typedef lucy_Folder*
> +typedef struct lucy_Folder*
> Lucy_TestFolderCommon_Set_Up_t(void);
> typedef void
> Lucy_TestFolderCommon_Tear_Down_t(void);
This should work but I prefer the more general fix that I made in commit cb609f42. There might be other C blocks which could cause similar problems.
Nick
Re: [lucy-dev] Clownfish C blocks and parcel headers
Posted by Marvin Humphrey <ma...@rectangular.com>.
On Wed, Jul 31, 2013 at 11:57 AM, Nick Wellnhofer <we...@aevum.de> wrote:
> Travis CI discovered another build failure:
>
> https://travis-ci.org/theory/lucy/jobs/9451089
>
> The reason is that the order of #includes in the autogenerated file
> callbacks.h is random, and for this build, the first included file seems to
> be Lucy/Test/Store/TestFolderCommon.h. The corresponding .cfh file happens
> to start with a Clownfish "C block" which relies on the forward declarations
> in lucy_parcel.h which has not been included yet. I can see the following
> solutions:
>
> 1. Generate an #include directive for every .cfh parcel definition.
>
> 2. Always include the parcel.h files for all dependencies of a generated
> header file first.
>
> I prefer the first solution. Thoughts?
C blocks are a heinous hack that I wish we could do without. For now, they're
an essential safety valve for a few features that are too complex to
implement directly in the Clownfish header language, but a part of me would
like to have them undocumented in the initial release in the faint hope that
we could get away with removing them eventually. I anticipate that
supporting them will constrain our ability to evolve Clownfish.
I think the fix in this particular case is minimal. This ought to do it,
right?
--- a/core/Lucy/Test/Store/TestFolderCommon.cfh
+++ b/core/Lucy/Test/Store/TestFolderCommon.cfh
@@ -17,7 +17,7 @@
parcel TestLucy;
__C__
-typedef lucy_Folder*
+typedef struct lucy_Folder*
Lucy_TestFolderCommon_Set_Up_t(void);
typedef void
Lucy_TestFolderCommon_Tear_Down_t(void);
I don't think we should go out of our way to accommodate C blocks at all.
Experts only, and only when there's no other recourse.
Marvin Humphrey