From lgautier at gmail.com  Thu Mar  7 15:04:42 2013
From: lgautier at gmail.com (Laurent Gautier)
Date: Thu, 07 Mar 2013 15:04:42 +0100
Subject: [Rd] Printing warning messages around R_tryEval
In-Reply-To: <mailman.27.1362654009.12396.r-devel@r-project.org>
References: <mailman.27.1362654009.12396.r-devel@r-project.org>
Message-ID: <51389E7A.1010704@gmail.com>

We are having a similar issue with rpy2 and R-devel.
I would also vote for having back a C-level solution to the problem.

I cannot find an explicit explanation for the change in the SVN logs,
and traced the change to rev 61771:

------------------------------------------------------------------------
r61771 | ripley | 2013-01-29 12:09:45 +0100 (Tue, 29 Jan 2013) | 1 line

more hiding
------------------------------------------------------------------------

Could this mean that the change could reverted and Rf_PrintWarnings
just be added to the C API ?

Laurent


On 2013-03-07 12:00, r-devel-request at r-project.org wrote:
>
> Hi!
>
> In RKWard we use R_tryEval() at a number places to run R commands. In order to
> make sure that any generated warnings become visible close to the problem, we
> were following up (most of) these calls with Rf_PrintWarnings().
>
> Rf_PrintWarnings() was never available in the headers (as far as I know), and
> in r61771 the symbol has been hidden from libR.so. So this solution is no
> longer available. Could you give advice on the best way to print warnings
> before returning to the top level?
>
> Some available options, I am aware of:
> 1. Call R function warnings(). However, this will always print the latest
> warning, even if it was generate by some earlier command. I would need a way
> to print new warnings, only.
>
> 2. Use options(warn=1) where applicable. However, in some cases, collecting
> warnings until some procedure is complete, and printing them then, would be
> preferrable.
>
> 3. I see there is an internal call printDeferredWarnings(), which seems to be
> almost exactly what I want. However, using an .Internal() does not look like a
> terribly stable solution, either. Also, having direct access to a similar
> function from the C-API would be very comfortable.
>
> Thanks!
> Thomas



[Rd] Printing warning messages around R_tryEval
Laurent Gautier