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.ulr...@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@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-tier...@uiowa.edu
Iowa City, IA 52242                 WWW:  http://www.stat.uiowa.edu
______________________________________________
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Reply via email to