Re: [Bioc-devel] SSL certificate error on nebbiolo2

2021-11-05 Thread Hervé Pagès
Thanks Mike. I never heard about useEnsembl() before. That sounds like a 
nice addition. There are a few packages maintained by the core team 
(OrganismDbi, GenomicFeatures, etc...) where we still use useMart(). 
These packages are victims of the Ensembl Mart flakiness almost every 
day on the build report :-/ Sounds like we should really give 
useEnsembl() a try ;-)


I also see that the use of useMart() vs useEnsembl() is still about 80% 
vs 20% across all Bioconductor software packages. I wonder if you would 
consider advertising the latter a little bit e.g. by mentioning it in 
the man page for useMart() and also maybe by emitting a note or warning 
when people use useMart() to access the ensembl Mart. What do you think?


Cheers,
H.


On 04/11/2021 15:02, Mike Smith wrote:

Hi Nico,

Please try changing your calls to useMart() to useEnsembl().  That 
function has some checking that should detect this problem (it's real 
for all Ubuntu 20.04 users, plus various other Linux distros) and will 
try to apply the appropriate fix in the background.  There's some 
further suggestions in the biomaRt vignette at if that doesn't work - 
https://bioconductor.org/packages/release/bioc/vignettes/biomaRt/inst/doc/accessing_ensembl.html#connection-troubleshooting 
 



The weird certificates that produce the issue are only on the Ensembl 
mirror sites, so it should not happen with the default arguments to 
useMart(), but if biomaRt finds it's taking > 10 seconds to get a 
response it will see if one of the mirrors is more responsive.  That's 
why it might take a variable number of tries before reproducing the problem.


Best,
Mike

On Thu, 4 Nov 2021 at 20:42, Hervé Pagès > wrote:


Hi Nico,

This looks like the usual flakiness of the Ensembl Mart service. I see
these errors on the build report every day for various packages. The
exact set of packages varies.

I can reproduce on my laptop (Ubuntu 21.04):

    > library(biomaRt)

    > ensembl <- useMart(biomart = "ensembl", dataset =
"dmelanogaster_gene_ensembl")

    > ensembl <- useMart(biomart = "ensembl", dataset =
"dmelanogaster_gene_ensembl")

    > ensembl <- useMart(biomart = "ensembl", dataset =
"dmelanogaster_gene_ensembl")

    Ensembl site unresponsive, trying uswest mirror

    Error in curl::curl_fetch_memory(url, handle = handle) :

      SSL certificate problem: unable to get local issuer certificate


See my sessionInfo() below.

Note that I had to try 3 times before getting the error.

I can also reproduce this with the Docker container for RELEASE_3_14
but
this time it took me 12 attempts:

  > library(biomaRt)
  > ensembl <- useMart(biomart = "ensembl", dataset =
"dmelanogaster_gene_ensembl")
  > ensembl <- useMart(biomart = "ensembl", dataset =
"dmelanogaster_gene_ensembl")
  > ensembl <- useMart(biomart = "ensembl", dataset =
"dmelanogaster_gene_ensembl")
  > ensembl <- useMart(biomart = "ensembl", dataset =
"dmelanogaster_gene_ensembl")
  > ensembl <- useMart(biomart = "ensembl", dataset =
"dmelanogaster_gene_ensembl")
  > ensembl <- useMart(biomart = "ensembl", dataset =
"dmelanogaster_gene_ensembl")
  > ensembl <- useMart(biomart = "ensembl", dataset =
"dmelanogaster_gene_ensembl")
  > ensembl <- useMart(biomart = "ensembl", dataset =
"dmelanogaster_gene_ensembl")
  > ensembl <- useMart(biomart = "ensembl", dataset =
"dmelanogaster_gene_ensembl")
  > ensembl <- useMart(biomart = "ensembl", dataset =
"dmelanogaster_gene_ensembl")
  > ensembl <- useMart(biomart = "ensembl", dataset =
"dmelanogaster_gene_ensembl")
  > ensembl <- useMart(biomart = "ensembl", dataset =
"dmelanogaster_gene_ensembl")
Ensembl site unresponsive, trying asia mirror
Error in curl::curl_fetch_memory(url, handle = handle) :
    SSL certificate problem: unable to get local issuer certificate

