[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