[Rd] Calling the original function after tweaking arguments is an incorrect use of the R-API?
Hi,
I am trying to create a small extension for R here for embedding the
current time on the R prompt:https://github.com/musically-ut/extPrompt
Things seem to be working overall, but R CMD check . raised a warning:
File '[truncated]..Rcheck/extPrompt/libs/extPrompt.so’: Found non-API call
> to R: ‘ptr_R_ReadConsole’
Compiled code should not call non-API entry points in R.
The concerned file is this:
https://github.com/musically-ut/extPrompt/blob/master/src/extPrompt.c and
occurs on line 38, I think.
void extPrompt() {
> // Initialize the plugin by replacing the R_ReadConsole function
> old_R_ReadConsole = ptr_R_ReadConsole;
> ptr_R_ReadConsole = extPrompt_ReadConsole;
> // ...
> }
> int extPrompt_ReadConsole(const char *old_prompt, unsigned char *buf, int
> len,
> int addtohistory) {
> // ...
> // Call the old function with the `new_prompt`
> return (*old_R_ReadConsole)(new_prompt, buf, len, addtohistory);
> }
I am trying to make the R_ReadConsole API call. However, since a different
plugin (like mine) could have overridden it already, I do not want to
directly invoke R_ReadConsole but the function which previously was at
ptr_R_ReadConsole.
Is this an incorrect use of the API?
Also, any other feedback on the plugin is also welcome.
Thanks.
~
ut
PS: I had posted this question on StackOverflow a while back:
http://stackoverflow.com/questions/26335571/is-this-an-incorrect-use-of-the-r-api
If I receive a response, I will update the question with the appropriate
answer.
[[alternative HTML version deleted]]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] proper use of reg.finalizer to close connections
Eh, after some flailing, I think I solved it.
I _think_ this pattern should guarantee that the finalizer function is
still present when needed:
.STATE_CONTAINER <- new.env(parent = emptyenv())
.STATE_CONTAINER$some_state_variable <- ## some code
.STATE_CONTAINER$some_other_state_variable <- ## some code
.myFinalizer <- function(name_of_state_variable_to_clean_up)
.onLoad <- function(libname, pkgname) {
reg.finalizer(
e = parent.env(environment()),
f = function(env) sapply(ls(env$.STATE_CONTAINER), .myFinalizer),
onexit = TRUE)
}
This way, the finalizer is registered on the enclosing environment of
the .onLoad function, which should be the package environment itself.
And that means .myFinalizer should still be around when it's called
during q() or unload/gc().
Effectively, the finalizer is tied to the entire package, rather than
the state variable container(s), which might not be the most elegant
solution, but it should work well enough for most purposes.
Cheers and thanks for the advice,
-m
On Mon, Oct 27, 2014 at 12:18 AM, Murat Tasan wrote:
> Ah, good point, I hadn't thought of that detail.
> Would moving reg.finalizer back outside of .onLoad and hooking it to the
> package's environment itself work (more safely)?
> Something like:
> finalizerFunction <- ## cleanup code
> reg.finalizer(parent.env(), finalizerFunction)
>
> -m
>
> On Oct 26, 2014 11:03 PM, "Henrik Bengtsson" wrote:
>>
>> On Sun, Oct 26, 2014 at 8:14 PM, Murat Tasan wrote:
>> > Ah (again)!
>> > Even with my fumbling presentation of the issue, you gave me the hint
>> > that solved it, thanks!
>> >
>> > Yes, the reg.finalizer call needs to be wrapped in an .onLoad hook so
>> > it's not called once during package installation and then never again.
>> > And once I switched to using ls() (instead of names()), everything
>> > works as expected.
>> >
>> > So, the package code effectively looks like so:
>> >
>> > .CONNS <- new.env(parent = emptyenv())
>> > .onLoad <- function(libname, pkgname) {
>> > reg.finalizer(.CONNS, function(x) sapply(ls(x), .disconnect))
>> > }
>> > .disconnect <- function(x) {
>> > ## handle disconnection of .CONNS[[x]] here
>> > }
>>
>> In your example above, I would be concerned about what happens if you
>> detach/unload your package, because then you're finalizer is still
>> registered and will be called whenever '.CONNS' is being garbage
>> collector (or there after). However, the finalizer function calls
>> .disconnect(), which is no longer available.
>>
>> Finalizers should be used with great care, because you're not in
>> control in what order things are occurring and what "resources" are
>> around when the finalizer function is eventually called and when it is
>> called. I've been bitten by this a few times and it can be very hard
>> to reproduce and troubleshoot such bugs. See also the 'Note' of
>> ?reg.finalizer.
>>
>> My $.02
>>
>> /Henrik
>>
>> >
>> > Cheers and thanks!
>> >
>> > -m
>> >
>> >
>> >
>> >
>> > On Sun, Oct 26, 2014 at 8:53 PM, Gábor Csárdi
>> > wrote:
>> >> Well, to be honest I don't understand fully what you are trying to do.
>> >> If you want to run code when the package is detached or when it is
>> >> unloaded, then use a hook:
>> >> http://cran.r-project.org/doc/manuals/r-devel/R-exts.html#Load-hooks
>> >>
>> >> If you want to run code when an object is freed, then use a finalizer.
>> >>
>> >> Note that when you install a package, R runs all the code in the
>> >> package and only stores the results of the code in the installed
>> >> package. So if you create an object outside of a function in your
>> >> package, then only the object will be stored in the package, but not
>> >> the code that creates it. The object will be simply loaded when you
>> >> load the package, but it will not be re-created.
>> >>
>> >> Now, I am not sure what happens if you set the finalizer on such an
>> >> object in the package. I can imagine that the finalizer will not be
>> >> saved into the package, and is only used once, when
>> >> building/installing the package. In this case you'll need to set the
>> >> finalizer in .onLoad().
>> >>
>> >> Gabor
>> >>
>> >> On Sun, Oct 26, 2014 at 10:35 PM, Murat Tasan wrote:
>> >>> Ah, thanks for the ls() vs names() tip!
>> >>> (But sadly, it didn't solve the issue... )
>> >>>
>> >>> So, after some more tinkering, I believe the finalizer is being called
>> >>> _sometimes_.
>> >>> I changed the reg.finalizer(...) call to just this:
>> >>>
>> >>> reg.finalizer(.CONNS, function(x) print("foo"), onexit = TRUE)
>> >>>
>> >>> Now, when I load the package and detach(..., unload = TRUE), nothing
>> >>> prints.
>> >>> And when I quit, nothing prints.
>> >>>
>> >>> If I, however, create an environment on the workspace, like so:
>> e <- new.env(parent = emptyenv())
>> reg.finalizer(e, function(x) print("bar"), onexit = TRUE)
>> >>> When I quit (or rm(e)), "bar" is printed.
>> >>> But no "foo" (corresponding to same sequence of cod
Re: [Rd] proper use of reg.finalizer to close connections
...and don't forget to make sure all the function that .myFinalizer()
calls are also around. /Henrik
On Mon, Oct 27, 2014 at 10:10 AM, Murat Tasan wrote:
> Eh, after some flailing, I think I solved it.
> I _think_ this pattern should guarantee that the finalizer function is
> still present when needed:
>
> .STATE_CONTAINER <- new.env(parent = emptyenv())
> .STATE_CONTAINER$some_state_variable <- ## some code
> .STATE_CONTAINER$some_other_state_variable <- ## some code
>
> .myFinalizer <- function(name_of_state_variable_to_clean_up)
>
> .onLoad <- function(libname, pkgname) {
> reg.finalizer(
> e = parent.env(environment()),
> f = function(env) sapply(ls(env$.STATE_CONTAINER), .myFinalizer),
> onexit = TRUE)
> }
>
> This way, the finalizer is registered on the enclosing environment of
> the .onLoad function, which should be the package environment itself.
> And that means .myFinalizer should still be around when it's called
> during q() or unload/gc().
> Effectively, the finalizer is tied to the entire package, rather than
> the state variable container(s), which might not be the most elegant
> solution, but it should work well enough for most purposes.
>
> Cheers and thanks for the advice,
>
> -m
>
> On Mon, Oct 27, 2014 at 12:18 AM, Murat Tasan wrote:
>> Ah, good point, I hadn't thought of that detail.
>> Would moving reg.finalizer back outside of .onLoad and hooking it to the
>> package's environment itself work (more safely)?
>> Something like:
>> finalizerFunction <- ## cleanup code
>> reg.finalizer(parent.env(), finalizerFunction)
>>
>> -m
>>
>> On Oct 26, 2014 11:03 PM, "Henrik Bengtsson" wrote:
>>>
>>> On Sun, Oct 26, 2014 at 8:14 PM, Murat Tasan wrote:
>>> > Ah (again)!
>>> > Even with my fumbling presentation of the issue, you gave me the hint
>>> > that solved it, thanks!
>>> >
>>> > Yes, the reg.finalizer call needs to be wrapped in an .onLoad hook so
>>> > it's not called once during package installation and then never again.
>>> > And once I switched to using ls() (instead of names()), everything
>>> > works as expected.
>>> >
>>> > So, the package code effectively looks like so:
>>> >
>>> > .CONNS <- new.env(parent = emptyenv())
>>> > .onLoad <- function(libname, pkgname) {
>>> > reg.finalizer(.CONNS, function(x) sapply(ls(x), .disconnect))
>>> > }
>>> > .disconnect <- function(x) {
>>> > ## handle disconnection of .CONNS[[x]] here
>>> > }
>>>
>>> In your example above, I would be concerned about what happens if you
>>> detach/unload your package, because then you're finalizer is still
>>> registered and will be called whenever '.CONNS' is being garbage
>>> collector (or there after). However, the finalizer function calls
>>> .disconnect(), which is no longer available.
>>>
>>> Finalizers should be used with great care, because you're not in
>>> control in what order things are occurring and what "resources" are
>>> around when the finalizer function is eventually called and when it is
>>> called. I've been bitten by this a few times and it can be very hard
>>> to reproduce and troubleshoot such bugs. See also the 'Note' of
>>> ?reg.finalizer.
>>>
>>> My $.02
>>>
>>> /Henrik
>>>
>>> >
>>> > Cheers and thanks!
>>> >
>>> > -m
>>> >
>>> >
>>> >
>>> >
>>> > On Sun, Oct 26, 2014 at 8:53 PM, Gábor Csárdi
>>> > wrote:
>>> >> Well, to be honest I don't understand fully what you are trying to do.
>>> >> If you want to run code when the package is detached or when it is
>>> >> unloaded, then use a hook:
>>> >> http://cran.r-project.org/doc/manuals/r-devel/R-exts.html#Load-hooks
>>> >>
>>> >> If you want to run code when an object is freed, then use a finalizer.
>>> >>
>>> >> Note that when you install a package, R runs all the code in the
>>> >> package and only stores the results of the code in the installed
>>> >> package. So if you create an object outside of a function in your
>>> >> package, then only the object will be stored in the package, but not
>>> >> the code that creates it. The object will be simply loaded when you
>>> >> load the package, but it will not be re-created.
>>> >>
>>> >> Now, I am not sure what happens if you set the finalizer on such an
>>> >> object in the package. I can imagine that the finalizer will not be
>>> >> saved into the package, and is only used once, when
>>> >> building/installing the package. In this case you'll need to set the
>>> >> finalizer in .onLoad().
>>> >>
>>> >> Gabor
>>> >>
>>> >> On Sun, Oct 26, 2014 at 10:35 PM, Murat Tasan wrote:
>>> >>> Ah, thanks for the ls() vs names() tip!
>>> >>> (But sadly, it didn't solve the issue... )
>>> >>>
>>> >>> So, after some more tinkering, I believe the finalizer is being called
>>> >>> _sometimes_.
>>> >>> I changed the reg.finalizer(...) call to just this:
>>> >>>
>>> >>> reg.finalizer(.CONNS, function(x) print("foo"), onexit = TRUE)
>>> >>>
>>> >>> Now, when I load the package and detach(..., unload = TRUE), nothing
>>> >>> prints.
>>> >>> And when I quit, nothing
[Rd] OSX Yosemite (10.10): Are package binaries the same as for OSX Mavericks (10.9)?
I'm trying to help someone to troubleshoot possible OSX Yosemite issues, but I've only got access to OSX (< 10.9) so I cannot check myself. When building/installing binary R packages, there are different binaries depending on OSX version. For instance, CRAN provides different binaries for 'OS X Snow Leopard' and 'OS X Mavericks', e.g. http://cran.r-project.org/web/packages/matrixStats/index.html. What about the new OSX Yosemite? From http://cran.r-project.org/doc/manuals/r-devel/R-admin.html#Yosemite it looks like its binaries are the same/compatible with those of 'OS X Mavericks' - can someone please confirm this? Another way to put it, if a repository provides OSX Mavericks binaries will an OSX Yosemite user install these or we s/he fall back to installing from source? Thanks Henrik __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] OSX Yosemite (10.10): Are package binaries the same as for OSX Mavericks (10.9)?
- Original Message - > From: "Henrik Bengtsson" > To: "R-devel" > Sent: Monday, October 27, 2014 11:16:10 AM > Subject: [Rd] OSX Yosemite (10.10): Are package binaries the same as for OSX > Mavericks (10.9)? > > I'm trying to help someone to troubleshoot possible OSX Yosemite > issues, but I've only got access to OSX (< 10.9) so I cannot check > myself. > > When building/installing binary R packages, there are different > binaries depending on OSX version. For instance, CRAN provides > different binaries for 'OS X Snow Leopard' and 'OS X Mavericks', e.g. > http://cran.r-project.org/web/packages/matrixStats/index.html. > > What about the new OSX Yosemite? From > http://cran.r-project.org/doc/manuals/r-devel/R-admin.html#Yosemite > it > looks like its binaries are the same/compatible with those of 'OS X > Mavericks' - can someone please confirm this? Another way to put it, > if a repository provides OSX Mavericks binaries will an OSX Yosemite > user install these or we s/he fall back to installing from source? > Yes, a Yosemite user will by default be installing packages built on Mavericks using the Mavericks build of R, and they should work. Dan > Thanks > > Henrik > > __ > 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] OSX Yosemite (10.10): Are package binaries the same as for OSX Mavericks (10.9)?
- Original Message - > From: "Dan Tenenbaum" > To: "Henrik Bengtsson" > Cc: "R-devel" > Sent: Monday, October 27, 2014 11:21:59 AM > Subject: Re: [Rd] OSX Yosemite (10.10): Are package binaries the same as for > OSX Mavericks (10.9)? > > > > - Original Message - > > From: "Henrik Bengtsson" > > To: "R-devel" > > Sent: Monday, October 27, 2014 11:16:10 AM > > Subject: [Rd] OSX Yosemite (10.10): Are package binaries the same > > as for OSX Mavericks (10.9)? > > > > I'm trying to help someone to troubleshoot possible OSX Yosemite > > issues, but I've only got access to OSX (< 10.9) so I cannot check > > myself. > > > > When building/installing binary R packages, there are different > > binaries depending on OSX version. For instance, CRAN provides > > different binaries for 'OS X Snow Leopard' and 'OS X Mavericks', > > e.g. > > http://cran.r-project.org/web/packages/matrixStats/index.html. > > > > What about the new OSX Yosemite? From > > http://cran.r-project.org/doc/manuals/r-devel/R-admin.html#Yosemite > > it > > looks like its binaries are the same/compatible with those of 'OS X > > Mavericks' - can someone please confirm this? Another way to put > > it, > > if a repository provides OSX Mavericks binaries will an OSX > > Yosemite > > user install these or we s/he fall back to installing from source? > > > > Yes, a Yosemite user will by default be installing packages built on > Mavericks using the Mavericks build of R, and they should work. > Provided of course that that Yosemite user is using the Mavericks build of R. They could also be using the Snow Leopard build of R which should also work, and would be installing by default packages build on Snow Leopard using the Snow Leopard build of R. Dan > Dan > > > > Thanks > > > > Henrik > > > > __ > > 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 > __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] OSX Yosemite (10.10): Are package binaries the same as for OSX Mavericks (10.9)?
On Mon, Oct 27, 2014 at 11:23 AM, Dan Tenenbaum wrote: > > > - Original Message - >> From: "Dan Tenenbaum" >> To: "Henrik Bengtsson" >> Cc: "R-devel" >> Sent: Monday, October 27, 2014 11:21:59 AM >> Subject: Re: [Rd] OSX Yosemite (10.10): Are package binaries the same as for >> OSX Mavericks (10.9)? >> >> >> >> - Original Message - >> > From: "Henrik Bengtsson" >> > To: "R-devel" >> > Sent: Monday, October 27, 2014 11:16:10 AM >> > Subject: [Rd] OSX Yosemite (10.10): Are package binaries the same >> > as for OSX Mavericks (10.9)? >> > >> > I'm trying to help someone to troubleshoot possible OSX Yosemite >> > issues, but I've only got access to OSX (< 10.9) so I cannot check >> > myself. >> > >> > When building/installing binary R packages, there are different >> > binaries depending on OSX version. For instance, CRAN provides >> > different binaries for 'OS X Snow Leopard' and 'OS X Mavericks', >> > e.g. >> > http://cran.r-project.org/web/packages/matrixStats/index.html. >> > >> > What about the new OSX Yosemite? From >> > http://cran.r-project.org/doc/manuals/r-devel/R-admin.html#Yosemite >> > it >> > looks like its binaries are the same/compatible with those of 'OS X >> > Mavericks' - can someone please confirm this? Another way to put >> > it, >> > if a repository provides OSX Mavericks binaries will an OSX >> > Yosemite >> > user install these or we s/he fall back to installing from source? >> > >> >> Yes, a Yosemite user will by default be installing packages built on >> Mavericks using the Mavericks build of R, and they should work. >> > > Provided of course that that Yosemite user is using the Mavericks build of R. > They could also be using the Snow Leopard build of R which should also work, > and would be installing by default packages build on Snow Leopard using the > Snow Leopard build of R. Thanks for this Dan. As far as I understand, for an OSX user to install binary packages option 'pkgType' has to be set to either "mac.binary" or "mac.binary.mavericks". A few questions for clarification: Q. Is it the default that 'pkgType' be set to "mac.binary" on OSX (< 10.9) and to "mac.binary.mavericks" on OSX (>= 10.9)? Q. Are you saying that if an OSX (>= 10.9) user uses options(pkgType="mac.binary"), then install.packages() will install the OSX 10.6 (Snow Leopard) binaries *and* that these binaries are backward compatible and should work equally well? Q. In other words, if a user have problems with a particular OSX 10.9 (Mavericks) binary, would a first step of troubleshooting be to ask that user to try the OSX 10.6 (Snow Leopard) build? Q. If a user has options(pkgType="mac.binary.mavericks"), but the repository does not provide such binaries, will install.packages() fall back to "mac.binary", or will it go directly to "source"? /Henrik PS. From a non-active OSX user, using names instead of numbers to refer to versions is cute but insane. You need a very good memory to keep track of the ordering of Snow Leopard, Leopard, Mavericks etc. and it's not getting easier. It would be great if R/BioC and everyone else would always present the version number when talking about OSX version and only use the name for redundancy. > > Dan > > >> Dan >> >> >> > Thanks >> > >> > Henrik >> > >> > __ >> > 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 >> __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] OSX Yosemite (10.10): Are package binaries the same as for OSX Mavericks (10.9)?
- Original Message - > From: "Henrik Bengtsson" > To: "Dan Tenenbaum" > Cc: "R-devel" > Sent: Monday, October 27, 2014 12:21:49 PM > Subject: Re: [Rd] OSX Yosemite (10.10): Are package binaries the same as for > OSX Mavericks (10.9)? > > On Mon, Oct 27, 2014 at 11:23 AM, Dan Tenenbaum > wrote: > > > > > > - Original Message - > >> From: "Dan Tenenbaum" > >> To: "Henrik Bengtsson" > >> Cc: "R-devel" > >> Sent: Monday, October 27, 2014 11:21:59 AM > >> Subject: Re: [Rd] OSX Yosemite (10.10): Are package binaries the > >> same as for OSX Mavericks (10.9)? > >> > >> > >> > >> - Original Message - > >> > From: "Henrik Bengtsson" > >> > To: "R-devel" > >> > Sent: Monday, October 27, 2014 11:16:10 AM > >> > Subject: [Rd] OSX Yosemite (10.10): Are package binaries the > >> > same > >> > as for OSX Mavericks (10.9)? > >> > > >> > I'm trying to help someone to troubleshoot possible OSX Yosemite > >> > issues, but I've only got access to OSX (< 10.9) so I cannot > >> > check > >> > myself. > >> > > >> > When building/installing binary R packages, there are different > >> > binaries depending on OSX version. For instance, CRAN provides > >> > different binaries for 'OS X Snow Leopard' and 'OS X Mavericks', > >> > e.g. > >> > http://cran.r-project.org/web/packages/matrixStats/index.html. > >> > > >> > What about the new OSX Yosemite? From > >> > http://cran.r-project.org/doc/manuals/r-devel/R-admin.html#Yosemite > >> > it > >> > looks like its binaries are the same/compatible with those of > >> > 'OS X > >> > Mavericks' - can someone please confirm this? Another way to > >> > put > >> > it, > >> > if a repository provides OSX Mavericks binaries will an OSX > >> > Yosemite > >> > user install these or we s/he fall back to installing from > >> > source? > >> > > >> > >> Yes, a Yosemite user will by default be installing packages built > >> on > >> Mavericks using the Mavericks build of R, and they should work. > >> > > > > Provided of course that that Yosemite user is using the Mavericks > > build of R. They could also be using the Snow Leopard build of R > > which should also work, and would be installing by default > > packages build on Snow Leopard using the Snow Leopard build of R. > > Thanks for this Dan. > > As far as I understand, for an OSX user to install binary packages > option 'pkgType' has to be set to either "mac.binary" or > "mac.binary.mavericks". A few questions for clarification: > > Q. Is it the default that 'pkgType' be set to "mac.binary" on OSX (< > 10.9) and to "mac.binary.mavericks" on OSX (>= 10.9)? > > Q. Are you saying that if an OSX (>= 10.9) user uses > options(pkgType="mac.binary"), then install.packages() will install > the OSX 10.6 (Snow Leopard) binaries *and* that these binaries are > backward compatible and should work equally well? > > Q. In other words, if a user have problems with a particular OSX 10.9 > (Mavericks) binary, would a first step of troubleshooting be to ask > that user to try the OSX 10.6 (Snow Leopard) build? > > Q. If a user has options(pkgType="mac.binary.mavericks"), but the > repository does not provide such binaries, will install.packages() > fall back to "mac.binary", or will it go directly to "source"? > First of all, this should be on R-SIG-Mac. It all depends on what build of R you are using. You can be on Snow Leopard or later (including Mavericks and Yosemite) and use the Snow Leopard build. The default package type will be mac.binary. You can be on Mavericks or later and using the Mavericks build of R and your package type will by default be mac.binary.mavericks. The two types of binary packages are NOT binary compatible! You should not mix and match them. (Technically, if a given package does not have native code in it, it should work, but you don't really want to go there.) If you're using the Mavericks build of R and the repository does not provide mac.binary.mavericks packages, don't (see above) install mac.binary packages, install from source. Dan > /Henrik > > PS. From a non-active OSX user, using names instead of numbers > to refer to versions is cute but insane. You need a very good memory > to keep track of the ordering of Snow Leopard, Leopard, Mavericks > etc. > and it's not getting easier. It would be great if R/BioC and > everyone else would always present the version number when talking > about OSX version and only use the name for redundancy. > > > > > Dan > > > > > >> Dan > >> > >> > >> > Thanks > >> > > >> > Henrik > >> > > >> > __ > >> > 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 > >> > __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] proper use of reg.finalizer to close connections
yup... for context, the finalizer code calls functions from packages
that are imported by my package.
so, i think (unless something else has gone seriously wrong), those
imported namespaces should still be available prior to my package's
unloading.
(and if imported namespaces are detached prior to the dependent
package's unloading, well, then, perhaps i'll just re-write all of
this in .)
thanks again!
-m
On Mon, Oct 27, 2014 at 11:27 AM, Henrik Bengtsson
wrote:
> ...and don't forget to make sure all the function that .myFinalizer()
> calls are also around. /Henrik
>
> On Mon, Oct 27, 2014 at 10:10 AM, Murat Tasan wrote:
>> Eh, after some flailing, I think I solved it.
>> I _think_ this pattern should guarantee that the finalizer function is
>> still present when needed:
>>
>> .STATE_CONTAINER <- new.env(parent = emptyenv())
>> .STATE_CONTAINER$some_state_variable <- ## some code
>> .STATE_CONTAINER$some_other_state_variable <- ## some code
>>
>> .myFinalizer <- function(name_of_state_variable_to_clean_up)
>>
>> .onLoad <- function(libname, pkgname) {
>> reg.finalizer(
>> e = parent.env(environment()),
>> f = function(env) sapply(ls(env$.STATE_CONTAINER), .myFinalizer),
>> onexit = TRUE)
>> }
>>
>> This way, the finalizer is registered on the enclosing environment of
>> the .onLoad function, which should be the package environment itself.
>> And that means .myFinalizer should still be around when it's called
>> during q() or unload/gc().
>> Effectively, the finalizer is tied to the entire package, rather than
>> the state variable container(s), which might not be the most elegant
>> solution, but it should work well enough for most purposes.
>>
>> Cheers and thanks for the advice,
>>
>> -m
>>
>> On Mon, Oct 27, 2014 at 12:18 AM, Murat Tasan wrote:
>>> Ah, good point, I hadn't thought of that detail.
>>> Would moving reg.finalizer back outside of .onLoad and hooking it to the
>>> package's environment itself work (more safely)?
>>> Something like:
>>> finalizerFunction <- ## cleanup code
>>> reg.finalizer(parent.env(), finalizerFunction)
>>>
>>> -m
>>>
>>> On Oct 26, 2014 11:03 PM, "Henrik Bengtsson" wrote:
On Sun, Oct 26, 2014 at 8:14 PM, Murat Tasan wrote:
> Ah (again)!
> Even with my fumbling presentation of the issue, you gave me the hint
> that solved it, thanks!
>
> Yes, the reg.finalizer call needs to be wrapped in an .onLoad hook so
> it's not called once during package installation and then never again.
> And once I switched to using ls() (instead of names()), everything
> works as expected.
>
> So, the package code effectively looks like so:
>
> .CONNS <- new.env(parent = emptyenv())
> .onLoad <- function(libname, pkgname) {
> reg.finalizer(.CONNS, function(x) sapply(ls(x), .disconnect))
> }
> .disconnect <- function(x) {
> ## handle disconnection of .CONNS[[x]] here
> }
In your example above, I would be concerned about what happens if you
detach/unload your package, because then you're finalizer is still
registered and will be called whenever '.CONNS' is being garbage
collector (or there after). However, the finalizer function calls
.disconnect(), which is no longer available.
Finalizers should be used with great care, because you're not in
control in what order things are occurring and what "resources" are
around when the finalizer function is eventually called and when it is
called. I've been bitten by this a few times and it can be very hard
to reproduce and troubleshoot such bugs. See also the 'Note' of
?reg.finalizer.
My $.02
/Henrik
>
> Cheers and thanks!
>
> -m
>
>
>
>
> On Sun, Oct 26, 2014 at 8:53 PM, Gábor Csárdi
> wrote:
>> Well, to be honest I don't understand fully what you are trying to do.
>> If you want to run code when the package is detached or when it is
>> unloaded, then use a hook:
>> http://cran.r-project.org/doc/manuals/r-devel/R-exts.html#Load-hooks
>>
>> If you want to run code when an object is freed, then use a finalizer.
>>
>> Note that when you install a package, R runs all the code in the
>> package and only stores the results of the code in the installed
>> package. So if you create an object outside of a function in your
>> package, then only the object will be stored in the package, but not
>> the code that creates it. The object will be simply loaded when you
>> load the package, but it will not be re-created.
>>
>> Now, I am not sure what happens if you set the finalizer on such an
>> object in the package. I can imagine that the finalizer will not be
>> saved into the package, and is only used once, when
>> building/installing the package. In this case you'll need to set the
>> finaliz