See my sessionInfo() below.

I'm not sure there's something we can do on our Linux builders about
this, or if it would be a good idea at all to try to do something (the
problem is real and can affect anybody using Ubuntu). Maybe discuss
this
with Mike Smith by opening an issue here
https://github.com/grimbough/biomaRt


Best,
H.


sessionInfo() for my laptop session:


R version 4.1.1 (2021-08-10)

Platform: x86_64-pc-linux-gnu (64-bit)

Running under: Ubuntu 21.04



Matrix products: default

BLAS:   /home/hpages/R/R-4.1.1/lib/libRblas.so

LAPACK: /home/hpages/R/R-4.1.1/lib/libRlapack.so



locale:

   [1] LC_CTYPE=en_US.UTF-8       LC_NUMERIC=C

   [3] LC_TIME=en_GB              LC_COLLATE=en_US.UTF-8

   [5] 

Re: [Rd] gettext(msgid, domain="R") doesn't work for some 'msgid':s

2021-11-05 Thread Martin Maechler
> Martin Maechler 
> on Fri, 5 Nov 2021 17:55:24 +0100 writes:

> Tomas Kalibera 
> on Fri, 5 Nov 2021 16:15:19 +0100 writes:

>> On 11/5/21 4:12 PM, Duncan Murdoch wrote:
>>> On 05/11/2021 10:51 a.m., Henrik Bengtsson wrote:
 I'm trying to reuse some of the translations available in base R by 
 using:
 
    gettext(msgid, domain="R")
 
 This works great for most 'msgid's, e.g.
 
 $ LANGUAGE=de Rscript -e 'gettext("cannot get working directory", 
 domain="R")'
 [1] "kann das Arbeitsverzeichnis nicht ermitteln"
 
 However, it does not work for all.  For instance,
 
 $ LANGUAGE=de Rscript -e 'gettext("Execution halted\n", domain="R")'
 [1] "Execution halted\n"
 
 This despite that 'msgid' existing in:
 
 $ grep -C 2 -F 'Execution halted\n' src/library/base/po/de.po
 
 #: src/main/main.c:342
 msgid "Execution halted\n"
 msgstr "Ausführung angehalten\n"
 
 It could be that the trailing newline causes problems, because the
 same happens also for:
 
 $ LANGUAGE=de Rscript --vanilla -e 'gettext("error during cleanup\n",
 domain="R")'
 [1] "error during cleanup\n"
 
 Is this meant to work, and if so, how do I get it to work, or is it a 
 bug?
>>> 
>>> I don't know the solution, but I think the cause is different than you 
>>> think, because I also have the problem with other strings not 
>>> including "\n":
>>> 
>>> $ LANGUAGE=de Rscript -e 'gettext("malformed version string", 
>>> domain="R")'
>>> [1] "malformed version string"

> You need domain="R-base" for the  "malformed version "string"


>> I can reproduce Henrik's report and the problem there is that the 
>> trailing \n is stripped by R before doing the lookup, in do_gettext


>>     /* strip leading and trailing white spaces and
>>    add back after translation */
>>     for(p = tmp;
>>     *p && (*p == ' ' || *p == '\t' || *p == '\n');
>>     p++, ihead++) ;

>> But, calling dgettext with the trailing \n does translate correctly for 
me.

>> I'd leave to translation experts how this should work (e.g. whether the 
>> .po files should have trailing newlines).

