savannah-register-public
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[task #16067] Submission of Dezyne


From: Ineiev
Subject: [task #16067] Submission of Dezyne
Date: Mon, 13 Dec 2021 05:28:39 -0500 (EST)
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:95.0) Gecko/20100101 Firefox/95.0

Follow-up Comment #26, task #16067 (project administration):

[comment #24 comment #24:]
> Using @include assumes texinfo format.  The texinfo format does not
> recognize "//" as a comment marker, and needs escaping for braces "{"
> and "}".  For example:
> 
>     // header
>     // comment
>     interface {
>     ..
>     }
> 
> becomes
> 
>     @c header
>     @c comment
>     interface @{
>     ..
>     @}

...or it becomes

     @c header
     @verbatim
     // comment
     interface {
     ..
     }
     @end verbatim

> which makes the example unusable for the Dezyne tooling.  While that
> is "only" very inconvenient for us maintainers, it is terrible for our
> users who want to try such an example out.

A one-liner like sed '/^@\(verbatim\|end verbatim\)/d;s,^@c,//,' will convert
it to a usable form which you can put to $docdir/examples, so this detail is
completely up to you.

Even an hopeless fool like your humble servant can easily make a build system
that will choke on the word 'Copyright' in any file in the archive; if such
things counted, the guidelines would mean very little.  The point is, I
shouldn't do such things.

> > https://www.gnu.org/prep/maintain/html_node/Copyright-Notices.html:
> >
> >> Any file more than ten lines long is nontrivial for this purpose.
> 
> As Alfred also mentioned in #17, your reading of the requirements is
> far to strict and not what is intended.

It matters little what Alfred mentioned, it doesn't matter very much what
Ineiev said, what matters is what the guidelines tell; the guidelines are
pretty clear and unambiguous.

> If you know the Dezyne language, there is really no other way to
> express what is explained in the text than in these three examples.

Yes, there are.

> Also, whitespace and other trivial lines with only parentheses or
> braces must not be counted.  The first example has, indeed eleven
> lines and the second one is seven lines.  Both are trivial.

It doesn't read, 'ten _non-trivial_ lines'---it reads, _'Any_ file more than
ten lines long'.

Empty lines serve their purpose---they provide visual separation, so they do
contribute, even if less than other lines.

Now, I wouldn't raise this issue if it were about files that are dozen lines
long or so, but join.dzn is clearly longer, even if we drop lines less than 5
non-blank characters long, so at any rate, some of these files definitely need
notices; therefore I suggest that you err on the side of copyrightability when
you add them, it won't be much extra work---if you do that at all.

    _______________________________________________________

Reply to this item at:

  <https://savannah.nongnu.org/task/?16067>

_______________________________________________
  Message sent via Savannah
  https://savannah.nongnu.org/




reply via email to

[Prev in Thread] Current Thread [Next in Thread]