Re: [Rd] Printing of anonymous functions in calls is sub-optimal
As there has been no response to this ...
Why not simply:
g - substitute(f(x),list(f=function(x){x+1})) ## with curly braces
g
function (x)
{
x + 1
}(x)
x - 2
eval(g)
[1] 3
Cheers,
Bert
On Fri, Feb 15, 2013 at 7:45 AM, Hadley Wickham h.wick...@gmail.com wrote:
e.g.
substitute(f(x), list(f = function(x) x + 1))
# function (x)
# x + 1(x)
An extra pair of parentheses would really help:
(function(x)
x + 1)(x)
(Better indenting etc would be nice, but not necessary for correct
understand of the code)
Hadley
--
Chief Scientist, RStudio
http://had.co.nz/
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
--
Bert Gunter
Genentech Nonclinical Biostatistics
Internal Contact Info:
Phone: 467-7374
Website:
http://pharmadevelopment.roche.com/index/pdb/pdb-functional-groups/pdb-biostatistics/pdb-ncb-home.htm
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Matrix does not build with R trunk since Oct.
Hin-Tak Leung htl10 at users.sourceforge.net writes: --- On Fri, 15/2/13, Simon Urbanek simon.urbanek at r-project.org wrote: On Feb 15, 2013, at 1:55 PM, Hin-Tak Leung wrote: Look. I don't see this as my problem - as far as I am concerned, I have donated my time - and over and over - to testing pre-released code. I am not using pre-released code for production work. If the released code in 3.0 does not work correctly in 6 weeks' time, I just don't upgrade. No loss for me there. It works - confirmed by several people. You have a problem, but you didn't tell us the specifics of the problem so there's nothing we can do. I do not have a problem. I do not need to spend time regularly testing pre-release code, and I think I should stop. The probably unknown now, for today's comfortable people, simple procedure has always been: svn up tools/rsync-recommended # R only ./configure ... make distclean ./configure ... make make check # R or relevant software only make install which always works even when building in the source tree. This whole thread is unnecessary if you remember to run make distclean, as all files that might appear to be fresh (but are not because of indirect dependencies, such as changes in the methods package), are rebuilt. When in doubt, use make distclean. It's as easy as that, nothing to get excited about. Section 7.2.6 of http://www.gnu.org/prep/standards/html_node/index.html. Roger I don't know why it is degenerating into another distraction about some people's egos. I don't either - it's not productive. Cheers, Simon __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Matrix does not build with R trunk since Oct.
On Feb 16, 2013, at 8:03 AM, Roger Bivand wrote: Hin-Tak Leung htl10 at users.sourceforge.net writes: --- On Fri, 15/2/13, Simon Urbanek simon.urbanek at r-project.org wrote: On Feb 15, 2013, at 1:55 PM, Hin-Tak Leung wrote: Look. I don't see this as my problem - as far as I am concerned, I have donated my time - and over and over - to testing pre-released code. I am not using pre-released code for production work. If the released code in 3.0 does not work correctly in 6 weeks' time, I just don't upgrade. No loss for me there. It works - confirmed by several people. You have a problem, but you didn't tell us the specifics of the problem so there's nothing we can do. I do not have a problem. I do not need to spend time regularly testing pre-release code, and I think I should stop. The probably unknown now, for today's comfortable people, simple procedure has always been: svn up tools/rsync-recommended # R only ./configure ... make distclean ./configure ... make make check # R or relevant software only make install which always works even when building in the source tree. Although it goes a long way, it doesn't always work -- it assumes that the directory structure did not change in the project between the revisions - distclean may not clean things that have changed since you updated the SVN (note that to address that you should run distclean *before* the update). Also note that R-devel is unstable for a reason -- as you are tracking it you may encounter bugs in the build which will make your in-source build (including distclean) break -- even if that bug is then fixed in next update the damage has been done already so you cannot recover. This has happened before, so in such cases you have to blow away everything and start from scratch (from svn co ..). That's why we are suggesting building outside sources, because it's easier to blow away just the build (there are still cases where even that won't work - e.g. when sources files are accidentally modified by the build). Before claiming that something doesn't work, you have to do a clean build.! In a majority of cases you will get away with in-sources build, but if you don't, you have to know what to do. This whole thread is unnecessary Period. It is indeed. The thread was about alleged issue with Matrix in R-devel which could not be confirmed (I even checked on Fedora 18 now and it builds just fine). We were not able to reproduce it and the reporter was unwilling to follow any suggestions hence we have no way to follow it up as it's not reproducible so I see the case as closed. Cheers, Simon if you remember to run make distclean, as all files that might appear to be fresh (but are not because of indirect dependencies, such as changes in the methods package), are rebuilt. When in doubt, use make distclean. It's as easy as that, nothing to get excited about. Section 7.2.6 of http://www.gnu.org/prep/standards/html_node/index.html. Roger I don't know why it is degenerating into another distraction about some people's egos. I don't either - it's not productive. Cheers, Simon __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Printing of anonymous functions in calls is sub-optimal
On 13-02-15 10:45 AM, Hadley Wickham wrote: e.g. substitute(f(x), list(f = function(x) x + 1)) # function (x) # x + 1(x) An extra pair of parentheses would really help: (function(x) x + 1)(x) (Better indenting etc would be nice, but not necessary for correct understand of the code) This is a little tricky for the deparser. It sees a call to a function which was determined by an expression. Sometimes you want parens, sometimes you don't. For example, if getfun(y) returns a function, it's clearer to display a call as getfun(y)(x) than (getfun(y))(x). I'll see if I can work out which kinds of expressions need to be parenthesized and implement it in the deparser. Duncan __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Printing of anonymous functions in calls is sub-optimal
On Sat, Feb 16, 2013 at 12:24 AM, Bert Gunter gunter.ber...@gene.com wrote:
As there has been no response to this ...
Why not simply:
g - substitute(f(x),list(f=function(x){x+1})) ## with curly braces
g
function (x)
{
x + 1
}(x)
x - 2
eval(g)
[1] 3
Thomas Lumley sent me a similar suggestion off-list; but I'm not
complaining about how it works; my example executed fine. I'm
complaining that the rendering of the call object is misleading.
Hadley
--
Chief Scientist, RStudio
http://had.co.nz/
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Printing of anonymous functions in calls is sub-optimal
This is a little tricky for the deparser. It sees a call to a function
which was determined by an expression. Sometimes you want parens, sometimes
you don't. For example, if getfun(y) returns a function, it's clearer to
display a call as getfun(y)(x) than (getfun(y))(x).
I'll see if I can work out which kinds of expressions need to be
parenthesized and implement it in the deparser.
I suspect it's only when you have a function in the quoted call, not a symbol:
# Don't add parens
q1 - quote(g(f)(x))
is.symbol(q1[[1]])
# Add parents
q2 - substitute(f(x), list(f = function(x) {x + 1}))
is.function(q2[[1]])
Thanks for thinking about it!
Hadley
--
Chief Scientist, RStudio
http://had.co.nz/
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Matrix does not build with R trunk since Oct.
Although it goes a long way, it doesn't always work -- it assumes that the directory structure did not change in the project between the revisions - distclean may not clean things that have changed since you updated the SVN (note that to address that you should run distclean *before* the update). Also note that R-devel is unstable for a reason -- as you are tracking it you may encounter bugs in the build which will make your in-source build (including distclean) break -- even if that bug is then fixed in next update the damage has been done already so you cannot recover. This has happened before, so in such cases you have to blow away everything and start from scratch (from svn co ..). One of the cool things about git is git clean - that allows you to remove all non-git files from the repo without having to do checkout from scratch. Hadley -- Chief Scientist, RStudio http://had.co.nz/ __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] RSetReg.exe
R.exe, Rgui.exe, Rcmd.exe and Rscript.exe all support the --help argument but RSetReg.exe --help ignores the argument and attempts to set the registry key. Since one might try this as a first attempt to figure out what the command is all about this seems a bit dangerous. It would be nice if it responded to --help as the other R*.exe commands do. -- Statistics Software Consulting GKX Group, GKX Associates Inc. tel: 1-877-GKX-GROUP email: ggrothendieck at gmail.com __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Printing of anonymous functions in calls is sub-optimal
On 13-02-16 10:19 AM, Hadley Wickham wrote:
On Sat, Feb 16, 2013 at 12:24 AM, Bert Gunter gunter.ber...@gene.com wrote:
As there has been no response to this ...
Why not simply:
g - substitute(f(x),list(f=function(x){x+1})) ## with curly braces
g
function (x)
{
x + 1
}(x)
x - 2
eval(g)
[1] 3
Thomas Lumley sent me a similar suggestion off-list; but I'm not
complaining about how it works; my example executed fine. I'm
complaining that the rendering of the call object is misleading.
Even with the braces it's misleading, in that
y - function (x)
{
x + 1
}(x)
is evaluated to define y to be a function with body
{
x + 1
}(x)
which is syntactically valid, but not the same as the thing being deparsed.
Duncan Murdoch
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Matrix does not build with R trunk since Oct.
On Feb 15, 2013, at 6:13 PM, Hin-Tak Leung wrote: FWIW, extracting snapshot source elsewhere outside svn, run tools/rsync-recommended then just plain ./configure make doesn't work either. Nothing to do with building inside checkout nor extra configure options. Can you define extracting snapshot source elsewhere outside svn? That is likely the crucial point. If you mean that you used svn checkout on one machine, copied the content to another machine which does *not* have svn and then built there -- then this is unsupported and it has never been supported (depending on the R version it would either break or report invalid svn rev in R.version). You can *only* build from the svn sources if you have svn installed on the machine (equally, you cannot use svn export - see R-admin 1.2.1). You can only proceed on a machine without svn if you first create a distribution tar ball (e.g., via make dist) on the machine with svn and then use that tar ball on another machine (this is how R snapshots work). This is fedora 18, x86_64. I checked on Fedora 18 and it works just fine using svn co https://svn.r-project.org/R/trunk R-devel cd R-devel/ tools/rsync-recommended ./configure make Cheers, Simon --- On Fri, 15/2/13, Hin-Tak Leung ht...@users.sourceforge.net wrote: Somebody else had written separately about this before, and so have I a couple of months ago. I assumed this will be fixed before the next R. Since R 3.0 is supposedly only 6 weeks away, even if it is fixed now it doesn't leave much room for testing. Anyway neither Matrix 1.0-11 (current) nor 1.0-9 (sept 2012) build with current R trunk. The last time it did was 1. 0-9 on 3rd october over 4 months ago. So it appears to be due to change inside r trunk in sept or early oct. Loading required package: Matrix Error in namespaceExport(ns, exports) : undefined exports: .M.classEnv Error : require(Matrix) is not TRUE ERROR: installing package indices failed * removing ‘/svn-loc/R/library/Matrix’ * restoring previous ‘/svn-loc/R/library/Matrix’ make[2]: *** [Matrix.ts] Error 1 make[2]: Leaving directory `/svn-loc/R/src/library/Recommended' make[1]: *** [recommended-packages] Error 2 make[1]: Leaving directory `/svn-loc/R/src/library/Recommended' make: *** [stamp-recommended] Error 2 If it matters, here is what r trunk built with: ./configure --enable-memory-profiling --enable-strict-barrier --enable-byte-compiled-packages --with-valgrind-instrumentation=2 --enable-lto __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Suggestion: Custom filename patterns for non-Sweave vignettes
Hi,
as said at the end, all comments are now in the light of R 3.x.0 (x 0).
On Fri, Feb 15, 2013 at 11:30 AM, Duncan Murdoch
murdoch.dun...@gmail.com wrote:
On 13-02-15 1:53 PM, Henrik Bengtsson wrote:
Hi Duncan,
thanks you for your prompt reply.
On Fri, Feb 15, 2013 at 1:15 AM, Duncan Murdoch
murdoch.dun...@gmail.com wrote:
There are several reasons I decided against that:
- two packages may request overlapping patterns, making it much
messier to
do the matching, checking etc, since the matching would have to depend on
the package being processed.
So, isn't that somewhat already taken care of by the 'VignetteBuilder'
field in DESCRIPTION? It specifies additional builders in addition to
the default/builtin Sweave builder.
No, it specifies additional packages besides utils. Packages may specify
multiple engines.
I think we're on the same page here - by builders I meant packages
that provide engine for building vignettes.
For example, knitr can handle Sweave-like knitr
vignettes, and markdown-based vignettes. Yihui chose to use the same engine
for both, but it might make more sense to specify different engines.
Just to add a tiny FYI related to this comment; RSP markup is
independent of the output format, so in that case it makes sense to
have a single engine regardless of output format.
So a user might say they want a knitr vignette and a .html.rsp vignette.
But perhaps in the meantime, Yihui added an engine that can handle .rsp
files. So the user would have to list both packages, and there would be an
ambiguity as to which one should be run. You might say that's the user's
problem, but they wouldn't complain to themselves, they'd complain to me, so
it's my problem.
As I understand it, currently the rule is that R will take a .Rnw, /
Rmd file, scan its content for \VignetteEngine{engine} to infer the
vignette engine, and then apply that vignette engine to the source
file. If no \VignetteEngine{} is found, the default is to use Sweave
(as before). The exact same strategy can be applied with support
custom filename patterns, with the default to give an error (or
alternatively silently skip it) if no \VignetteEngine{} is found (*).
This would remove any ambiguities between an R.rsp and knitr 'rsp'
engine, just as it does for *.Rnw currently.
(*) Ideally, I'd like the default to be inferred from the file's
content type, which in turn could be guessed from the filename
extension and possibly some content-type markup (e.g.
\VignetteContentType{...}), but I'm willing to step back from that.
It would be possible to design all of this to work: the engine could check
the file and say oops, that's not my kind of .rsp file, try the next
engine. I just don't think it's worth it. I certainly don't have time to
design and program it or even to check your offered patch before feature
freeze. I can make small tweaks, but big changes that need lots of testing
aren't going to happen.
I definitely hear you and I fully understand.
Conflicts would only happen if a
package developer (e.g. PkgA) includes a pattern that either (A)
overrides the builtin in [.][RrSs](nw|tex)$ / [.]Rmd$ patterns, or
(B) specifies to builders with the same patterns. First of all, there
are not that many builder packages, so this is something that could be
negotiated among those to minimize conflicts. Second, case (A) can be
protected against by not allowing builder packages (e.g. knitr, rsp,
...) to add/register those patterns (tricky but possible to test for)
I don't think it's feasible to check for overlap in regular expression
patterns.
Here I was only thinking of testing for overlaps with
[.][RrSs](nw|tex)$ / [.]Rmd$, which can be done as:
illegalPattern - function(pattern) {
files - c(outer(c(R, r, S, s), c(nw, tex), FUN=paste,
sep=), Rmd)
files - paste(., files, sep=)
any(regexpr(pattern, files) != -1L)
}
But yes, checking for overlapping patterns in general would be very hard.
(but only default to them if that is what they wish to use). For case
(B), the developer of package PkgA has the power to avoid conflicts.
One could also imagine the ordering of packages listed in
'VignetteBuilder' would provide a prioritization.
Sure, but it would be confusing to get an error from knitr when you didn't
know knitr was handling .rsp.
See above reply on \VignetteEngine{}.
BTW, case (A) is basically what the new design is already providing;
all builder packages use the same patterns.
So, from a package building point of view, I don't see how this would
make it messier. I can see that when checking a package it is harder
to validate matches between input and output formats (is that done?).
Let me know if I simplifying things too much - then I'll read up on
the 'R CMD *' source code.
- one package may request a pattern that another package uses for
auxiliary files, e.g. .bib. If a user has both types of vignette it
would
just be
Re: [Rd] Printing of anonymous functions in calls is sub-optimal
On 13-02-16 10:22 AM, Hadley Wickham wrote:
This is a little tricky for the deparser. It sees a call to a function
which was determined by an expression. Sometimes you want parens, sometimes
you don't. For example, if getfun(y) returns a function, it's clearer to
display a call as getfun(y)(x) than (getfun(y))(x).
I'll see if I can work out which kinds of expressions need to be
parenthesized and implement it in the deparser.
I suspect it's only when you have a function in the quoted call, not a symbol:
# Don't add parens
q1 - quote(g(f)(x))
is.symbol(q1[[1]])
# Add parents
q2 - substitute(f(x), list(f = function(x) {x + 1}))
is.function(q2[[1]])
Thanks for thinking about it!
It's in place now. There are two kinds of cases it handles:
Unevaluated expressions are the hardest. For those, parens are used
when the function is an infix operator other than ::, :::, $, [ or [[.
They're also used for special syntax, like if, while, etc.
For evaluated things, only your example (a closure object) get parens.
I'm sure you can construct things that deparse improperly, but it does a
better job now. For example, from the new test script:
## Anonymous function calls were not deparsed properly
substitute(f(x), list(f = function(x) x + 1))
(function (x)
x + 1)(x)
substitute(f(x), list(f = quote(function(x) x + 1)))
(function(x) x + 1)(x)
substitute(f(x), list(f = quote(f+g)))
(f + g)(x)
substitute(f(x), list(f = quote(base::mean)))
base::mean(x)
substitute(f(x), list(f = quote(a[n])))
a[n](x)
substitute(f(x), list(f = quote(g(y
g(y)(x)
## The first three need parens, the last three don't.
This is in R-devel and R-patched.
Duncan Murdoch
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Printing of anonymous functions in calls is sub-optimal
I suspect it's only when you have a function in the quoted call, not a symbol:
Add a call to 'function' (as opposed to the function made by evaluating that
call)
to your test suite:
Q - list(
q1 = quote(getFunction(-)(x)),
q2 = substitute(f(x), list(f = function(x) {-x})),
q3 = substitute(f(x), list(f = quote(function(x) {-x}
sapply(Q, function(x)class(x[[1]]))
q1 q2 q3
call function call
Q
$q1
getFunction(-)(x)
$q2
function (x)
{
-x
}(x)
$q3
function(x) {
-x
}(x)
sapply(Q, eval, list(x=137))
q1 q2 q3
-137 -137 -137
Bill Dunlap
Spotfire, TIBCO Software
wdunlap tibco.com
-Original Message-
From: r-devel-boun...@r-project.org [mailto:r-devel-boun...@r-project.org] On
Behalf
Of Hadley Wickham
Sent: Saturday, February 16, 2013 7:22 AM
To: Duncan Murdoch
Cc: r-devel@r-project.org
Subject: Re: [Rd] Printing of anonymous functions in calls is sub-optimal
This is a little tricky for the deparser. It sees a call to a function
which was determined by an expression. Sometimes you want parens, sometimes
you don't. For example, if getfun(y) returns a function, it's clearer to
display a call as getfun(y)(x) than (getfun(y))(x).
I'll see if I can work out which kinds of expressions need to be
parenthesized and implement it in the deparser.
I suspect it's only when you have a function in the quoted call, not a symbol:
# Don't add parens
q1 - quote(g(f)(x))
is.symbol(q1[[1]])
# Add parents
q2 - substitute(f(x), list(f = function(x) {x + 1}))
is.function(q2[[1]])
Thanks for thinking about it!
Hadley
--
Chief Scientist, RStudio
http://had.co.nz/
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