> Thanks a lot, Tomas.
> This is "interesting" .. and I think an R bug  one way or the
> other (and I also note that Henrik's guess was also right on !).

> We have the following:

> - New translation *.po source files are to be made from the original 
*.pot  files.

> In our case it's our code that produce  R.pot and R-base.pot  
> (and more for the non-base packages, and more e.g. for
> Recommended packages 'Matrix' and 'cluster' I maintain).

> And notably the R.pot (from all the "base" C error/warn/.. messages)
> contains tons of msgid strings of the form  "...\n"
> i.e., ending in \n.
>> From that automatically the translator's  *.po files should also
> end in \n.

> Additionally, the GNU gettext FAQ has
> (here :   https://www.gnu.org/software/gettext/FAQ.html#newline )

> 
> Q: What does this mean: “'msgid' and 'msgstr' entries do not both end 
with '\n'”

> A: It means that when the original string ends in a newline, your 
translation must also end in a newline. And if the original string does not end 
in a newline, then your translation should likewise not have a newline at the 
end.
> 
 
>> From all that I'd conclude that we (R base code) are the source
> of the problem.
> Given the above FAQ, it seems common in other projects also to
> have such trailing \n  and so we should really change the C code
> you cite above.

> On the other hand, this is from almost the very beginning of
> when Brian added translation to R,
> 
> r32938 | ripley | 2005-01-30 20:24:04 +0100 (Sun, 30 Jan 2005) | 2 lines

> include \n in whitespace ignored for R-level gettext
> 

> I think this has been because simultaneously we had started to
> emphasize to useRs  they should *not* end message/format strings
> in stop() / warning()  by a new line, but rather stop() and
> warning() would *add* the newlines(s) themselves.

> Still, currently we have a few such cases in  R-base.pot,
> but just these few and maybe they really are "in error", in the
> sense we could drop the ending '\n' (and do the same in all the *.po 
files!),
> and newlines would be appended later {{not just by Rstudio which
> graceously adds 

Re: [Rd] gettext(msgid, domain="R") doesn't work for some 'msgid':s

2021-11-05 Thread Martin Maechler
> Tomas Kalibera 
> on Fri, 5 Nov 2021 16:15:19 +0100 writes:

> On 11/5/21 4:12 PM, Duncan Murdoch wrote:
>> On 05/11/2021 10:51 a.m., Henrik Bengtsson wrote:
>>> I'm trying to reuse some of the translations available in base R by 
>>> using:
>>> 
>>>    gettext(msgid, domain="R")
>>> 
>>> This works great for most 'msgid's, e.g.
>>> 
>>> $ LANGUAGE=de Rscript -e 'gettext("cannot get working directory", 
>>> domain="R")'
>>> [1] "kann das Arbeitsverzeichnis nicht ermitteln"
>>> 
>>> However, it does not work for all.  For instance,
>>> 
>>> $ LANGUAGE=de Rscript -e 'gettext("Execution halted\n", domain="R")'
>>> [1] "Execution halted\n"
>>> 
>>> This despite that 'msgid' existing in:
>>> 
>>> $ grep -C 2 -F 'Execution halted\n' src/library/base/po/de.po
>>> 
>>> #: src/main/main.c:342
>>> msgid "Execution halted\n"
>>> msgstr "Ausführung angehalten\n"
>>> 
>>> It could be that the trailing newline causes problems, because the
>>> same happens also for:
>>> 
>>> $ LANGUAGE=de Rscript --vanilla -e 'gettext("error during cleanup\n",
>>> domain="R")'
>>> [1] "error during cleanup\n"
>>> 
>>> Is this meant to work, and if so, how do I get it to work, or is it a 
>>> bug?
>> 
>> I don't know the solution, but I think the cause is different than you 
>> think, because I also have the problem with other strings not 
>> including "\n":
>> 
>> $ LANGUAGE=de Rscript -e 'gettext("malformed version string", 
>> domain="R")'
>> [1] "malformed version string"

You need domain="R-base" for the  "malformed version "string"


> I can reproduce Henrik's report and the problem there is that the 
> trailing \n is stripped by R before doing the lookup, in do_gettext


>     /* strip leading and trailing white spaces and
>    add back after translation */
>     for(p = tmp;
>     *p && (*p == ' ' || *p == '\t' || *p == '\n');
>     p++, ihead++) ;

> But, calling dgettext with the trailing \n does translate correctly for 
me.

> I'd leave to translation experts how this should work (e.g. whether the 
> .po files should have trailing newlines).

Thanks a lot, Tomas.
This is "interesting" .. and I think an R bug  one way or the
other (and I also note that Henrik's guess was also right on !).

We have the following:

- New translation *.po source files are to be made from the original *.pot  
files.

  In our case it's our code that produce  R.pot and R-base.pot  
  (and more for the non-base packages, and more e.g. for
   Recommended packages 'Matrix' and 'cluster' I maintain).

And notably the R.pot (from all the "base" C error/warn/.. messages)
contains tons of msgid strings of the form  "...\n"
i.e., ending in \n.
>From that automatically the translator's  *.po files should also
end in \n.

Additionally, the GNU gettext FAQ has
 (here :   https://www.gnu.org/software/gettext/FAQ.html#newline )


Q: What does this mean: “'msgid' and 'msgstr' entries do not both end with '\n'”

A: It means that when the original string ends in a newline, your translation 
must also end in a newline. And if the original string does not end in a 
newline, then your translation should likewise not have a newline at the end.

 
>From all that I'd conclude that we (R base code) are the source
of the problem.
Given the above FAQ, it seems common in other projects also to
have such trailing \n  and so we should really change the C code
you cite above.

On the other hand, this is from almost the very beginning of
when Brian added translation to R,

r32938 | ripley | 2005-01-30 20:24:04 +0100 (Sun, 30 Jan 2005) | 2 lines

include \n in whitespace ignored for R-level gettext


I think this has been because simultaneously we had started to
emphasize to useRs  they should *not* end message/format strings
in stop() / warning()  by a new line, but rather stop() and
warning() would *add* the newlines(s) themselves.

Still, currently we have a few such cases in  R-base.pot,
but just these few and maybe they really are "in error", in the
sense we could drop the ending '\n' (and do the same in all the *.po files!),
and newlines would be appended later {{not just by Rstudio which
   graceously adds final newlines in its R console, even for say
   cat("abc") }}

However, this is quite different for all the message strings from C, as
used there in  error() or warn() e.g., and so in   R.pot
we see many many msg strings ending in "\n" (which must then
also be in the *.po files.

My current conclusion is we should try simplifying the
do_gettext() code and 

[Bioc-devel] Add or Transfer Maintainership of DecoupleR Package

2021-11-05 Thread Jesús Vélez Santiago
Hi,

I would like to request to add a new maintainership or change the
maintainership completely for the decoupleR package (
https://www.bioconductor.org/packages/release/bioc/html/decoupleR.html).

New maintainer information:

   - Name: Pau Badia-i-Mompel
   - email: pau.ba...@uni-heidelberg.de

Do you think you can help us?

Thanks!

-- 
Best regards

Jesús Vélez Santiago, B.S.
Center for Genome Sciences, UNAM
jvelezmagic.com

[[alternative HTML version deleted]]

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel


Re: [Rd] gettext(msgid, domain="R") doesn't work for some 'msgid':s

2021-11-05 Thread Tomas Kalibera



On 11/5/21 4:12 PM, Duncan Murdoch wrote:

On 05/11/2021 10:51 a.m., Henrik Bengtsson wrote:
I'm trying to reuse some of the translations available in base R by 
using:


   gettext(msgid, domain="R")

This works great for most 'msgid's, e.g.

$ LANGUAGE=de Rscript -e 'gettext("cannot get working directory", 
domain="R")'

[1] "kann das Arbeitsverzeichnis nicht ermitteln"

However, it does not work for all.  For instance,

$ LANGUAGE=de Rscript -e 'gettext("Execution halted\n", domain="R")'
[1] "Execution halted\n"

This despite that 'msgid' existing in:

$ grep -C 2 -F 'Execution halted\n' src/library/base/po/de.po

#: src/main/main.c:342
msgid "Execution halted\n"
msgstr "Ausführung angehalten\n"

It could be that the trailing newline causes problems, because the
same happens also for:

$ LANGUAGE=de Rscript --vanilla -e 'gettext("error during cleanup\n",
domain="R")'
[1] "error during cleanup\n"

Is this meant to work, and if so, how do I get it to work, or is it a 
bug?


I don't know the solution, but I think the cause is different than you 
think, because I also have the problem with other strings not 
including "\n":


$ LANGUAGE=de Rscript -e 'gettext("malformed version string", 
domain="R")'

[1] "malformed version string"


I can reproduce Henrik's report and the problem there is that the 
trailing \n is stripped by R before doing the lookup, in do_gettext



    /* strip leading and trailing white spaces and
   add back after translation */
    for(p = tmp;
    *p && (*p == ' ' || *p == '\t' || *p == '\n');
    p++, ihead++) ;

But, calling dgettext with the trailing \n does translate correctly for me.

I'd leave to translation experts how this should work (e.g. whether the 
.po files should have trailing newlines).


