Re: [Rd] Pointer ownership with GECreateDevDesc/GEDestroyDevDesc

2014-09-22 Thread Ritch Melton
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

2014-09-22 Thread Paul Gilbert
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

2014-09-22 Thread Wang, Zhu
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

2014-09-22 Thread Berend Hasselman

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