Re: license copyright patch to MELT for dual GPLv3+ GFDL1.2+
On Wed, Jun 09, 2010 at 12:11:01PM -0700, Mark Mitchell wrote:
I think that literate programming approaches (whether the full Knuth
version, or the more mild JavaDoc version, or auto-extraction of
command-line options or whatever) are valuable. RMS, based on my
communications with him, is less convinced that they are valuable. I
think he agrees that his opinions of the technical merits shouldn't
override a consensus opinion of the developers, but it does influence
how hard he wants to work on changing the licensing regime, and it is a
legitimately hard problem to solve.
Meanwhile, I think we should try to make use of the fact that RMS is
permitting auto-generated reference documentation (which I have been
instructed not to call a manual) using JavaDoc/Doxygen tools. If we use
those tools, and demonstrate their value, we're then in a stronger
position to say how generation of actual manuals is important.
What I don't understand is what is so special about Doxygen.
MELT is a lispy dialect, and is bootstrapped in the sense of being its
own tranlator.
Could you understand that for me Basile (who don't know doxygen's
internals), since I am MELT designer implementor, and since MELT
translator (i.e. the code generating C code from MELT source) has been
implemented by me Basile in MELT, it is much easier to implement MELT
documentation's generator in MELT than to patch Doxygen for that
purpose.
So why using Doxygen is permitted for documentation generation, while
using a GCC plugin or branch (this is what MELT is) is prohibited?
Could people understand at least my misunderstanding? Why generating
documentation with Doxygen (probably not a GNU, FSF copyrighted,
software like GCC is) is permitted, while generating the documentation
of a branch of GCC [=MELT] with itself, [MELT=] a branch or plugin of GCC is
prohibited?
Sorry, I don't understand the logic here. And I am not sure it is only a
cultural (I am French, not US American) or language issue (I am not a
native English speaker).
OF course, I don't claim that MELT documentation generating mode is as
powerful as complete as Doxygen. It is actally a very simple hack
(only generating .texi format) much less powerful than doxygen.
Please explain me why using Doxygen is permitted, while using a branch
of GCC is not permitted, to generate that same's branch documentation.
Sorry, I don't understand the logic.
Please also explain who should I contact, and how? Please also explain
how the GNU Emacs is generated. I guess it is by a software of the GNU
emacs package.
Cheers.
PS. What I probably did understand or at least guess, is that to be
permitted to redistribute the generated documention of MELT, I'll have
to wait many [dozens?] years. I probably will lose interest in GCC by
then, or perhaps even I'll be already dead (and perhaps RMS also, since
he is born in 1953, and I was born in 1959). I even could imagine that
GCC won't be very relevant by then (hint: the SIGPLAN programming
language award went to a C compiler which is free -at least for some
definition of free- but not GCC).
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basileatstarynkevitchdotnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mines, sont seulement les miennes} ***
Re: license copyright patch to MELT for dual GPLv3+ GFDL1.2+
Basile Starynkevitch wrote: Meanwhile, I think we should try to make use of the fact that RMS is permitting auto-generated reference documentation (which I have been instructed not to call a manual) using JavaDoc/Doxygen tools. If we use those tools, and demonstrate their value, we're then in a stronger position to say how generation of actual manuals is important. What I don't understand is what is so special about Doxygen. Basile, there's nothing special about Doxygen. It's just an example of a tool that generates cross-reference information. I think you can reasonably distinguish the kind of thing that comes out of JavaDoc or Doxygen from a manual. If you don't know what kind of output JavaDoc and Doxygen produce, please go read about them for a while and look at some examples. -- Mark Mitchell CodeSourcery m...@codesourcery.com (650) 331-3385 x713
Re: license copyright patch to MELT for dual GPLv3+ GFDL1.2+
On Wed, Jun 09, 2010 at 10:46:26PM +0200, Basile Starynkevitch wrote:
Please also explain who should I contact, and how? Please also explain
how the GNU Emacs is generated. I guess it is by a software of the GNU
emacs package.
Sorry for the typo, I mean
how the GNU emacs documentation is generated
GNU emacs has documentation annotations, like MELT has (I copied the
idea from Emacs)!
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basileatstarynkevitchdotnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mines, sont seulement les miennes} ***
Re: license copyright patch to MELT for dual GPLv3+ GFDL1.2+
On Wed, Jun 09, 2010 at 01:57:03PM -0700, Mark Mitchell wrote:
Basile Starynkevitch wrote:
Meanwhile, I think we should try to make use of the fact that RMS is
permitting auto-generated reference documentation (which I have been
instructed not to call a manual) using JavaDoc/Doxygen tools. If we use
those tools, and demonstrate their value, we're then in a stronger
position to say how generation of actual manuals is important.
What I don't understand is what is so special about Doxygen.
Basile, there's nothing special about Doxygen. It's just an example of
a tool that generates cross-reference information. I think you can
reasonably distinguish the kind of thing that comes out of JavaDoc or
Doxygen from a manual. If you don't know what kind of output JavaDoc
and Doxygen produce, please go read about them for a while and look at
some examples.
I did read many doxygen generated documentation, and in my eyes, the
documentation generated by MELT is ofvery similar nature: also, the
cross-reference, inheritance, etc.
The MELT generated documentation was heavily inspired by what Emacs
Doxygen are doing.
So I still don't understand why generating cross-reference documentation
with Doxygen for C++ code is permitted, while generating cross-reference
documentation witb ÂMELT for MELT code is prohibited.
Did *you* have a tiny look at the documentation of MELT generated by MELT?
http://gcc.gnu.org/wiki/MELT%20tutorial?action=AttachFiledo=viewtarget=GCC-MELT--gcc-internals-snapshot.pdf
Cheers!
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basileatstarynkevitchdotnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mines, sont seulement les miennes} ***
Re: license copyright patch to MELT for dual GPLv3+ GFDL1.2+
Basile Starynkevitch wrote: So I still don't understand why generating cross-reference documentation with Doxygen for C++ code is permitted, while generating cross-reference documentation witb ÂMELT for MELT code is prohibited. As far as I know, nobody said that. http://gcc.gnu.org/wiki/MELT%20tutorial?action=AttachFiledo=viewtarget=GCC-MELT--gcc-internals-snapshot.pdf That contains much more than cross-reference documentation! -- Mark Mitchell CodeSourcery m...@codesourcery.com (650) 331-3385 x713