Tomas



Duncan Murdoch

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel


__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel


Re: [Rd] gettext(msgid, domain="R") doesn't work for some 'msgid':s

2021-11-05 Thread Serguei Sokol

Le 05/11/2021 à 15:51, Henrik Bengtsson a écrit :

I'm trying to reuse some of the translations available in base R by using:

   gettext(msgid, domain="R")

This works great for most 'msgid's, e.g.

$ LANGUAGE=de Rscript -e 'gettext("cannot get working directory", domain="R")'
[1] "kann das Arbeitsverzeichnis nicht ermitteln"

However, it does not work for all.  For instance,

$ LANGUAGE=de Rscript -e 'gettext("Execution halted\n", domain="R")'
[1] "Execution halted\n"

This despite that 'msgid' existing in:

$ grep -C 2 -F 'Execution halted\n' src/library/base/po/de.po

#: src/main/main.c:342
msgid "Execution halted\n"
msgstr "Ausführung angehalten\n"

It could be that the trailing newline causes problems, because the
same happens also for:

$ LANGUAGE=de Rscript --vanilla -e 'gettext("error during cleanup\n",
domain="R")'
[1] "error during cleanup\n"

It happens also to:

$ LANGUAGE=de Rscript -e 'gettext("During startup - ", domain="R")'
[1] "During startup - "


#: src/main/main.c:1078
msgid "During startup - "
msgstr "Beim Start - "

which has not "\n" at the end.

Just a testimony with a hope it helps.

Best,
Serguei.



Is this meant to work, and if so, how do I get it to work, or is it a bug?

Thanks,

Henrik

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel



--
Serguei Sokol
Ingenieur de recherche INRAE

Cellule Mathématiques
TBI, INSA/INRAE UMR 792, INSA/CNRS UMR 5504
135 Avenue de Rangueil
31077 Toulouse Cedex 04

tel: +33 5 61 55 98 49
email: so...@insa-toulouse.fr
http://www.toulouse-biotechnology-institute.fr/en/technology_platforms/mathematics-cell.html

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel


Re: [Rd] gettext(msgid, domain="R") doesn't work for some 'msgid':s

2021-11-05 Thread Duncan Murdoch

On 05/11/2021 10:51 a.m., Henrik Bengtsson wrote:

I'm trying to reuse some of the translations available in base R by using:

   gettext(msgid, domain="R")

This works great for most 'msgid's, e.g.

$ LANGUAGE=de Rscript -e 'gettext("cannot get working directory", domain="R")'
[1] "kann das Arbeitsverzeichnis nicht ermitteln"

However, it does not work for all.  For instance,

$ LANGUAGE=de Rscript -e 'gettext("Execution halted\n", domain="R")'
[1] "Execution halted\n"

This despite that 'msgid' existing in:

$ grep -C 2 -F 'Execution halted\n' src/library/base/po/de.po

#: src/main/main.c:342
msgid "Execution halted\n"
msgstr "Ausführung angehalten\n"

It could be that the trailing newline causes problems, because the
same happens also for:

