[Rd] Setting the path to Rtools for package compilation on Windows
Hi all, I'm trying to set up the Windows Rtools toolset for building packages with compiled code. I installed for Windows R-3.4.3 from CRAN and installed Rtools-3.4 in a custom location M:\R\R-3.4.3 and M:\R\Rtools-3.4 Following the instructions, in shell, I set Path=M:\R\Rtools-3.4\bin;M:\R\Rtools-3.4\gcc-4.6.3\bin;M:\R\R-3.4.3\bin;... (the ... are other paths irrelevant for R/Rtools). When I run M:\Work\RLibs>R.exe CMD INSTALL --build WGCNA I get the following ouput: In R CMD INSTALL * installing to library 'M:/R/R-3.4.3/library' * installing *source* package 'WGCNA' ... ** libs *** arch - i386 c:/Rtools/mingw_32/bin/g++ -I"M:/R/R-3.4.3/include" -DNDEBUG -O2 -Wall -mtune=generic -c bucketApproxSort.cc -o bucketApproxSort.o c:/Rtools/mingw_32/bin/g++: not found make: *** [bucketApproxSort.o] Error 127 Warning: running command 'make -f "Makevars.win" -f "M:/R/R-3.4.3/etc/i386/Makeconf" -f "M:/R/R-3.4.3/share/make/winshli b.mk" SHLIB_LDFLAGS='$(SHLIB_CXXLDFLAGS)' SHLIB_LD='$(SHLIB_CXXLD)' SHLIB="WGCNA.dll" OBJECTS="bucketApproxSort.o corFun ctions-common.o corFunctions-unified.o networkFunctions.o pivot.o quantileC.o"' had status 2 ERROR: compilation failed for package 'WGCNA' * removing 'M:/R/R-3.4.3/library/WGCNA' * restoring previous 'M:/R/R-3.4.3/library/WGCNA' Apparently the install is looking for Rtools in c:\Rtools. I am a perpetual Windows newbie and would be really thankful for any pointers as to how to proceed. Peter __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Setting the path to Rtools for package compilation on Windows
On Tue, Feb 13, 2018 at 2:20 AM, Jeroen Ooms wrote: > Thanks for your question. Your logs show that 'gcc' is not found. As > of R 3.3 you need to set the path to the compiler using the BINPREF > variable. This is because we ship two separate versions of gcc, one > targeting win32 and one targeting win64. I am not sure what your > rtools installation looks like, but could you try setting this > environment variable: > > BINPREF="M:/R/Rtools-3.4/mingw_$(WIN)/bin/" > > I think this will do the job. Thanks, that indeed did the trick. May I suggest that this hint be also included in "REMAINING TASKS" section of the file Rtools.txt that is part of the Rtools distribution? The R installation manual does mention BINPREF and BINPREF64 but I missed that part... Peter __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] CRAN Check warnings with GCC 8.1
Some time ago I (and some other CRAN package maintainers) got an email from Brian Ripley (copied below) regarding compiler warnings under gcc 8.1. In my case this concerns package PropClust (https://CRAN.R-project.org/package=PropClust). The check with gcc 8.1 (https://www.stats.ox.ac.uk/pub/bdr/gcc8/PropClust.out) produced a warning about an uninitialized variable. I cannot reproduce the warning under gcc 8.1.1 using standard R CMD check (with or without --as-cran) under R Under development (unstable) (2018-05-24 r74781); the check finishes "OK" without any warnings or notes. Does anyone have any suggestions as to how to reproduce the warning, or is this something specific to a particular gcc version? My gcc version 8.1.1 20180502 (Red Hat 8.1.1-1). Thanks, Peter On Sat, May 5, 2018 at 11:53 PM Prof Brian Ripley wrote: > > This concerns CRAN packages > > Amelia C50 Cubist Cyclops DetSel GENLIB IRISSeismic KSgeneral > MigClim MonetDBLite Numero OpenMx PBSmapping PSPManalysis > PropClust RArcInfo RandomFields RandomFieldsUtils RcppMsgPack > RcppParallel RcppRedis RecordLinkage Rmalschains RnavGraph Rvcg > RxODE SiMRiv antiword bigrquery bsamGP catnet coxme dbarts > dggridR divest dpglasso earth epanet2toolkit fs gap geojsonsf > gglasso graphql hashmap haven hier.part imager iptools jiebaR > kernlab lpridge lvec mlvocab mongolite nandb ore phreeqc polyclip > qtbase rbamtools rebmix rexpokit rgdal rioja rlas rpf rphast > rtfbs s2 scio sdnet sdwd sequoia tmlenet tth udpipe validatejsonr > velox wrassp > > GCC 8.1 (the current release) reports more compilation issues than > previous versions, the more important of which are reported as check > warnings by R CMD check (in R 3.5.0 and later) and as 'Additional > issues' on the CRAN check pages. > > GCC 8 is already part of the Fedora Linux 28 release and in Debian > unstable. Although you may not have access to it yet, the warnings are > self-contained and usually easy to understand (often that buffers are > too small). > > Please see the reports for your package(s) and correct ASAP. For > packages gap and rexpokit these include a .log file with the complete > compilation log. > > -- > Brian D. Ripley, rip...@stats.ox.ac.uk > Emeritus Professor of Applied Statistics, University of Oxford __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] maximum matrix size
Does this help a little? https://cran.r-project.org/doc/manuals/r-release/R-ints.html#Long-vectors One thing I seem to remember but cannot find a reference for is that long vectors can only be passed to .Call calls, not C/Fortran. I remember rewriting .C() in my WGCNA package to .Call for this very reason but perhaps the restriction has been removed. Peter On Tue, Oct 2, 2018 at 9:43 AM Therneau, Terry M., Ph.D. via R-devel wrote: > > I am now getting the occasional complaint about survival routines that are > not able to > handle big data. I looked in the manuals to try and update my understanding > of max > vector size, max matrix, max data set, etc; but it is either not there or I > missed it (the > latter more likely). Is it still .Machine$integer.max for everything? > Will that > change? Found where? > > I am going to need to go through the survival package and put specific checks > in front > some or all of my .Call() statements, in order to give a sensible message > whenever a > bounday is struck. A well meaning person just posted a suggested "bug fix" > to the github > source of one routine where my .C call allocates a scratch vector, suggesting > "resid = > double( as.double(n) *nvar)" to prevent a "NA produced by integer overflow" > message, in > the code below. A fix is obvously not quite that easy :-) > > resid <- .C(Ccoxscore, as.integer(n), > as.integer(nvar), > as.double(y), > x=as.double(x), > as.integer(newstrat), > as.double(score), > as.double(weights[ord]), > as.integer(method=='efron'), > resid= double(n*nvar), > double(2*nvar))$resid > > Terry T. > > > [[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] openblas
I'm a linux guy so take the advice with a grain of salt... When you run the configure script, look at the output at the end of the run, it should either say Options enabled: shared BLAS, ... (means you are using R BLAS) or it should mention OpenBLAS in External libraries (meaning you are using OpenBLAS). You can also see the results in config.log of you search for BLAS. Or you could use the old trick of replacing libRblas.dylib with a link to the appropriate OpenBLAS dylib. On Tue, May 7, 2019 at 5:01 PM robin hankin wrote: > > Hello, macosx 10.13.6, Rdevel r76458 > > I'm trying to compile against openblas to reproduce an error on the > CRAN check page (my package is clean under winbuilder and all but one > of the checks). I've downloaded and installed openblas 0.3.7 but I > am not 100% sure that it is being used by R. > > Using > > ./configure --with-blas="-lopenblas" > > Then running R to discover the PID I get: > > > Rd % lsof -p 17960|egrep -i blas > > R 17960 rhankin txtREG1,8 189224 33471762 > /Users/rhankin/Rd/lib/R/lib/libRblas.dylib > > > But it is not clear to me how to interpret this. Am I using openblas > as intended? I suspect not, for I cannot reproduce the error. Can > anyone advise? > > > hankin.ro...@gmail.com > > __ > 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] openblas
(CCing the R-devel list, maybe someone will have a better answer.) To be honest, I don't know how to. I wasn't able to configure R to use OpenBLAS using the configure script and options on my Linux Fedora system. I configure it without external BLAS, then replace the libRblas.dylib (.so in my case) with a link to the OpenBLAS dynamic link library. Peter On Tue, May 7, 2019 at 7:39 PM robin hankin wrote: > thanks Peter, I appreciate your advice here. > > ./configure --with-blas="-lopenblas" --without-recommended-packages > > > gives me > > > > > Interfaces supported:X11, aqua, tcltk > > External libraries: readline, curl > > Additional capabilities: JPEG, NLS, ICU > > Options enabled: shared BLAS, R profiling > > > Capabilities skipped:PNG, TIFF, cairo > > Options not enabled: memory profiling > > > Recommended packages:no > > > > so it doesn't look like it's using the openBlas... how come the arguments > to ./configure are being ignored? > > > > > hankin.ro...@gmail.com > > > > > > > On Wed, May 8, 2019 at 1:04 PM Peter Langfelder < > peter.langfel...@gmail.com> wrote: > >> I'm a linux guy so take the advice with a grain of salt... When you >> run the configure script, look at the output at the end of the run, it >> should either say >> >> Options enabled: shared BLAS, ... (means you are using R BLAS) >> >> or it should mention OpenBLAS in External libraries (meaning you are >> using OpenBLAS). >> >> You can also see the results in config.log of you search for BLAS. >> >> Or you could use the old trick of replacing libRblas.dylib with a link >> to the appropriate OpenBLAS dylib. >> >> On Tue, May 7, 2019 at 5:01 PM robin hankin >> wrote: >> > >> > Hello, macosx 10.13.6, Rdevel r76458 >> > >> > I'm trying to compile against openblas to reproduce an error on the >> > CRAN check page (my package is clean under winbuilder and all but one >> > of the checks). I've downloaded and installed openblas 0.3.7 but I >> > am not 100% sure that it is being used by R. >> > >> > Using >> > >> > ./configure --with-blas="-lopenblas" >> > >> > Then running R to discover the PID I get: >> > >> > >> > Rd % lsof -p 17960|egrep -i blas >> > >> > R 17960 rhankin txtREG1,8 189224 33471762 >> > /Users/rhankin/Rd/lib/R/lib/libRblas.dylib >> > >> > >> > But it is not clear to me how to interpret this. Am I using openblas >> > as intended? I suspect not, for I cannot reproduce the error. Can >> > anyone advise? >> > >> > >> > hankin.ro...@gmail.com >> > >> > __ >> > 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] openblas
On Wed, May 8, 2019 at 9:00 AM Ralf Stubner wrote: > AFAIK a single-threaded OpenBLAS is used. When compiling R from source > on a CentOS system I have used the configure option > '--with-blas="-lopenblasp"' to link with the pthread version of OpenBLAS. Yes, that's the right incantation. Thanks for solving it for me... Peter __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] survival changes
On Sat, Jun 1, 2019 at 3:22 AM Therneau, Terry M., Ph.D. via R-devel wrote: > > In the next version of the survival package I intend to make a non-upwardly > compatable > change to the survfit object. With over 600 dependent packages this is not > something to > take lightly, and I am currently undecided about the best way to go about it. > I'm looking > for advice. > > The change: 20+ years ago I had decided not to include the initial x=0,y=1 > data point in > the survfit object itself. It was not formally an estimand and the > plot/points/lines etc > routines could add this on themselves. That turns out to have been a > mistake, and has led > to a steady proliferation of extra bits as I realized that the time axis > doesn't always > start at 0, and later (with multi state) that y does not always start at 1 > (though the > states sum to 1), and later the the error doesn't always start at 0, and > another > realization with cumulative hazard, and ... > The new survfit method for multi-state coxph models was going to add yet > another special > case. Basically every component is turning into a duplicate of "row 1" vs > "all the > others". (And inconsistently named.) > > Three possible solutions > 1. Current working draft of survival_3.0.3: Add a 'version' element to the > survfit object > and a 'survfit2.3' function that converts old to new. All my downstream > functions (print, > plot,...) start with an "if (old) update to new" line. This has allowed me > to stage > updates to the functions that create survfit objects -- I expect it to happen > slowly. > There will also be a survfit3.2 function to go backwards. Both the forward > and backwards > functions leave objects alone if they are currently in the desired format. > > 2. Make a new class "survfit3" and the necessary 'as' functions. The package > would contain > plot.survfit and plot.survfit3 methods, the former a two line "convert and > call the > second" function. > > 3. Something I haven't thought of. A more "clean break" solution would be to start a whole new package (call it survival2) that would make these changes, and deprecate the current survival. You could add warnings about deprecation and urging users to switch in existing survival functions. You could continue bugfixes for survival but only add new features to survival2. The new survival2 and the current survival could live side by side on CRAN for quite some time, giving maintainers of dependent packages (and just plain users) enough time to switch. This could allow you to change/clean up other parts of the package that you could perhaps also use a rethink/rewrite, without too much concern for backward compatibility. Peter __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] point size in svg
Unless this is something Apple-specific, the problem seems to be with
Gimp, not with R. On my system (linux), opening your examples with
either firefox or inkscape shows huge letters. At least firefox should
be able to open the svg on a Mac as well. BTW, Gimp on linux does not
open your cex-svg.svg at all, it says the plugin crashed.
Peter
On Wed, Jun 19, 2019 at 8:19 AM Spencer Graves
wrote:
>
> Hello, All:
>
>
>I'm unable to control the font size in plots to svg. Consider
> the following:
>
>
> svg('cex-svg.svg')
> cex. <- 5
> plot(1:2, cex.axis=cex.)
> text(1:2, 1:2, c('as', 'DF'),
>cex=cex.)
> dev.off()
>
>
>When I open this in Gimp 2.10.4, the font size is tiny. I also
> tried:
>
>
> svg('cex-svg.svg', width=15, height=15, pointsize=24)
> cex. <- 5
> plot(1:2, cex.axis=cex.)
> text(1:2, 1:2, c('as', 'DF'),
>cex=cex.)
> dev.off()
>
>
>What do I do to control the font size in svg?
>
>
>Thanks,
>Spencer Graves
>
>
> sessionInfo()
> R version 3.6.0 (2019-04-26)
> Platform: x86_64-apple-darwin15.6.0 (64-bit)
> Running under: macOS Mojave 10.14.5
>
> Matrix products: default
> BLAS:
> /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libBLAS.dylib
> LAPACK:
> /Library/Frameworks/R.framework/Versions/3.6/Resources/lib/libRlapack.dylib
>
> locale:
> [1] en_US.UTF-8/en_US.UTF-8/en_US.UTF-8/C/en_US.UTF-8/en_US.UTF-8
>
> attached base packages:
> [1] stats graphics grDevices utils datasets
> [6] methods base
>
> other attached packages:
> [1] Ecdat_0.3-2 Ecfun_0.2-1
>
> __
> 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] inconsistent behaviour of c(...)
I think your character vector got converted to a factor. See ?options, section stringsAsFactors: ‘stringsAsFactors’: The default setting for arguments of ‘data.frame’ and ‘read.table’. The default is TRUE, so strings get converted to factors when building data frames. Set options(stringsAsFactors=FALSE) and try again. Peter On Fri, Jul 19, 2019 at 12:15 AM Michael Meyer via R-devel wrote: > > > > Greetings, > > Running R 3.5.0 under Windows 7 > > typeof(c(1,"2")) yields "character" as expected. But in > > d.f <- data.frame(C=c(1,"2")) > > typeof(d.f$C) yields "integer". > > Is this a bug? > > Michael Meyer > > __ > 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] R-patched is now R-beta?
Just downloaded the newest R-patched.tar.bz. DEcompressing and untarring now produces a directory R-beta instead of the usual (for me, at least) R. The file VERSION now says 3.2.2 beta. Just wanted to double-check that there is no mixup of development and patched versions. Thanks, Peter __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R-patched is now R-beta?
Thanks!
Peter
On Thu, Aug 6, 2015 at 12:07 PM, Dirk Eddelbuettel wrote:
>
> On 6 August 2015 at 11:33, Peter Langfelder wrote:
> | Just downloaded the newest R-patched.tar.bz. DEcompressing and
> | untarring now produces a directory R-beta instead of the usual (for
> | me, at least) R. The file VERSION now says 3.2.2 beta. Just wanted to
> | double-check that there is no mixup of development and patched
> | versions.
>
> That is the common pattern leading up to a release. See eg
> http://developer.r-project.org/
> and I quoteL
>
> The release of 3.2.2 ("Fire Safety") is scheduled for August 14,
> 2015. Release candidate tarballs will be made available during the week up
> to
> the release.
>
> 2015-08-04: START (3.2.2 beta)
> 2015-08-07: CODE FREEZE (3.2.2 RC)
> 2015-08-14: RELEASE (3.2.2)
>
> I made a first beta release for Debian on Aug 4th and plan to make one more
> before August 14 when 3.2.2 becomes official.
>
> Dirk
>
> --
> http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Problem with a regular expression.
FWIW, I tried it on my linux box. The memory use shot through the roof, the system crawled to a halt due to constant swapping, and after a minute or so top showed memory use of 47GB, at which point I killed the R process. On linux at least R is not frozen but the strsplit call gobbles up memory (and does not seem to end) which makes it look like it's frozen. Peter > sessionInfo() R version 3.4.1 Patched (2017-08-11 r73090) Platform: x86_64-pc-linux-gnu (64-bit) Running under: Fedora 26 (Twenty Six) Matrix products: default BLAS: /usr/local/atlas/lib/libtatlas.so LAPACK: /usr/local/lib64/R-3.4.1-patched-atlas-parallel/lib/libRlapack.so locale: [1] LC_CTYPE=en_US.UTF-8 LC_NUMERIC=C [3] LC_TIME=en_US.UTF-8LC_COLLATE=en_US.UTF-8 [5] LC_MONETARY=en_US.UTF-8LC_MESSAGES=en_US.UTF-8 [7] LC_PAPER=en_US.UTF-8 LC_NAME=C [9] LC_ADDRESS=C LC_TELEPHONE=C [11] LC_MEASUREMENT=en_US.UTF-8 LC_IDENTIFICATION=C attached base packages: [1] stats graphics grDevices utils datasets methods base loaded via a namespace (and not attached): [1] compiler_3.4.1 On Wed, Aug 16, 2017 at 3:31 PM, Chris Triggs wrote: > Hi... > > I have come upon a problem with a regular expression which causes base-R > to freeze. I have reproduced the phenomenon on several machines running R > under Windows 10, and also under OSX on different Apple MACs. > > The minimal example is:- > Oldterm is a vector of characters, e.g. "A", "B", "A", "*", "B" > The regular expression is ")" > > The call which freezes R is > strsplit(Oldterm, ")" ) > > Thomas - after he had reproduced the problem - suggested that I submit it > to r-devel. > > Best wishes >Chris Triggs > > > [[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] OpenBLAS in everyday R?
I would be very cautious about OpenBLAS in particular... from time to time I get complains from users that compiled code calculations in my WGCNA package crash or produce wrong answers with large data, and they all come from OpenBLAS users. I am yet to reproduce any of their crashes when using MKL and ATLAS BLAS implementations. Just my 2 cents... Peter On Sat, Dec 16, 2017 at 12:28 PM, Kenny Bell wrote: > Hi R-devel list, > > OpenBLAS is readily available for unix-likes: > > https://cloud.r-project.org/web/packages/gcbd/vignettes/gcbd.pdf > > However, my questions are: > > 1) Would R-devel consider using OpenBLAS for the main distribution of R for > all platforms including Windows? > 2) If so, would R-devel set the default multi-thread level to the number of > (real) cores on a machine? > > My sense is there're a lot of wasted resources on laptops and personal > desktops around the world that could be utilised by such a switch. I > believe most unix-like users don't know about OpenBLAS and are blissfully > ignorant of the available speed gains. It seems to be quite difficult for a > typical Windows user to get this done today. > > Thanks heaps, > Kenny > > [[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] Trivial typo in help("browser")
I'm also not a native speaker but my take is that a "be" is missing in
the sentence and it should read
An expression, which if it evaluates to TRUE the debugger will be invoked,
otherwise control is returned directly.
On Wed, Jul 28, 2021 at 11:52 PM Rui Barradas wrote:
>
> Hello,
>
> R 4.1.0 on Ubuntu 20.04, session info below.
>
> I am not an English native speaker but in help("browser"), section
> Arguments, argument expr, there is a wrong verb tense:
>
> "invoked" should be "invoke", right?
>
> expr
> An expression, which if it evaluates to TRUE the debugger will invoked,
> otherwise control is returned directly.
>
>
>
> sessionInfo()
> R version 4.1.0 (2021-05-18)
> Platform: x86_64-pc-linux-gnu (64-bit)
> Running under: Ubuntu 20.04.2 LTS
>
> Matrix products: default
> BLAS: /usr/lib/x86_64-linux-gnu/blas/libblas.so.3.9.0
> LAPACK: /usr/lib/x86_64-linux-gnu/lapack/liblapack.so.3.9.0
>
> locale:
> [1] LC_CTYPE=pt_PT.UTF-8 LC_NUMERIC=C
> [3] LC_TIME=pt_PT.UTF-8LC_COLLATE=pt_PT.UTF-8
> [5] LC_MONETARY=pt_PT.UTF-8LC_MESSAGES=pt_PT.UTF-8
> [7] LC_PAPER=pt_PT.UTF-8 LC_NAME=C
> [9] LC_ADDRESS=C LC_TELEPHONE=C
> [11] LC_MEASUREMENT=pt_PT.UTF-8 LC_IDENTIFICATION=C
>
> attached base packages:
> [1] stats graphics grDevices utils datasets methods base
>
> loaded via a namespace (and not attached):
> [1] compiler_4.1.0
>
>
>
> Thanks to all R Core Team members for their great work for all of us.
>
> Hope this helps,
>
> Rui Barradas
>
> __
> 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] hist.default for long vectors
Hi all, this may have been noticed/discussed before but my search came up empty, so here it is: hist.default throws a (somewhat cryptic) error when trying to call it on a long vector. The error is invalid length(x) and is thrown because lines 4 and 5 or so are n <- length(x <- x[is.finite(x)]) n <- as.integer(n) Would adapting hist.default for long vectors be as simple as removing the as.integer line, or is there other code that depends on n being representable as a 4-byte integer? I see a 'call' to C_BinCount which I briefly skimmed and it seems to be ready for long vectors (uses R_xlen_t for indexing variables). Anything else I am missing? While we're at it, anyone aware of a hist alternative that can handle long vectors? Thanks, Peter __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] [External] R hang/bug with circular references and promises
On Sat, May 11, 2024 at 9:34 AM luke-tierney--- via R-devel
wrote:
>
> On Sat, 11 May 2024, Travers Ching wrote:
>
> > The following code snippet causes R to hang. This example might be a
> > bit contrived as I was experimenting and trying to understand
> > promises, but uses only base R.
>
> This has nothing to do with promises. You created a cycle in the
> environment chain. A simpler variant:
>
> e <- new.env()
> parent.env(e) <- e
> get("x", e)
>
> This will hang and is not interruptable -- loops searching up
> environment chains are too speed-critical to check for interrupts. It
> is, however, pretty easy to check whether the parent change would
> create a cycle and throw an error if it would. Need to think a bit
> about exactly where the check should go.
FWIW, the help for parent.env already explicitly warns against using
parent.env <-:
The replacement function ‘parent.env<-’ is extremely dangerous as
it can be used to destructively change environments in ways that
violate assumptions made by the internal C code. It may be
removed in the near future.
Peter
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] R-patched on CRAN is R-4.3.3
Hi all, apologies if I missed something here. Just downloaded and compiled R-patched from https://stat.ethz.ch/R/daily/ but it reports as R-4.3.3 (2024-04-09 r86895) -- "Angel Food Cake". The last dated R-patched is from 2024-04-09, about 3 months old. Are R-patched not updated anymore, am I looking at a wrong directory or even a wrong server? The current R Installation and Administration manual (https://cran.r-project.org/doc/manuals/r-patched/R-admin.html#Getting-patched-and-development-versions) suggests that the current R-patched should be where I looked for it: A patched version of the current release, ‘r-patched’, and the current development version, ‘r-devel’, are available as daily tarballs and via access to the R Subversion repository. (For the two weeks prior to the release of a minor (4.x.0) version, ‘r-patched’ tarballs may refer to beta/release candidates of the upcoming release, the patched version of the current release being available via Subversion.) The tarballs are available from https://stat.ethz.ch/R/daily/. Download R-patched.tar.gz or R-devel.tar.gz (or the .tar.bz2 versions) and unpack as described in the previous section. They are built in exactly the same way as distributions of R releases. Thanks, Peter __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Bug in stats::plot.hclust/graphics:::plotHclust/underlying C code (C_dend) in R-3.0?
Hi all, it appears that plot.hclust disregards the argument 'cex'. Up until 2.15.1 (and probably all 2.15.x), specifying cex in plot.hclust changed the size of the plotted labels on each leaf. In 3.0.0 the character size remains the same irrespective of the cex setting. Since the help text for plot.hclust does not mention the cex argument, it is possible that an "undocumentde feature" was simply removed - but it was very useful when it was available. The following code illustrates the problem: data = c(1:20) dst = dist(data) tree = hclust(dst, method = "a") plot(tree, cex = 1) plot(tree, cex = 0.5) plot(tree, cex = 0.2) Under R-2.15 and earlier, the leaf labels would get progressively smaller; under 3.0.0, the label size remains the same. I tried this both under Windows R version 2.15.1 (2012-06-22) Platform: x86_64-pc-mingw32/x64 (64-bit) locale: [1] LC_COLLATE=English_United States.1252 [2] LC_CTYPE=English_United States.1252 [3] LC_MONETARY=English_United States.1252 [4] LC_NUMERIC=C [5] LC_TIME=English_United States.1252 attached base packages: [1] stats graphics grDevices utils datasets methods base -- Session info for R-3.0.0 R version 3.0.0 (2013-04-03) Platform: x86_64-w64-mingw32/x64 (64-bit) locale: [1] LC_COLLATE=English_United States.1252 [2] LC_CTYPE=English_United States.1252 [3] LC_MONETARY=English_United States.1252 [4] LC_NUMERIC=C [5] LC_TIME=English_United States.1252 attached base packages: [1] stats graphics grDevices utils datasets methods base and under Linux R version 3.0.0 Patched (2013-04-24 r62658) Platform: x86_64-unknown-linux-gnu (64-bit) locale: [1] LC_CTYPE=en_US.UTF-8 LC_NUMERIC=C [3] LC_TIME=en_US.UTF-8LC_COLLATE=en_US.UTF-8 [5] LC_MONETARY=en_US.UTF-8LC_MESSAGES=en_US.UTF-8 [7] LC_PAPER=C LC_NAME=C [9] LC_ADDRESS=C LC_TELEPHONE=C [11] LC_MEASUREMENT=en_US.UTF-8 LC_IDENTIFICATION=C attached base packages: [1] stats graphics grDevices utils datasets methods base Looking at the source code of plot.hclust leads to graphics:::plotHclust which calls .External.graphics, which is where my ability to read code quickly stops :) I realize that these are not the most recent releases but I couldn't find anything mentioning a bug fix for this in the changelog, so I assume it has not been fixed. Thanks, Peter __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Problem with R >3.0.0
Hi Sam, I assume you mean that correlation for _genes_ (not samples) 11262:3 is 0? I am the maintainer of the WGCNA package but unfortunately I don't have access to a Mac big enough to try 3x3 correlation matrix, but I would be thankful if you could try reproducing the problem with smaller matrices (e.g. 2x2) and try to produce a small reproducible example by generating the data using say rnorm, say like this: nGenes = 2 # as small as possible that still produces the error nSamples = 100 datExpr1 = matrix(rnorm(nSamples * nGenes), nSamples, nGenes) simMat = bicor(datExpr1, use = 'p') Best, Peter On Mon, Aug 19, 2013 at 11:53 AM, Shelton, Samuel wrote: > Dear R developer, > > I am an R user and am currently having a problem with versions of R >3.0.0. > We build larger correlation matrices of >3 with pairwise correlations > made. We have been using a line of code > > simMat=bicor(datExpr1,use="p") > > To build the similarity matrix with datExpr1 being a matrix with genes as > columns (>3) and rows being samples. This code works fine on an iMac > running OSX 10.8.5 and using R 2.15.2 and the Rblas library. When I try to > run the same code with R version 3.0.0 and 3.0.1 it only partially builds the > matrix. It will return correlations for samples 1:11262 but from 11262:3 > the matrix is full of 0's. > > We would like to be able to use R 3.0.0 to allow us to build larger > correlation matrices on our cluster but we can't use it at the moment due to > this problem. My colleague has previously had a similar issue when using snow > leopard and this was to do with a compatibility issue between snow leopard > and the veclib. Has something changed in version 3.0.0 to give an > incompatibility with the veclib? > > Many thanks > > Sam > > Samuel Shelton, Ph.D. > Postdoctoral Researcher, > The Oldham Lab, > The institute of Regeneration Medicine, > University of California San Francisco, > San Francisco, CA 94143 > > email: shelt...@stemcell.ucsf.edu > > > [[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] Problem with R >3.0.0
On Tue, Aug 20, 2013 at 9:23 AM, peter dalgaard wrote: > What is bicor()? From the WGCNA package? Perhaps the package is doing > something incompatible with the long vector support in R 3.0.0. You need to > report such queries to the maintainer. The maintainer is reporting for duty :) The version of WGCNA currently on CRAN uses .C to call compiled code. If I read the manuals right, long vectors are not allowed in .C calls. In my .C calls I use explicit type casts (as.integer, as.double etc) for all arguments. Once we see a reproducible example, we can figure out the problem. Peter __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Problem with R >3.0.0
0.5282165 0.48879156 0.11807913 0.7372706 0.9975103 > [8,] 0.8392414 0.17107463 1.08732839 0.28981611 0.4722655 0.17587788 > 1.7426814 0.13985161 1.86885446 1.9031580 1.1088431 > [9,] 3.4648342 0.33834943 0.07891645 0.07206860 1.1792628 0.54092203 > 0.8141844 2.82687085 0.78395229 0.5313417 3.2164664 > [10,] 0.1524299 0.02045616 0.67881610 1.51491647 2.4390115 0.89033581 > 0.9026651 0.46858464 1.47711638 2.1821178 2.2149071 > [11,] 0.9397162 0.42376104 0.20034405 1.47672836 1.0461904 0.97296202 > 2.1658717 0.04487329 0.30611082 1.1680312 0.9952517 > > diag(mat1)=0 > > mat1[1:10,1:10] >[,1] [,2] [,3] [,4][,5] [,6] > [,7] [,8] [,9] [,10] > [1,] 0.000 0.1357886 1.64090976 0.4494637 0.812315613 0.5328906 > 0.45672475 0.2891504 1.57087882 1.27375802 > [2,] 3.8229940 0.000 0.30189392 1.2100152 0.003323061 0.7195875 > 0.60251052 1.9820380 0.18637086 0.05154236 > [3,] 2.0411498 0.8371707 0. 1.3032572 0.330472063 0.3502267 > 0.11908140 0.4155857 3.46471729 0.31890778 > [4,] 1.5503390 0.7377494 2.01433675 0.000 1.844484309 1.2492693 > 0.09365743 0.4006219 2.37769616 0.38643521 > [5,] 0.4815804 0.5824312 0.61003728 0.4782871 0.0 0.1207842 > 0.93567987 1.7369767 4.47922786 0.20033928 > [6,] 0.3791645 0.1015489 1.96832962 1.5417178 1.030250434 0.000 > 1.72807083 0.2570055 0.02127689 0.80225716 > [7,] 1.5212795 2.8133952 0.15990367 0.4337506 0.526532536 2.9926685 > 0. 0.6064162 0.69264596 0.50871566 > [8,] 1.2600365 0.1901277 2.34806048 1.1472887 0.141571521 2.0355007 > 1.12583466 0.000 0.18707165 3.71877247 > [9,] 3.0197258 2.3693633 0.94571337 0.2756933 0.938999190 1.5892456 > 0.18612994 1.0498866 0. 1.56643880 > [10,] 0.3573243 0.3047595 0.01894034 2.4666841 0.660994174 0.2248711 > 0.25436398 1.1275389 0.20960212 0. > > > ## After calling the diag function the bottom of the matrix is all set to > 0. > > > mat1[37990:38000,37990:38000] > [,1] [,2] [,3] [,4] [,5] [,6] [,7] [,8] [,9] [,10] [,11] > [1,]000000000 0 0 > [2,]000000000 0 0 > [3,]000000000 0 0 > [4,] 00 0000000 0 0 > [5,]000000000 0 0 > [6,]000000000 0 0 > [7,]000000000 0 0 > [8,]000000000 0 0 > [9,]000000000 0 0 > [10,]000000000 0 0 > [11,]000000000 0 0 > > It looks like there is an issue with larger matrices when calling diag > function and it has nothing to do with WGCNA. > > > > > > > On 8/20/13 9:43 AM, "Peter Langfelder" wrote: > >>Hi Sam, >> >>I assume you mean that correlation for _genes_ (not samples) >>11262:3 is 0? I am the maintainer of the WGCNA package but >>unfortunately I don't have access to a Mac big enough to try >>3x3 correlation matrix, but I would be thankful if you could >>try reproducing the problem with smaller matrices (e.g. 2x2) >>and try to produce a small reproducible example by >>generating the data using say rnorm, say like this: >> >>nGenes = 2 # as small as possible that still produces the error >>nSamples = 100 >>datExpr1 = matrix(rnorm(nSamples * nGenes), nSamples, nGenes) >> >>simMat = bicor(datExpr1, use = 'p') >> >>Best, >> >>Peter >> >>On Mon, Aug 19, 2013 at 11:53 AM, Shelton, Samuel >> wrote: >>> Dear R developer, >>> >>> I am an R user and am currently having a problem with versions of R >>>>3.0.0. We build larger correlation matrices of >3 with pairwise >>>>correlations made. We have been using a line of code >>> >>> simMat=bicor(datExpr1,use="p") >>> >>> To build the similarity matrix with datExpr1 being a matrix with genes >>>as columns (>3) and rows being samples. This code works fine on an >>>iMac running OSX 10.8.5 and using R 2.15.2 and the Rblas library. When I >>>try to run the same code with R version 3.0.0 and 3.0.1 it only >>>partially builds the matrix. It will return correlations for samples >>>1:11262 but from 11262:3 the matrix is full of 0's. >>> >>> We would like to be able to use R 3.0.0 to allow us to build larger >>>correlation matrices on our cluster but we can't use it at the moment >>>due to this problem. My colleague has previously had a similar issue >>>when using snow leopard and this was to do with a compatibility issue >>>between snow leopard and the veclib. Has something changed in version >>>3.0.0 to give an incompatibility with the veclib? >>> >>> Many thanks >>> >>> Sam >>> >>> Samuel Shelton, Ph.D. >>> Postdoctoral Researcher, >>> The Oldham Lab, >>> The institute of Regeneration Medicine, >>> University of California San Francisco, >>> San Francisco, CA 94143 >>> >>> email: shelt...@stemcell.ucsf.edu >>> >>> >>> [[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] Extending suggestion for stopifnot
On Tue, Aug 20, 2013 at 11:41 AM, ivo welch wrote:
> I am using a variant of stopifnot a lot. can I suggest that base R
> extends its functionality? I know how to do this for myself. this is
> a suggestion for beginners and students. I don't think it would break
> anything.
>
> first, I think it would be more useful if it had an optional character
> string, so users could write
>
> stopifnot( is.matrix(m), "m is not a matrix" )
>
> this would mean that stopifnot would have to detect whether the last
> argument is a string. (I think stopifnot should have had only one
> condition, and one should have used all() to test multiple conditions,
> but this is a bridge that was already crossed.) upon failure,
> stopifnot should print the character string. that's it.
>
>
> A second enhancement would be a "smart string", which knows that
> everything inside {{...}} should be evaluated.
>
> stopifnot( is.matrix(m), "m is not a matrix, but a {{class(m)}}" )
I think using a function (in this case paste) is cleaner:
paste("m is not a matrix, but a", class(m))
It avoids adding a new convention ("evaluate everything between {{
}}") and has additional arguments.
>
>
> my own programming variant looks even nicer,
>
>is.matrix(m) %or% "m is not a matrix but a {{class(m)}}"
In R you can write it as
is.matrix(m) || stop("m is not a matrix but a ", class(m))
Examples:
m = 1
> is.matrix(m) || stop("m is not a matrix but a ", class(m))
Error: m is not a matrix but a numeric
> m = matrix(0,2,2)
> is.matrix(m) || stop("m is not a matrix but a ", class(m))
[1] TRUE
But the construct
if (!is.matrix(m)) stop("m is not a matrix but a ", class(m))
is more readable for people not used to Pearl.
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Problems when moving to Imports from Depends
Hi all, one of my packages uses the rcorr.cens function from the Hmisc package. Until now I have simply put the Hmisc package into Depends:, but prodded on by new CRAN requirements, I tried to moving it into Imports:. However, this fails because rcorr.cens calls the function is.Surv from survival, which does not seem to be on the search path when Hmisc is "imported from" rather then being "depended on". (Hmisc both Depends: on and Imports: from survival, which is a bit confusing and discouraged by Writing R extensions.) Do I need to include an explicit dependency on or import from survival? Or should I leave Hmisc in the "Depends: " field? Apologies if this is a trivial question - I am not versed in R internals and couldn't find the answer in the Writing R extensions manual either. Thanks, Peter __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Problems when moving to Imports from Depends
On Fri, Sep 27, 2013 at 2:50 PM, Kasper Daniel Hansen wrote: > Peter, > > This is a relatively "new" warning from R CMD check (for some definition of > new). The authors of Hmisc have clearly not yet gone through the process of > cleaning it up, as you are doing right now (and there are many other > packages that still need to address this, including several of mine). Given > who the authors are of Hmisc, I would suggest writing to them and ask them > to look into this, and ask for a time estimate. thanks for the suggestion, but I must be missing something: since Hmisc imports survival (as well as Depends: on it), what can Hmisc change to make the survival functionality visible to my package? > > In the meantime, you may have to do something about this, and whatever you > do I would suggest following the Hmisc package and undo it as soon as > possible, as the right thing is to fix Hmisc. Having said that, it is not > clear to me that you can easily solve this yourself, because I don't think > that putting survival into your own imports will make the package available > to Hmisc functions, but it is not impossible there is some way around it. Well, as I said, things work fine if I leave Hmisc in the Depends: field, which, however, is against CRAN policy. The trouble is that I don't have a good way of checking whether something breaks by moving a package from Depends into Imports... Peter __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Two R editiosn in Unix cluster systems
On Tue, Oct 15, 2013 at 1:15 PM, Paul Johnson wrote: > Dear R Devel > > Some of our R users are still insisting we run R-2.15.3 because of > difficulties with a package called OpenMX. It can't cooperate with new R, > oh well. > > Other users need to run R-3.0.1. I'm looking for the most direct route to > install both, and allow users to choose at runtime. [...] Since no experts have replied, here's my non-expert opinion (take it as a disclaimer). R is happy to be installed in multiple versions. I have always had several versions of R installed (under Linux). I always compile from source and simply set the appropriate destination directories appropriately, then symlink the R and Rscript executables. In my case I put each version into a separate directory under /usr/local/lib64, for example /usr/local/lib64/R-3.0.2-patched . I put all executables into /usr/local/bin but change their names, e.g. R is called R-3.0.2-patched etc; then symlink the executable that I want to be my "default" version to /usr/local/bin/R and /usr/local/bin/Rscript. If I want to call another version of R, I invoke it explicitly as say R-2.15.3 (assuming such version exists). You could also create a separate directory for the executables for each version and symlink them under different names to /usr/bin or /usr/local/bin. I never had problems with versions of R clashing. The executable R that a user executes is a shell wrapper that sets up all necessary environment variables and then calls the actual executable (which sits in /usr/local/lib64//bin/exec). Thus, other versions on $PATH do not cause any trouble. HTH, Peter __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Package impute on CRAN OSX Mavericks check machine
Hello, would it be possible to install the Bioconductor package impute on the machine that checks and builds binary packages for OSX 10.9 Mavericks? Thanks, Peter __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] as.Date.character suggestion
The default format="" in as.Date.character is supremely confusing. The
help shows as.Date defined as
## S3 method for class 'character'
as.Date(x, format = "", ...)
yet the function behaves very differently when format is not specified
and when it is specified to its default:
as.Date("2012-01-01")
[1] "2012-01-01"
> as.Date("2012-01-01", format = "")
[1] "2014-08-20" ### Gives today.
The default setting is never used, because if format is not given,
values "%Y-%m-%d" and "%Y/%m/%d" are tried for it (rather than "").
My suggestion is to leave out the default "" for format in as.Date:
as.Date(x, format, ...)
If this causes a conflict in the S3 dispatching, at least indicate in
the help that the default is never used and the function works
differently if format is specified to its default.
Thanks,
Peter
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] as.Date.character suggestion
That would be my preferred solution, but it would break backwards
compatibility for format="", so others may disagree.
Peter
On Wed, Aug 20, 2014 at 1:18 PM, Duncan Murdoch
wrote:
> On 20/08/2014, 4:11 PM, Peter Langfelder wrote:
>> The default format="" in as.Date.character is supremely confusing. The
>> help shows as.Date defined as
>>
>> ## S3 method for class 'character'
>> as.Date(x, format = "", ...)
>>
>> yet the function behaves very differently when format is not specified
>> and when it is specified to its default:
>>
>> as.Date("2012-01-01")
>> [1] "2012-01-01"
>>> as.Date("2012-01-01", format = "")
>> [1] "2014-08-20" ### Gives today.
>>
>>
>> The default setting is never used, because if format is not given,
>> values "%Y-%m-%d" and "%Y/%m/%d" are tried for it (rather than "").
>>
>> My suggestion is to leave out the default "" for format in as.Date:
>>
>> as.Date(x, format, ...)
>>
>> If this causes a conflict in the S3 dispatching, at least indicate in
>> the help that the default is never used and the function works
>> differently if format is specified to its default.
>
> Wouldn't it be simpler to change the test from
>
> if (missing(format))
>
> to
>
> if (format == "")
>
> ?
>
> Duncan Murdoch
>
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] as.Date.character suggestion
On Wed, Aug 20, 2014 at 4:52 PM, Gabriel Becker wrote: > Could do both to preserve bc... > > if(missing(format) || !nchar(format)) > No, the problem is that the function behaves differently when format is missing than when it equals its default. Removing this difference necessarily changes behaviour and hence (at least in principle) breaks backward compatibility. Peter __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] R under deveoplment CMD check note " ... used in a situation where it does not exist"
Hi all,
just installed the current version of R-devel (2015-01-13 r67453) from
CRAN. Package checking via CMD check suddenly prints a lot of notes
that complain of ... used in a situation where it does not exist. A
prototypical example is
fa = function(...)
{
fb(...)
}
where fa and fb are defined and available functions.
I haven't seen this note before on my package, so something changed in
R-devel - did I miss something in the NEWS? I looked for something
relating to ... but didn't find anything relevant.
Thanks,
Peter
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R under deveoplment CMD check note " ... used in a situation where it does not exist"
Apologies... missed Michal's email and the discussion of the same topic.
Thanks,
Peter
On Wed, Jan 14, 2015 at 6:15 PM, Peter Langfelder
wrote:
> Hi all,
>
> just installed the current version of R-devel (2015-01-13 r67453) from
> CRAN. Package checking via CMD check suddenly prints a lot of notes
> that complain of ... used in a situation where it does not exist. A
> prototypical example is
>
> fa = function(...)
> {
> fb(...)
> }
>
> where fa and fb are defined and available functions.
>
> I haven't seen this note before on my package, so something changed in
> R-devel - did I miss something in the NEWS? I looked for something
> relating to ... but didn't find anything relevant.
>
> Thanks,
>
> Peter
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Crash - cause 'memory not mapped'
I'm not an expert, but from what I know you should certainly use the
.Call interface when you define a function as you did. The problem is
that your function must return a value (of type SEXP) which it does
not. If you don't return a value, all bets are off as to what will
happen, and if the internal R code uses a pointer to the result of
your function, you can easily get memory map errors.
HTH,
Peter
On Fri, Nov 9, 2012 at 2:31 PM, niandra wrote:
> i'm using the following c++ code
> using namespace std;
> #include
> #include
> #include
> #include
> #include
> #include
> #include
> #include
> #include
> #include
>
> extern "C" {
> SEXP FiltroGaus(SEXP size1_r, SEXP size2_r, SEXP sigma_r) {
>
> int size1 = INTEGER(size1_r)[0];
> int size2 = INTEGER(size2_r)[0];
> double sigma = REAL(sigma_r)[0];
>
> }
> }
>
> The compilation go without errors but when in R i type
> .C("FiltroGaus",3,3,2)
> the message is: Errore: INTEGER() can only be applied to a 'integer', not a
> 'NULL'
> if i type .C("FiltroGaus",as.integer(3),as.integer(3),as.double(2))
> the message is Errore: INTEGER() can only be applied to a 'integer', not a
> 'closure'
>
> while if i type .Call("FiltroGaus",as.integer(3),as.integer(3),as.double(2))
> the message is
> NULL
>
> *** caught segfault ***
> address 0x20be, cause 'memory not mapped'
>
> Possible actions:
> 1: abort (with core dump, if enabled)
> 2: normal R exit
> 3: exit R without saving workspace
> 4: exit R saving workspace
>
>
> I now, i need to study and i know also for sure the answer is in some book
> (i have lot). I swear i read a lot and i'm still reading, but i really need
> help :)
>
>
>
> --
> View this message in context:
> http://r.789695.n4.nabble.com/Crash-cause-memory-not-mapped-tp4649141.html
> Sent from the R devel mailing list archive at Nabble.com.
>
> __
> 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] Crash - cause 'memory not mapped'
On Fri, Nov 9, 2012 at 3:05 PM, gianluca mastrantonio
wrote:
> the error "memory non mapped" happen also if i use
> void FiltroGaus(SEXP size1_r, SEXP size2_r, SEXP sigma_r)
> instead
> SEXP FiltroGaus(SEXP size1_r, SEXP size2_r, SEXP sigma_r) {
>
If you use a .Call on a function, the function must return a SEXP, it
cannot be have a void return value.
Peter
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] What is preferable - a single large package or a few smaller packages?
Hi all, I maintain the WGCNA package which at present has nearly 200 functions. In the future there will be more. Curious whether it would be preferable or useful to split the package into a couple different ones with different aims. Obviously, when one calls a function in R, package name spaces have to be traversed to find the matching name - does the speed of this depend on how functions are partitioned into packages? Any other considerations? My knowledge of R internals in this regard is pretty non-existent - thanks for any pointers. Best, Peter __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
