hi martin
that is extremely clarifying - and perfectly fixed our problems!
i did read that comment in the release notes but failed to appreciate its
significance - it does make sense to do it this way for both the
performance improvements & safety issues mentioned in ?.Call. especially
in a package such as ANTsR which uses this feature heavily.
with much gratitude -
brian
On Thu, Apr 11, 2013 at 1:29 AM, Martin Morgan <mtmor...@fhcrc.org> wrote:
> For what it's worth, the package loads many DLLs in its NAMESPACE via
> repeated calls to useDynLib. antsImageRead is not in the first DLL loaded,
> and from NEWS.Rd, the problem comes from
>
> o A foreign function call (.C() etc) in a package without a PACKAGE
> argument will only look in the first DLL specified in the NAMESPACE
> file of the package rather than searching all loaded DLLs. A few
> packages needed PACKAGE arguments added.
>
> From ?.Call, 'PACKAGE' is I believe meant to name the DLL
> (libRantsImageRead in this case) rather than the R package.
>
> Some archaeology below.
>
> Martin
>
>
> On 04/10/2013 02:35 PM, brian avants wrote:
>
>> Thank you for the advice - the function formed like this:
>>
>> antsImageRead <- function( filename , dimension , pixeltype = "float" )
>> {
>> rval <- (.Call("antsImageRead", filename, pixeltype, dimension))
>> return(rval)
>> }
>>
>> worked up to R 2.15.x but fails in R 3.0.x
>>
>> if i include the PACKAGE = 'whatever' , in the .Call above, as here:
>>
>> antsImageRead <- function( filename , dimension , pixeltype = "float" )
>> {
>> rval <- (.Call("antsImageRead", filename, pixeltype, dimension,
>> PACKAGE="ANTsR"))
>> return(rval)
>> }
>>
>> then it fails in both 2.15.x and 3.0.x ....
>>
>
> When .Call has a PACKAGE argument, or when R tries to guess the DLL from
> the fact that .Call is from within a NAMESPACE, only one DLL is found (from
> R_FindNativeSymbolFromDLL in main/dotcode.c:1331, which calls
> getCallingDLLe). the function "antsImageRead" is not in the DLL returned by
> getCallingDLLe, so not found.
>
> > getNativeSymbolInfo("**antsImageRead")$package
> DLL name: libRantsImageRead
> Filename:
>
> /home/mtmorgan/R/x86_64-**unknown-linux-gnu-library/3.0-**2.13/ANTsR/libs/
> **libRantsImageRead.so
> Dynamic lookup: TRUE
>
> > getCallingDLLe(getNamespace("**ANTsR"))
> DLL name: libRantsRegistration
> Filename:
>
> /home/mtmorgan/R/x86_64-**unknown-linux-gnu-library/3.0-**2.13/ANTsR/libs/
> **libRantsRegistration.so
> Dynamic lookup: TRUE
>
>
> if i source the file
>>
>> source("ANTsR/R/antsImageRead.**R")
>>
>> after loading the library, then it works fine in 3.0.x without the direct
>> call to PACKAGE=ANTsR.
>>
>
> from the command line, we are not in a NAMESPACE so R uses R_FindSymbol at
> dotcode.c:259; this performs a more general search and finds the
> appropriate symbol.
>
> The change was somewhere around
>
> ------------------------------**------------------------------**
> ------------
> r60607 | ripley | 2012-09-07 10:56:35 -0700 (Fri, 07 Sep 2012) | 1 line
> Changed paths:
> M /trunk/doc/NEWS.Rd
> M /trunk/src/main/dotcode.c
>
> confine .C etc in a package to the registered DLL.
>
>
>
>> anyway - i hope this clarifies things a bit -
>>
>> does anyone know of something that might have changed between 2.x and 3.x
>> that would relate to this issue?
>>
>>
>>
>>
>>
>> brian
>>
>>
>>
>>
>> On Wed, Apr 10, 2013 at 3:53 PM, Duncan Murdoch <murdoch.dun...@gmail.com
>> >**wrote:
>>
>> On 10/04/2013 2:25 PM, brian avants wrote:
>>>
>>> hi simon
>>>>
>>>> thank you for your questions ---- answers here:
>>>>
>>>> I won't answer your question directly but some suggestions:
>>>>
>>>>> a) does adding PACKAGE="ANTsR" to .Call change anything? (It should
>>>>>
>>>> really
>>>>
>>>>> be there if you are using strings as names)
>>>>>
>>>>>
>>>> this does change things .... for instance, this works:
>>>>
>>>> library(ANTsR)
>>>> filename<-getANTsRData('r16')
>>>> .Call("antsImageRead", filename,'double',2) # Succeeds!
>>>> .Call("antsImageRead", filename,'double',2,PACKAGE=****ANTsR) # Fails!
>>>>
>>>> # Error in .Call("antsImageRead", filename, "double", 2, PACKAGE =
>>>> "ANTsR")
>>>> :
>>>> # "antsImageRead" not available for .Call() for package "ANTsR"
>>>>
>>>>
>>> That makes it look as though it is finding that entry point somewhere
>>> other than in the ANTsR.{so|dll} file installed with the package.
>>>
>>>
>>> the problem is when we call this function:
>>>>
>>>> antsImageRead <- function( filename , dimension , pixeltype = "float" )
>>>> {
>>>> rval <- (.Call("antsImageRead", filename, pixeltype, dimension))
>>>> return(rval)
>>>> }
>>>>
>>>>
>>> That's the one where you should be using the PACKAGE declaration.
>>>
>>>
>>>
>>> the we get the error antsImageRead not resolved from current
>>>> namespace ,
>>>> e.g.:
>>>>
>>>> antsImageRead(filename,2)
>>>>>
>>>> Error in .Call("antsImageRead", filename, pixeltype, dimension) :
>>>> "antsImageRead" not resolved from current namespace (ANTsR)
>>>>
>>>>>
>>>>>
>>>>
>>>> b) you may want to consider use the more efficient registration - either
>>>>
>>>>> explicit or in NAMESPACE - so in your case you could use
>>>>> NAMESPACE: useDynLib(ANTsR, antsImageRead, ...)
>>>>> foo.R: .Call(antsImageRead, ...)
>>>>>
>>>>>
>>>> yes - we have all of our shared libraries registered in the NAMESPACE
>>>> file
>>>> e.g.
>>>>
>>>> useDynLib(libRantsImageRead)
>>>>
>>>>
>>> But this doesn't register the entry point. List it explicitly, and it
>>> will create an object called antsImageRead in the package namespace that
>>> has entry point information.
>>>
>>> Duncan Murdoch
>>>
>>>
>>>> etcetera ....
>>>>
>>>>
>>>> [[alternative HTML version deleted]]
>>>>
>>>> ______________________________****________________
>>>> R-devel@r-project.org mailing list
>>>> https://stat.ethz.ch/mailman/****listinfo/r-devel<https://stat.ethz.ch/mailman/**listinfo/r-devel>
>>>> <https://**stat.ethz.ch/mailman/listinfo/**r-devel<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<https://stat.ethz.ch/mailman/listinfo/r-devel>
>>
>>
>
> --
> Computational Biology / Fred Hutchinson Cancer Research Center
> 1100 Fairview Ave. N.
> PO Box 19024 Seattle, WA 98109
>
> Location: Arnold Building M1 B861
> Phone: (206) 667-2793
>
[[alternative HTML version deleted]]
______________________________________________
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
