Jon,
> So, I might caution that this runs the risk of introducing a whole bunch
> of complexity and dependency where we might not need more. We
> need better writing and a willingness to write more complete sentences
> with an eye toward understanding that the details are maybe not yet
> obvious
On Thu, Jan 18, 2018 at 2:32 AM, Ole Troan wrote:
> Hi Jon,
>
> I find embedded documentation (and excessive comments) problematic for
> that exact reason.
>
Absolutely agree 100%.
> We're never going to make them consistent.
>
Sadly, correct again.
> Stepping back a little; I think we agre
ary 18, 2018 3:33
> To: Jon Loeliger
> Cc: vpp-dev
> Subject: Re: [vpp-dev] Heads up: VPPAPIGEN rewrite
>
> Hi Jon,
>
> > Can we add to the "Future Plans" list?
> > I would like to see it draw a correlation between a message's actual
> > list of field
Hi Jon,
> Can we add to the "Future Plans" list?
> I would like to see it draw a correlation between a message's actual
> list of fields and the attempt at a documentation for those fields.
> Specifically, there always seems to be some discrepancy and it is
> hard to tell which to believe without
On Wed, Jan 17, 2018 at 2:25 AM, Ole Troan wrote:
> Hi there,
>
> For a while there has been some interest in making the API language more
> explicit.
> This is a rewrite of the vppapigen generator with support for services {}
> (like grpc), enums, output plugins, better error checking.
>
The ch
Hi there,
For a while there has been some interest in making the API language more
explicit.
This is a rewrite of the vppapigen generator with support for services {} (like
grpc), enums, output plugins, better error checking.
Currently supported is C/JSON output plugins.
It also removes the nee
