Re: [Rd] Pointer ownership with GECreateDevDesc/GEDestroyDevDesc
I perused the source for RStudio and noticed that they had a similar problem. I didn't think that the GEDevDesc structure was exported, but apparently this is a worthwhile workaround to the defect. void GD_Close(pDevDesc dev) { ...elided... // explicitly free and then null out the dev pointer of the GEDevDesc // This is to avoid incompatabilities between the heap we are compiled with // and the heap R is compiled with (we observed this to a problem with // 64-bit R) std::free(s_pGEDevDesc->dev); s_pGEDevDesc->dev = NULL; // set GDDevDesc to NULL so we don't reference it again s_pGEDevDesc = NULL; } } I will On Fri, Sep 19, 2014 at 10:37 AM, Ritch Melton wrote: > According to the "R Internals" document, for a custom device, I should > create a pDevDesc structure that gets passed to GECreateDevDesc. > > ..elided... > pDevDesc dev; > /* Allocate and initialize the device driver data */ > if (!(dev = (pDevDesc) calloc(1, sizeof(DevDesc return 0; > /* or error() */ > /* set up device driver or free ’dev’ and error() */ > gdd = GEcreateDevDesc(dev); GEaddDevice2(gdd, "dev_name"); > ...elided... > > which indicates to me that the calling code owns the pDevDesc structure > and should be responsible for freeing it. > However, in GEdestroyDevDesc, that particular code calls free(dd->dev), > freeing the pointer. > > In my case, I have a device implemented and created in a language that is > using a different allocator. The pDevDesc I pass in is not owned by R and > causes a crash on free with "dev.off()". > > I thought I could mitigate the issue, by making a call to the allocator R > is using via an exported R function, such as R_alloc, but I did not see > such a function available to me. > > I would like to know if I should be creating the pDevDesc via an imported > alloc routine somehow? or is there a way to prevent this code from freeing > the structure I pass in. > > Blue Skies, > Ritch > [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] extra package tests directory
I am trying to decide on a name for a directory where I will put some extra package tests. The main motivation for this is the need to limit the package test time on CRAN. That is, these are tests that could be in the tests/ directory and could be run on CRAN, but will take longer than CRAN likes. Scanning through names currently being used in packages on CRAN I see a large number of inst/tests/ directories, but they seem to be instead of a tests/ directory at the top level of the package. (There are also some occurrences of inst/test and test/ at the top level.) I would prefer not to use these directories as I don't like the possible confusion over whether these are the standard package tests or additional ones. The other name that is used a fair amount is inst/unitTests/ (plus inst/UnitTests/, plus inst/UnitTest/, plus inst/unittests). In many case these seem to be run by a script in the tests/ directory using a unit testing framework, so they cannot easily be distinguished from the normal package tests/ run by CRAN. I see also an occurrence each of inst/otherTests/ inst/testScripts/ and inst/test_cases. My own preference would be inst/extraTests but no one is using that. Have I missed anything? Does anyone have suggestions or comments? Are there other reasons one might want tests that are not usually run by CRAN? Paul __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Replace isnan and lgamma in Fortran subroutine in R package
Hello, I submitted a package which used Fortran functions isnan and lgamma. However, I was told that: isnan and lgamma are not Fortran 95 functions. I was asked to write 'cross-platform portable code' and so should not be writing GNU extensions to Fortran. See http://cran.r-project.org/web/checks/check_results_mpath.html, which will shortly show installation failures under Solaris. I will appreciate advice on how to replace these two functions to avoid failure on some platforms. Thanks in advance, Zhu Wang [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Replace isnan and lgamma in Fortran subroutine in R package
On 23-09-2014, at 00:33, Wang, Zhu wrote: > Hello, > > I submitted a package which used Fortran functions isnan and lgamma. However, > I was told that: > > isnan and lgamma are not Fortran 95 functions. > > I was asked to write 'cross-platform portable code' and so should not be > writing GNU extensions to Fortran. > > See http://cran.r-project.org/web/checks/check_results_mpath.html, which will > shortly show installation failures under Solaris. > > I will appreciate advice on how to replace these two functions to avoid > failure on some platforms. > I don’t know about lgamma. Instead of isnan you could use Lapack’s logical function disnan to test for NaN (it’s in lapack 3.4.2; I don’t know about earlier versions). Another way would be to write a C function using functions provided by R to test for NaN. That function should be declared with F77_NAME so that it can be called from a Fortran routine. I haven’t tried this so I don’t know if this would be foolproof or is the best way to do it.. Berend __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel