question re: error message --- package error: "functionName" not resolved from current namespace

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

question re: error message --- package error: "functionName" not resolved from current namespace

brian avants
hello everyone

we are developing a package that has worked up until R3.0 which we just
tested.

the issue is as above .... when we call a function that works in R 2.15.2
from  R 3.0 we get an error

Error in .Call("antsImageRead", filename, pixeltype, dimension) :
  "antsImageRead" not resolved from current namespace (ANTsR)

this Error occurs when the .Call is made from within the .R function
wrapper that eases access to the C++ version of antsImageRead.

however, a direct  .Call("antsImageRead", etc. ) works as usual.

this happens for some of our functions and not others - not all are .Calls
...

i don't see a pattern to it.

a hack resolution that "works" is to source the .R files again within the R
shell.

of course, this is not a satisfying solution.

finally, if anyone cares to try to reproduce this error, here is what you
would do:


If you have CMake installed, then open R 3.0 and do:


install.packages(c("devtools", "Rcpp", "methods", "signal", "parallel",
    "timeSeries", "mFilter", "MASS", "robust", "magic", "knitr",
"pixmap", "rgl", "misc3d"))

then Clone or Pull ANTsR from this repository as follows:

$ git clone [hidden email]:stnava/ANTsR.git

>From the parent directory of the new ANTsR directory, install the package
as follows:

$ R CMD INSTALL ANTsR


finally - the error can be reproduced in R 3.0 as :

library(ANTsR)
fi<-antsImageRead( getANTsRData('r16') ,2)

any help would be appreciated -

brian

        [[alternative HTML version deleted]]

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: question re: error message --- package error: "functionName" not resolved from current namespace

Simon Urbanek

On Apr 10, 2013, at 1:53 PM, brian avants wrote:

> hello everyone
>
> we are developing a package that has worked up until R3.0 which we just
> tested.
>
> the issue is as above .... when we call a function that works in R 2.15.2
> from  R 3.0 we get an error
>
> Error in .Call("antsImageRead", filename, pixeltype, dimension) :
>  "antsImageRead" not resolved from current namespace (ANTsR)
>

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)
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, ...)

Cheers,
Simon


> this Error occurs when the .Call is made from within the .R function
> wrapper that eases access to the C++ version of antsImageRead.
>
> however, a direct  .Call("antsImageRead", etc. ) works as usual.
>
> this happens for some of our functions and not others - not all are .Calls
> ...
>
> i don't see a pattern to it.
>
> a hack resolution that "works" is to source the .R files again within the R
> shell.
>
> of course, this is not a satisfying solution.
>
> finally, if anyone cares to try to reproduce this error, here is what you
> would do:
>
>
> If you have CMake installed, then open R 3.0 and do:
>
>
> install.packages(c("devtools", "Rcpp", "methods", "signal", "parallel",
>    "timeSeries", "mFilter", "MASS", "robust", "magic", "knitr",
> "pixmap", "rgl", "misc3d"))
>
> then Clone or Pull ANTsR from this repository as follows:
>
> $ git clone [hidden email]:stnava/ANTsR.git
>
>> From the parent directory of the new ANTsR directory, install the package
> as follows:
>
> $ R CMD INSTALL ANTsR
>
>
> finally - the error can be reproduced in R 3.0 as :
>
> library(ANTsR)
> fi<-antsImageRead( getANTsRData('r16') ,2)
>
> any help would be appreciated -
>
> brian
>
> [[alternative HTML version deleted]]
>
> ______________________________________________
> [hidden email] mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>
>

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: question re: error message --- package error: "functionName" not resolved from current namespace

brian avants
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"

the problem is when we call this function:

antsImageRead <- function( filename , dimension , pixeltype = "float" )
{
    rval <- (.Call("antsImageRead", filename, pixeltype, dimension))
    return(rval)
}

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)

etcetera ....

        [[alternative HTML version deleted]]

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: question re: error message --- package error: "functionName" not resolved from current namespace

Duncan Murdoch-2
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]]
>
> ______________________________________________
> [hidden email] mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: question re: error message --- package error: "functionName" not resolved from current namespace

brian avants
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 ....

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.

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 <[hidden email]>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]]
>>
>> ______________________________**________________
>> [hidden email] mailing list
>> https://stat.ethz.ch/mailman/**listinfo/r-devel<https://stat.ethz.ch/mailman/listinfo/r-devel>
>>
>
>

        [[alternative HTML version deleted]]

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: question re: error message --- package error: "functionName" not resolved from current namespace

Duncan Murdoch-2
On 13-04-10 5: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 ....
>
> 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.
>
> 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?

If you can build a Windows binary or a MacOSX binary of the package, or
a tarball that the standard tools can install, I'll take a look.

Duncan Murdoch

>
>
>
>
>
> brian
>
>
>
>
> On Wed, Apr 10, 2013 at 3:53 PM, Duncan Murdoch
> <[hidden email] <mailto:[hidden email]>> 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]]
>
>         ________________________________________________
>         [hidden email] <mailto:[hidden email]> mailing list
>         https://stat.ethz.ch/mailman/__listinfo/r-devel
>         <https://stat.ethz.ch/mailman/listinfo/r-devel>
>
>
>

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: question re: error message --- package error: "functionName" not resolved from current namespace

Martin Morgan
In reply to this post by brian avants
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 <[hidden email]>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]]
>>>
>>> ______________________________**________________
>>> [hidden email] mailing list
>>> https://stat.ethz.ch/mailman/**listinfo/r-devel<https://stat.ethz.ch/mailman/listinfo/r-devel>
>>>
>>
>>
>
> [[alternative HTML version deleted]]
>
> ______________________________________________
> [hidden email] mailing list
> 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

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: question re: error message --- package error: "functionName" not resolved from current namespace

brian avants
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 <[hidden email]> 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 <[hidden email]
>> >**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]]
>>>>
>>>> ______________________________****________________
>>>> [hidden email] 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]]
>>
>> ______________________________**________________
>> [hidden email] 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]]

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel