> Tomas Kalibera
> on Fri, 4 May 2018 08:34:03 +0200 writes:
> On 05/03/2018 11:14 PM, Henrik Bengtsson wrote:
>> Also, as mentioned in my
>> https://stat.ethz.ch/pipermail/r-devel/2012-August/064739.html,
>> when not specifying the mode argument, the default on
>>
On Fri, May 4, 2018 at 8:34 AM, Tomas Kalibera
wrote:
> The current heuristic/hack is in line with the compatibility approach: it
> detects files that are obviously binary, so it changes the default behavior
> only for cases when it would obviously cause damage.
>
> Tomas
Well, I was trying to
> Joris Meys
> on Fri, 4 May 2018 10:00:07 +0200 writes:
> On Fri, May 4, 2018 at 8:34 AM, Tomas Kalibera
> wrote:
>> The current heuristic/hack is in line with the
>> compatibility approach: it detects files that are
>> obviously binary, so it changes the defaul
Thanks for the update. I believe I've fixed a part of the problem you
have reported, the crash while entering Chinese characters to the
console (e.g. via Pinyin, the error message about invalid multibyte
character in mbcs_get_next). The fix is in R-devel 74693 - Windows
function ReadConsoleIn
> Hervé Pagès
> on Thu, 3 May 2018 08:55:20 -0700 writes:
> Hi,
> It would be great if one of the experts could comment on the
> difference between Hadley's dotlength and ...length? The fact
> that someone bothered to implement a new primitive for that
> when there
The one difference I see, is the necessity to pass the dots to the function
dotlength :
dotlength <- function(...) nargs()
myfun <- function(..., someArg = 1){
n1 <- ...length()
n2 <- dotlength()
n3 <- dotlength(...)
return(c(n1, n2, n3))
}
myfun(stop("A"), stop("B"), someArg = stop("c")
> Joris Meys
> on Fri, 4 May 2018 15:37:27 +0200 writes:
> The one difference I see, is the necessity to pass the dots to the
function
> dotlength :
> dotlength <- function(...) nargs()
> myfun <- function(..., someArg = 1){
> n1 <- ...length()
> n2 <- dotle
Hi all,
I wish to push a new version of a package (heatmaply).
I sent it to winbuild with no issues but after submitting it to CRAN I got
an update that it breaks on Debian, see:
package heatmaply_0.15.0.tar.gz does not pass the incoming checks
automatically, please see the following pre-tests:
W
Thanks for your reply, Ista, and your advice. I will re-post to r-help.
Best,
Scott
--
Scott Kostyshak
Assistant Professor of Economics
University of Florida
https://people.clas.ufl.edu/skostyshak/
On Tue, May 01, 2018 at 07:15:30PM +, Ista Zahn wrote:
> Hi Scott,
>
> This question is ap
Tal,
I don't have a debian machine at my fingertips, but I don't see that error
when installing heatmaply into a clean library in R 3.5.0 (that takes a
while...).
I suspect you're hitting old installed versions of packages in that build
on that machine, especially since the failure is not univers
The Debian failure is in R-devel, and you should see the same failure
in R-devel on all platforms. A recent change in R-devel has unmasked
an issue in data.table that needs to be fixed. The data.table
maintainer is working on this.
Best,
luke
On Fri, 4 May 2018, Tal Galili wrote:
Hi all,
I wi
11 matches
Mail list logo
