For my logging package (futile.logger) any log statements coming from a package
are assigned to a package namespace. This way you have control of log messages
at a package level (e.g. I can set the default log threshold to DEBUG, while
package 'A' has a log threshold of WARN).
I seems a hierar
On 04/18/2013 05:57 AM, Duncan Murdoch wrote:
On 13-04-18 7:31 AM, Felix Schönbrodt wrote:
Hello,
is there a convenient way to suppress only *specific* warnings? (I know about
?suppressWarnings)
I depend on another package, from which I want to suppress only some warnings,
but not others.
Thi
On 13-04-18 7:31 AM, Felix Schönbrodt wrote:
Hello,
is there a convenient way to suppress only *specific* warnings? (I know about
?suppressWarnings)
I depend on another package, from which I want to suppress only some warnings,
but not others.
This is difficult in most cases, because most pa
Hello,
is there a convenient way to suppress only *specific* warnings? (I know about
?suppressWarnings)
I depend on another package, from which I want to suppress only some warnings,
but not others.
Felix
__
R-devel@r-project.org mailing list
https://
On 26/10/2012 12:04, peter dalgaard wrote:
On Oct 26, 2012, at 11:17 , Martin Maechler wrote:
Duncan Murdoch
on Thu, 25 Oct 2012 06:51:25 -0400 writes:
On 12-10-25 5:28 AM, Martin Maechler wrote:
Sorry guys, for coming late,
but *please* don't go there.
I've been there years ago,
and
On Oct 26, 2012, at 11:17 , Martin Maechler wrote:
>> Duncan Murdoch
>>on Thu, 25 Oct 2012 06:51:25 -0400 writes:
>
>> On 12-10-25 5:28 AM, Martin Maechler wrote:
>>> Sorry guys, for coming late,
>>> but *please* don't go there.
>>>
>>> I've been there years ago,
>>> and found late
> Duncan Murdoch
> on Thu, 25 Oct 2012 06:51:25 -0400 writes:
> On 12-10-25 5:28 AM, Martin Maechler wrote:
>> Sorry guys, for coming late,
>> but *please* don't go there.
>>
>> I've been there years ago,
>> and found later why the approach is flawed "by desig
On 12-10-25 5:28 AM, Martin Maechler wrote:
Sorry guys, for coming late,
but *please* don't go there.
I've been there years ago,
and found later why the approach is flawed "by design" :
Internationalization / Localization:
- If the warning comes from a "standard R" function,
the warning is
Sorry guys, for coming late,
but *please* don't go there.
I've been there years ago,
and found later why the approach is flawed "by design" :
Internationalization / Localization:
- If the warning comes from a "standard R" function,
the warning is almost surely different in a (say) German
loc
On 10/22/2012 09:57 AM, luke-tier...@uiowa.edu wrote:
On Sun, 21 Oct 2012, Martin Morgan wrote:
On 10/21/2012 12:28 PM, Ben Bolker wrote:
Not desperately important, but nice to have and possibly of use to
others, is the ability to suppress specific warnings rather than
suppressing warnings
On Sun, 21 Oct 2012, Martin Morgan wrote:
On 10/21/2012 12:28 PM, Ben Bolker wrote:
Not desperately important, but nice to have and possibly of use to
others, is the ability to suppress specific warnings rather than
suppressing warnings indiscriminately. I often know of a specific
warning
On 12-10-21 09:08 PM, Martin Morgan wrote:
> On 10/21/2012 12:28 PM, Ben Bolker wrote:
>>
>>Not desperately important, but nice to have and possibly of use to
>> others, is the ability to suppress specific warnings rather than
>> suppressing warnings indiscriminately. I often know of a specifi
On 10/21/2012 12:28 PM, Ben Bolker wrote:
Not desperately important, but nice to have and possibly of use to
others, is the ability to suppress specific warnings rather than
suppressing warnings indiscriminately. I often know of a specific
warning that I want to ignore (because I know that's
Not desperately important, but nice to have and possibly of use to
others, is the ability to suppress specific warnings rather than
suppressing warnings indiscriminately. I often know of a specific
warning that I want to ignore (because I know that's it's a false
positive/ignorable), but the cu
14 matches
Mail list logo
