date:20200826

Re: [Rd] R 4.0.2 64-bit Windows hangs

2020-08-26 Thread Tomas Kalibera


On 8/25/20 6:14 PM, Tomas Kalibera wrote:

On 8/22/20 9:33 PM, Jeroen Ooms wrote:
On Sat, Aug 22, 2020 at 9:10 PM Tomas Kalibera 
 wrote:

On 8/22/20 8:26 PM, Tomas Kalibera wrote:

On 8/22/20 7:58 PM, Jeroen Ooms wrote:

On Sat, Aug 22, 2020 at 8:39 AM Tomas Kalibera
 wrote:

On 8/21/20 11:45 PM, m19tdn+9alxwj7d2bmk--- via R-devel wrote:

Ah yes, this is related. I reported v2010 below, but it looks like
I was updated to this Insider Build overnight without my knowledge,
and conflated it with the new installation R v4 this morning.

I will continue to look into the issue with the methods Tomas
mentioned.

It is interesting that a rare 5 years old problem would re-appear on
current Insider builds. Which build of Windows are you running 
exactly?
I've seen another report about a crash on 20190.1000. It'd be 
nice to

know if it is present also in newer builds, i.e. in 20197.
I installed the latest 20197 build in a vm, and I can indeed 
reproduce

this problem.

What seems to be happening is that R triggers an infinite 
recursion in

Windows unwinding mechanism, and eventually dies with a stack
overflow. Attached a backtrace of the initial 100 frames of the main
thread (the pattern in the top ~30 frames continues forever).

The microsoft blog doesn't mention anything related to exception
handling has changed in recent versions:
https://docs.microsoft.com/en-us/windows-insider/at-home/active-dev-branch 




Thanks, unfortunately that does not ring any bells (except below), I
can't guess from this what is the underlying cause of the problem.
There may be something wrong in how we use setjmp/longjmp or how
setjmp/longjmp works on Windows.

It reminds me of a problem I've been debugging few days ago, when
longjump implementation segfaults on Windows 10 (recent but not
Insider build) probably soon after unwinding the stack, but only with
GCC 10 / MinGW 7 and only in one of the no-segfault tests, and only
with -03 (not -O2, not with with -O3 -fno-split-loops). The problem
was sensitive to these optimization options interestingly on the call
site of long jump (do_abs), even when it was not an immediate caller
of the longjump. I've not tracked this down yet, it will require
looking at the assembly level, and I was suspecting a compiler error
causing the compiler to generate code that messes with the stack or
registers in a way that impacts the upcoming jump. But now as we have
this other problem with setjmp/logjmp, the compiler may not be the top
suspect anymore.

I may not be able to work on this in the next few days or a week, so
if anyone gets there first, please let me know what you find out.

Btw could you please try out if the UCRT build of R crashes as well in
the Insider Windows build ?

Yes, it hangs in exactly the same way, except that the backtrace shows

  ucrtbase!.intrinsic_setjmpex () from C:\WINDOWS\System32\ucrtbase.dll

Instead of msvcrt!_setjmpex (as expected of course).


Thanks. I found what is causing the problem I observed with 
GCC10/stock Windows 10, I expect this is the same one as in the 
Insider build.

I will investigate further,

Tomas

It seems the problem is between MinGW-W64 and Windows, and really it 
causes both the reported crashes in an Insider build (I tested in 20197) 
and in my GCC 10 builds in a single "no-segfault" test. setjmp is 
implemented using Windows call _setjmpex, which has a second argument 
argument, which is set differently by MinGW based on GCC version. When I 
set this argument as MinGW-W64 did on early versions of GCC, 
mingw_getsp(), it fixes/hides the problems on my systems. Perl5 uses a 
similar workaround, but otherwise there is no solid base (documentation, 
specification, etc) I am aware of for this change, so this may take some 
more time to be properly fixed. Still, if anyone experiments with this 
workaround and finds a problem, please let me know. In particular, I am 
curious whether it works on earlier versions of Windows (at least with 
check-all, including recommended packages).


Thanks
Tomas




Index: src/gnuwin32/fixed/h/psignal.h
===
--- src/gnuwin32/fixed/h/psignal.h	(revision 79084)
+++ src/gnuwin32/fixed/h/psignal.h	(working copy)
@@ -30,6 +30,15 @@
 #include 
 #include 
 
+#if defined(__MINGW64__)
+  #undef setjmp
+  #ifdef _UCRT
+#define setjmp(x) __intrinsic_setjmpex((x), mingw_getsp())
+  #else
+#define setjmp(x) _setjmp((x), mingw_getsp())
+  #endif  
+#endif
+
 #define	SIGHUP	1	/* hangup */
 #define	SIGINT	2	/* interrupt */
 #define	SIGQUIT	3	/* quit */
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] trace creates object in base namespace if called on function argument

2020-08-26 Thread Tomas Kalibera

Hi Antoine,

ok, I thought you were reporting that

 > foo <- function() "hello"
 > trace2 <- function(fun) trace(fun, quote(print("!!!")))
 > trace2(foo)
 > base::fun

in error did not trace "foo" in the top-level environment. This is, 
however, expected, because "trace" is called with argument fun, so the 
name of the function binding to replace is "fun" (not "foo"), and "fun" 
does not exist in the top-level environment. You cannot wrap "trace" 
like this.

If you meant to report that instead of throwing an error that an object 
named "fun" was not found, this example inserts the instrumented code 
into "base", that I also find surprising. The behavior I would have 
expected is like with primitive tracing

 > foo <- function() "hello"
 > trace2 <- function(fun) trace(fun)
 > trace2(foo)
 > base::fun
Error in get(name, envir = ns, inherits = FALSE) : object 'fun' not found

If you are interested in this problem, feel free to investigate in more 
detail (validate it is a bug via reading the documentation in detail, 
reading the code, debugging, checking the commit history) and if it 
turns out to be really a bug, feel free to submit a well-tested minimal 
patch, via bugzilla.

Thanks,
Tomas


