[Rd] withAutoprint({ .... }) ?

luke-tierney at uiowa.edu luke-tierney at uiowa.edu
Fri Sep 2 19:56:41 CEST 2016


On Fri, 2 Sep 2016, Kirill Müller wrote:

> On 02.09.2016 14:38, Duncan Murdoch wrote:
>> On 02/09/2016 7:56 AM, Martin Maechler wrote:
>>> On R-help, with subject
>>>    '[R] source() does not include added code'
>>>
>>>>>>>> Joshua Ulrich <josh.m.ulrich at gmail.com>
>>>>>>>>     on Wed, 31 Aug 2016 10:35:01 -0500 writes:
>>>
>>>     > I have quantstrat installed and it works fine for me. If you're
>>>     > asking why the output of t(tradeStats('macross')) isn't being 
>>> printed,
>>>     > that's because of what's described in the first paragraph in the
>>>     > *Details* section of help("source"):
>>>
>>>     > Note that running code via ‘source’ differs in a few respects from
>>>     > entering it at the R command line.  Since expressions are not
>>>     > executed at the top level, auto-printing is not done. So you will
>>>     > need to include explicit ‘print’ calls for things you want to be
>>>     > printed (and remember that this includes plotting by ‘lattice’,
>>>     > FAQ Q7.22).
>>>
>>>
>>>
>>>     > So you need:
>>>
>>>     > print(t(tradeStats('macross')))
>>>
>>>     > if you want the output printed to the console.
>>>
>>> indeed, and "of course"" ;-)
>>>
>>> As my subject indicates, this is another case, where it would be
>>> very convenient to have a function
>>>
>>>    withAutoprint()
>>>
>>> so the OP could have (hopefully) have used
>>>    withAutoprint(source(..))
>>> though that would have been equivalent to the already nicely existing
>>>
>>>    source(.., print.eval = TRUE)
>>>
>>> which works via the  withVisible(.) utility that returns for each
>>> 'expression' if it would auto print or not, and then does print (or
>>> not) accordingly.
>>>
>>> My own use cases for such a withAutoprint({...})
>>> are demos and examples, sometimes even package tests which I want to 
>>> print:
>>>
>>> Assume I have a nice demo / example on a help page/ ...
>>>
>>> foo(..)
>>> (z <- bar(..))
>>> summary(z)
>>> ....
>>>
>>> where I carefully do print parts (and don't others),
>>> and suddenly I find I want to run that part of the demo /
>>> example / test only in some circumstances, e.g., only when
>>> interactive, but not in BATCH, or only if it is me, the package 
>>> maintainer,
>>>
>>> if( identical(Sys.getenv("USER"), "maechler") ) {
>>>   foo(..)
>>>   (z <- bar(..))
>>>   summary(z)
>>>   ....
>>> }
>>>
>>> Now all the auto-printing is gone, and
>>>
>>> 1) I have to find out which of these function calls do autoprint and 
>>> wrap
>>>    a print(..) around these, and
>>>
>>> 2) the result is quite ugly (for an example on a help page etc.)
>>>
>>> What I would like in a future R, is to be able to simply wrap the "{
>>> .. } above with an 'withAutoprint(.) :
>>>
>>> if( identical(Sys.getenv("USER"), "maechler") ) withAutoprint({
>>>   foo(..)
>>>   (z <- bar(..))
>>>   summary(z)
>>>   ....
>>> })
>>>
>>> Conceptually such a function could be written similar to source() 
>>> with an R
>>> level for loop, treating each expression separately, calling eval(.) 
>>> etc.
>>> That may cost too much performnace, ... still to have it would be 
>>> better than
>>> not having the possibility.
>>>
>>> ----
>>>
>>> If you read so far, you'd probably agree that such a function
>>> could be a nice asset in R,
>>> notably if it was possible to do this on the fast C level of R's main
>>> REPL.
>>>
>>> Have any of you looked into how this could be provided in R ?
>>> If you know the source a little, you will remember that there's
>>> the global variable  R_Visible  which is crucial here.
>>> The problem with that is that it *is* global, and only available
>>> as that; that the auto-printing "concept" is so linked to "toplevel 
>>> context"
>>> and that is not easy, and AFAIK not so much centralized in one place 
>>> in the
>>> source. Consequently, all kind of (very) low level functions 
>>> manipulate R_Visible
>>> temporarily.... and so a C level implementation of withAutoprint() may
>>> need considerable more changes than just setting R_Visible to TRUE in 
>>> one
>>> place.
>>>
>>> Have any efforts / experiments already happened towards providing such
>>> functionality ?
>>
>> I don't think the performance cost would matter.  If you're printing 
>> something, you're already slow.  So doing this at the R level would 
>> make most sense to me --- that's how Sweave and source and knitr do 
>> it, so it can't be that bad.
>>
>> Duncan Murdoch
>>
> A C-level implementation would bring the benefit of a lean traceback() 
> in case of an error. I suspect eval() could be enhanced to auto-print.
>
> By the same token it would be extremely helpful to have a C-level 
> implementation of local() which wouldn't litter the stack trace.

local() within a byte compiled function already produces a less
cluttered traceback, though perhaps not ideal. Moving the interpreted
version closer to the compiled one is in the works.

Best,

luke

>
>
> -Kirill
>
> ______________________________________________
> R-devel at r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel

-- 
Luke Tierney
Ralph E. Wareham Professor of Mathematical Sciences
University of Iowa                  Phone:             319-335-3386
Department of Statistics and        Fax:               319-335-3017
    Actuarial Science
241 Schaeffer Hall                  email:   luke-tierney at uiowa.edu
Iowa City, IA 52242                 WWW:  http://www.stat.uiowa.edu


More information about the R-devel mailing list