Re: [Rd] Matrix does not build with R trunk since Oct.
On Fri, Feb 15, 2013 at 1:25 PM, Joshua Ulrich wrote: > On Fri, Feb 15, 2013 at 12:19 PM, Kasper Daniel Hansen > wrote: >> I build from svn daily and I have not had this problem. I build in a >> tree separate from the source tree. >> >> I do think Hin-Tak has a point about clearly specifying that this is >> how you should do it, in the manual (if that has not already >> happened). As a casual user, I would expect make clean to clean out >> any stale files, but perhaps that is not happening. Anyway, seems >> more to be a possible documentation problem. >> > It's already in the R Installation and Administration Manual: > http://cran.r-project.org/doc/manuals/R-admin.html#Simple-compilation > > See the second-to-last paragraph. It recommends you do not build in > the top-level source directory, particularly when you work with a > version of R from Subversion. Ok, this certainly recommends doing it in another build tree, so I think it is quite clearly documented. Kasper > Best, > Josh > >> Kasper >> >> On Fri, Feb 15, 2013 at 1:08 PM, Simon Urbanek >> wrote: >>> On Feb 15, 2013, at 11:36 AM, Hin-Tak Leung wrote: >>> --- On Fri, 15/2/13, Simon Urbanek wrote: > On Feb 15, 2013, at 9:11 AM, Hin-Tak > Leung 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. >> > > No problem here - Matrix 1.0-11 and R-devel build just fine > with your flags (tested on Ubuntu 12.10, x86_64). > > If in doubt, please remove R-devel and checkout a fresh > copy. Also FWIW it's a bad practice to build inside the > sources - it often causes all sorts of problems when you try > to track the sources and stale files are probably what's > hitting you. > > FWIW: This is likely not the problem you're mentioning, but > some recent gcc versions break and LTO is also known to > cause issues depending on the compiler version, so tread > lightly on the cutting edge. Here is a fairly similar post: http://r.789695.n4.nabble.com/Build-from-Source-fails-on-Loading-required-package-Matrix-td4640371.html The eventual "solution" of that thread seems to be building from tar ball, which is quite beside the whole point of building from svn trunk. >>> >>> And how is that relevant to what I said? Did you follow the advice I sent? >>> If you did and still have an issue, post *exact* details on what you did, >>> what system and tools you are using. >>> >>> FWIW, it is very unproductive to talk about "bad practice" - in a hand-waving undocumented/unsubstantiated manner >>> >>> Building in sources has two problems: a) the content of the source tree can >>> change so subsequent builds can be different from the clean one - you >>> cannot undo that and b) if you update the sources stale files from previous >>> builds can break the build. >>> >>> If solving your problems is "unproductive" then I'm not surprised you have >>> them for 4 moths now. >>> >>> - and options that might or might not work. If "--enable-lto" (or any other options, or build within the dev directory) does not work reliably, it should be either disabled/removed, or documented, or both. >>> >>> R cannot test all aspects of a compiler and detect all its bugs. It is >>> *your* responsibility to provide a working compiler - if you are unwilling >>> to do that, R cannot do anything about that. >>> >>> Anyway, it has not been working for over 4 months. >>> >>> That is not true, obviously, and I have presented a counter-example. It may >>> not have been working for *you* and it's likely a problem in your setup >>> (given your lack of cooperation there is no way to tell for sure). We >>> cannot prevent user errors. We can try to point people in the right >>> direction, but if they refuse to listen it's on their head. >>> >>> You have about 6 weeks before this becomes a big problem - "big" as in "wide-spread". >>> >>> You are yet to show that this is a problem in R at all. You failed to >>> follow the basic instructions in the FAQ. >>> >>> Cheers, >>> Simon >>> >>> >>> > Cheers, > Simon > > >> >> >> 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 pr
Re: [Rd] Matrix does not build with R trunk since Oct.
On Fri, Feb 15, 2013 at 12:19 PM, Kasper Daniel Hansen wrote: > I build from svn daily and I have not had this problem. I build in a > tree separate from the source tree. > > I do think Hin-Tak has a point about clearly specifying that this is > how you should do it, in the manual (if that has not already > happened). As a casual user, I would expect make clean to clean out > any stale files, but perhaps that is not happening. Anyway, seems > more to be a possible documentation problem. > It's already in the R Installation and Administration Manual: http://cran.r-project.org/doc/manuals/R-admin.html#Simple-compilation See the second-to-last paragraph. It recommends you do not build in the top-level source directory, particularly when you work with a version of R from Subversion. Best, Josh > Kasper > > On Fri, Feb 15, 2013 at 1:08 PM, Simon Urbanek > wrote: >> On Feb 15, 2013, at 11:36 AM, Hin-Tak Leung wrote: >> >>> --- On Fri, 15/2/13, Simon Urbanek wrote: >>> On Feb 15, 2013, at 9:11 AM, Hin-Tak Leung 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. > No problem here - Matrix 1.0-11 and R-devel build just fine with your flags (tested on Ubuntu 12.10, x86_64). If in doubt, please remove R-devel and checkout a fresh copy. Also FWIW it's a bad practice to build inside the sources - it often causes all sorts of problems when you try to track the sources and stale files are probably what's hitting you. FWIW: This is likely not the problem you're mentioning, but some recent gcc versions break and LTO is also known to cause issues depending on the compiler version, so tread lightly on the cutting edge. >>> >>> >>> Here is a fairly similar post: >>> http://r.789695.n4.nabble.com/Build-from-Source-fails-on-Loading-required-package-Matrix-td4640371.html >>> >>> The eventual "solution" of that thread seems to be building from tar ball, >>> which is quite beside the whole point of building from svn trunk. >>> >> >> And how is that relevant to what I said? Did you follow the advice I sent? >> If you did and still have an issue, post *exact* details on what you did, >> what system and tools you are using. >> >> >>> FWIW, it is very unproductive to talk about "bad practice" - in a >>> hand-waving undocumented/unsubstantiated manner >> >> Building in sources has two problems: a) the content of the source tree can >> change so subsequent builds can be different from the clean one - you cannot >> undo that and b) if you update the sources stale files from previous builds >> can break the build. >> >> If solving your problems is "unproductive" then I'm not surprised you have >> them for 4 moths now. >> >> >>> - and options that might or might not work. If "--enable-lto" (or any other >>> options, or build within the dev directory) does not work reliably, it >>> should be either disabled/removed, or documented, or both. >> >> R cannot test all aspects of a compiler and detect all its bugs. It is >> *your* responsibility to provide a working compiler - if you are unwilling >> to do that, R cannot do anything about that. >> >> >>> Anyway, it has not been working for over 4 months. >>> >> >> That is not true, obviously, and I have presented a counter-example. It may >> not have been working for *you* and it's likely a problem in your setup >> (given your lack of cooperation there is no way to tell for sure). We cannot >> prevent user errors. We can try to point people in the right direction, but >> if they refuse to listen it's on their head. >> >> >>> You have about 6 weeks before this becomes a big problem - "big" as in >>> "wide-spread". >>> >> >> You are yet to show that this is a problem in R at all. You failed to follow >> the basic instructions in the FAQ. >> >> Cheers, >> Simon >> >> >> Cheers, Simon > > > 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-recommen
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 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 users.sourceforge.net> writes: > > --- On Fri, 15/2/13, Simon Urbanek 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 users.sourceforge.net> writes: > >> >> --- On Fri, 15/2/13, Simon Urbanek 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 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 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 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
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
>> 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{} 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
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