$ LANGUAGE=de Rscript --vanilla -e 'gettext("error during cleanup\n",
domain="R")'
[1] "error during cleanup\n"

Is this meant to work, and if so, how do I get it to work, or is it a bug?


I don't know the solution, but I think the cause is different than you 
think, because I also have the problem with other strings not including 
"\n":


$ LANGUAGE=de Rscript -e 'gettext("malformed version string", domain="R")'
[1] "malformed version string"

Duncan Murdoch

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel


[Rd] gettext(msgid, domain="R") doesn't work for some 'msgid':s

2021-11-05 Thread Henrik Bengtsson
I'm trying to reuse some of the translations available in base R by using:

  gettext(msgid, domain="R")

This works great for most 'msgid's, e.g.

$ LANGUAGE=de Rscript -e 'gettext("cannot get working directory", domain="R")'
[1] "kann das Arbeitsverzeichnis nicht ermitteln"

However, it does not work for all.  For instance,

$ LANGUAGE=de Rscript -e 'gettext("Execution halted\n", domain="R")'
[1] "Execution halted\n"

This despite that 'msgid' existing in:

$ grep -C 2 -F 'Execution halted\n' src/library/base/po/de.po

#: src/main/main.c:342
msgid "Execution halted\n"
msgstr "Ausführung angehalten\n"

It could be that the trailing newline causes problems, because the
same happens also for:

$ LANGUAGE=de Rscript --vanilla -e 'gettext("error during cleanup\n",
domain="R")'
[1] "error during cleanup\n"

Is this meant to work, and if so, how do I get it to work, or is it a bug?

Thanks,

Henrik

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel


Re: [Rd] Data Frame Conversion and Table Input

2021-11-05 Thread Duncan Murdoch

On 05/11/2021 8:00 a.m., Dario Strbenac via R-devel wrote:

Good day,

as.data.frame is documented on ?table and on ?as.data.frame (for list and 
matrix inputs). For inputs of list type and matrix type, there is an argument 
optional, which allows preservation of column names. If the input is a table, 
there is no such option. Could the API be made consistent for base data types?


as.data.frame.character is also inconsistent with the generic.

Duncan Murdoch

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel


[Rd] Data Frame Conversion and Table Input

2021-11-05 Thread Dario Strbenac via R-devel
Good day,

as.data.frame is documented on ?table and on ?as.data.frame (for list and 
matrix inputs). For inputs of list type and matrix type, there is an argument 
optional, which allows preservation of column names. If the input is a table, 
there is no such option. Could the API be made consistent for base data types?

--
Dario Strbenac
University of Sydney
Camperdown NSW 2050
Australia
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel


Re: [Rd] .onLoad, packageStartupMessage, and R CMD check

2021-11-05 Thread Michael Chirico via R-devel
Examining more closely, it's a NOTE produced by R CMD check --
originally I had thought it was a WARNING, which I think would have
been too strong for this case. A NOTE actually seems fine, on second
thought.

For a tiny bit of context, it's common for us to issue messaging
around some state initialization, which has to happen after some
(ex-ante unknown) set of packages are loaded. It's important to do so
whether or not the package is attached, so the proviso in .onLoad()
indeed makes the most sense.

Thanks!

