Re: [Rd] unable to load shared object
Thanks for asking. The path where R tries to load the dll from does not exist I think (or the install process deletes it after the error - might this be the case?): C:/Users/wewol/OneDrive/Documents/R/win-library/3.5/grpc/libs/x64/grpc.dll' When I am checking after the error that path is only valid up to: C:/Users/wewol/OneDrive/Documents/R/win-library/3.5/ So maybe (?) the install process wrongly assums that the package is installed (but it never was) and than it executes ** testing if installed package can be loaded To run into the error. Error: package or namespace load failed for 'grpc' in inDL(x, as.logical(local), as.logical(now), ...): unable to load shared object 'C:/Users/wewol/OneDrive/Documents/R/win-library/3.5/grpc/libs/x64/grpc.dll': LoadLibrary failure: The specified module could not be found. On Fri, 5 Oct 2018 at 09:37, Paul Johnson wrote: > > Greetings. > Is it possible that Onedrive is causing trouble? Do other packages you build > and install work well from that directory? > > Paul Johnson > University of Kansas > > On Wed, Oct 3, 2018, 3:13 AM Witold E Wolski wrote: >> >> Hello, >> >> I am trying to install a package with some src files on windows (linux >> install works fine). The sources seem to build, there is an *.dll in >> the src folder but than the installation process fails with: >> >> ``` >> ** testing if installed package can be loaded >> Error: package or namespace load failed for 'grpc' in inDL(x, >> as.logical(local), as.logical(now), ...): >> unable to load shared object >> 'C:/Users/wewol/OneDrive/Documents/R/win-library/3.5/grpc/libs/x64/grpc.dll': >> LoadLibrary failure: The specified module could not be found. >> >> Error: loading failed >> Execution halted >> ``` >> >> Do I need to point the installer to the *.dll in the src directory by >> creating some special function (e.g. dyn.load) or creating some >> special file? >> >> Help would be greatly appreciated: >> >> The packages sources are here: >> https://github.com/wolski/grpc-1 >> >> Witek >> >> >> -- >> Witold Eryk Wolski >> >> __ >> R-devel@r-project.org mailing list >> https://stat.ethz.ch/mailman/listinfo/r-devel -- Witold Eryk Wolski __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] unable to load shared object
Hm. I cannot find it now, but I saw notes about problems with Onedrive, maybe also Dropbox, because file paths are not exactly what r expects. Usually I have package library as local folder. Did your R choose that location automatically? Paul Johnson University of Kansas On Fri, Oct 5, 2018, 3:01 AM Witold E Wolski wrote: > Thanks for asking. > > The path where R tries to load the dll from does not exist I think (or > the install process deletes it after the error - might this be the > case?): > C:/Users/wewol/OneDrive/Documents/R/win-library/3.5/grpc/libs/x64/grpc.dll' > > When I am checking after the error that path is only valid up to: > C:/Users/wewol/OneDrive/Documents/R/win-library/3.5/ > > So maybe (?) the install process wrongly assums that the package is > installed (but it never was) and than it executes > ** testing if installed package can be loaded > > To run into the error. > > Error: package or namespace load failed for 'grpc' in inDL(x, > as.logical(local), as.logical(now), ...): > unable to load shared object > > 'C:/Users/wewol/OneDrive/Documents/R/win-library/3.5/grpc/libs/x64/grpc.dll': > LoadLibrary failure: The specified module could not be found. > On Fri, 5 Oct 2018 at 09:37, Paul Johnson wrote: > > > > Greetings. > > Is it possible that Onedrive is causing trouble? Do other packages you > build and install work well from that directory? > > > > Paul Johnson > > University of Kansas > > > > On Wed, Oct 3, 2018, 3:13 AM Witold E Wolski wrote: > >> > >> Hello, > >> > >> I am trying to install a package with some src files on windows (linux > >> install works fine). The sources seem to build, there is an *.dll in > >> the src folder but than the installation process fails with: > >> > >> ``` > >> ** testing if installed package can be loaded > >> Error: package or namespace load failed for 'grpc' in inDL(x, > >> as.logical(local), as.logical(now), ...): > >> unable to load shared object > >> > 'C:/Users/wewol/OneDrive/Documents/R/win-library/3.5/grpc/libs/x64/grpc.dll': > >> LoadLibrary failure: The specified module could not be found. > >> > >> Error: loading failed > >> Execution halted > >> ``` > >> > >> Do I need to point the installer to the *.dll in the src directory by > >> creating some special function (e.g. dyn.load) or creating some > >> special file? > >> > >> Help would be greatly appreciated: > >> > >> The packages sources are here: > >> https://github.com/wolski/grpc-1 > >> > >> Witek > >> > >> > >> -- > >> Witold Eryk Wolski > >> > >> __ > >> R-devel@r-project.org mailing list > >> https://stat.ethz.ch/mailman/listinfo/r-devel > > > > -- > Witold Eryk Wolski > [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Seg fault stats::runmed
Dear all,
I just found this issue:
dd1 = c(rep(NaN,82), rep(-1, 144), rep(1, 74))
xx = runmed(dd1, 21)
-> R crashes reproducibly in R 3.4.3, R3.4.4 (Ubuntu 14.04/Ubuntu 16.04)
With GDB:
Program received signal SIGSEGV, Segmentation fault.
swap (l=53, r=86, window=window@entry=0xc59308,
outlist=outlist@entry=0x12ea2e8, nrlist=nrlist@entry=0x114fdd8,
print_level=print_level@entry=0) at Trunmed.c:64
64 outlist[nr/* = nrlist[l] */] = l;
Valgrind also reports access to unallocated memory and/or writing past
the end of the heap.
The crash does not happen if the order is changed:
dd2 = c(rep(-1, 144), rep(1, 74), rep(NaN,82))
xx = runmed(dd2,21)
Error in if (a < b) { : missing value where TRUE/FALSE needed
Best regards,
Hilmar
--
Dr. Hilmar Berger, MD
Max Planck Institute for Infection Biology
Charitéplatz 1
D-10117 Berlin
GERMANY
Phone: + 49 30 28460 430
Fax:+ 49 30 28460 401
E-Mail: ber...@mpiib-berlin.mpg.de
Web : www.mpiib-berlin.mpg.de
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] [R] Bug : Autocorrelation in sample drawn from stats::rnorm (hmh)
On Fri, Oct 5, 2018 at 2:07 PM hmh wrote: > > On 05/10/2018 10:28, Annaert Jan wrote: > > you discard any time series structure; > But that is PRECISELY what a call a bug: > There should not be any "time series structure" in the output or rnorm, > runif and so on but there is one. > > rnorm(N,0,1) > should give on average the same output as > sample(rnorm(N,0,1)) Agreed, but that is not what your code is testing. You seem to think that something much more specific should be true; namely, X[1:10] ~ iid normal, then cor(X[1:9], X[2:10]) and cor(sample(X[-1]), sample(X[-10])) should have the same distribution. This is not at all obvious, and in fact not true. Please check the reference you have been pointed to. Here is a related article in the same volume: https://www.jstor.org/stable/2332719 -Deepayan > Which is not the case. rnorm(N,0,1) should draw INDEPENDENT samples i.e. > without time series structure ! > > > -- > - no title specified > > Hugo Mathé-Hubert > > ATER > > Laboratoire Interdisciplinaire des Environnements Continentaux (LIEC) > > UMR 7360 CNRS - Bât IBISE > > Université de Lorraine - UFR SciFA > > 8, Rue du Général Delestraint > > F-57070 METZ > > +33(0)9 77 21 66 66 > - - - - - - - - - - - - - - - - - - > Les réflexions naissent dans les doutes et meurent dans les certitudes. > Les doutes sont donc un signe de force et les certitudes un signe de > faiblesse. La plupart des gens sont pourtant certains du contraire. > - - - - - - - - - - - - - - - - - - > Thoughts appear from doubts and die in convictions. Therefore, doubts > are an indication of strength and convictions an indication of weakness. > Yet, most people believe the opposite. > > > [[alternative HTML version deleted]] > > __ > r-h...@r-project.org mailing list -- To UNSUBSCRIBE and more, see > https://stat.ethz.ch/mailman/listinfo/r-help > PLEASE do read the posting guide http://www.R-project.org/posting-guide.html > and provide commented, minimal, self-contained, reproducible code. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Dots are not fixed by make.names()
Hi
It seems that names of the form "..#" and "..." are not fixed by
make.names(), even though they are reserved words. The documentation reads:
> [...] Names such as ".2way" are not valid, and neither are the
reserved words.
> Reserved words in R: [...] ... and ..1, ..2 etc, which are used to
refer to arguments passed down from a calling function, see ?... .
I have pasted a reproducible example below.
I'd like to suggest to convert these to "...#" and "", respectively.
Happy to contribute PR.
Best regards
Kirill
make.names(c("..1", "..13", "..."))
#> [1] "..1" "..13" "..."
`..1` <- 1
`..13` <- 13
`...` <- "dots"
mget(c("..1", "..13", "..."))
#> $..1
#> [1] 1
#>
#> $..13
#> [1] 13
#>
#> $...
#> [1] "dots"
`..1`
#> Error in eval(expr, envir, enclos): the ... list does not contain any
elements
`..13`
#> Error in eval(expr, envir, enclos): the ... list does not contain 13
elements
`...`
#> Error in eval(expr, envir, enclos): '...' used in an incorrect context
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] [R] Bug : Autocorrelation in sample drawn from stats::rnorm (hmh)
I got it ! thanks and sorry for annoying you with that. have a nice day, hugo On 05/10/2018 11:16, Deepayan Sarkar wrote: > On Fri, Oct 5, 2018 at 2:07 PM hmh wrote: >> On 05/10/2018 10:28, Annaert Jan wrote: >>> you discard any time series structure; >> But that is PRECISELY what a call a bug: >> There should not be any "time series structure" in the output or rnorm, >> runif and so on but there is one. >> >> rnorm(N,0,1) >> should give on average the same output as >> sample(rnorm(N,0,1)) > Agreed, but that is not what your code is testing. You seem to think > that something much more specific should be true; namely, > > X[1:10] ~ iid normal, then > > cor(X[1:9], X[2:10]) > > and > > cor(sample(X[-1]), sample(X[-10])) > > should have the same distribution. This is not at all obvious, and in > fact not true. > > Please check the reference you have been pointed to. Here is a related > article in the same volume: > > https://www.jstor.org/stable/2332719 > > -Deepayan > > >> Which is not the case. rnorm(N,0,1) should draw INDEPENDENT samples i.e. >> without time series structure ! >> >> >> -- >> - no title specified >> >> Hugo Mathé-Hubert >> >> ATER >> >> Laboratoire Interdisciplinaire des Environnements Continentaux (LIEC) >> >> UMR 7360 CNRS - Bât IBISE >> >> Université de Lorraine - UFR SciFA >> >> 8, Rue du Général Delestraint >> >> F-57070 METZ >> >> +33(0)9 77 21 66 66 >> - - - - - - - - - - - - - - - - - - >> Les réflexions naissent dans les doutes et meurent dans les certitudes. >> Les doutes sont donc un signe de force et les certitudes un signe de >> faiblesse. La plupart des gens sont pourtant certains du contraire. >> - - - - - - - - - - - - - - - - - - >> Thoughts appear from doubts and die in convictions. Therefore, doubts >> are an indication of strength and convictions an indication of weakness. >> Yet, most people believe the opposite. >> >> >> [[alternative HTML version deleted]] >> >> __ >> r-h...@r-project.org mailing list -- To UNSUBSCRIBE and more, see >> https://stat.ethz.ch/mailman/listinfo/r-help >> PLEASE do read the posting guide http://www.R-project.org/posting-guide.html >> and provide commented, minimal, self-contained, reproducible code. -- - no title specified Hugo Mathé-Hubert ATER Laboratoire Interdisciplinaire des Environnements Continentaux (LIEC) UMR 7360 CNRS - Bât IBISE Université de Lorraine - UFR SciFA 8, Rue du Général Delestraint F-57070 METZ +33(0)9 77 21 66 66 - - - - - - - - - - - - - - - - - - Les réflexions naissent dans les doutes et meurent dans les certitudes. Les doutes sont donc un signe de force et les certitudes un signe de faiblesse. La plupart des gens sont pourtant certains du contraire. - - - - - - - - - - - - - - - - - - Thoughts appear from doubts and die in convictions. Therefore, doubts are an indication of strength and convictions an indication of weakness. Yet, most people believe the opposite. [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Seg fault stats::runmed
> Hilmar Berger
> on Fri, 5 Oct 2018 10:17:49 +0200 writes:
> Dear all, I just found this issue:
> I just found this issue:
> dd1 = c(rep(NaN,82), rep(-1, 144), rep(1, 74))
> xx = runmed(dd1, 21)
>> R crashes reproducibly in R 3.4.3, R3.4.4 (Ubuntu 14.04/Ubuntu 16.04)
and also in the latest development version (we call "R-devel").
THank you very much, Hilmar!
I will have a look, to ensure missing values (incl NaN) are
handled propertly.
Martin
--
Martin Maechler
ETH Zurich and R Core Team
> With GDB:
> Program received signal SIGSEGV, Segmentation fault.
> swap (l=53, r=86, window=window@entry=0xc59308,
> outlist=outlist@entry=0x12ea2e8, nrlist=nrlist@entry=0x114fdd8,
> print_level=print_level@entry=0) at Trunmed.c:64
> 64 outlist[nr/* = nrlist[l] */] = l;
> Valgrind also reports access to unallocated memory and/or writing past
> the end of the heap.
> The crash does not happen if the order is changed:
> dd2 = c(rep(-1, 144), rep(1, 74), rep(NaN,82))
> xx = runmed(dd2,21)
> Error in if (a < b) { : missing value where TRUE/FALSE needed
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] [R] Bug : Autocorrelation in sample drawn from stats::rnorm (hmh)
On 05/10/2018, 09:45, "R-help on behalf of hmh" wrote: Hi, Thanks William for this fast answer, and sorry for sending the 1st mail to r-help instead to r-devel. I noticed that bug while I was simulating many small random walks using c(0,cumsum(rnorm(10))). Then the negative auto-correlation was inducing a muchsmaller space visited by the random walks than expected if there would be no auto-correlation in the samples. The code I provided and you optimized was only provided to illustrated and investigate that bug. It is really worrying that most of the R distributions are affected by this bug What I did should have been one of the first check done for _*each*_ distributions by the developers of these functions ! And if as you suggested this is a "tolerated" _error_ of the algorithm, I do think this is a bad choice, but any way, this should have been mentioned in the documentations of the functions !! cheers, hugo This is not a bug. You have simply rediscovered the finite-sample bias in the sample autocorrelation coefficient, known at least since Kendall, M. G. (1954). Note on bias in the estimation of autocorrelation. Biometrika, 41(3-4), 403-404. The bias is approximately -1/T, with T sample size, which explains why it seems to disappear in the larger sample sizes you consider. Jan __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Redundant code in 'split.default' in R devel
After r75387, function 'split.default' in R devel still has this part that no
longer has effect.
lf <- levels(f)
y <- vector("list", length(lf))
names(y) <- lf
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] segfault issue with parallel::mclapply and download.file() on Mac OS X
Jeroen/Tomas, Thanks for the additional follow-ups. As shown in my original post, I am on macOS 10.12.6. I was using the command line version of R to get the error message I sent; I also get similar problems when running via GUI tools such as RStudio. I have co-workers who are only using macOS and they got similar crashes - though I'm not sure which version of macOS they are on. Based on Gábor's recommendation I did quit using the default libcurl backend (default on my machine at least). Using download.file(url, path, method = curl) has been working great for my use case. Seth [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
