Re: [Rd] Add a new environment variable switch for the 'large version' check

2020-04-16 Thread Jan Gorecki
For the same reason, handling false positive in CRAN checks, there are other places that could be improved. Like "size of tarball" NOTE. If one could control this size with an environment variable. Similarly to the proposal made by Jim. It would be useful as well. On Thu, Apr 16, 2020 at 5:06 PM H

Re: [Rd] suggestion: "." in [lsv]apply()

2020-04-16 Thread Simon Urbanek
Sergei, the main problem that I was pointing out is is that there is no way you can introduce the new syntax without breaking the old one. The expression is evaluated to obtain a function, so by definition using anything that results in a valid expression for your syntax will break. E.g., using

Re: [Rd] suggestion: "." in [lsv]apply()

2020-04-16 Thread Sokol Serguei
Thanks Henrik, Probably, it will be the solution I'll retain. Best, Serguei. Le 16/04/2020 à 18:50, Henrik Bengtsson a écrit : I'm sure this exists elsewhere, but, as a trade-off, could you achieve what you want with a separate helper function F(expr) that constructs the function you want to p

[Rd] Read.Spss use $variable.labels as attributes instead of read/write.dta's $var.labels

2020-04-16 Thread Ellie Chen
Hi, I notice that read.spss store variables' labels into df's attributes as $variable.labels, while write.dta read df's attribute $var.labels as variable labels. This becomes a problem when I try to convert a bulk of SPSS's por files into STATA's dta format using these commands. The data were succ

Re: [Rd] suggestion: "." in [lsv]apply()

2020-04-16 Thread Voeten, C.C.
Such a helper already exists in magrittr, which allows you to compose anonymous functions like so: library(magrittr) sapply(1:10,. %>% add(4)) That said, I'm all for this being able to be shortened to sapply(1:10,add(.)), but that would require language support, as Serguei asks for. Languages s

Re: [Rd] suggestion: "." in [lsv]apply()

2020-04-16 Thread Henrik Bengtsson
I'm sure this exists elsewhere, but, as a trade-off, could you achieve what you want with a separate helper function F(expr) that constructs the function you want to pass to [lsv]apply()? Something that would allow you to write: sapply(split(mtcars, mtcars$cyl), F(summary(lm(mpg ~ wt,.))$r.square

Re: [Rd] suggestion: "." in [lsv]apply()

2020-04-16 Thread Michael Mahoney
This syntax is already implemented in the {purrr} package, more or less -- you need to add a tilde before your function call for it to work exactly as written: purrr::map_dbl(split(mtcars, mtcars$cyl), ~ summary(lm(wt ~ mpg, .))$r.squared) is equivalent to sapply(split(mtcars, mtcars$cyl), funct

Re: [Rd] Add a new environment variable switch for the 'large version' check

2020-04-16 Thread Henrik Bengtsson
I'd second Jim's feature request - it would be useful to be able to disable this in CI and elsewhere.The concept of using an "unusual" version component such as a very large number does a nice job of indicating "unusual" and serves as a blocker for submitting work-in-progress to CRAN by mistake

Re: [Rd] suggestion: "." in [lsv]apply()

2020-04-16 Thread Sokol Serguei
Thanks Bill, Clearly, my first proposition for wsapply() is quick and dirty one. However, if "." becomes a reserved variable with this new syntax, wsapply() can be fixed (at least for your example and alike) as: wsapply=function(l, fun, ...) {     .=substitute(fun)     if (is.name(.) || is.cal

Re: [Rd] suggestion: "." in [lsv]apply()

2020-04-16 Thread Sokol Serguei
Simon, Thanks for replying. In what follows I won't try to argue (I understood that you find this a bad idea) but I would like to make clearer some of your point for me (and may be for others). Le 16/04/2020 à 16:48, Simon Urbanek a écrit : Serguei, On 17/04/2020, at 2:24 AM, Sokol Serguei

Re: [Rd] suggestion: "." in [lsv]apply()

2020-04-16 Thread William Dunlap via R-devel
Passing in a function passes not only an argument list but also an environment from which to get free variables. Since your function doesn't pay attention to the environment you get things like the following. > wsapply(list(1,2:3), paste(., ":", deparse(s))) [[1]] [1] "1 : paste(., \":\", deparse

Re: [Rd] suggestion: "." in [lsv]apply()

2020-04-16 Thread Simon Urbanek
Serguei, > On 17/04/2020, at 2:24 AM, Sokol Serguei wrote: > > Hi, > > I would like to make a suggestion for a small syntactic modification of FUN > argument in the family of functions [lsv]apply(). The idea is to allow > one-liner expressions without typing "function(item) {...}" to surroun

Re: [Rd] Add a new environment variable switch for the 'large version' check

2020-04-16 Thread Dirk Eddelbuettel
Or you use a fourth component to signal a development version as Rcpp has done for years (and, IIRC, for longer than devtools et al used '9000'). There is no functional difference between 1.2.3.1 and 1.2.3.9000. They are both larger than 1.2.3 (in the package_version() sense) and signal an inter

[Rd] suggestion: "." in [lsv]apply()

2020-04-16 Thread Sokol Serguei
Hi, I would like to make a suggestion for a small syntactic modification of FUN argument in the family of functions [lsv]apply(). The idea is to allow one-liner expressions without typing "function(item) {...}" to surround them. The argument to the anonymous function is simply referred as "."