Re: [Rd] .onLoad, packageStartupMessage, and R CMD check
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
[Rd] Data Frame Conversion and Table Input
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] Data Frame Conversion and Table Input
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] gettext(msgid, domain="R") doesn't work for some 'msgid':s
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] gettext(msgid, domain="R") doesn't work for some 'msgid':s
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
Re: [Rd] gettext(msgid, domain="R") doesn't work for some 'msgid':s
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
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
> 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 *no
Re: [Rd] gettext(msgid, domain="R") doesn't work for some 'msgid':s
> 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 f
