[Rd] [PATCH] minor suggestions for R-ints manual

2013-10-12 Thread Scott Kostyshak
Attached is a patch with minor suggestions for the R-ints manual at
r64048. The most substantial change is the following:

 The top layer comprises the graphics subsystems. Although there is
-provision for 24 subsystems, after 6 years only two exist, `base' and
+provision for 24 subsystems, since 2001 only two exist, `base' and
 `grid'.

Is the year 2001 correct? I base it on the date of the commit that
introduced the "6 years" string and on the date of grid 0.1.

Scott


--
Scott Kostyshak
Economics PhD Candidate
Princeton University
Index: trunk/doc/manual/R-ints.texi
===
--- trunk/doc/manual/R-ints.texi(revision 64048)
+++ trunk/doc/manual/R-ints.texi(working copy)
@@ -462,7 +462,7 @@
 (which are 32 bits on all @R{} platforms).
 
 @item REALSXP
-@code{length}, @code{truelength} followed by a block of C @code{double}s
+@code{length}, @code{truelength} followed by a block of C @code{double}s.
 
 @item CPLXSXP
 @code{length}, @code{truelength} followed by a block of C99 @code{double
@@ -1330,7 +1330,7 @@
 The relationship between the pairs is similar: @code{warning} tries to
 fathom out a suitable call, and then calls @code{warningcall} with that
 call as the first argument if it succeeds, and with @code{call =
-R_NilValue} it is does not.  When @code{warningcall} is called, it
+R_NilValue} if it does not.  When @code{warningcall} is called, it
 includes the deparsed call in its printout unless @code{call =
 R_NilValue}.
 
@@ -2289,12 +2289,12 @@
 @file{src/main/names.c}: primitives have @samp{Y = 0} in the @samp{eval}
 field.
 
-There needs to an a @samp{\alias} entry in a help file in the @pkg{base}
+There needs to be a @samp{\alias} entry in a help file in the @pkg{base}
 package, and the primitive needs to be added to one of the lists at the
 start of this section.
 
 Some primitives are regarded as language elements (the current ones are
-listed above).  These need to be in added to two lists of exceptions,
+listed above).  These need to be added to two lists of exceptions,
 @code{langElts} in @code{undoc()} (in file
 @file{src/library/tools/R/QC.R}) and @code{lang_elements} in
 @file{tests/primitives.R}.
@@ -2778,7 +2778,7 @@
 
 
 The top layer comprises the graphics subsystems. Although there is
-provision for 24 subsystems, after 6 years only two exist, `base' and
+provision for 24 subsystems, since 2001 only two exist, `base' and
 `grid'.  The base subsystem is registered with the engine when @R{} is
 initialized, and unregistered (via @code{KillAllDevices}) when an @R{}
 session is shut down.  The grid subsystem is registered in its
@@ -3797,7 +3797,7 @@
 interactively.
 Default: true.
 @item _R_CHECK_VIGNETTES_NLINES_
-Maximum number of lines to show of the bottom of the output when reporting
+Maximum number of lines to show at the bottom of the output when reporting
 errors in running vignettes.
 Default: 10.
 @item _R_CHECK_CODOC_S4_METHODS_
@@ -4258,7 +4258,7 @@
 @file{Renviron} file.  This used to record @samp{false} if no command
 was found, but it nowadays records the name for looking up on the path
 at run time.  The latter can be important for binary distributions: one
-does not want to be tied to, for example, TeXLive 2007.
+does not want to be tied to, for example, TeX Live 2007.
 
 
 @node Current and future directions, Function and variable index, Use of TeX 
dialects, Top
@@ -4408,7 +4408,7 @@
 are supported provided that each of the dimensions is no more than
 2^31-1.  However, not all applications can be supported.
 
-The main problem is linear algebra, on done by FORTRAN code compiled
+The main problem is linear algebra done by FORTRAN code compiled
 with 32-bit @code{INTEGER}.  Although not guaranteed, it seems that all
 the compilers currently used with @R{} on a 64-bit platform allow
 matrices each of whose dimensions is less than 2^31 but with more than
@@ -4416,7 +4416,7 @@
 support software (such as @acronym{BLAS} and @acronym{LAPACK}) also
 work.
 
-There are exceptions: for example some complex @acronym{LAPACK})
+There are exceptions: for example some complex @acronym{LAPACK}
 auxiliary routines do use a single @code{INTEGER} index and hence
 overflow silently and segfault or give incorrect results.  One example
 is @code{svd()} on a complex matrix.
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel


Re: [Rd] user defined macros in Rd files

2013-10-12 Thread R. Michael Weylandt


On Oct 9, 2013, at 21:18, Duncan Murdoch  wrote:

> On 13-10-09 7:54 PM, Henrik Bengtsson wrote:
>> 
>> 
>> On my related wishlist: A standardized mechanism to 'R CMD build' for
>> building man/*.Rd from any input format (e.g. roxygen and so on)
>> analogously how we can now build vignettes of any input format.  With
>> that in place, it would a be piece of cake to include macros from
>> external files.
>> 
>> Just wanted to throw it out there.
> 
> No, we certainly won't do that.  We rely on being able to process the Rd 
> files in multiple ways.
> 

I'm a but confused here Duncan: 

Henrik's proposal still results in the Rd files being created and then all of 
the cool things which get done (example checking, HTML, PDF, etc.) can carry on 
as usual. Since those are all done from the tarball by R CMD build, they can't 
know how the Rd files were created in the first place. 

Can you say a bit more about what would break? I'm afraid I'm missing something 
obvious. 

Michael

> Duncan Murdoch

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel


Re: [Rd] user defined macros in Rd files

2013-10-12 Thread Duncan Murdoch

On 13-10-12 6:49 PM, R. Michael Weylandt  wrote:



On Oct 9, 2013, at 21:18, Duncan Murdoch  wrote:


On 13-10-09 7:54 PM, Henrik Bengtsson wrote:



On my related wishlist: A standardized mechanism to 'R CMD build' for
building man/*.Rd from any input format (e.g. roxygen and so on)
analogously how we can now build vignettes of any input format.  With
that in place, it would a be piece of cake to include macros from
external files.

Just wanted to throw it out there.


No, we certainly won't do that.  We rely on being able to process the Rd files 
in multiple ways.



I'm a but confused here Duncan:

Henrik's proposal still results in the Rd files being created and then all of 
the cool things which get done (example checking, HTML, PDF, etc.) can carry on 
as usual. Since those are all done from the tarball by R CMD build, they can't 
know how the Rd files were created in the first place.

Can you say a bit more about what would break? I'm afraid I'm missing something 
obvious.


I was assuming he wanted to build the help system from another format. 
If he just wants to build a standard *.Rd file from something else, then 
why get "R CMD build" involved?  Why not just do it in two steps, "make 
the help, build the tarball"?   He'll have to clarify, but the comment 
about vignettes makes me think I'm right:  you can have a vignette in 
any format, and you just need a way to convert it to HTML or PDF, it 
doesn't need to become a Sweave document first.


Duncan Murdoch

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel