Thanks - this help is a great addition - i vote doxygen comment method -
btw I meant to say 'Please say No'just 'say no' missed the inflection of
I never got use to info over man and certainly not doxygen over latex :)
On Tue, 18 Apr 2017 20:29:38 +0200
Juergen Sauermann wrote:
>
Hi,
No. This is just to be able to use the same comments in Doxygen
and in the )HELP command of GNU APL.
Likewise, if we go for toronto toolkit then we would be able to use the same comments in
the toronto toolkit and
in the )HELP command of GN
will i have to install doxygen to use this?? say no
On Tue, 18 Apr 2017 19:56:25 +0200
Juergen Sauermann wrote:
> Hi David,
>
> I believe the initial question was whether we should adopt the Doxygen style
> of comments or
> the toronto toolkit style.
>
> So this means do we prefer to be lo
Hi David,
I believe the initial question was whether we should adopt the
Doxygen style of comments or
the toronto toolkit style.
So this means do we prefer to be locked into Doxygen or into the
toronto toolkit?
We could of course adopt a thi
This all looks great btw - great addition to system
On Tue, 18 Apr 2017 10:49:28 +0800
Elias Mårtenson wrote:
> Hello David,
>
> Having a standardised format is what makes this so useful. The whole point
> of this is to make sure that everybody uses the same convention so
> third-party tools c
The last thing we want is to add one more implementation dependent
feature to an already fractured APL ecosystem.
If our developers prefer a set of strict rules of doxygen style
documents, you can make your own simple documentation list with
awk. The following one liner should do the trick. I've
On 18 April 2017 at 23:57, David B. Lamkins wrote:
>
> Is "all the leading comment lines until the first non-comment line" that
> complex? I'm just trying to be precise about what's a "header comment" and
> what's not.
>
This special comment describes what the function does, in a format suitable
On Tue, Apr 18, 2017 at 10:49:28AM +0800, Elias Mårtenson wrote:
> Hello David,
>
> Having a standardised format is what makes this so useful. The whole point of
> this is to make sure that everybody uses the same convention so third-party
> tools can integrate with the system. If everybody “adopt
I'm not sure that's even a different point of view. What you listed is
common sense and I hope everybody who is developing code for more than one
person abides by it.
It also doesn't conflict with the idea of docstrings. What the double lamp
signifies is the difference between documentation explai
Actually for a slightly different POV…
Some criteria for writing maintainable APL from my days at Sharp:
a) Extracting only the comments should allow a competent APL’er to provide the
missing code.
b) No horrendous one-liners
c) Code and comments may not exceed a single 8.5 x 11 sheet of paper.
Hi,
as some of you may have noticed in the GNU APL source code, I am a
big fan of Doxygen.
The ⍝⍝ idea adopts the practice of Doxygen to repeat the last
character of comment markers
in a language (Doxyge supports several languages today, but not
Hi Xiao-Yong.
thanks, fixed in SVN 924. ⎕ and ⍞ are now listed as system
variables.
/// Jürgen
On 04/17/2017 11:54 PM, Xiao-Yong Jin
wrote:
If you haven't added those, the quads are missing too, ⌷ ⎕ ⍞.
In addition, the resul
12 matches
Mail list logo