On 8/26/20 4:39 PM, Antoine Fabri wrote:
> Hi Tomas,
>
> The doc indeed describes `what` as "the name, possibly quote()d, of a 
> function to be traced or untraced".
> This is a good argument not to change the function and make it behave 
> more like debug.
>
> However the doc also tells us "A call to trace allows you to insert 
> debugging code (e.g., a call to browser or recover) at chosen places 
> in any function" and "The trace function operates by constructing a 
> revised version of the function (or of the method, if signature is 
> supplied), and assigning the new object back where the original was 
> found". In the issue I report a function was created in the base 
> environment, which is not "where the function was found". It's not 
> clear to me what "where it was found" would mean in that case, but I 
> would assume the execution environment of trace2, or maybe the calling 
> environment (global in that case), or parent of foo (global here 
> again), but not the base namespace.
>
> It would make sense to me to either have a traced fun in the execution 
> environment, or to have an error.
>
> Best,
>
> Antoine
>
> Le mer. 26 août 2020 à 14:17, Tomas Kalibera  > a écrit :
>
> Please note that this is documented in ?trace. "fun" is matched to
> what,
> it is a _name_ of the function to be traced, which is traced in the
> top-level environment. I don't know why it was designed this way,
> but it
> is documented in detail, and hence the expected behavior.
>
> Debugging is often, and also in R, implemented in the core.
> Tracing is
> implemented on top without specific support, it thus cannot do some
> things debugging can do.
>
> Tomas
>
>
> On 8/26/20 3:31 AM, Antoine Fabri wrote:
> > Apologies there is one line missing in my last email, the code
> should be :
> >
> > foo <- function() "hello"
> > trace2 <- function(fun) trace(fun, quote(print("!!!")))
> > trace2(foo) # <- THIS LINE WAS MISSING
> > base::fun
> >
> > Best,
> >
> > Antoine
> >
> > Le mar. 25 août 2020 à 22:02, Antoine Fabri
> mailto:antoine.fa...@gmail.com>> a
> > écrit :
> >
> >> Dear R-devel,
> >>
> >> I don't think this is expected :
> >>
> >> foo <- function() "hello"
> >> trace2 <- function(fun) trace(fun, quote(print("!!!")))
> >> base::fun
> >> # Object with tracing code, class "functionWithTrace"
> >> # Original definition:
> >> # function() "hello"
> >> #
> >> # ## (to see the tracing code, look at body(object))
> >>
> >> `untrace()` has the same behavior.
> >>
> >> This is inconsistent with how debug works :
> >>
> >> foo <- function() "hello"
> >> debug2 <- function(fun) debug(fun)
> >> debug2(foo)
> >> isdebugged(foo)
> >> # [1] TRUE
> >>
> >> This can be worked around by defining :
> >>
> >> trace2 <- function(fun) eval.parent(substitute(trace(fun,
> >> quote(print("!!!")))
> >>
> >> but I believe the current behavior is undesired and it'd be
> better to make
> >> it behave as `debug()`, or to throw an error.
> >>
> >> Best,
> >>
> >> Antoine
> >>
> >       [[alternative HTML version deleted]]
> >
> > __
> > R-devel@r-project.org  mailing list
> > https://stat.ethz.ch/mailman/listinfo/r-devel
>
>


[[alternative HTML version deleted]]

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

Re: [Rd] trace creates object in base namespace if called on function argument

2020-08-26 Thread Antoine Fabri

Hi Tomas,

The doc indeed describes `what` as "the name, possibly quote()d, of a
function to be traced or untraced".
This is a good argument not to change the function and make it behave more
like debug.

However the doc also tells us "A call to trace allows you to insert
debugging code (e.g., a call to browser or recover) at chosen places in any
function" and "The trace function operates by constructing a revised
version of the function (or of the method, if signature is supplied), and
assigning the new object back where the original was found". In the issue I
report a function was created in the base environment, which is not "where
the function was found". It's not clear to me what "where it was found"
would mean in that case, but I would assume the execution environment of
trace2, or maybe the calling environment (global in that case), or parent
of foo (global here again), but not the base namespace.

It would make sense to me to either have a traced fun in the execution
environment, or to have an error.

Best,

Antoine

Le mer. 26 août 2020 à 14:17, Tomas Kalibera  a
écrit :

> Please note that this is documented in ?trace. "fun" is matched to what,
> it is a _name_ of the function to be traced, which is traced in the
> top-level environment. I don't know why it was designed this way, but it
> is documented in detail, and hence the expected behavior.
>
> Debugging is often, and also in R, implemented in the core. Tracing is
> implemented on top without specific support, it thus cannot do some
> things debugging can do.
>
> Tomas
>
>
> On 8/26/20 3:31 AM, Antoine Fabri wrote:
> > Apologies there is one line missing in my last email, the code should be
> :
> >
> > foo <- function() "hello"
> > trace2 <- function(fun) trace(fun, quote(print("!!!")))
> > trace2(foo) # <- THIS LINE WAS MISSING
> > base::fun
> >
> > Best,
> >
> > Antoine
> >
> > Le mar. 25 août 2020 à 22:02, Antoine Fabri  a
> > écrit :
> >
> >> Dear R-devel,
> >>
> >> I don't think this is expected :
> >>
> >> foo <- function() "hello"
> >> trace2 <- function(fun) trace(fun, quote(print("!!!")))
> >> base::fun
> >> # Object with tracing code, class "functionWithTrace"
> >> # Original definition:
> >> # function() "hello"
> >> #
> >> # ## (to see the tracing code, look at body(object))
> >>
> >> `untrace()` has the same behavior.
> >>
> >> This is inconsistent with how debug works :
> >>
> >> foo <- function() "hello"
> >> debug2 <- function(fun) debug(fun)
> >> debug2(foo)
> >> isdebugged(foo)
> >> # [1] TRUE
> >>
> >> This can be worked around by defining :
> >>
> >> trace2 <- function(fun) eval.parent(substitute(trace(fun,
> >> quote(print("!!!")))
> >>
> >> but I believe the current behavior is undesired and it'd be better to
> make
> >> it behave as `debug()`, or to throw an error.
> >>
> >> Best,
> >>
> >> Antoine
> >>
> >   [[alternative HTML version deleted]]
> >
> > __
> > R-devel@r-project.org mailing list
> > https://stat.ethz.ch/mailman/listinfo/r-devel
>
>
>

[[alternative HTML version deleted]]

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

Re: [Rd] NAs and rle

2020-08-26 Thread William Dunlap via R-devel

Splus's rle() also grouped NA's (separately from NaN's):

% Splus
TIBCO Software Inc. Confidential Information
Copyright (c) 1988-2008 TIBCO Software Inc. ALL RIGHTS RESERVED.
TIBCO Spotfire S+ Version 8.1.1 for Linux 2.6.9-34.EL, 32-bit : 2008
> dput(rle(c(11,11,NA,NA,NA,NaN,14,14,14,14)))
list("lengths" = c(2, 3, 1, 4)
, "values" = c(11., NA, NaN, 14.)
)

Bill Dunlap
TIBCO Software
wdunlap tibco.com

On Tue, Aug 25, 2020 at 10:57 PM Gabriel Becker  wrote:
>
> Hi All,
>
> A twitter user, Mike fc (@coolbutuseless) mentioned today that he was
> surprised that repeated NAs weren't treated as a run by the rle function.
>
> Now I know why they are not. NAs represent values which could be the same
> or different from eachother if they were known, so from a purely conceptual
> standpoint there is no way to tell whether they are the same and thus
> constitute a run or not.
>
> This conceptual strictness isnt universally observed, though, because we
> get the following:
>
> > unique(c(1, 2, 3, NA, NA, NA))
>
> [1]  1  2  3 NA
>
>
> Which means that rle(sort(x))$value is not guaranteed to be the same as
> unique(x), which is a little strange (though likely of little practical
> impact).
>
>
> Personally, to me it also seems that, from a purely data-compression
> standpoint, it would be valid to collapse those missing values into a run
> of missing, as it reduces size in-memory/on disk without losing any
> information.
>
> Now none of this is to say that I suggest the default behavior be changed
> (that would surely disrupt some non-trivial amount of existing code) but
> what do people think of a  group.nas argument which defaults to FALSE
> controlling the behavior?
>
> As a final point, there is some precedent here (though obviously not at all
> binding), as Bioconductor's Rle functionality does group NAs.
>
> Best,
> ~G
>
> [[alternative HTML version deleted]]
>
> __
> 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: [R-pkg-devel] url checks not working for me

2020-08-26 Thread Dirk Eddelbuettel



On 26 August 2020 at 08:46, Dirk Eddelbuettel wrote:
| One way to ensure the last point is to have a file
| 
|   ~/.R/check.Renviron-Rdevel
| 
| which I had (but where I had commented out 'incoming' as it can take a
| moment).  Current values below, with thanks to Uwe for the reminder.

And I forgot to add them.  This time.  One of the values is local to my
R-devel build.  I am sure Henrik will follow-up soon with an extended list :)

| I reiterate that this really should be part of R CMD check --as-cran.  Maybe
| one day it will be.


edd@rob:~$ cat ~/.R/check.Renviron-Rdevel 
# See R Internals manual -- there is now --as-cran too
_R_CHECK_CRAN_INCOMING_=FALSE
_R_CHECK_FORCE_SUGGESTS_=FALSE
_R_CHECK_VC_DIRS_=TRUE
_R_CHECK_UNSAFE_CALLS_=TRUE
_R_CHECK_TIMINGS_=10
_R_CHECK_INSTALL_DEPENDS_=TRUE
_R_CHECK_SUGGESTS_ONLY_=TRUE
_R_CHECK_NO_RECOMMENDED_=TRUE
_R_CHECK_SUBDIRS_NOCASE_=TRUE
_R_CHECK_EXECUTABLES_EXCLUSIONS_=FALSE
_R_CHECK_LICENSE_=TRUE
_R_CHECK_DOC_SIZES2_=TRUE
_R_CHECK_CODETOOLS_PROFILE_='suppressPartialMatchArgs=false'
#
_R_CHECK_VIGNETTES_NLINES_=50
_R_CHECK_DOT_INTERNAL_=TRUE
#
# edd Apr 2015
_R_CHECK_CRAN_INCOMING_USE_ASPELL_=TRUE

# edd Jan 2018  for RD 
R_LIBS="/usr/local/lib/R-devel/site-library"

# edd Aug 2020
_R_CHECK_CRAN_INCOMING_=TRUE
edd@rob:~$


Dirk

-- 
https://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org

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

Re: [R-pkg-devel] url checks not working for me

2020-08-26 Thread Dirk Eddelbuettel



Ok, Uwe was kind enough to take me to task off-list and I can now confirm
that I _can_ replicate the URL issue locally by ensuring all three of

 - recent enough r-devel build (that was true, I may add that the
   rocker/r-devel and rocker/drd containers I look after can help)

 - built with libcurl support so check capabilities()[["libcurl"]] (that was
   also true for me)

 - CRAN incoming checks turned on (and that was my issue)

One way to ensure the last point is to have a file

  ~/.R/check.Renviron-Rdevel

which I had (but where I had commented out 'incoming' as it can take a
moment).  Current values below, with thanks to Uwe for the reminder.

I reiterate that this really should be part of R CMD check --as-cran.  Maybe
one day it will be.

Dirk

-- 
https://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org

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

Re: [R-pkg-devel] Error in winbuilder

2020-08-26 Thread Uwe Ligges


Pls try agaibn, if it fails again, pls let me know privately.

Best,
Uwe Ligges



On 26.08.2020 15:13, Nicholas Tierney wrote:

Hi Uwe,

OK thank you for that, good to know! I imagine it might be a bit tricky 
to know when, but do you have an idea of when submissions might return 
to normal? Or should I be good to submit again soon?


Thanks again,

Nick

On Wed, 26 Aug 2020 at 23:06, Uwe Ligges 
> wrote:


Friends, thias looks like a hang in the CRAN incoming feasibility
checks, hence may well be some web related issue as it seems it ran
into
the timeout there.

Best,
Uwe Ligges

On 26.08.2020 14:57, Nicholas Tierney wrote:
 > Hi Michael,
 >
 > I do indeed have quite a few examples in the package, this hasn't
been a
 > problem in the past, but I guess I could try reducing them down.
Have you
 > had this problem before?
 >
 > Cheers,
 >
 > Nick
 >
 > On Wed, 26 Aug 2020 at 22:49, Michael Dewey
mailto:li...@dewey.myzen.co.uk>> wrote:
 >
 >> Dear Nicholas
 >>
 >> Do you in fact have many examples in the package? Perhaps for some
 >> mysterious reason they take longer there than when you check at
home.
 >>
 >> Michael
 >>
 >> On 25/08/2020 14:54, Nicholas Tierney wrote:
 >>> Hi Everyone,
 >>>
 >>> I have an error when submitting to Winbuilder for my R package,
naniar
 >>> .
 >>>
 >>> When using `devtools::check_win_devel()` or
 >> `devtools::check_win_release()`
 >>> on naniar, I get the following logfile from winbuilder:
 >>>
 >>> ```
 >>> * using log directory
'd:/RCompile/CRANguest/R-release/naniar.Rcheck'
 >>> * using R version 4.0.2 (2020-06-22)
 >>> * using platform: x86_64-w64-mingw32 (64-bit)
 >>> * using session charset: ISO8859-1
 >>> * checking for file 'naniar/DESCRIPTION' ... OK
 >>> * checking extension type ... Package
 >>> * this is package 'naniar' version '0.5.3'
 >>> * package encoding: UTF-8
 >>> * checking CRAN incoming feasibility ... ERROR
 >>> Check process probably crashed or hung up for 20 minutes ... killed
 >>> Most likely this happened in the example checks (?),
 >>> if not, ignore the following last lines of example output:
 >>>
 >>>  End of example output (where/before crash/hang up
occured ?)
 >>> 
 >>> ```
 >>>
 >>> (submission URL here:
https://win-builder.r-project.org/77PYyM2kMri1/)
 >>>
 >>> I had previously thought this was a problem to do with CRAN
being closed
 >>> last week, but apparently this is not the case, and it should
have been
 >>> working. I cannot find any details on CRAN for this, but it
passes build
 >> on
 >>> R HUB for windows, and it passes build with no warnings,
errors, or notes
 >>> for me on Mac OSX, as well as on github actions (windows,
macOS, and
 >>> ubuntu).
 >>>
 >>> Just wondering if anyone has thoughts on this? I have also cross
 >>> posted on Rstudio
 >>> community
 >>> <
 >>>
 >>

https://community.rstudio.com/t/winbuilder-error-check-process-probably-crashed-or-hung-up-for-20-minutes-killed/77492
  ,
 >>> in case that is of interest.
 >>>
 >>> Thanks for your time, and apologies if I have missed something
obvious.
 >>>
 >>> All the best,
 >>>
 >>> Nick
 >>>
 >>>        [[alternative HTML version deleted]]
 >>>
 >>> __
 >>> R-package-devel@r-project.org
 mailing list
 >>> https://stat.ethz.ch/mailman/listinfo/r-package-devel
 >>>
 >>
 >> --
 >> Michael
 >> http://www.dewey.myzen.co.uk/home.html
 >>
 >
 >       [[alternative HTML version deleted]]
 >
 > __
 > R-package-devel@r-project.org
 mailing list
 > https://stat.ethz.ch/mailman/listinfo/r-package-devel
 >



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

Re: [R-pkg-devel] Error in winbuilder

2020-08-26 Thread Nicholas Tierney

Hi Uwe,

OK thank you for that, good to know! I imagine it might be a bit tricky to
know when, but do you have an idea of when submissions might return to
normal? Or should I be good to submit again soon?

Thanks again,

Nick

On Wed, 26 Aug 2020 at 23:06, Uwe Ligges 
wrote:

> Friends, thias looks like a hang in the CRAN incoming feasibility
> checks, hence may well be some web related issue as it seems it ran into
> the timeout there.
>
> Best,
> Uwe Ligges
>
> On 26.08.2020 14:57, Nicholas Tierney wrote:
> > Hi Michael,
> >
> > I do indeed have quite a few examples in the package, this hasn't been a
> > problem in the past, but I guess I could try reducing them down. Have you
> > had this problem before?
> >
> > Cheers,
> >
> > Nick
> >
> > On Wed, 26 Aug 2020 at 22:49, Michael Dewey 
> wrote:
> >
> >> Dear Nicholas
> >>
> >> Do you in fact have many examples in the package? Perhaps for some
> >> mysterious reason they take longer there than when you check at home.
> >>
> >> Michael
> >>
> >> On 25/08/2020 14:54, Nicholas Tierney wrote:
> >>> Hi Everyone,
> >>>
> >>> I have an error when submitting to Winbuilder for my R package, naniar
> >>> .
> >>>
> >>> When using `devtools::check_win_devel()` or
> >> `devtools::check_win_release()`
> >>> on naniar, I get the following logfile from winbuilder:
> >>>
> >>> ```
> >>> * using log directory 'd:/RCompile/CRANguest/R-release/naniar.Rcheck'
> >>> * using R version 4.0.2 (2020-06-22)
> >>> * using platform: x86_64-w64-mingw32 (64-bit)
> >>> * using session charset: ISO8859-1
> >>> * checking for file 'naniar/DESCRIPTION' ... OK
> >>> * checking extension type ... Package
> >>> * this is package 'naniar' version '0.5.3'
> >>> * package encoding: UTF-8
> >>> * checking CRAN incoming feasibility ... ERROR
> >>> Check process probably crashed or hung up for 20 minutes ... killed
> >>> Most likely this happened in the example checks (?),
> >>> if not, ignore the following last lines of example output:
> >>>
> >>>  End of example output (where/before crash/hang up occured ?)
> >>> 
> >>> ```
> >>>
> >>> (submission URL here: https://win-builder.r-project.org/77PYyM2kMri1/)
> >>>
> >>> I had previously thought this was a problem to do with CRAN being
> closed
> >>> last week, but apparently this is not the case, and it should have been
> >>> working. I cannot find any details on CRAN for this, but it passes
> build
> >> on
> >>> R HUB for windows, and it passes build with no warnings, errors, or
> notes
> >>> for me on Mac OSX, as well as on github actions (windows, macOS, and
> >>> ubuntu).
> >>>
> >>> Just wondering if anyone has thoughts on this? I have also cross
> >>> posted on Rstudio
> >>> community
> >>> <
> >>>
> >>
> https://community.rstudio.com/t/winbuilder-error-check-process-probably-crashed-or-hung-up-for-20-minutes-killed/77492
>  ,
> >>> in case that is of interest.
> >>>
> >>> Thanks for your time, and apologies if I have missed something obvious.
> >>>
> >>> All the best,
> >>>
> >>> Nick
> >>>
> >>>[[alternative HTML version deleted]]
> >>>
> >>> __
> >>> R-package-devel@r-project.org mailing list
> >>> https://stat.ethz.ch/mailman/listinfo/r-package-devel
> >>>
> >>
> >> --
> >> Michael
> >> http://www.dewey.myzen.co.uk/home.html
> >>
> >
> >   [[alternative HTML version deleted]]
> >
> > __
> > R-package-devel@r-project.org mailing list
> > https://stat.ethz.ch/mailman/listinfo/r-package-devel
> >
>

[[alternative HTML version deleted]]

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

Re: [R-pkg-devel] Error in winbuilder

2020-08-26 Thread Uwe Ligges

Friends, thias looks like a hang in the CRAN incoming feasibility
checks, hence may well be some web related issue as it seems it ran into
the timeout there.

Best,
Uwe Ligges

On 26.08.2020 14:57, Nicholas Tierney wrote:

Hi Michael,

I do indeed have quite a few examples in the package, this hasn't been a
problem in the past, but I guess I could try reducing them down. Have you
had this problem before?

Cheers,

Nick

On Wed, 26 Aug 2020 at 22:49, Michael Dewey wrote:

Dear Nicholas

Do you in fact have many examples in the package? Perhaps for some
mysterious reason they take longer there than when you check at home.

Michael

On 25/08/2020 14:54, Nicholas Tierney wrote:

Hi Everyone,

I have an error when submitting to Winbuilder for my R package, naniar
.

When using `devtools::check_win_devel()` or

`devtools::check_win_release()`

on naniar, I get the following logfile from winbuilder:

```
* using log directory 'd:/RCompile/CRANguest/R-release/naniar.Rcheck'
* using R version 4.0.2 (2020-06-22)
* using platform: x86_64-w64-mingw32 (64-bit)
* using session charset: ISO8859-1
* checking for file 'naniar/DESCRIPTION' ... OK
* checking extension type ... Package
* this is package 'naniar' version '0.5.3'
* package encoding: UTF-8
* checking CRAN incoming feasibility ... ERROR
Check process probably crashed or hung up for 20 minutes ... killed
Most likely this happened in the example checks (?),
if not, ignore the following last lines of example output:

End of example output (where/before crash/hang up occured ?)

```

(submission URL here: https://win-builder.r-project.org/77PYyM2kMri1/)

R HUB for windows, and it passes build with no warnings, errors, or notes
for me on Mac OSX, as well as on github actions (windows, macOS, and
ubuntu).

Just wondering if anyone has thoughts on this? I have also cross
posted on Rstudio
community
<

https://community.rstudio.com/t/winbuilder-error-check-process-probably-crashed-or-hung-up-for-20-minutes-killed/77492

in case that is of interest.

Thanks for your time, and apologies if I have missed something obvious.

All the best,

Nick

[[alternative HTML version deleted]]

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

--
Michael
http://www.dewey.myzen.co.uk/home.html

[[alternative HTML version deleted]]

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

Re: [R-pkg-devel] url checks not working for me

2020-08-26 Thread Dirk Eddelbuettel



On 26 August 2020 at 14:34, Vincent van Hees wrote:
| Addressing the errors is not the problem. I want to be able to detect these
| problems when I do: R CMD check --as-cran.

You cannot :-/. I pointed that out to CRAN maintainers a few times myself.

| At the moment, I can only detect the errors by submitting the package to
| CRAN, because only their package check triggers these errors.

Apparently we are supposed to find that in the generated ${package}.Rcheck
directory even when no warning was issued. Supposedly one has to live in
Auckland, Dortmund, Oxford or Vienna to find that normal.

Dirk

-- 
https://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org

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

Re: [R-pkg-devel] Error in winbuilder

2020-08-26 Thread Nicholas Tierney

Hi Michael,

I do indeed have quite a few examples in the package, this hasn't been a
problem in the past, but I guess I could try reducing them down. Have you
had this problem before?

Cheers,

Nick

On Wed, 26 Aug 2020 at 22:49, Michael Dewey  wrote:

> Dear Nicholas
>
> Do you in fact have many examples in the package? Perhaps for some
> mysterious reason they take longer there than when you check at home.
>
> Michael
>
> On 25/08/2020 14:54, Nicholas Tierney wrote:
> > Hi Everyone,
> >
> > I have an error when submitting to Winbuilder for my R package, naniar
> > .
> >
> > When using `devtools::check_win_devel()` or
> `devtools::check_win_release()`
> > on naniar, I get the following logfile from winbuilder:
> >
> > ```
> > * using log directory 'd:/RCompile/CRANguest/R-release/naniar.Rcheck'
> > * using R version 4.0.2 (2020-06-22)
> > * using platform: x86_64-w64-mingw32 (64-bit)
> > * using session charset: ISO8859-1
> > * checking for file 'naniar/DESCRIPTION' ... OK
> > * checking extension type ... Package
> > * this is package 'naniar' version '0.5.3'
> > * package encoding: UTF-8
> > * checking CRAN incoming feasibility ... ERROR
> > Check process probably crashed or hung up for 20 minutes ... killed
> > Most likely this happened in the example checks (?),
> > if not, ignore the following last lines of example output:
> >
> >  End of example output (where/before crash/hang up occured ?)
> > 
> > ```
> >
> > (submission URL here: https://win-builder.r-project.org/77PYyM2kMri1/)
> >
> > I had previously thought this was a problem to do with CRAN being closed
> > last week, but apparently this is not the case, and it should have been
> > working. I cannot find any details on CRAN for this, but it passes build
> on
> > R HUB for windows, and it passes build with no warnings, errors, or notes
> > for me on Mac OSX, as well as on github actions (windows, macOS, and
> > ubuntu).
> >
> > Just wondering if anyone has thoughts on this? I have also cross
> > posted on Rstudio
> > community
> > <
> >
> https://community.rstudio.com/t/winbuilder-error-check-process-probably-crashed-or-hung-up-for-20-minutes-killed/77492
> >> ,
> > in case that is of interest.
> >
> > Thanks for your time, and apologies if I have missed something obvious.
> >
> > All the best,
> >
> > Nick
> >
> >   [[alternative HTML version deleted]]
> >
> > __
> > R-package-devel@r-project.org mailing list
> > https://stat.ethz.ch/mailman/listinfo/r-package-devel
> >
>
> --
> Michael
> http://www.dewey.myzen.co.uk/home.html
>

[[alternative HTML version deleted]]

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

Re: [R-pkg-devel] url checks not working for me

2020-08-26 Thread Bryan Hanson

Sorry, I was reading too fast.  One possibility is your R version is wee bit 
old.  Try a more recently daily build.

I recently saw such errors when submitting to Win-Builder, but was fine locally 
(per your situation).

Bryan

> On Aug 26, 2020, at 8:34 AM, Vincent van Hees  
> wrote:
> 
> Addressing the errors is not the problem. I want to be able to detect these 
> problems when I do: R CMD check --as-cran.
> At the moment, I can only detect the errors by submitting the package to 
> CRAN, because only their package check triggers these errors.
> 
> On Wed, 26 Aug 2020 at 14:30, Bryan Hanson  > wrote:
> At the minimum you should look at the “moved to” URLs and change your links 
> to those (some are outright changes in URLs that were redirected and some are 
> http to https changes).
> 
> Bryan
> 
> > On Aug 26, 2020, at 8:22 AM, Vincent van Hees  > > wrote:
> > 
> > Hello,
> > URL errors in my DESCRIPTION file and package vignette are not picked up
> > when I do R CMD check --as-cran or devtools::check(). I only know about
> > these errors because CRAN has rejected my package submission and instructed
> > me to fix the urls (example at end of this message).
> > 
> > I am trying to figure out how I can get R CMD check --as-cran to detect
> > these URL mistakes. From
> > https://cran.r-project.org/web/packages/URL_checks.html 
> >  I understand that 
> > I
> > need libcurl installed, which I have.
> > 
> > Can anyone tell me whether I am using the wrong combination of libcurl
> > version, R version, and Ubuntu version? (see versions below). If not, what
> > else can I do to get the URL checks to work?
> > 
> > Thanks, Vincent
> > 
> > vincent@vincent-VB:~$ curl-config --version
> > *libcurl 7.58.0*
> > 
> > vincent@vincent-VB:~$ curl -V
> > *curl 7.58.0* (x86_64-pc-linux-gnu) libcurl/7.58.0 OpenSSL/1.1.1
> > zlib/1.2.11 libidn2/2.0.4 libpsl/0.19.1 (+libidn2/2.0.4) nghttp2/1.30.0
> > librtmp/2.3
> > Release-Date: 2018-01-24
> > Protocols: dict file ftp ftps gopher http https imap imaps ldap ldaps pop3
> > pop3s rtmp rtsp smb smbs smtp smtps telnet tftp
> > Features: AsynchDNS IDN IPv6 Largefile GSS-API Kerberos SPNEGO NTLM NTLM_WB
> > SSL libz TLS-SRP HTTP2 UnixSockets HTTPS-proxy PSL
> > 
> > vincent@vincent-VB:~$ R --version
> > *R version 4.0.2* (2020-06-22) -- "Taking Off Again"
> > Copyright (C) 2020 The R Foundation for Statistical Computing
> > Platform: x86_64-pc-linux-gnu (64-bit)
> > 
> > R is free software and comes with ABSOLUTELY NO WARRANTY.
> > You are welcome to redistribute it under the terms of the
> > GNU General Public License versions 2 or 3.
> > For more information about these matters see
> > https://www.gnu.org/licenses/ .
> > 
> > vincent@vincent-VB:~$ lsb_release -a
> > No LSB modules are available.
> > Distributor ID: Ubuntu
> > Description: *Ubuntu 18.04.5 LTS*
> > Release: 18.04
> > Codename: bionic
> > 
> > Example of most recent URL mistakes in my package detected by CRAN package
> > submission process which I could not detect locally:
> > Found the following (possibly) invalid URLs: URL:
> > http://journals.plos.org/plosone/article?id=10.1371/journal.pone.0142533 
> > 
> > (moved to
> > https://journals.plos.org/plosone/article?id=10.1371/journal.pone.0142533 
> > )
> > From: inst/CITATION Status: 200 Message: OK URL: https://geneactiv.org/ 
> > 
> > (moved to https://www.activinsights.com/ ) 
> > From: inst/doc/GGIR.html Status:
> > 200 Message: OK URL: https://www.accelting.com/ 
> >  (moved to
> > https://accelting.com/ ) From: inst/doc/GGIR.html 
> > Status: 200 Message: OK
> > URL: https://www.physiology.org/doi/10.1152/japplphysiol.00421.2014 
> >  (moved
> > to https://journals.physiology.org/doi/10.1152/japplphysiol.00421.2014 
> > )
> > From: inst/CITATION Status: 200 Message: OK
> > 
> >   [[alternative HTML version deleted]]
> > 
> > __
> > R-package-devel@r-project.org  
> > mailing list
> > https://stat.ethz.ch/mailman/listinfo/r-package-devel 
> > 
> 


[[alternative HTML version deleted]]

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

Re: [R-pkg-devel] url checks not working for me

2020-08-26 Thread Joshua Ulrich

On Wed, Aug 26, 2020 at 7:43 AM Vincent van Hees
 wrote:
>
> Addressing the errors is not the problem. I want to be able to detect these
> problems when I do: R CMD check --as-cran.
> At the moment, I can only detect the errors by submitting the package to
> CRAN, because only their package check triggers these errors.
>
The win-builder system will also detect them.

These checks trigger for me on your package.

> R CMD check GGIR_2.1-0.tar.gz --as-cran
* using log directory '/home/josh/git/GGIR.Rcheck'
* using R version 4.0.2 (2020-06-22)
* using platform: x86_64-pc-linux-gnu (64-bit)
* using session charset: UTF-8
* using option '--as-cran'
* checking for file 'GGIR/DESCRIPTION' ... OK
* checking extension type ... Package
* this is package 'GGIR' version '2.1-0'
* checking CRAN incoming feasibility ... NOTE
Maintainer: 'Vincent T van Hees '

New maintainer:
  Vincent T van Hees 
Old maintainer(s):
  Vincent T van Hees 

Found the following (possibly) invalid URLs:
  URL: https://cran.r-project.org/web/packages/activityCounts/index.html
From: inst/doc/ExternalFunction.html
Status: 200
Message: OK
CRAN URL not in canonical form
  URL: https://europepmc.org/article/med/22770768
From: inst/doc/GGIR.html
Status: Error
Message: libcurl error code 35:
  error:14094410:SSL routines:ssl3_read_bytes:sslv3 alert
handshake failure
  The canonical URL of the CRAN page for a package is
https://CRAN.R-project.org/package=pkgname
* checking package namespace information ... OK
* checking package dependencies ... OK
...

Make sure you have incoming checks enabled, by setting the environment
variable _R_CHECK_CRAN_INCOMING_=TRUE.

Best,
Josh

> On Wed, 26 Aug 2020 at 14:30, Bryan Hanson  wrote:
>
> > At the minimum you should look at the “moved to” URLs and change your
> > links to those (some are outright changes in URLs that were redirected and
> > some are http to https changes).
> >
> > Bryan
> >
> > > On Aug 26, 2020, at 8:22 AM, Vincent van Hees 
> > wrote:
> > >
> > > Hello,
> > > URL errors in my DESCRIPTION file and package vignette are not picked up
> > > when I do R CMD check --as-cran or devtools::check(). I only know about
> > > these errors because CRAN has rejected my package submission and
> > instructed
> > > me to fix the urls (example at end of this message).
> > >
> > > I am trying to figure out how I can get R CMD check --as-cran to detect
> > > these URL mistakes. From
> > > https://cran.r-project.org/web/packages/URL_checks.html I understand
> > that I
> > > need libcurl installed, which I have.
> > >
> > > Can anyone tell me whether I am using the wrong combination of libcurl
> > > version, R version, and Ubuntu version? (see versions below). If not,
> > what
> > > else can I do to get the URL checks to work?
> > >
> > > Thanks, Vincent
> > >
> > > vincent@vincent-VB:~$ curl-config --version
> > > *libcurl 7.58.0*
> > >
> > > vincent@vincent-VB:~$ curl -V
> > > *curl 7.58.0* (x86_64-pc-linux-gnu) libcurl/7.58.0 OpenSSL/1.1.1
> > > zlib/1.2.11 libidn2/2.0.4 libpsl/0.19.1 (+libidn2/2.0.4) nghttp2/1.30.0
> > > librtmp/2.3
> > > Release-Date: 2018-01-24
> > > Protocols: dict file ftp ftps gopher http https imap imaps ldap ldaps
> > pop3
> > > pop3s rtmp rtsp smb smbs smtp smtps telnet tftp
> > > Features: AsynchDNS IDN IPv6 Largefile GSS-API Kerberos SPNEGO NTLM
> > NTLM_WB
> > > SSL libz TLS-SRP HTTP2 UnixSockets HTTPS-proxy PSL
> > >
> > > vincent@vincent-VB:~$ R --version
> > > *R version 4.0.2* (2020-06-22) -- "Taking Off Again"
> > > Copyright (C) 2020 The R Foundation for Statistical Computing
> > > Platform: x86_64-pc-linux-gnu (64-bit)
> > >
> > > R is free software and comes with ABSOLUTELY NO WARRANTY.
> > > You are welcome to redistribute it under the terms of the
> > > GNU General Public License versions 2 or 3.
> > > For more information about these matters see
> > > https://www.gnu.org/licenses/.
> > >
> > > vincent@vincent-VB:~$ lsb_release -a
> > > No LSB modules are available.
> > > Distributor ID: Ubuntu
> > > Description: *Ubuntu 18.04.5 LTS*
> > > Release: 18.04
> > > Codename: bionic
> > >
> > > Example of most recent URL mistakes in my package detected by CRAN
> > package
> > > submission process which I could not detect locally:
> > > Found the following (possibly) invalid URLs: URL:
> > > http://journals.plos.org/plosone/article?id=10.1371/journal.pone.0142533
> > > (moved to
> > >
> > https://journals.plos.org/plosone/article?id=10.1371/journal.pone.0142533)
> > > From: inst/CITATION Status: 200 Message: OK URL: https://geneactiv.org/
> > > (moved to https://www.activinsights.com/) From: inst/doc/GGIR.html
> > Status:
> > > 200 Message: OK URL: https://www.accelting.com/ (moved to
> > > https://accelting.com/) From: inst/doc/GGIR.html Status: 200 Message: OK
> > > URL: https://www.physiology.org/doi/10.1152/japplphysiol.00421.2014
> > (moved
> > > to https://journals.physiology.org/doi/10.1152/japplphysiol.00421.2014)
> > > From:

Re: [R-pkg-devel] Error in winbuilder

2020-08-26 Thread Michael Dewey

Dear Nicholas

Do you in fact have many examples in the package? Perhaps for some
mysterious reason they take longer there than when you check at home.

Michael

On 25/08/2020 14:54, Nicholas Tierney wrote:

Hi Everyone,

I have an error when submitting to Winbuilder for my R package, naniar
.

When using `devtools::check_win_devel()` or `devtools::check_win_release()`
on naniar, I get the following logfile from winbuilder:

End of example output (where/before crash/hang up occured ?)

```

(submission URL here: https://win-builder.r-project.org/77PYyM2kMri1/)

I had previously thought this was a problem to do with CRAN being closed
last week, but apparently this is not the case, and it should have been
working. I cannot find any details on CRAN for this, but it passes build on
R HUB for windows, and it passes build with no warnings, errors, or notes
for me on Mac OSX, as well as on github actions (windows, macOS, and
ubuntu).

Just wondering if anyone has thoughts on this? I have also cross
posted on Rstudio
community
<
https://community.rstudio.com/t/winbuilder-error-check-process-probably-crashed-or-hung-up-for-20-minutes-killed/77492

in case that is of interest.

Thanks for your time, and apologies if I have missed something obvious.

All the best,

Nick

[[alternative HTML version deleted]]

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

--
Michael
http://www.dewey.myzen.co.uk/home.html

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

Re: [R-pkg-devel] url checks not working for me

2020-08-26 Thread Vincent van Hees

Addressing the errors is not the problem. I want to be able to detect these
problems when I do: R CMD check --as-cran.
At the moment, I can only detect the errors by submitting the package to
CRAN, because only their package check triggers these errors.

On Wed, 26 Aug 2020 at 14:30, Bryan Hanson  wrote:

> At the minimum you should look at the “moved to” URLs and change your
> links to those (some are outright changes in URLs that were redirected and
> some are http to https changes).
>
> Bryan
>
> > On Aug 26, 2020, at 8:22 AM, Vincent van Hees 
> wrote:
> >
> > Hello,
> > URL errors in my DESCRIPTION file and package vignette are not picked up
> > when I do R CMD check --as-cran or devtools::check(). I only know about
> > these errors because CRAN has rejected my package submission and
> instructed
> > me to fix the urls (example at end of this message).
> >
> > I am trying to figure out how I can get R CMD check --as-cran to detect
> > these URL mistakes. From
> > https://cran.r-project.org/web/packages/URL_checks.html I understand
> that I
> > need libcurl installed, which I have.
> >
> > Can anyone tell me whether I am using the wrong combination of libcurl
> > version, R version, and Ubuntu version? (see versions below). If not,
> what
> > else can I do to get the URL checks to work?
> >
> > Thanks, Vincent
> >
> > vincent@vincent-VB:~$ curl-config --version
> > *libcurl 7.58.0*
> >
> > vincent@vincent-VB:~$ curl -V
> > *curl 7.58.0* (x86_64-pc-linux-gnu) libcurl/7.58.0 OpenSSL/1.1.1
> > zlib/1.2.11 libidn2/2.0.4 libpsl/0.19.1 (+libidn2/2.0.4) nghttp2/1.30.0
> > librtmp/2.3
> > Release-Date: 2018-01-24
> > Protocols: dict file ftp ftps gopher http https imap imaps ldap ldaps
> pop3
> > pop3s rtmp rtsp smb smbs smtp smtps telnet tftp
> > Features: AsynchDNS IDN IPv6 Largefile GSS-API Kerberos SPNEGO NTLM
> NTLM_WB
> > SSL libz TLS-SRP HTTP2 UnixSockets HTTPS-proxy PSL
> >
> > vincent@vincent-VB:~$ R --version
> > *R version 4.0.2* (2020-06-22) -- "Taking Off Again"
> > Copyright (C) 2020 The R Foundation for Statistical Computing
> > Platform: x86_64-pc-linux-gnu (64-bit)
> >
> > R is free software and comes with ABSOLUTELY NO WARRANTY.
> > You are welcome to redistribute it under the terms of the
> > GNU General Public License versions 2 or 3.
> > For more information about these matters see
> > https://www.gnu.org/licenses/.
> >
> > vincent@vincent-VB:~$ lsb_release -a
> > No LSB modules are available.
> > Distributor ID: Ubuntu
> > Description: *Ubuntu 18.04.5 LTS*
> > Release: 18.04
> > Codename: bionic
> >
> > Example of most recent URL mistakes in my package detected by CRAN
> package
> > submission process which I could not detect locally:
> > Found the following (possibly) invalid URLs: URL:
> > http://journals.plos.org/plosone/article?id=10.1371/journal.pone.0142533
> > (moved to
> >
> https://journals.plos.org/plosone/article?id=10.1371/journal.pone.0142533)
> > From: inst/CITATION Status: 200 Message: OK URL: https://geneactiv.org/
> > (moved to https://www.activinsights.com/) From: inst/doc/GGIR.html
> Status:
> > 200 Message: OK URL: https://www.accelting.com/ (moved to
> > https://accelting.com/) From: inst/doc/GGIR.html Status: 200 Message: OK
> > URL: https://www.physiology.org/doi/10.1152/japplphysiol.00421.2014
> (moved
> > to https://journals.physiology.org/doi/10.1152/japplphysiol.00421.2014)
> > From: inst/CITATION Status: 200 Message: OK
> >
> >   [[alternative HTML version deleted]]
> >
> > __
> > R-package-devel@r-project.org mailing list
> > https://stat.ethz.ch/mailman/listinfo/r-package-devel
>
>

[[alternative HTML version deleted]]

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

Re: [R-pkg-devel] url checks not working for me

2020-08-26 Thread Bryan Hanson

At the minimum you should look at the “moved to” URLs and change your links to 
those (some are outright changes in URLs that were redirected and some are http 
to https changes).

Bryan

> On Aug 26, 2020, at 8:22 AM, Vincent van Hees  
> wrote:
> 
> Hello,
> URL errors in my DESCRIPTION file and package vignette are not picked up
> when I do R CMD check --as-cran or devtools::check(). I only know about
> these errors because CRAN has rejected my package submission and instructed
> me to fix the urls (example at end of this message).
> 
> I am trying to figure out how I can get R CMD check --as-cran to detect
> these URL mistakes. From
> https://cran.r-project.org/web/packages/URL_checks.html I understand that I
> need libcurl installed, which I have.
> 
> Can anyone tell me whether I am using the wrong combination of libcurl
> version, R version, and Ubuntu version? (see versions below). If not, what
> else can I do to get the URL checks to work?
> 
> Thanks, Vincent
> 
> vincent@vincent-VB:~$ curl-config --version
> *libcurl 7.58.0*
> 
> vincent@vincent-VB:~$ curl -V
> *curl 7.58.0* (x86_64-pc-linux-gnu) libcurl/7.58.0 OpenSSL/1.1.1
> zlib/1.2.11 libidn2/2.0.4 libpsl/0.19.1 (+libidn2/2.0.4) nghttp2/1.30.0
> librtmp/2.3
> Release-Date: 2018-01-24
> Protocols: dict file ftp ftps gopher http https imap imaps ldap ldaps pop3
> pop3s rtmp rtsp smb smbs smtp smtps telnet tftp
> Features: AsynchDNS IDN IPv6 Largefile GSS-API Kerberos SPNEGO NTLM NTLM_WB
> SSL libz TLS-SRP HTTP2 UnixSockets HTTPS-proxy PSL
> 
> vincent@vincent-VB:~$ R --version
> *R version 4.0.2* (2020-06-22) -- "Taking Off Again"
> Copyright (C) 2020 The R Foundation for Statistical Computing
> Platform: x86_64-pc-linux-gnu (64-bit)
> 
> R is free software and comes with ABSOLUTELY NO WARRANTY.
> You are welcome to redistribute it under the terms of the
> GNU General Public License versions 2 or 3.
> For more information about these matters see
> https://www.gnu.org/licenses/.
> 
> vincent@vincent-VB:~$ lsb_release -a
> No LSB modules are available.
> Distributor ID: Ubuntu
> Description: *Ubuntu 18.04.5 LTS*
> Release: 18.04
> Codename: bionic
> 
> Example of most recent URL mistakes in my package detected by CRAN package
> submission process which I could not detect locally:
> Found the following (possibly) invalid URLs: URL:
> http://journals.plos.org/plosone/article?id=10.1371/journal.pone.0142533
> (moved to
> https://journals.plos.org/plosone/article?id=10.1371/journal.pone.0142533)
> From: inst/CITATION Status: 200 Message: OK URL: https://geneactiv.org/
> (moved to https://www.activinsights.com/) From: inst/doc/GGIR.html Status:
> 200 Message: OK URL: https://www.accelting.com/ (moved to
> https://accelting.com/) From: inst/doc/GGIR.html Status: 200 Message: OK
> URL: https://www.physiology.org/doi/10.1152/japplphysiol.00421.2014 (moved
> to https://journals.physiology.org/doi/10.1152/japplphysiol.00421.2014)
> From: inst/CITATION Status: 200 Message: OK
> 
>   [[alternative HTML version deleted]]
> 
> __
> R-package-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel

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

[R-pkg-devel] url checks not working for me

2020-08-26 Thread Vincent van Hees

Hello,
URL errors in my DESCRIPTION file and package vignette are not picked up
when I do R CMD check --as-cran or devtools::check(). I only know about
these errors because CRAN has rejected my package submission and instructed
me to fix the urls (example at end of this message).

I am trying to figure out how I can get R CMD check --as-cran to detect
these URL mistakes. From
https://cran.r-project.org/web/packages/URL_checks.html I understand that I
need libcurl installed, which I have.

Can anyone tell me whether I am using the wrong combination of libcurl
version, R version, and Ubuntu version? (see versions below). If not, what
else can I do to get the URL checks to work?

Thanks, Vincent

vincent@vincent-VB:~$ curl-config --version
*libcurl 7.58.0*

vincent@vincent-VB:~$ curl -V
*curl 7.58.0* (x86_64-pc-linux-gnu) libcurl/7.58.0 OpenSSL/1.1.1
zlib/1.2.11 libidn2/2.0.4 libpsl/0.19.1 (+libidn2/2.0.4) nghttp2/1.30.0
librtmp/2.3
Release-Date: 2018-01-24
Protocols: dict file ftp ftps gopher http https imap imaps ldap ldaps pop3
pop3s rtmp rtsp smb smbs smtp smtps telnet tftp
Features: AsynchDNS IDN IPv6 Largefile GSS-API Kerberos SPNEGO NTLM NTLM_WB
SSL libz TLS-SRP HTTP2 UnixSockets HTTPS-proxy PSL

vincent@vincent-VB:~$ R --version
*R version 4.0.2* (2020-06-22) -- "Taking Off Again"
Copyright (C) 2020 The R Foundation for Statistical Computing
Platform: x86_64-pc-linux-gnu (64-bit)

R is free software and comes with ABSOLUTELY NO WARRANTY.
You are welcome to redistribute it under the terms of the
GNU General Public License versions 2 or 3.
For more information about these matters see
https://www.gnu.org/licenses/.

vincent@vincent-VB:~$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description: *Ubuntu 18.04.5 LTS*
Release: 18.04
Codename: bionic

Example of most recent URL mistakes in my package detected by CRAN package
submission process which I could not detect locally:
Found the following (possibly) invalid URLs: URL:
http://journals.plos.org/plosone/article?id=10.1371/journal.pone.0142533
(moved to
https://journals.plos.org/plosone/article?id=10.1371/journal.pone.0142533)
From: inst/CITATION Status: 200 Message: OK URL: https://geneactiv.org/
(moved to https://www.activinsights.com/) From: inst/doc/GGIR.html Status:
200 Message: OK URL: https://www.accelting.com/ (moved to
https://accelting.com/) From: inst/doc/GGIR.html Status: 200 Message: OK
URL: https://www.physiology.org/doi/10.1152/japplphysiol.00421.2014 (moved
to https://journals.physiology.org/doi/10.1152/japplphysiol.00421.2014)
From: inst/CITATION Status: 200 Message: OK

[[alternative HTML version deleted]]

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

Re: [Rd] trace creates object in base namespace if called on function argument

2020-08-26 Thread Tomas Kalibera

Please note that this is documented in ?trace. "fun" is matched to what, 
it is a _name_ of the function to be traced, which is traced in the 
top-level environment. I don't know why it was designed this way, but it 
is documented in detail, and hence the expected behavior.


Debugging is often, and also in R, implemented in the core. Tracing is 
implemented on top without specific support, it thus cannot do some 
things debugging can do.


Tomas


On 8/26/20 3:31 AM, Antoine Fabri wrote:

Apologies there is one line missing in my last email, the code should be :

foo <- function() "hello"
trace2 <- function(fun) trace(fun, quote(print("!!!")))
trace2(foo) # <- THIS LINE WAS MISSING
base::fun

Best,

Antoine

Le mar. 25 août 2020 à 22:02, Antoine Fabri  a
écrit :


Dear R-devel,

I don't think this is expected :

foo <- function() "hello"
trace2 <- function(fun) trace(fun, quote(print("!!!")))
base::fun
# Object with tracing code, class "functionWithTrace"
# Original definition:
# function() "hello"
#
# ## (to see the tracing code, look at body(object))

`untrace()` has the same behavior.

This is inconsistent with how debug works :

foo <- function() "hello"
debug2 <- function(fun) debug(fun)
debug2(foo)
isdebugged(foo)
# [1] TRUE

This can be worked around by defining :

trace2 <- function(fun) eval.parent(substitute(trace(fun,
quote(print("!!!")))

but I believe the current behavior is undesired and it'd be better to make
it behave as `debug()`, or to throw an error.

Best,

Antoine


[[alternative HTML version deleted]]

__
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] R 4.0.2 64-bit Windows hangs

Re: [Rd] trace creates object in base namespace if called on function argument

Re: [Rd] trace creates object in base namespace if called on function argument

Re: [Rd] NAs and rle

Re: [R-pkg-devel] url checks not working for me

Re: [R-pkg-devel] url checks not working for me

Re: [R-pkg-devel] Error in winbuilder

Re: [R-pkg-devel] Error in winbuilder

Re: [R-pkg-devel] Error in winbuilder

Re: [R-pkg-devel] url checks not working for me

Re: [R-pkg-devel] Error in winbuilder

Re: [R-pkg-devel] url checks not working for me

Re: [R-pkg-devel] url checks not working for me

Re: [R-pkg-devel] Error in winbuilder

Re: [R-pkg-devel] url checks not working for me

Re: [R-pkg-devel] url checks not working for me

[R-pkg-devel] url checks not working for me

Re: [Rd] trace creates object in base namespace if called on function argument

18 matches

Site Navigation

Mail list logo

Footer information