Dear Hadley,
given you're on the list of R foundation members, I rest assured you have
other channels to ask about the identity of new CRAN staff directly to
those responsible. Their names and paychecks are of no interest to the
general dev world. I can understand CRAN doesn't want to make these n
Dear Hadley,
a follow up mail: You know who they are. Your organisation has the policy
to add all email correspondence with CRAN to the github repo.
https://github.com/r-lib/gargle/tree/master/cran-correspondence
That's how I now also found out who they are. One is a doctor. She has a
PhD. The m
I can't speak for Hadley, but my read of his email was that CRAN has
appointed new staff and while extra staff are clearly justified, it
was unclear how they were appointed and whether they had equal
seniority and authority as existing members. Indeed, the fact they use
titles which are clearly jun
Thinking about this a bit more, I think this might be a bug in R CMD
check, actually.
I understand that these flags are not portable, and yes, they should
be reported if they are specified in the packages's Makevars* files.
But in this case they are coming from the Ubuntu system's Makevars
setup,
Dear all,
as a CRAN contributor, I am interested in answers to the questions
Hadley raises.
I very much appreciate the huge amount of work the CRAN team do. I get
the impression that hitherto much of it has been funded by "goodwill".
That's not sustainable and it definitely needs to be staffed
su
On 15 May 2019 at 11:49, Gábor Csárdi wrote:
| Thinking about this a bit more, I think this might be a bug in R CMD
| check, actually.
|
| I understand that these flags are not portable, and yes, they should
| be reported if they are specified in the packages's Makevars* files.
| But in this cas
message() / warning() / stop() write to stderr whereas print() / cat() write
(by default) to stdout. Even without being able to suppress messages, it is
well-established practice (the story is that this is the reason why 'stderr'
was introduced into unix,
https://www.jstorimer.com/blogs/working
Dear John,
I guess Rcmdr::errorCondition() will rarely be called by users (nor
base::errorCondition), hence it should be quite safe if other packages
import correctly into their namespace and use the version their
maintainers import?
From that point of view, there are no changes required in
On Wed, 15 May 2019 at 13:16, Dirk Eddelbuettel wrote:
>
>
> On 15 May 2019 at 11:49, Gábor Csárdi wrote:
> | Thinking about this a bit more, I think this might be a bug in R CMD
> | check, actually.
> |
> | I understand that these flags are not portable, and yes, they should
> | be reported if th
Forgive me for not completely understanding the back and forth. Do I need to do
anything on my end, or are these changes that are being made on the server side?
- Keith
From: R-package-devel on behalf of
I�aki Ucar
Sent: Wednesday, May 15, 2019 9:01:31 AM
To:
You don't need to do anything.
Gabor
On Wed, May 15, 2019 at 2:13 PM Goldfeld, Keith
wrote:
>
> Forgive me for not completely understanding the back and forth. Do I need to
> do anything on my end, or are these changes that are being made on the server
> side?
>
>
> - Keith
>
> ___
I agree that `message()` is in an ideally preferred, precisely because
of the reasons Martin stated, it is easily controlled by the user.
Unfortunately, in the real world, the windows R gui console and
RStudio (which copied behavior) color messages, and anything on stderr
in fact, in red, which co
So - even though I am getting the same note:
Compilation used the following non-portable flag(s):
from Ubuntu Linux, I should go ahead and submit?
From: G�bor Cs�rdi
Sent: Wednesday, May 15, 2019 9:14:50 AM
To: Goldfeld, Keith
Cc: I�aki Ucar; Dirk Eddelbuett
Sorry first sentence should read
I agree that `message()` is ideally preferred, precisely because
of the reasons Martin stated, it is easily controlled by the user.
On Wed, May 15, 2019 at 9:41 AM Jim Hester wrote:
>
> I agree that `message()` is in an ideally preferred, precisely because
> of t
On Wed, 15 May 2019 at 15:43, Goldfeld, Keith
wrote:
> So - even though I am getting the same note:
>
> Compilation used the following non-portable flag(s):
>
> from Ubuntu Linux, I should go ahead and submit?
Definitely.
Iñaki
__
R-package-devel@r-pr
Dialogue is not always getting what you demand in one step. One form dialogue
with CRAN is re-submitting with CRAN-correspondence stating what one wants.
Also, for a lot of applications being able to turn off messages is critical.
> Sorry first sentence should read
>
> I agree that `message(
Hello,
Since this has turned into a worldwide code review, I will briefly address
that, then reiterate the point of the original message.
I am working on an initial release of a package. It reveals information to
a user, sometimes in a print method-y way, sometimes in more of a verbose /
debuggin
For what it's worth,
I recently submitted a new package that was initially refused (with
comments) by CRAN. I updated number of them accordingly, but there were a
few that with good reasons I could not change. I explained this in the
comments when uploading a new version and it got accepted. So I
On 15/05/2019 10:40 a.m., Jennifer Bryan wrote:
Hello,
Since this has turned into a worldwide code review, I will briefly address
that, then reiterate the point of the original message.
I am working on an initial release of a package. It reveals information to
a user, sometimes in a print metho
Dear Uwe,
> -Original Message-
> From: Uwe Ligges [mailto:lig...@statistik.tu-dortmund.de]
> Sent: Wednesday, May 15, 2019 7:51 AM
> To: Fox, John ; R Package Development de...@r-project.org>
> Subject: Re: [R-pkg-devel] advice about errorCondition() function in the Rcmdr
> package
>
> D
Hello,
My package has recently been posted to CRAN, however, there is an
additional issue of noLD on tests on x86_64 Linux with R-devel.
I haven't yet received an email from CRAN maintainers on resolving the
issue.
However, I would like to submit an updated package version with improved
document
On 15.05.2019 19:50, Jarrett Phillips wrote:
Hello,
My package has recently been posted to CRAN, however, there is an
additional issue of noLD on tests on x86_64 Linux with R-devel.
I haven't yet received an email from CRAN maintainers on resolving the
issue.
However, I would like to submit
I have just upgraded to R 3.6.0 and when building and checking my
package, R CMD check passes all the checks, including running the
examples, but devtools::check reports a failure when running the
examples. I have also run the example successfully manually in RStudio.
I would appreciate help i
--- Begin Message ---
I had a similar experience with a couple of my package updates needing changes.
The background is that I have a family of packages for talking to Microsoft's
Azure cloud service from R, and my examples are all marked \dontrun because
they need an Azure subscription to work.
Barbara,
On 15 May 2019 at 17:09, Barbara Lerner wrote:
| I have just upgraded to R 3.6.0 and when building and checking my
| package, R CMD check passes all the checks, including running the
| examples, but devtools::check reports a failure when running the
| examples. I have also run the e
25 matches
Mail list logo
