Re: [Rd] R 2.15.2 still missing two files useful with the X11 icon patch
Glad to see this as well. Two notes on Dirk's comments: 1) As Dirk wrote, the changes in 2.15.2 apply to almost any X11 system (although, as the NEWS says, this change is particularly crucial with Ubuntu's new Unity interface). 2) The additional two files mentioned by Dirk are only useful on systems complying with the freedesktop.org standards (i.e., at least gnome and kde). With Unity, these files result in a crisper icon in the Unity launcher. To summarize: the change in R 2.15.2 helps any X11 system. The additional two files not yet in mainline R help only freedesktop.org-compliant systems -- although I can't imagine how they would hurt any other system. Thanks for incorporating at least the first patch into main line development! Regards, Philip On 10/26/2012 10:07 AM, Dirk Eddelbuettel wrote: Congrats on getting 2.15.2 out on schedule. Debian builds have been uploaded. It is my understanding that Phil's patch for the X11 logo -- so promimently featured as the first item in the NEWS file for the release -- offers more when two extra files are supplied. I have supplied these for the Debian test release, for our 2.15.1-* releases and again now. We install these files as /usr/share/icons/hicolor/48x48/apps/rlogo_icon.png /usr/share/applications/R.desktop and I would urge R Core to do the same so that users of other binaries get the same benefit. I have in fact mailed twice already before about this. As I understand, with the 'desktop' files and the png it references, menus showing R as an entry get more meta info, and a crisper (png) logo. Now, the NEWS file entry is also half-incorrect. The benefit of the patch is visible in Ubuntu, nomatter which desktop env you use, but not limited to it. Even under Windows 7, the taskbar now supplies the R icon when the patched Debian / Ubuntu build is used --- but not with an rpm build of 2.15.1 where the generic x11 icon is shown. Having R windows visually identified as such is very useful, no matter the Linux or X11 flavour. And that is what Phil's patch does this: adds the feature no matter the X11 GUI or desktop environment. Dirk __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R 2.15.2 make check failure on 32-bit --with-blas="-lgoto2"
On 12-10-26 12:15 PM, Prof Brian Ripley wrote:
On 26/10/2012 16:37, Paul Gilbert wrote:
Is --with-blas="-lgoto2" a known problem (other than possibly not being
the preferred choice)?
And what precisely is it? And what chipset are you using?
I thought I had been testing RC with the same setup I regularly use, but
I now see there was a slight difference. I am now getting the following
failure in make check on 32-bit Ubuntu 12.04, configuring with
--with-blas="-lgoto2". (These may not be surprising statistically or
numerically, but it is a bit disconcerting when make check fails.)
No failure shown here ... surely you know that the signs of principal
components are not determined?
I apologize, I missed the real error. (But yes, I am aware of this, and
also that I should expect precision differences with different libraries
and different architectures.) I thought for a moment that make was
throwing an error because of the differences, but in fact it was later:
Testing examples for package ‘grid’
comparing ‘grid-Ex.Rout’ to ‘grid-Ex.Rout.save’ ... OK
Testing examples for package ‘splines’
Error: testing 'splines' failed
Execution halted
make[3]: *** [test-Examples-Base] Error 1
make[3]: Leaving directory `/home/paul/RoboAdmin/R-2.15.2/tests/Examples'
make[2]: *** [test-Examples] Error 2
make[2]: Leaving directory `/home/paul/RoboAdmin/R-2.15.2/tests'
make[1]: *** [test-all-basics] Error 1
make[1]: Leaving directory `/home/paul/RoboAdmin/R-2.15.2/tests'
make: *** [check] Error 2
paul@toaster:~/RoboAdmin/R-2.15.2$
The problem seems to be here:
> source("~/RoboAdmin/R-2.15.2/tests/Examples/splines-Ex.R")
List of 2
$ x: num [1:51] 58 58.3 58.6 58.8 59.1 ...
$ y: num [1:51] 115 115 116 117 117 ...
- attr(*, "class")= chr "xyVector"
Warning in bs(height, degree = 3L, knots = c(62.7,
67.3 :
some 'x' values beyond boundary knots may cause ill-conditioned bases
Error: identical(ns(x, df = 2), ns(x, df = 2, knots = NULL)) is not TRUE
> traceback()
6: stop(paste0(ch, " is not ", if (length(r) > 1L) "all ", "TRUE"),
call. = FALSE)
5: stopifnot(identical(ns(x), ns(x, df = 1)), identical(ns(x, df = 2),
ns(x, df = 2, knots = NULL)), !is.null(kk <- attr(ns(x),
"knots")), length(kk) == 0) at splines-Ex.R#130
4: eval(expr, envir, enclos)
3: eval(ei, envir)
2: withVisible(eval(ei, envir))
1: source("~/RoboAdmin/R-2.15.2/tests/Examples/splines-Ex.R")
>
It also seems that this error is transient. If I rerun several times, it
does not always happen. Is anyone aware of other cases of transient
problems with 32-bit goto2?
Here is the cpu info:
paul@toaster:~$ cat /proc/cpuinfo
processor : 0
vendor_id : GenuineIntel
cpu family : 6
model : 15
model name : Intel(R) Core(TM)2 Duo CPU T7300 @ 2.00GHz
stepping: 10
microcode : 0x92
cpu MHz : 800.000
cache size : 4096 KB
physical id : 0
siblings: 2
core id : 0
cpu cores : 2
apicid : 0
initial apicid : 0
fdiv_bug: no
hlt_bug : no
f00f_bug: no
coma_bug: no
fpu : yes
fpu_exception : yes
cpuid level : 10
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic mtrr pge mca cmov pat
pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe nx lm constant_tsc
arch_perfmon pebs bts aperfmperf pni dtes64 monitor ds_cpl vmx est tm2
ssse3 cx16 xtpr pdcm lahf_lm ida dtherm tpr_shadow vnmi flexpriority
bogomips: 3989.99
clflush size: 64
cache_alignment : 64
address sizes : 36 bits physical, 48 bits virtual
power management:
processor : 1
vendor_id : GenuineIntel
cpu family : 6
model : 15
model name : Intel(R) Core(TM)2 Duo CPU T7300 @ 2.00GHz
stepping: 10
microcode : 0x92
cpu MHz : 800.000
cache size : 4096 KB
physical id : 0
siblings: 2
core id : 1
cpu cores : 2
apicid : 1
initial apicid : 1
fdiv_bug: no
hlt_bug : no
f00f_bug: no
coma_bug: no
fpu : yes
fpu_exception : yes
cpuid level : 10
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic mtrr pge mca cmov pat
pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe nx lm constant_tsc
arch_perfmon pebs bts aperfmperf pni dtes64 monitor ds_cpl vmx est tm2
ssse3 cx16 xtpr pdcm lahf_lm ida dtherm tpr_shadow vnmi flexpriority
bogomips: 3989.97
clflush size: 64
cache_alignment : 64
address sizes : 36 bits physical, 48 bits virtual
power management:
Paul
And 32-bit platforms seem prone to round in different ways (to each
other and to 64-bit platforms): the differences in the last digit are
typical of 32-bit platforms.
...
Testing examples for package ‘stats’
comparing ‘stats-Ex.Rout’ to ‘stats-Ex.Rout.save’ ...
2959c2959
< N:K1 33.13 33.13 2.146 0.16865
---
> N:K1 33.14 33.14 2.146 0.1
Re: [Rd] R 2.15.2 make check failure on 32-bit --with-blas="-lgoto2"
On 26/10/2012 16:37, Paul Gilbert wrote: Is --with-blas="-lgoto2" a known problem (other than possibly not being the preferred choice)? And what precisely is it? And what chipset are you using? I thought I had been testing RC with the same setup I regularly use, but I now see there was a slight difference. I am now getting the following failure in make check on 32-bit Ubuntu 12.04, configuring with --with-blas="-lgoto2". (These may not be surprising statistically or numerically, but it is a bit disconcerting when make check fails.) No failure shown here ... surely you know that the signs of principal components are not determined? And 32-bit platforms seem prone to round in different ways (to each other and to 64-bit platforms): the differences in the last digit are typical of 32-bit platforms. ... Testing examples for package ‘stats’ comparing ‘stats-Ex.Rout’ to ‘stats-Ex.Rout.save’ ... 2959c2959 < N:K1 33.13 33.13 2.146 0.16865 --- > N:K1 33.14 33.14 2.146 0.16865 12782c12782 < Murder -0.536 0.418 0.341 0.649 --- > Murder -0.536 0.418 -0.341 0.649 12783c12783 < Assault -0.583 0.188 0.268 -0.743 --- > Assault -0.583 0.188 -0.268 -0.743 12784c12784 < UrbanPop -0.278 -0.873 0.378 0.134 --- > UrbanPop -0.278 -0.873 -0.378 0.134 12785c12785 < Rape -0.543 -0.167 -0.818 --- > Rape -0.543 -0.167 0.818 12943c12943 < 6 -0.5412 20.482886-0.845157 --- > 6 -0.5412 20.482887-0.845157 14481c14481 < Sum of Squares 780.1250 276.1250 2556.1250 112.5000 774.0937 --- > Sum of Squares 780.1250 276.1250 2556.1250 112.5000 774.0938 15571c15571 < Murder -0.54 0.42 0.34 0.65 --- > Murder -0.54 0.42 -0.34 0.65 15572c15572 < Assault -0.58 0.27 -0.74 --- > Assault -0.58 -0.27 -0.74 15573c15573 < UrbanPop -0.28 -0.87 0.38 --- > UrbanPop -0.28 -0.87 -0.38 15574c15574 < Rape -0.54 -0.82 --- > Rape -0.54 0.82 Testing examples for package ‘datasets’ comparing ‘datasets-Ex.Rout’ to ‘datasets-Ex.Rout.save’ ... OK ... I inadvertently seemed to have set things slightly differently while testing RC. While testing the RC, I was using ./configure --prefix=/home/paul/RoboRC/R-test/ --enable-R-shlib and configure gave ... External libraries:readline Additional capabilities: PNG, NLS Options enabled: shared R library, shared BLAS, R profiling, Java whereas with the release I used ./configure --prefix=/home/paul/RoboAdmin/R-2.15.2 --enable-R-shlib --with-blas="-lgoto2" and configure gave ... External libraries:readline, BLAS(generic) Additional capabilities: PNG, NLS Options enabled: shared R library, R profiling, Java Thanks, Paul __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel -- Brian D. Ripley, rip...@stats.ox.ac.uk Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/ University of Oxford, Tel: +44 1865 272861 (self) 1 South Parks Road, +44 1865 272866 (PA) Oxford OX1 3TG, UKFax: +44 1865 272595 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] R 2.15.2 make check failure on 32-bit --with-blas="-lgoto2"
Is --with-blas="-lgoto2" a known problem (other than possibly not being the preferred choice)? I thought I had been testing RC with the same setup I regularly use, but I now see there was a slight difference. I am now getting the following failure in make check on 32-bit Ubuntu 12.04, configuring with --with-blas="-lgoto2". (These may not be surprising statistically or numerically, but it is a bit disconcerting when make check fails.) ... Testing examples for package ‘stats’ comparing ‘stats-Ex.Rout’ to ‘stats-Ex.Rout.save’ ... 2959c2959 < N:K1 33.13 33.13 2.146 0.16865 --- > N:K1 33.14 33.14 2.146 0.16865 12782c12782 < Murder -0.536 0.418 0.341 0.649 --- > Murder -0.536 0.418 -0.341 0.649 12783c12783 < Assault -0.583 0.188 0.268 -0.743 --- > Assault -0.583 0.188 -0.268 -0.743 12784c12784 < UrbanPop -0.278 -0.873 0.378 0.134 --- > UrbanPop -0.278 -0.873 -0.378 0.134 12785c12785 < Rape -0.543 -0.167 -0.818 --- > Rape -0.543 -0.167 0.818 12943c12943 < 6 -0.5412 20.482886-0.845157 --- > 6 -0.5412 20.482887-0.845157 14481c14481 < Sum of Squares 780.1250 276.1250 2556.1250 112.5000 774.0937 --- > Sum of Squares 780.1250 276.1250 2556.1250 112.5000 774.0938 15571c15571 < Murder -0.54 0.42 0.34 0.65 --- > Murder -0.54 0.42 -0.34 0.65 15572c15572 < Assault -0.58 0.27 -0.74 --- > Assault -0.58 -0.27 -0.74 15573c15573 < UrbanPop -0.28 -0.87 0.38 --- > UrbanPop -0.28 -0.87 -0.38 15574c15574 < Rape -0.54 -0.82 --- > Rape -0.54 0.82 Testing examples for package ‘datasets’ comparing ‘datasets-Ex.Rout’ to ‘datasets-Ex.Rout.save’ ... OK ... I inadvertently seemed to have set things slightly differently while testing RC. While testing the RC, I was using ./configure --prefix=/home/paul/RoboRC/R-test/ --enable-R-shlib and configure gave ... External libraries:readline Additional capabilities: PNG, NLS Options enabled: shared R library, shared BLAS, R profiling, Java whereas with the release I used ./configure --prefix=/home/paul/RoboAdmin/R-2.15.2 --enable-R-shlib --with-blas="-lgoto2" and configure gave ... External libraries:readline, BLAS(generic) Additional capabilities: PNG, NLS Options enabled: shared R library, R profiling, Java Thanks, Paul __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] R 2.15.2 still missing two files useful with the X11 icon patch
Congrats on getting 2.15.2 out on schedule. Debian builds have been uploaded. It is my understanding that Phil's patch for the X11 logo -- so promimently featured as the first item in the NEWS file for the release -- offers more when two extra files are supplied. I have supplied these for the Debian test release, for our 2.15.1-* releases and again now. We install these files as /usr/share/icons/hicolor/48x48/apps/rlogo_icon.png /usr/share/applications/R.desktop and I would urge R Core to do the same so that users of other binaries get the same benefit. I have in fact mailed twice already before about this. As I understand, with the 'desktop' files and the png it references, menus showing R as an entry get more meta info, and a crisper (png) logo. Now, the NEWS file entry is also half-incorrect. The benefit of the patch is visible in Ubuntu, nomatter which desktop env you use, but not limited to it. Even under Windows 7, the taskbar now supplies the R icon when the patched Debian / Ubuntu build is used --- but not with an rpm build of 2.15.1 where the generic x11 icon is shown. Having R windows visually identified as such is very useful, no matter the Linux or X11 flavour. And that is what Phil's patch does this: adds the feature no matter the X11 GUI or desktop environment. Dirk -- Dirk Eddelbuettel | e...@debian.org | http://dirk.eddelbuettel.com __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] suppress *specific* warnings?
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 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
locale, and your pattern won't be detected.
- Ditto if from a recommended package.
- If it is a warning that is not translated then it may be that
it is just not *YET* translated.
I think the other Martin's suggestion addressed this: he matched the
translated message, not the English original.
Duncan Murdoch
Well, I don't think I understand.
Of course you can only match "the message" that warning() or
error() {or rather tryCatch() ,...} produces.
But you cannot guarantee nor know (for sure) if that message is 'original'
or translated.
"cannot", because AFAIK
we cannot guarantee Sys.setlocale() is obeyed platform
independently:
You would have to query the current and save that, set it to C, get the
message, and then reset the locale to the previously saved one.
And these do not work reliably, on some platforms, AFAIK and
read our documentation.
I think the point was to use gettext() on the pattern-to-match. If
the warning is translated, so would this be. The main limitations would seem
to be that you have to be d*mn sure to get the spelling right and,
presumably, it only works with straight string translations, not variant
forms like
msgid "found %d fatal error"
msgid_plural "found %d fatal errors"
msgstr[0] "s'ha trobat %d error fatal"
msgstr[1] "s'han trobat %d errors fatals"
Yes: you also need to get the domain right (and it would be unsafe not
to specify it on the gettext() call). And C-level messages do move
between domains; for example between R 2.15.x and R-devel most of the
graphics ones have moved from 'R' to 'graphics'.
--
Brian D. Ripley, rip...@stats.ox.ac.uk
Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/
University of Oxford, Tel: +44 1865 272861 (self)
1 South Parks Road, +44 1865 272866 (PA)
Oxford OX1 3TG, UKFax: +44 1865 272595
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] suppress *specific* warnings?
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 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
>>> locale, and your pattern won't be detected.
>>>
>>> - Ditto if from a recommended package.
>>>
>>> - If it is a warning that is not translated then it may be that
>>> it is just not *YET* translated.
>
>> I think the other Martin's suggestion addressed this: he matched the
>> translated message, not the English original.
>
>> Duncan Murdoch
>
> Well, I don't think I understand.
> Of course you can only match "the message" that warning() or
> error() {or rather tryCatch() ,...} produces.
> But you cannot guarantee nor know (for sure) if that message is 'original'
> or translated.
> "cannot", because AFAIK
> we cannot guarantee Sys.setlocale() is obeyed platform
> independently:
> You would have to query the current and save that, set it to C, get the
> message, and then reset the locale to the previously saved one.
> And these do not work reliably, on some platforms, AFAIK and
> read our documentation.
I think the point was to use gettext() on the pattern-to-match. If the warning
is translated, so would this be. The main limitations would seem to be that you
have to be d*mn sure to get the spelling right and, presumably, it only works
with straight string translations, not variant forms like
msgid "found %d fatal error"
msgid_plural "found %d fatal errors"
msgstr[0] "s'ha trobat %d error fatal"
msgstr[1] "s'han trobat %d errors fatals"
>
> Martin
>
>>>
>>> The really dangerous thing about matching error / warning
>>> messages -- I had done it in the past with the error message I
>>> caught via tryCatch() --
>>> is that
>>> - in your tests the code will work perfectly.
>>> - on CRAN the code will work perfectly, as "they" also use
>>> the English (or C) locale.
>>>
>>> So, by doing this you are distributing code that "almost always"
>>> works ... in your environment if you are US, UK or similarly
>>> based.
>>>
>>> Indeed, a *really* dangerous practice.
>>>
>>> Martin Maechler, ETH Zurich
>>>
>>>
>>>
>>>
Martin Morgan
on Tue, 23 Oct 2012 05:28:48 -0700 writes:
>>>
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 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 current design of suppressWarnings() forces
>>> me to ignore *any* warnings coming from the expression.
>>>
>>> I started to write a new version that would check and, if supplied
>>> with a regular expression, would only block matching warnings and
>>> otherwise would produce the warnings as usual, but I don't quite know
>>> enough about what I'm doing: see ??? in expression below.
>>>
>>> Can anyone help, or suggest pointers to relevant
>>> examples/documentation (I've looked at demo(error.catching), which isn't
>>> helping me ... ?)
>>>
>>> suppressWarnings2 <- function(expr,regex=NULL) {
>>> opts <- options(warn = -1)
>>> on.exit(options(opts))
>>
>> I'm not really sure what the options(warn=-1) is doing there, maybe its
>> for
>> efficiency to avoid generating a warning message (as distinct from
>> signalling
>
> The sources in srs/library/base/conditions.R have
>
> suppressWarnings <- function(expr) {
> ops <- options(warn = -1) ## FIXME: temporary hack until R_tryEval
> on.exit(options(ops)) ## calls are removed from methods code
> withCallingHandlers(expr,
> warning=function(w)
> invokeRestart("muffleWarning"))
> }
>
> I uspect we have still not entirely eliminated R_tryEval in this context
> but I'm not sure. Will check when I get a chance.
>
>> a warning). I think you're after something like
>>
>> suppressWarnings2 <-
>> function(expr, regex=character())
>> {
>> withCallingHandlers(expr, warning=function(w) {
>> if (length(regex) == 1 && length(grep(regex, conditionMessage(w {
>> invokeRestart("muffleWarning")
>> }
>> })
>> }
>
> A problem with using expression matching is of course that this fails
> with internationalized messages. Ideally warnings should be signa
[Rd] Namespace Dependencies not required
Hi, I am trying to build an R package so reading the manual on CRAN. I could figure out that using imports to load functions in your namespace would be the best bet to use in the Description file. After adding to the description file, I also added it to the namespace file. I added importFrom to the namespace file with the functions required. Now when I run R CMD check on my package, I get an ERROR as Namespace dependencies not required : 'ggplot2' Further imformation : Even if i add the package to the Depends in the description file, they are not getting loaded. Please help with this. Mayank Bansal| +91 9901729939 | www.mu-sigma.com | This email message may contain proprietary, private and confidential information. The information transmitted is intended only for the person(s) or entities to which it is addressed. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited and may be illegal. If you received this in error, please contact the sender and delete the message from your system. Mu Sigma takes all reasonable steps to ensure that its electronic communications are free from viruses. However, given Internet accessibility, the Company cannot accept liability for any virus introduced by this e-mail or any attachment and you are advised to use up-to-date virus checking software. [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] suppress *specific* warnings?
> 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 design" :
>>
>> Internationalization / Localization:
>>
>> - If the warning comes from a "standard R" function,
>> the warning is almost surely different in a (say) German
>> locale, and your pattern won't be detected.
>>
>> - Ditto if from a recommended package.
>>
>> - If it is a warning that is not translated then it may be that
>> it is just not *YET* translated.
> I think the other Martin's suggestion addressed this: he matched the
> translated message, not the English original.
> Duncan Murdoch
Well, I don't think I understand.
Of course you can only match "the message" that warning() or
error() {or rather tryCatch() ,...} produces.
But you cannot guarantee nor know (for sure) if that message is 'original'
or translated.
"cannot", because AFAIK
we cannot guarantee Sys.setlocale() is obeyed platform
independently:
You would have to query the current and save that, set it to C, get the
message, and then reset the locale to the previously saved one.
And these do not work reliably, on some platforms, AFAIK and
read our documentation.
Martin
>>
>> The really dangerous thing about matching error / warning
>> messages -- I had done it in the past with the error message I
>> caught via tryCatch() --
>> is that
>> - in your tests the code will work perfectly.
>> - on CRAN the code will work perfectly, as "they" also use
>> the English (or C) locale.
>>
>> So, by doing this you are distributing code that "almost always"
>> works ... in your environment if you are US, UK or similarly
>> based.
>>
>> Indeed, a *really* dangerous practice.
>>
>> Martin Maechler, ETH Zurich
>>
>>
>>
>>
>>> Martin Morgan
>>> on Tue, 23 Oct 2012 05:28:48 -0700 writes:
>>
>> > 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 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 current design of suppressWarnings()
forces
>> me to ignore *any* warnings coming from the expression.
>>
>> I started to write a new version that would check and, if supplied
>> with a regular expression, would only block matching warnings and
>> otherwise would produce the warnings as usual, but I don't quite
know
>> enough about what I'm doing: see ??? in expression below.
>>
>> Can anyone help, or suggest pointers to relevant
>> examples/documentation (I've looked at demo(error.catching), which
isn't
>> helping me ... ?)
>>
>> suppressWarnings2 <- function(expr,regex=NULL) {
>> opts <- options(warn = -1)
>> on.exit(options(opts))
>> >>>
>> >>> I'm not really sure what the options(warn=-1) is doing there, maybe
its for
>> >>> efficiency to avoid generating a warning message (as distinct from
signalling
>> >>
>> >> The sources in srs/library/base/conditions.R have
>> >>
>> >> suppressWarnings <- function(expr) {
>> >> ops <- options(warn = -1) ## FIXME: temporary hack until R_tryEval
>> >> on.exit(options(ops)) ## calls are removed from methods code
>> >> withCallingHandlers(expr,
>> >> warning=function(w)
>> >> invokeRestart("muffleWarning"))
>> >> }
>> >>
>> >> I uspect we have still not entirely eliminated R_tryEval in this
context
>> >> but I'm not sure. Will check when I get a chance.
>> >>
>> >>> a warning). I think you're after something like
>> >>>
>> >>> suppressWarnings2 <-
>> >>> function(expr, regex=character())
>> >>> {
>> >>> withCallingHandlers(expr, warning=function(w) {
>> >>> if (length(regex) == 1 && length(grep(regex, conditionMessage(w {
>> >>> invokeRestart("muffleWarning")
>> >>> }
>> >>> })
>> >>> }
>> >>
>> >> A problem with using expression matching is of course that this fails
>> >> with internationalized messages. Ideally warnings should be signaled
as
>> >> warning conditions of a particular class, and that class can be used
>> >> to discriminate. Unfortunately very few warnings are designed this
way.
>>
>> > Probably specific messages, rather than patterns,
