[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/
- [task #16067] Submission of Dezyne, (continued)
- [task #16067] Submission of Dezyne, Alfred M. Szmidt, 2021/12/06
- [task #16067] Submission of Dezyne, Jan Nieuwenhuizen, 2021/12/06
- [task #16067] Submission of Dezyne, Jan Nieuwenhuizen, 2021/12/07
- [task #16067] Submission of Dezyne, Ineiev, 2021/12/07
- [task #16067] Submission of Dezyne, Jan Nieuwenhuizen, 2021/12/07
- [task #16067] Submission of Dezyne, Jan Nieuwenhuizen, 2021/12/07
- [task #16067] Submission of Dezyne, Ineiev, 2021/12/07
- [task #16067] Submission of Dezyne, Jan Nieuwenhuizen, 2021/12/07
- [task #16067] Submission of Dezyne, Jan Nieuwenhuizen, 2021/12/09
- [task #16067] Submission of Dezyne, Jan Nieuwenhuizen, 2021/12/09
- [task #16067] Submission of Dezyne,
Ineiev <=
- Re: [task #16067] Submission of Dezyne, Alfred M. Szmidt, 2021/12/06