On Thu, Nov 4, 2021 at 1:02 PM Gabriel Becker  wrote:
>
> Hi Michael,
>
> Indeed, just to elaborate further on what I believe Duncan's point is, can 
> you give any examples, "dire" or not, that are appropriate when the package 
> is loaded but not attached (ie none of its symbols are visible to the user 
> without using :::)?
>
> The only things I can think of are a package that changes the behavior of 
> other, attached package code, such as conflicted. Doing so is very much an 
> anti-pattern imo generally, with something like conflicted being an 
> (arguable) exception. And that's assuming conflicted even works/does anything 
> when loaded but not attached (I have not confirmed whether thats the case or 
> not). That or a package that is at end-of-life and is or soon will be 
> unsupported entirely.
>
> The examples don't need to be yours, per se, if you know what those pushing 
> back against your linter were using messages from .onLoad for...
>
> Best,
> ~G
>
>
>
> On Thu, Nov 4, 2021 at 12:37 PM Duncan Murdoch  
> wrote:
>>
>> On 04/11/2021 2:50 p.m., Michael Chirico via R-devel wrote:
>> > I wrote a linter to stop users from using packageStartupMessage() in
>> > their .onLoad() hook because of the R CMD check warning it triggers:
>> >
>> > https://github.com/wch/r-source/blob/8b6625e39cd62424dc23399dade37f20fa8afa91/src/library/tools/R/QC.R#L5167
>> >
>> > However, this received some pushback which I ultimately agree with,
>> > and moreover ?.onLoad seems to agree as well:
>> >
>> >> Loading a namespace should where possible be silent, with startup
>> > messages given by \code{.onAttach}. These messages (**and any essential
>> > ones from \code{.onLoad}**) should use \code{\link{packageStartupMessage}}
>> > so they can be silenced where they would be a distraction.
>> >
>> > **emphasis** mine. That is, if we think some message is _essential_ to
>> > print during loadNamespace(), we are told to use
>> > packageStartupMessage().
>> >
>> > Should we remove this R CMD check warning?
>>
>> The help page doesn't define what an "essential" message would be, but I
>> would assume it's a message about some dire condition, not just "Hi! I
>> just got loaded!".  So I think a note or warning would be appropriate,
>> but not an error.
>>
>> Do you have an example of something that should routinely print, but
>> that triggers a warning when checked?
>>
>> Duncan Murdoch
>>
>> __
>> R-devel@r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-devel

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel


Re: [Bioc-devel] SSL certificate error on nebbiolo2

2021-11-05 Thread Nicolas Delhomme
Thanks Mike and Hervé for the answers!

I’ll give it a go.

Best,

Nico

