This is a bug in the package: you are required to quote paths in
Makefiles, e.g. to allow for spaces in the path.
And let's knock the issue of forward and backwards slashes on the
head: they are equivalent on Windows. Despite your perjorative
comments, the supplied value of R_HOME is valid.
On 03/21/2011 07:22 PM, Simon Urbanek wrote:
On Mar 21, 2011, at 9:07 PM, Dan Tenenbaum wrote:
Hello,
I have come across two separate packages that have a Makefile in inst/doc
which use the R_HOME variable.
In both cases, the path to R_HOME gets munged in such a way that commands
that includ
simplify: logical or character string; should the result be simplified
to a vector, matrix or higher dimensional array if possible?
The default, ‘TRUE’, returns a vector or matrix if
appropriate, whereas ‘signify = "array"’, rather recommended
typically, t
On Mon, Mar 21, 2011 at 7:22 PM, Simon Urbanek
wrote:
>
> On Mar 21, 2011, at 9:07 PM, Dan Tenenbaum wrote:
>
> > Hello,
> >
> > I have come across two separate packages that have a Makefile in inst/doc
> > which use the R_HOME variable.
> >
> > In both cases, the path to R_HOME gets munged in suc
On Mar 21, 2011, at 9:07 PM, Dan Tenenbaum wrote:
> Hello,
>
> I have come across two separate packages that have a Makefile in inst/doc
> which use the R_HOME variable.
>
> In both cases, the path to R_HOME gets munged in such a way that commands
> that include R_HOME fail on Windows:
>
> For
Hello,
I have come across two separate packages that have a Makefile in inst/doc
which use the R_HOME variable.
In both cases, the path to R_HOME gets munged in such a way that commands
that include R_HOME fail on Windows:
For example, one Makefile, for the xmapcore package (
https://hedgehog.fh
L.S.
I noticed weird tools::texi2dvi behaviour on R-alpha
when specifying an absolute path to the .tex
file.
The same phenomenon also appears to occur on
R-2.12.2, so maybe the issue is independent
of R.
I hope I did not overlook any important information.
Best,
Tobias
> require(tools)
Loadin
On Mar 21, 2011, at 17:16 , William Dunlap wrote:
>> split(factor(letters[1:3]), c("Group one", "Group two"))
Yes, that's a bug (at the very least, it is against documented behavior)
The strong suspicion is that
ind <- .Internal(split(seq_along(f), f))
should have seq_along(x) , not f. B
hi,
I am preparing my package for R 2.13
build and check gives no warnings just OK's
However when running R CMD INSTALL it gives me (nfortunately it is in
german)
** help
*** installing help indices
** building package indices ...
** testing if installed package can be loaded
Fehler: '\U' ohne H
When split's x argument has a class attribute and the
grouping vector, f, is shorter than x then split gives
the wrong result. It appears to not extend f to the length
of x before doing the split. E.g.,
> split(factor(letters[1:3]), "Group one") # expect all 3 elements in
the single group
$
On Mon, Mar 21, 2011 at 10:46:41AM -0500, Terry Therneau wrote:
> Survfit had a bug in some prior releases due to the use of both
> unique(times) and table(times); I fixed it by rounding to 15 digits per
> the manual page for as.character. Yes, I should ferret out all the
> usages instead, but th
Survfit had a bug in some prior releases due to the use of both
unique(times) and table(times); I fixed it by rounding to 15 digits per
the manual page for as.character. Yes, I should ferret out all the
usages instead, but this was fast and it cured the user's problem.
The bug is back! A data
12 matches
Mail list logo
