jerry gay wrote:
i'd rather see FUNCDOC stay. it allows us to specify just the parts of
the documentation that we need to, and generates the rest from the
source. this allows us to skip
=item void myfunc(does_not, match, source)
because it's generated from the source, so is always up to date.
On 9/15/07, Allison Randal <[EMAIL PROTECTED]> wrote:
> Paul Cochrane wrote:
> > =item Per-entity comments
> >
> > I've noticed in the source lots of C sections in C-language
> > code. Shouldn't this just be plain pod as mentioned in PDD07? This
> > would mean that more docs are picked up when we
Paul Cochrane wrote:
=item *
Under "Language Standards and Portability" there is the todo item:
{{ RT#45359: Enumerate all other non-C89 assumptions that Parrot
depends on. }}
Currently we have such assumptions as:
In addition, C code may assume that any pointer value can be coerced to
Hi everyone!
Continuing with the theme of discussing the PDDs, here is a starter
email to kick off discussion of PDD07 - the coding standards of
Parrot. Coding standards can often be a really touchy subject, so I
hope we can amicably come to consensus decisions about the various
points I'm about