> On 4 Nov 2021, at 23:02, Mike Smith  wrote:
> 
> Hi Nico,
> 
> Please try changing your calls to useMart() to useEnsembl().  That function 
> has some checking that should detect this problem (it's real for all Ubuntu 
> 20.04 users, plus various other Linux distros) and will try to apply the 
> appropriate fix in the background.  There's some further suggestions in the 
> biomaRt vignette at if that doesn't work - 
> https://bioconductor.org/packages/release/bioc/vignettes/biomaRt/inst/doc/accessing_ensembl.html#connection-troubleshooting
>  
> 
> The weird certificates that produce the issue are only on the Ensembl mirror 
> sites, so it should not happen with the default arguments to useMart(), but 
> if biomaRt finds it's taking > 10 seconds to get a response it will see if 
> one of the mirrors is more responsive.  That's why it might take a variable 
> number of tries before reproducing the problem.
> 
> Best,
> Mike
> 
> On Thu, 4 Nov 2021 at 20:42, Hervé Pagès  wrote:
> Hi Nico,
> 
> This looks like the usual flakiness of the Ensembl Mart service. I see 
> these errors on the build report every day for various packages. The 
> exact set of packages varies.
> 
> I can reproduce on my laptop (Ubuntu 21.04):
> 
>> library(biomaRt)
> 
>> ensembl <- useMart(biomart = "ensembl", dataset = 
> "dmelanogaster_gene_ensembl")
> 
>> ensembl <- useMart(biomart = "ensembl", dataset = 
> "dmelanogaster_gene_ensembl")
> 
>> ensembl <- useMart(biomart = "ensembl", dataset = 
> "dmelanogaster_gene_ensembl")
> 
>Ensembl site unresponsive, trying uswest mirror
> 
>Error in curl::curl_fetch_memory(url, handle = handle) :
> 
>  SSL certificate problem: unable to get local issuer certificate
> 
> 
> See my sessionInfo() below.
> 
> Note that I had to try 3 times before getting the error.
> 
> I can also reproduce this with the Docker container for RELEASE_3_14 but 
> this time it took me 12 attempts:
> 
>  > library(biomaRt)
>  > ensembl <- useMart(biomart = "ensembl", dataset = 
> "dmelanogaster_gene_ensembl")
>  > ensembl <- useMart(biomart = "ensembl", dataset = 
> "dmelanogaster_gene_ensembl")
>  > ensembl <- useMart(biomart = "ensembl", dataset = 
> "dmelanogaster_gene_ensembl")
>  > ensembl <- useMart(biomart = "ensembl", dataset = 
> "dmelanogaster_gene_ensembl")
>  > ensembl <- useMart(biomart = "ensembl", dataset = 
> "dmelanogaster_gene_ensembl")
>  > ensembl <- useMart(biomart = "ensembl", dataset = 
> "dmelanogaster_gene_ensembl")
>  > ensembl <- useMart(biomart = "ensembl", dataset = 
> "dmelanogaster_gene_ensembl")
>  > ensembl <- useMart(biomart = "ensembl", dataset = 
> "dmelanogaster_gene_ensembl")
>  > ensembl <- useMart(biomart = "ensembl", dataset = 
> "dmelanogaster_gene_ensembl")
>  > ensembl <- useMart(biomart = "ensembl", dataset = 
> "dmelanogaster_gene_ensembl")
>  > ensembl <- useMart(biomart = "ensembl", dataset = 
> "dmelanogaster_gene_ensembl")
>  > ensembl <- useMart(biomart = "ensembl", dataset = 
> "dmelanogaster_gene_ensembl")
> Ensembl site unresponsive, trying asia mirror
> Error in curl::curl_fetch_memory(url, handle = handle) :
>SSL certificate problem: unable to get local issuer certificate
> 
> See my sessionInfo() below.
> 
> I'm not sure there's something we can do on our Linux builders about 
> this, or if it would be a good idea at all to try to do something (the 
> problem is real and can affect anybody using Ubuntu). Maybe discuss this 
> with Mike Smith by opening an issue here 
> https://github.com/grimbough/biomaRt
> 
> Best,
> H.
> 
> 
> sessionInfo() for my laptop session:
> 
> 
> R version 4.1.1 (2021-08-10)
> 
> Platform: x86_64-pc-linux-gnu (64-bit)
> 
> Running under: Ubuntu 21.04
> 
> 
> 
> Matrix products: default
> 
> BLAS:   /home/hpages/R/R-4.1.1/lib/libRblas.so
> 
> LAPACK: /home/hpages/R/R-4.1.1/lib/libRlapack.so
> 
> 
> 
> locale:
> 
>   [1] LC_CTYPE=en_US.UTF-8   LC_NUMERIC=C
> 
>   [3] LC_TIME=en_GB  LC_COLLATE=en_US.UTF-8
> 
>   [5] LC_MONETARY=en_US.UTF-8LC_MESSAGES=en_US.UTF-8
> 
>   [7] LC_PAPER=en_US.UTF-8   LC_NAME=C
> 
>   [9] LC_ADDRESS=C   LC_TELEPHONE=C
> 
> [11] LC_MEASUREMENT=en_US.UTF-8 LC_IDENTIFICATION=C
> 
> 
> 
> attached base packages:
> 
> [1] stats graphics  grDevices utils datasets  methods   base
> 
> 
> 
> other attached packages:
> 
> [1] biomaRt_2.50.0
> 
> 
> 
> loaded via a namespace (and not attached):
> 
>   [1] KEGGREST_1.34.0progress_1.2.2 tidyselect_1.1.1
> 
>   [4] purrr_0.3.4vctrs_0.3.8generics_0.1.1
> 
>   [7] stats4_4.1.1   BiocFileCache_2.2.0utf8_1.2.2
> 
> [10] blob_1.2.2 XML_3.99-0.8   rlang_0.4.12
> 
> [13] pillar_1.6.4   glue_1.4.2 DBI_1.1.1
> 
> [16] rappdirs_0.3.3 BiocGenerics_0.40.0bit64_4.0.5
> 
> [19] dbplyr_2.1.1   GenomeInfoDbData_1.2.7