On 15 May 2020 at 02:30, Gábor Csárdi wrote:
| It is unlikely that this is an R-hub issue because the first link is
| CRAN's machine, and the same error happens there.
My bad, sorry -- I read the original email(s) wrong.
Dirk
--
http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
Ah, I hadn't considered that the startup message could be the problem
- I thought the point of startup messages was to be distinct from
errors and warnings, so I wouldn't have expected that to trip up R CMD
Check. I assumed the failure was occurring somewhere inside the actual
code for my unit
Apparently, this is not a warning, but the package itself is printing
it as a startup message:
https://github.com/cran/PAutilities/blob/ada73d8d44177c12867cc385cdca0054885ddae3/R/zzz.R#L5
Gabor
On Fri, May 15, 2020 at 2:30 AM Gábor Csárdi wrote:
>
> It is unlikely that this is an R-hub issue
Is it just my installation or does edit() (or fix(), etc.) in R-4.0.0
double all the backslashes when options(keep.source=TRUE)? E.g.,
> options(keep.source=TRUE)
> f <- function(x) { cat("\t", x, "\n", sep="") }
> edit(f) # exit the editor without making any changes
The editor (vi or notepad)
It is unlikely that this is an R-hub issue because the first link is
CRAN's machine, and the same error happens there.
I can reproduce it on macOS:
git clone https://github.com/paulhibbing/PAutilities
R CMD INSTALL PAutilities
R -q -e 'packageDescription("PAutilities")$Built'
#> >
On 14 May 2020 at 11:41, Paul Hibbing wrote:
| * Here is the CRAN check (devel version 2020-05-13):
|
|
https://www.r-project.org/nosvn/R.check/r-devel-linux-x86_64-debian-gcc/PAutilities-00check.html
|
| * Here is the successful R-hub check (devel version 2020-05-10):
|
|
Thanks for the fix.
H.
On 5/12/20 23:29, Tomas Kalibera wrote:
Thanks, fixed.
Tomas
On 5/13/20 5:14 AM, Dirk Eddelbuettel wrote:
On 12 May 2020 at 19:59, Hervé Pagès wrote:
| While reading about the new 'recycle0' argument of paste/paste0, I
| spotted a mysterious "cd" floating in the air
sorry, corrected now.
On 5/14/20, 2:13 PM, "Bioc-devel on behalf of 顾祖光"
wrote:
Dear Bioconductor,
I submitted a package "simplifyEnrichment" ten days ago, but the status of
the submission is still "awaiting moderation" and has not been changed yet.
I want to ask is there
Hi R developers,
I observed that system(timeout=) may still return exit code 0, when
killing the process due to timeout.
In src/unix/sys-unix.c there is
#define KILL_SIGNAL1 SIGINT
#define KILL_SIGNAL2 SIGTERM
#define KILL_SIGNAL3 SIGKILL
#define EMERGENCY_TIMEOUT 20
After little bit of
Dear Bioconductor,
I submitted a package "simplifyEnrichment" ten days ago, but the status of
the submission is still "awaiting moderation" and has not been changed yet.
I want to ask is there anything I missed or I just wait?
The link for the submission is
Dear expeRts,
when trying to submit a new package of mine, my submission was rejected during
automic incoming checks.
In fact on Windows it says Status: 1 NOTE
This note says:
* checking CRAN incoming feasibility ... NOTE
Maintainer: 'Wolfgang Raffelsberger '
New submission
On my previous
* Here is the CRAN check (devel version 2020-05-13):
https://www.r-project.org/nosvn/R.check/r-devel-linux-x86_64-debian-gcc/PAutilities-00check.html
* Here is the successful R-hub check (devel version 2020-05-10):
Hi all,
At some point (I believe within the last week or so), my package
`PAutilities` has developed the following error for
r-devel-linux-x86_64-debian-gcc:
* checking tests ... [3s/3s] ERROR
Running ‘testthat.R’ [3s/3s]
Running the tests in ‘tests/testthat.R’ failed.
Complete output:
>
I suspected it was partly due to the fact that ftable doesn't get much
interest/isn't much used...
So thank you very much for answering, and for your time!
>> Dear all,
>> I haven't received any feedback so far on my proposal to make "justify"
>> argument available in stats:::format.ftable
>>
On 14/05/2020 5:46 a.m., Gábor Csárdi wrote:
On Thu, May 14, 2020 at 10:27 AM Duncan Murdoch
wrote:
On 14/05/2020 3:30 a.m., Georgi Boshnakov wrote:
The issue is not with Rstudio per se but that in devtools' development mode
help() is modified to show the Rd files in the source directory,
On Thu, May 14, 2020 at 10:27 AM Duncan Murdoch
wrote:
>
> On 14/05/2020 3:30 a.m., Georgi Boshnakov wrote:
> > The issue is not with Rstudio per se but that in devtools' development mode
> > help() is modified to show the Rd files in the source directory, as one
> > would expect, but doesn't
> SOEIRO Thomas
> on Wed, 13 May 2020 20:27:15 + writes:
> Dear all,
> I haven't received any feedback so far on my proposal to make "justify"
argument available in stats:::format.ftable
> Is this list the appropriate place for this kind of proposal?
Yes, it is..
On 14/05/2020 3:30 a.m., Georgi Boshnakov wrote:
The issue is not with Rstudio per se but that in devtools' development mode
help() is modified to show the Rd files in the source directory, as one would
expect, but doesn't load the RdMacros. So, the issue appears when one is
development
The issue is not with Rstudio per se but that in devtools' development mode
help() is modified to show the Rd files in the source directory, as one would
expect, but doesn't load the RdMacros. So, the issue appears when one is
development mode.
Rdpack::viewRd() can be of some help but it
19 matches
Mail list logo
