Re: [Rd] rscproxy version conflict
On Thu, 18 Dec 2008, meerman wrote:
After installing the package 'rscproxy' downloaded from the CRAN server, I
get the following error message from R 2.8.0 about a version conflict :
I see no 'error message' nor no 'confict'.
I see a *warning* which you could stop by using 2.8.1 RC or by updating to
2.8.1 early next week, but should be harmless.
package 'rscproxy' successfully unpacked and MD5 sums checked
The downloaded packages are in
C:\Documents and Settings\John Meerman\Local
Settings\Temp\RtmpbK9mxN\downloaded_packages
updating HTML package descriptions
local({pkg <- select.list(sort(.packages(all.available = TRUE)))
+ if(nchar(pkg)) library(pkg, character.only=TRUE)})
*Warning message:
package 'rscproxy' was built under R version 2.8.1 *>
This prevents me e.g. to use the R (D)COM 3.0 server.
John Meerman
[[alternative HTML version deleted]]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
--
Brian D. Ripley, rip...@stats.ox.ac.uk
Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/
University of Oxford, Tel: +44 1865 272861 (self)
1 South Parks Road, +44 1865 272866 (PA)
Oxford OX1 3TG, UKFax: +44 1865 272595
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Misuse of $$ in Rd files
'Writing R Extensions' tells you that $ needs to be escaped in Rd files
outside \code and similar. So I was surprised to find that ca 80 CRAN
packages have constructions like (from ISwR)
\item{\code{folate}}{
a numeric vector, folate concentration ($\mu$g/l).
}
This does not render sensibly in non-latex conversions, and it is what we
have \eqn{} for.
That $ needs to be escaped is an implementation restriction that we hope
to remove so that things like (package fields)
greater than or equal to 2*m where m= length( grid$x).
do not generate an error (although \code{}) markup would be appropriate
and avoid the problem).
It is not clear if we are going to be able to do this backwards compatibly
or not, so plese check that you are using $ correctly. The most plausible
scenario now is that we will have versions of Rd files with the current
version being implicitly '1.0', and in '1.1' $ will be treated literally.
Finally, \eqn{} is for mathematics, and arbitrary markup is not allowed.
The following (SoPhy) is causing problems:
\eqn{\code{zlim}=\command{\link[base]{range}}(\{0,
\theta_{s,i}\}, max(\code{h$hQThFlC}))}{\code{zlim}=\command{range}({0,
theta_{s,i}}, max(\code{h$hQThFlC}))},
--
Brian D. Ripley, rip...@stats.ox.ac.uk
Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/
University of Oxford, Tel: +44 1865 272861 (self)
1 South Parks Road, +44 1865 272866 (PA)
Oxford OX1 3TG, UKFax: +44 1865 272595
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] gregexpr - match overlap mishandled (PR#13391)
Prof Brian Ripley wrote: > Please do your own homework: the help page says > > For 'gregexpr' a list of the same length as 'text' each element of > which is an integer vector as in 'regexpr', except that the > starting positions of every (disjoint) match are given. > > > If that is still not clear enough for you, please ask your supervisor > for remedial help. > i must say that even knowing what is meant i have trouble finding it written in the docs. someone who's looking for help because he does not know the answer yet will most certainly get confused here. the point is that gregexpr returns the starting positions of *mutually non-overlapping*, or *pairwise disjoint* matches (which still does not tell the whole story). the expression 'every (disjoint) match' is nonsense, as it suggests that only those matches which are individually disjoint (and what would this mean?) are reported, as if of all possible matches found only those that pass some disjointness test in a grep-like filter were left. i'd humbly suggest that once users are referred to specific man pages, those pages are reassessed and improved where necessary -- this one would be a good candidate. vQ __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Misuse of $$ in Rd files
Prof Brian Ripley wrote:
'Writing R Extensions' tells you that $ needs to be escaped in Rd files
outside \code and similar. So I was surprised to find that ca 80 CRAN
packages have constructions like (from ISwR)
\item{\code{folate}}{
a numeric vector, folate concentration ($\mu$g/l).
}
This does not render sensibly in non-latex conversions, and it is what
we have \eqn{} for.
I suspect last I looked at this was in copy editing that getting the
LaTeX to look right took priority.
It renders as "$\mu$g/l" (for now) which is semi-sensible to my eyes. I
can see that I have \eqn{\mu}g/l in other places, but that comes out as
"mug/l" which looks like an inverted measure for coffee cups. I probably
gave up deciding a good incantation for "microgram per liter" in text
mode. Possibly \eqn{\mu}{u} is the best on can do.
--
O__ Peter Dalgaard Øster Farimagsgade 5, Entr.B
c/ /'_ --- Dept. of Biostatistics PO Box 2099, 1014 Cph. K
(*) \(*) -- University of Copenhagen Denmark Ph: (+45) 35327918
~~ - (p.dalga...@biostat.ku.dk) FAX: (+45) 35327907
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Misuse of $$ in Rd files
On Fri, 19 Dec 2008, Peter Dalgaard wrote:
Prof Brian Ripley wrote:
'Writing R Extensions' tells you that $ needs to be escaped in Rd files
outside \code and similar. So I was surprised to find that ca 80 CRAN
packages have constructions like (from ISwR)
\item{\code{folate}}{
a numeric vector, folate concentration ($\mu$g/l).
}
This does not render sensibly in non-latex conversions, and it is what we
have \eqn{} for.
I suspect last I looked at this was in copy editing that getting the LaTeX to
look right took priority.
It renders as "$\mu$g/l" (for now) which is semi-sensible to my eyes. I can
Actually, it renders (e.g. in 2.8.0) as '$mu$g/l', which is less sensible
that what you read it as, but in my experience only people from the more
mathematical sciences are likely to be aware of TeX notation.
see that I have \eqn{\mu}g/l in other places, but that comes out as "mug/l"
which looks like an inverted measure for coffee cups. I probably gave up
deciding a good incantation for "microgram per liter" in text mode. Possibly
\eqn{\mu}{u} is the best on can do.
Well, why try an abbreviation that is unclear? E.g. other examples are
trying to get a degree sign as $^\circ$C, and why not just say 'degrees
Celsius'?
You probably not had a copy-editor make you write out DNA
--
Brian D. Ripley, rip...@stats.ox.ac.uk
Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/
University of Oxford, Tel: +44 1865 272861 (self)
1 South Parks Road, +44 1865 272866 (PA)
Oxford OX1 3TG, UKFax: +44 1865 272595
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
