Re: [Rd] [tryExcept] New try Function

[Andrew Redd]

I have two related packages that are already submitted to CRAN but are
awaiting approval.  They are part of the R Documentation Task Force efforts
to improve documentation.  The exact function you are referring to I have
called `catch_condition()` and included it in my `testextra` package.  You
might also want to check out the `pkgcond` package which facilitates
creating informative conditions (errors, warnings, and messages).  These
conditions are automatically classed to tell you where the error is coming
from, the package and function, including class for reference methods.

https://github.com/RDocTaskForce/testextra
https://github.com/RDocTaskForce/pkgcond

On Fri, Nov 23, 2018 at 7:48 AM Ernest Benedito 
wrote:

> Hi Emil,
>
> First, thanks for the response. As you mentioned, a lot of times tryCatch
> does the work, as you can return a value. However, sometimes it is useful
> to assign several variables when an error occurs. You could do it with <<-,
> but I prefer to reduce it's usage unless completely necessary.
>
> I guess that the attachment was missed in the moderation. Here it is the
> function:
>
> tryExcept <- function (expr,
>except = {})
> {
>   doTryExcept <- function(expr, parentenv) {
> .Internal(.addCondHands("error", list(NULL), parentenv,
> environment(), FALSE))
> expr
>   }
>   parentenv <- parent.frame()
>   doTryExcept(return(expr), parentenv)
>   invisible(except)
> }
>
> As you can see, the tryExcept function uses a simplified version of the
> tryCatch architecture, but it allows you to pass by a second expression
> that is evaluated in case an error occurs during the evaluation of the
> first expression. It could even work as an infix operator:
>
> `%except%` <- tryExcept
>
> # dummy example
> {foo <- "foo"} %except% {foo <- "foo bar"}
> print(foo) # "foo"
>
> { foo <- "foo"
>   stop()
> } %except% {
>   foo <- "foo bar"
> }
> print(foo) # "foo bar"
>
> It's main downside is that you are not able to handle the error occured,
> although there is the possibility to add a 'silent' parameter such as in
> 'try' in order to print the error if desired. All in all, this would be a
> function for simple error handling, but I think it would be practical, and
> you can always move to tryCatch if you need a more complex error handling.
>
> I will be looking forward to hearing your insights.
>
> Best,
> Ernest Benedito
>
> Missatge de Emil Bode  del dia dv., 23 de nov.
> 2018
> a les 13:17:
>
> > Hi Ernest,
> >
> > To start: I don't see an attachment, I think they're not (always) allowed
> > on this mailing-list. If you want to send something, text is your safest
> > bet.
> > But regarding the issue of tryCatch: I think you're not fully using what
> > it already can do. In almost all circumstances I've encountered the
> > following works fine:
> > res <- tryCatch(expr, error = function(cond) {
> >   # a bunch of code
> >   # Some value to be stored in res
> > })
> > The only difference is that now "#abunchofcode" is run from inside a
> > function, which means you're working in a different environment, and if
> you
> > want to assign values to other variables you need to use <<- or assign.
> > For a modified function, I think it would be nice if there's a way to
> > supply an expression instead of a function, so that evaluation (and
> > assignment!) takes place in the same environment as the main code in the
> > tryCatch (in expr). Is that what you made?
> > And with the current tryCatch, you could use something like this:
> > res <- tryCatch(expr, error=function(e) evalq({
> >   # a bunch of code
> >   # Some value for res
> > }, envir=parent.frame(4))) # The 4 is because some internal functions are
> > involved, parent.frame(4) is the same environment as used by expr
> >
> > Although this is cumbersome, and it gets even more cumbersome if you want
> > to access the error-object in #abunchofcode, or use #abunchofcode to
> return
> > to a higher level, so I get it you're looking for a more elegant
> solution.
> >
> > Best regards,
> > Emil Bode
> >
> > On 23/11/2018, 08:49, "R-devel on behalf of Ernest Benedito" <
> > r-devel-boun...@r-project.org on behalf of ebenedi...@gmail.com> wrote:
> >
> > Hi everyone,
> >
> > When dealing with errors, sometimes I want to run a bunch of code
> when
> > an error occurs.
> > For now I usually use a structure such as:
> >
> > res <- tryCatch(expr, error = function(cond) cond) # or try(expr)
> >
> > if (inherits(res, “error”)) # or inherits(res, “try-error”)
> >   # a bunch of code
> >
> > I though it would be useful to have a function that does this
> > naturally, so I came up with the attached function.
> >
> > I would be glad to hear your insights and if you think it would make
> > sense to add this function to R.
> >
> > Best regards,
> > Ernest
> > __
> > R-devel@r-project.org mailing list
> > 

Re: [Rd] formal process for orphaning a package

[Andrew Redd]

The README states clearly that a package is orphaned under any of three
conditions:

   1. The Maintainer requests is.
   2. The maintainer email bounces
   3. The maintainer is unresponsive to requests regarding the package from
   CRAN maintainers

But I think that it is a good idea to include those conditions in the
manuals.

On Wed, Sep 21, 2016 at 9:30 AM Max Kuhn  wrote:

> The CRAN policy page
> (https://cran.r-project.org/web/packages/policies.html) implies that
> there is a formal procedure for orphaning a package but none is
> mentioned in the Extensions manual
> (https://cran.r-project.org/doc/manuals/r-devel/R-exts.html).
>
> This page (https://cran.r-project.org/src/contrib/Orphaned/README)
> implies that one would simply resubmit the package to CRAN with the
> text "ORPHANED" in the `Maintainer` field.
>
> Is this the case?
>
> If this is not documented somewhere, can it be added to the Extensions
> manual?
>
> Thanks,
>
> Max
>
> __
> R-devel@r-project.org mailing list
> 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

Re: [Rd] Announcing the R Documentation Task Force

[Andrew Redd]

To clarify, the developers, Duncan Murdoch, Michael Lawrence, and Martin
Maechler, who are R Core Developers are participating in the project, but
this should not be construed to be an endorsement from the R Core
Developers as a whole, and the work of the R Documentation Task Force is
not guaranteed to be included in R Core.  My apologies to any who may have
misinterpreted the intentions of the announcement.

Sincerely,
Andrew Redd

On Fri, Sep 9, 2016 at 8:46 PM Andrew Redd <andrew.r...@hsc.utah.edu> wrote:

> cross-posting announcement to R-Announce, R-devel and R-package-devel.
>
> The R Consortium recently announced
> (
> https://www.r-consortium.org/news/blogs/2016/08/r-consortium-funds-three-projects-july
> )
> support of the R Documentation Task Force.  The task force aims to
> design and implement the next generation documentation system for R.  We
> aim to take the best from the many attempts to improve documentation and
> unify them into a system that will be more standard, flexible and
> powerful.  We have the support and participation of R Core Developers.
> The full proposal is available on the announcement website given above.
>
> If you have expertise in documentation systems or documentation of
> objects or interest in building a documentation system we invite you to
> participate.  We will be considering documentation in all common forms
> such as function and class documentation, but also areas such as data
> frames, non-standard objects, packages, and how vignettes fit into the
> documentation framework.  If you have opinions or concerns that you
> would like to make sure are addressed please join.
>
> To join send an email to Andrew dot Redd at hsc dot utah dot edu,
> expressing your interests, skills or expertise as it relates to R
> documentation.  Also email if you have ideas or concerns but do not wish
> to play and active role.
>
> Thank you,
> Andrew Redd
> __
> R-devel@r-project.org mailing list
> 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

[Rd] Announcing the R Documentation Task Force

[Andrew Redd]

cross-posting announcement to R-Announce, R-devel and R-package-devel.

The R Consortium recently announced 
(https://www.r-consortium.org/news/blogs/2016/08/r-consortium-funds-three-projects-july)
 
support of the R Documentation Task Force.  The task force aims to 
design and implement the next generation documentation system for R.  We 
aim to take the best from the many attempts to improve documentation and 
unify them into a system that will be more standard, flexible and 
powerful.  We have the support and participation of R Core Developers.  
The full proposal is available on the announcement website given above.

If you have expertise in documentation systems or documentation of 
objects or interest in building a documentation system we invite you to 
participate.  We will be considering documentation in all common forms 
such as function and class documentation, but also areas such as data 
frames, non-standard objects, packages, and how vignettes fit into the 
documentation framework.  If you have opinions or concerns that you 
would like to make sure are addressed please join.

To join send an email to Andrew dot Redd at hsc dot utah dot edu, 
expressing your interests, skills or expertise as it relates to R 
documentation.  Also email if you have ideas or concerns but do not wish 
to play and active role.

Thank you,
Andrew Redd
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

[Rd] Description depends line for windows only

[Andrew Redd]

I am developing a package that is only applicable on windows, is there a
line I can put in the depends field of the DESCRIPTION file to tell that
this should only be build for windows?

Are there any other protocols that I should follow?

Thanks,

-- 
Andrew
May the Open Source be with you.

[[alternative HTML version deleted]]

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

[Rd] Write unix format files on windows and vice versa

[Andrew Redd]

I go back and forth between windows and linux, and find myself running
into problem with line endings.  Is there a way to control the line
ending conversion when writing files, such as write and cat?  More
explicitly I want to be able to write files with LF line endings
rather than CRLF line ending on windows; and CRLF line endings instead
of LF on linux, and I want to be able to control when the conversion
is made and/or choose the line endings that I want.

As far as I can tell the conversion is not optional and buried deep in
compiled code. Is there a possible work around?

Thanks,
Andrew

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] unloading compiled code.

[Andrew Redd]

I thought I would update with what I did.  Not liking overwriting the
.Last function in case another package I decided to see if the
reg.finalizer would work.  This is what my .onLoad function look like.
---
.onLoad-function(libname, pkgname){
e-emptyenv()
library.dynam('gpuBayes',package=pkgname)
reg.finalizer(e,function(...){unloadNamespace(pkgname)},T)
}
.onUnload-function(libpath){
library.dynam.unload('gpuBayes',libpath)
}
---
 This takes attaches a reg.finalizer to the empty environment with
onexit=T.  Since the empty environment will never be collected this
will only run on exit.

-Andrew

On Tue, Nov 16, 2010 at 6:34 PM, Charles C. Berry cbe...@tajo.ucsd.edu wrote:
 On Tue, 16 Nov 2010, Andrew Redd wrote:

 so should I use reg.finalizer or overwrite .Last()?

 .Last

 Error: object '.Last' not found


 You create your own .Last - there is nothing to overwrite.

 Chuck


  If I use

 reg.finalizer, what should be the environment that I specify?  The
 straight forward solution would be to have a hook .onExit that a
 package could specify to make sure  that the code was unloaded before
 the program terminates, that way I don't overwrite .Last if if has
 another purpose.

 -Andrew

 On Tue, Nov 16, 2010 at 11:27 AM, Charles C. Berry cbe...@tajo.ucsd.edu
 wrote:

 On Tue, 16 Nov 2010, Andrew Redd wrote:

 Just found in the documentation for getHook that packages are not
 unloaded on quit.  How should I force a package to unload on quit?

 See

        ?q


 HTH,

 Chuck


 -Andrew

 On Tue, Nov 16, 2010 at 10:25 AM, Andrew Redd amr...@gmail.com wrote:

 Are packages unloaded on quit so that the .Last.lib or .onUnload are
 called for packages?

 -Andrew

 On Fri, Nov 12, 2010 at 3:52 PM, Andrew Redd amr...@gmail.com wrote:

 Perhaps you could help me make some sense of this.  Here is a printout
 of my sessions.
 ---
 toys$R -q

 library(test2)
 gpualloctest()

 testing allocation on gpu
 C Finished
 Collecting Garbage
 done.

 q()

 Save workspace image? [y/n/c]: n

  *** caught segfault ***
 address 0x7f12ec1add50, cause 'memory not mapped'

 Possible actions:
 1: abort (with core dump, if enabled)
 2: normal R exit
 3: exit R without saving workspace
 4: exit R saving workspace
 Selection: 1
 aborting ...
 Segmentation fault
 toys$R -q

 library(test2)
 gpualloctest()

 testing allocation on gpu
 C Finished
 Collecting Garbage
 done.

 library.dynam.unload('test2',system.file(package='test2'))
 q()

 Save workspace image? [y/n/c]: n
 toys$
 ---

 I have a in the test2/R/zzz.R file
 ---
 .onUnload - function(libpath)
    library.dynam.unload(test2, libpath)
 ---

 so the code should be unloaded.  But it appears that it is not from
 errors when I explicitly unload the test2.so it does not through a
 segfault.  Why would this be happening?  and how do I circumvent it.

 thanks,
 Andrew


 On Fri, Nov 12, 2010 at 3:32 PM, Prof Brian Ripley
 rip...@stats.ox.ac.uk wrote:

 On Fri, 12 Nov 2010, Andrew Redd wrote:

 I have a package that I'm developing that I need to unload the
 library.  Long story short I figured out that the leaving the
 compiled
 code loaded lead to a segmentation fault, but unloading the code
 will
 fix it.  I've read the documentation and it appears that there are
 several ways to do this?  What is the popper accepted current
 standard
 for unloading compiled code?

 Depends how you loaded it: you basically reverse the process.

 The options as I understand them are:
 1. dyn.unload
 2. library.dynam.unload
 used with either
 A. .Last.lib
 B. .onUnload

 If it makes a difference my package does use a NAMESPACE so the
 package is loaded through useDynLib.

 So you need an .onUnload action calling library.dynam.unload.

 Slightly longer version: you need the DLL loaded whilst the namepace
 is
 in
 use, so it has to be in .onUnload, and useDynLib calls library.dynam
 so
 you
 need library.dynam.unload to do the housekeeping around dyn.unload
 which
 matches what library.dynam does around dyn.load.

 There are quite a lot of examples to look at, including in R itself.
 MASS is
 one example I've just checked.

 Having said all that, my experience is that unloading the DLL often
 does not
 help if you need to load it again (and that is why e.g. tcltk does
 not
 unload its DLL).

 Thanks,
 Andrew Redd

 __
 R-devel@r-project.org mailing list
 https://stat.ethz.ch/mailman/listinfo/r-devel


 --
 Brian D. Ripley,                  rip...@stats.ox.ac.uk
 Professor of Applied Statistics,  http://www.stats.ox.ac.uk/~ripley/
 University of Oxford,             Tel:  +44 1865 272861 (self)
 1 South Parks Road,                     +44 1865 272866 (PA)
 Oxford OX1 3TG, UK                Fax:  +44 1865 272595




 __
 R-devel@r-project.org mailing list
 https://stat.ethz.ch/mailman/listinfo/r-devel


 Charles C. Berry                            Dept of Family/Preventive
 Medicine
 cbe

Re: [Rd] unloading compiled code.

[Andrew Redd]

Are packages unloaded on quit so that the .Last.lib or .onUnload are
called for packages?

-Andrew

On Fri, Nov 12, 2010 at 3:52 PM, Andrew Redd amr...@gmail.com wrote:
 Perhaps you could help me make some sense of this.  Here is a printout
 of my sessions.
 ---
 toys$R -q
 library(test2)
 gpualloctest()
 testing allocation on gpu
 C Finished
 Collecting Garbage
 done.
 q()
 Save workspace image? [y/n/c]: n

  *** caught segfault ***
 address 0x7f12ec1add50, cause 'memory not mapped'

 Possible actions:
 1: abort (with core dump, if enabled)
 2: normal R exit
 3: exit R without saving workspace
 4: exit R saving workspace
 Selection: 1
 aborting ...
 Segmentation fault
 toys$R -q
 library(test2)
 gpualloctest()
 testing allocation on gpu
 C Finished
 Collecting Garbage
 done.
 library.dynam.unload('test2',system.file(package='test2'))
 q()
 Save workspace image? [y/n/c]: n
 toys$
 ---

 I have a in the test2/R/zzz.R file
 ---
 .onUnload - function(libpath)
    library.dynam.unload(test2, libpath)
 ---

 so the code should be unloaded.  But it appears that it is not from
 errors when I explicitly unload the test2.so it does not through a
 segfault.  Why would this be happening?  and how do I circumvent it.

 thanks,
 Andrew


 On Fri, Nov 12, 2010 at 3:32 PM, Prof Brian Ripley
 rip...@stats.ox.ac.uk wrote:
 On Fri, 12 Nov 2010, Andrew Redd wrote:

 I have a package that I'm developing that I need to unload the
 library.  Long story short I figured out that the leaving the compiled
 code loaded lead to a segmentation fault, but unloading the code will
 fix it.  I've read the documentation and it appears that there are
 several ways to do this?  What is the popper accepted current standard
 for unloading compiled code?

 Depends how you loaded it: you basically reverse the process.

 The options as I understand them are:
 1. dyn.unload
 2. library.dynam.unload
 used with either
 A. .Last.lib
 B. .onUnload

 If it makes a difference my package does use a NAMESPACE so the
 package is loaded through useDynLib.

 So you need an .onUnload action calling library.dynam.unload.

 Slightly longer version: you need the DLL loaded whilst the namepace is in
 use, so it has to be in .onUnload, and useDynLib calls library.dynam so you
 need library.dynam.unload to do the housekeeping around dyn.unload which
 matches what library.dynam does around dyn.load.

 There are quite a lot of examples to look at, including in R itself. MASS is
 one example I've just checked.

 Having said all that, my experience is that unloading the DLL often does not
 help if you need to load it again (and that is why e.g. tcltk does not
 unload its DLL).

 Thanks,
 Andrew Redd

 __
 R-devel@r-project.org mailing list
 https://stat.ethz.ch/mailman/listinfo/r-devel


 --
 Brian D. Ripley,                  rip...@stats.ox.ac.uk
 Professor of Applied Statistics,  http://www.stats.ox.ac.uk/~ripley/
 University of Oxford,             Tel:  +44 1865 272861 (self)
 1 South Parks Road,                     +44 1865 272866 (PA)
 Oxford OX1 3TG, UK                Fax:  +44 1865 272595



__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] unloading compiled code.

[Andrew Redd]

Just found in the documentation for getHook that packages are not
unloaded on quit.  How should I force a package to unload on quit?

-Andrew

On Tue, Nov 16, 2010 at 10:25 AM, Andrew Redd amr...@gmail.com wrote:
 Are packages unloaded on quit so that the .Last.lib or .onUnload are
 called for packages?

 -Andrew

 On Fri, Nov 12, 2010 at 3:52 PM, Andrew Redd amr...@gmail.com wrote:
 Perhaps you could help me make some sense of this.  Here is a printout
 of my sessions.
 ---
 toys$R -q
 library(test2)
 gpualloctest()
 testing allocation on gpu
 C Finished
 Collecting Garbage
 done.
 q()
 Save workspace image? [y/n/c]: n

  *** caught segfault ***
 address 0x7f12ec1add50, cause 'memory not mapped'

 Possible actions:
 1: abort (with core dump, if enabled)
 2: normal R exit
 3: exit R without saving workspace
 4: exit R saving workspace
 Selection: 1
 aborting ...
 Segmentation fault
 toys$R -q
 library(test2)
 gpualloctest()
 testing allocation on gpu
 C Finished
 Collecting Garbage
 done.
 library.dynam.unload('test2',system.file(package='test2'))
 q()
 Save workspace image? [y/n/c]: n
 toys$
 ---

 I have a in the test2/R/zzz.R file
 ---
 .onUnload - function(libpath)
    library.dynam.unload(test2, libpath)
 ---

 so the code should be unloaded.  But it appears that it is not from
 errors when I explicitly unload the test2.so it does not through a
 segfault.  Why would this be happening?  and how do I circumvent it.

 thanks,
 Andrew


 On Fri, Nov 12, 2010 at 3:32 PM, Prof Brian Ripley
 rip...@stats.ox.ac.uk wrote:
 On Fri, 12 Nov 2010, Andrew Redd wrote:

 I have a package that I'm developing that I need to unload the
 library.  Long story short I figured out that the leaving the compiled
 code loaded lead to a segmentation fault, but unloading the code will
 fix it.  I've read the documentation and it appears that there are
 several ways to do this?  What is the popper accepted current standard
 for unloading compiled code?

 Depends how you loaded it: you basically reverse the process.

 The options as I understand them are:
 1. dyn.unload
 2. library.dynam.unload
 used with either
 A. .Last.lib
 B. .onUnload

 If it makes a difference my package does use a NAMESPACE so the
 package is loaded through useDynLib.

 So you need an .onUnload action calling library.dynam.unload.

 Slightly longer version: you need the DLL loaded whilst the namepace is in
 use, so it has to be in .onUnload, and useDynLib calls library.dynam so you
 need library.dynam.unload to do the housekeeping around dyn.unload which
 matches what library.dynam does around dyn.load.

 There are quite a lot of examples to look at, including in R itself. MASS is
 one example I've just checked.

 Having said all that, my experience is that unloading the DLL often does not
 help if you need to load it again (and that is why e.g. tcltk does not
 unload its DLL).

 Thanks,
 Andrew Redd

 __
 R-devel@r-project.org mailing list
 https://stat.ethz.ch/mailman/listinfo/r-devel


 --
 Brian D. Ripley,                  rip...@stats.ox.ac.uk
 Professor of Applied Statistics,  http://www.stats.ox.ac.uk/~ripley/
 University of Oxford,             Tel:  +44 1865 272861 (self)
 1 South Parks Road,                     +44 1865 272866 (PA)
 Oxford OX1 3TG, UK                Fax:  +44 1865 272595




__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] unloading compiled code.

[Andrew Redd]

so should I use reg.finalizer or overwrite .Last()?  If I use
reg.finalizer, what should be the environment that I specify?  The
straight forward solution would be to have a hook .onExit that a
package could specify to make sure  that the code was unloaded before
the program terminates, that way I don't overwrite .Last if if has
another purpose.

-Andrew

On Tue, Nov 16, 2010 at 11:27 AM, Charles C. Berry cbe...@tajo.ucsd.edu wrote:
 On Tue, 16 Nov 2010, Andrew Redd wrote:

 Just found in the documentation for getHook that packages are not
 unloaded on quit.  How should I force a package to unload on quit?

 See

        ?q


 HTH,

 Chuck


 -Andrew

 On Tue, Nov 16, 2010 at 10:25 AM, Andrew Redd amr...@gmail.com wrote:

 Are packages unloaded on quit so that the .Last.lib or .onUnload are
 called for packages?

 -Andrew

 On Fri, Nov 12, 2010 at 3:52 PM, Andrew Redd amr...@gmail.com wrote:

 Perhaps you could help me make some sense of this.  Here is a printout
 of my sessions.
 ---
 toys$R -q

 library(test2)
 gpualloctest()

 testing allocation on gpu
 C Finished
 Collecting Garbage
 done.

 q()

 Save workspace image? [y/n/c]: n

  *** caught segfault ***
 address 0x7f12ec1add50, cause 'memory not mapped'

 Possible actions:
 1: abort (with core dump, if enabled)
 2: normal R exit
 3: exit R without saving workspace
 4: exit R saving workspace
 Selection: 1
 aborting ...
 Segmentation fault
 toys$R -q

 library(test2)
 gpualloctest()

 testing allocation on gpu
 C Finished
 Collecting Garbage
 done.

 library.dynam.unload('test2',system.file(package='test2'))
 q()

 Save workspace image? [y/n/c]: n
 toys$
 ---

 I have a in the test2/R/zzz.R file
 ---
 .onUnload - function(libpath)
    library.dynam.unload(test2, libpath)
 ---

 so the code should be unloaded.  But it appears that it is not from
 errors when I explicitly unload the test2.so it does not through a
 segfault.  Why would this be happening?  and how do I circumvent it.

 thanks,
 Andrew


 On Fri, Nov 12, 2010 at 3:32 PM, Prof Brian Ripley
 rip...@stats.ox.ac.uk wrote:

 On Fri, 12 Nov 2010, Andrew Redd wrote:

 I have a package that I'm developing that I need to unload the
 library.  Long story short I figured out that the leaving the compiled
 code loaded lead to a segmentation fault, but unloading the code will
 fix it.  I've read the documentation and it appears that there are
 several ways to do this?  What is the popper accepted current standard
 for unloading compiled code?

 Depends how you loaded it: you basically reverse the process.

 The options as I understand them are:
 1. dyn.unload
 2. library.dynam.unload
 used with either
 A. .Last.lib
 B. .onUnload

 If it makes a difference my package does use a NAMESPACE so the
 package is loaded through useDynLib.

 So you need an .onUnload action calling library.dynam.unload.

 Slightly longer version: you need the DLL loaded whilst the namepace is
 in
 use, so it has to be in .onUnload, and useDynLib calls library.dynam so
 you
 need library.dynam.unload to do the housekeeping around dyn.unload
 which
 matches what library.dynam does around dyn.load.

 There are quite a lot of examples to look at, including in R itself.
 MASS is
 one example I've just checked.

 Having said all that, my experience is that unloading the DLL often
 does not
 help if you need to load it again (and that is why e.g. tcltk does not
 unload its DLL).

 Thanks,
 Andrew Redd

 __
 R-devel@r-project.org mailing list
 https://stat.ethz.ch/mailman/listinfo/r-devel


 --
 Brian D. Ripley,                  rip...@stats.ox.ac.uk
 Professor of Applied Statistics,  http://www.stats.ox.ac.uk/~ripley/
 University of Oxford,             Tel:  +44 1865 272861 (self)
 1 South Parks Road,                     +44 1865 272866 (PA)
 Oxford OX1 3TG, UK                Fax:  +44 1865 272595




 __
 R-devel@r-project.org mailing list
 https://stat.ethz.ch/mailman/listinfo/r-devel


 Charles C. Berry                            Dept of Family/Preventive
 Medicine
 cbe...@tajo.ucsd.edu                        UC San Diego
 http://famprevmed.ucsd.edu/faculty/cberry/  La Jolla, San Diego 92093-0901



__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

[Rd] unloading compiled code.

[Andrew Redd]

I have a package that I'm developing that I need to unload the
library.  Long story short I figured out that the leaving the compiled
code loaded lead to a segmentation fault, but unloading the code will
fix it.  I've read the documentation and it appears that there are
several ways to do this?  What is the popper accepted current standard
for unloading compiled code?

The options as I understand them are:
1. dyn.unload
2. library.dynam.unload
used with either
A. .Last.lib
B. .onUnload

If it makes a difference my package does use a NAMESPACE so the
package is loaded through useDynLib.

Thanks,
Andrew Redd

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] unloading compiled code.

[Andrew Redd]

Perhaps you could help me make some sense of this.  Here is a printout
of my sessions.
---
toys$R -q
 library(test2)
 gpualloctest()
testing allocation on gpu
C Finished
Collecting Garbage
done.
 q()
Save workspace image? [y/n/c]: n

 *** caught segfault ***
address 0x7f12ec1add50, cause 'memory not mapped'

Possible actions:
1: abort (with core dump, if enabled)
2: normal R exit
3: exit R without saving workspace
4: exit R saving workspace
Selection: 1
aborting ...
Segmentation fault
toys$R -q
 library(test2)
 gpualloctest()
testing allocation on gpu
C Finished
Collecting Garbage
done.
 library.dynam.unload('test2',system.file(package='test2'))
 q()
Save workspace image? [y/n/c]: n
toys$
---

I have a in the test2/R/zzz.R file
---
.onUnload - function(libpath)
library.dynam.unload(test2, libpath)
---

so the code should be unloaded.  But it appears that it is not from
errors when I explicitly unload the test2.so it does not through a
segfault.  Why would this be happening?  and how do I circumvent it.

thanks,
Andrew


On Fri, Nov 12, 2010 at 3:32 PM, Prof Brian Ripley
rip...@stats.ox.ac.uk wrote:
 On Fri, 12 Nov 2010, Andrew Redd wrote:

 I have a package that I'm developing that I need to unload the
 library.  Long story short I figured out that the leaving the compiled
 code loaded lead to a segmentation fault, but unloading the code will
 fix it.  I've read the documentation and it appears that there are
 several ways to do this?  What is the popper accepted current standard
 for unloading compiled code?

 Depends how you loaded it: you basically reverse the process.

 The options as I understand them are:
 1. dyn.unload
 2. library.dynam.unload
 used with either
 A. .Last.lib
 B. .onUnload

 If it makes a difference my package does use a NAMESPACE so the
 package is loaded through useDynLib.

 So you need an .onUnload action calling library.dynam.unload.

 Slightly longer version: you need the DLL loaded whilst the namepace is in
 use, so it has to be in .onUnload, and useDynLib calls library.dynam so you
 need library.dynam.unload to do the housekeeping around dyn.unload which
 matches what library.dynam does around dyn.load.

 There are quite a lot of examples to look at, including in R itself. MASS is
 one example I've just checked.

 Having said all that, my experience is that unloading the DLL often does not
 help if you need to load it again (and that is why e.g. tcltk does not
 unload its DLL).

 Thanks,
 Andrew Redd

 __
 R-devel@r-project.org mailing list
 https://stat.ethz.ch/mailman/listinfo/r-devel


 --
 Brian D. Ripley,                  rip...@stats.ox.ac.uk
 Professor of Applied Statistics,  http://www.stats.ox.ac.uk/~ripley/
 University of Oxford,             Tel:  +44 1865 272861 (self)
 1 South Parks Road,                     +44 1865 272866 (PA)
 Oxford OX1 3TG, UK                Fax:  +44 1865 272595


__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

[Rd] Segmentation Fault when using CUDA

[Andrew Redd]

I'm developing packages with CUDA, and I'm running into a problem with
memory allocation.  Since CUDA involves memory on the GPU device it
requires that the program handle memory allocation and deallocation
separately from R.

The simplest case of allocating a char and then deallocating causes a
segmentation fault when R closes.  Not on garbage collection but only
on exit.  Is there anything in the R internals that explain why this
is happening?

The relevant C++ code is
---
void gpualloctest(){
   char * _a;
   cudaMalloc(_a,sizeof(char));
   cudaFree(_a);
   _a=NULL;
}
--- from gpu.cu
gputest-function(){
   cat(testing allocation on gpu\n)
   Module('test','gputest')$gpualloctest()
   cat(Test successful\n)
   cat(Collecting Garbage\n)
   gc()
   cat(done.\n)
}
--- from gputest.R

As you can see Rcpp is used to interface with the C++ code, but the
Rcpp is not the problem, but happened to be convenient to use to get
the configure scripts right for the CUDA cu files.

The results from running valgrind Rscript testgpu.R are linked to in
testgpu.log but do not show anything interesting.

Can anyone give any insight?

Thanks,
Andrew Redd

Links to files:
http://andrewredd.us/gputest/testgpu.R
http://andrewredd.us/gputest/testgpu.Rout
http://andrewredd.us/gputest/gputest_1.0.tar.gz
http://andrewredd.us/gputest/testgpu.log

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

[Rd] Changing the Prompt for browser()

[Andrew Redd]

Is there a way that I can change the prompt for within a browser() call.  I
often use use code like

 with(obj1,browser())
Browse[1]

Is there a way that I can set it so that I can get something like

 with(obj1,browser(prompt=obj1))
obj1[1]

I know that prompt is not a valid option for browser, but it would be nice
if it were.   There is an option('prompt)  but that does not affect the
prompt for browser.  Can I change this and how?

Thanks,
Andrew

[[alternative HTML version deleted]]

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

[Rd] dger_ in BLAS definition

[Andrew Redd]

I'm developing some software and running into compiling warning:
conditionals.c:104: warning: passing argument 4 of 'dger_' discards
qualifiers from pointer target type
conditionals.c:104: warning: passing argument 6 of 'dger_' discards
qualifiers from pointer target type

the netlib documentation states that the arguments x and y should be
unchanged on exit.  Should should imply the defintion:

F77_NAME(dger)(const int * const m, const int * const n, const double *
const alpha,
   double const * const x, const int *const incx,
   double const * const y, const int *const incy,
   double * const a, const int * const lda);

the current definition is missing the appropriate consts:
F77_NAME(dger)(const int *m, const int *n, const double *alpha,
   double *x, const int *incx,
   double *y, const int *incy,
   double *a, const int *lda);

I don't want my code compiling with warnings that shouldn't be there.  Are
there suggestions of how to work around this?

Thanks

[[alternative HTML version deleted]]

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

[Rd] Diagnosing Crashes on garbage collection

[Andrew Redd]

I'm having problems with an access violation error on some compiled code
that I'm writing and I was hoping that some one had insights as to what
might be causing the access violation and possibly how to remedy it.

Here's the situation.  The compiled code performs an EM algorithm on the
data for given penalty parameters. The penalty parameters are estimated
through optim on the cross validated log likelihood.  The program works most
of the time. When the EM Algorithm fails to converge  the program crashes on
garbage collection.  Although this makes little sense, as there is no
special computations when the algorithm fails to converge.

The compiled code can either free it's used memory or let R's garbage
collection take care of it, it makes no differeence, the program still
crashes.

Any help on trying to either fix or even help on figuring it out, like tools
to use, would be a great help.

Thanks,
Andrew

[[alternative HTML version deleted]]

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

[Rd] na.action does not return na.action element of lm object

[Andrew Redd]

I'm not sure if this is the official behavior but I would expect the
na.action function applied to a lm object to return the na.action.
Here is what I mean.

 x-0:10
 y-x+rnorm(10)
Warning message:
In x + rnorm(10) :
  longer object length is not a multiple of shorter object length
 y[5]-NA
 m-lm(y~x)
 m$na.action
5
5
attr(,class)
[1] omit
 na.action(m)
NULL

I would expect na.action(m) to return m$na.action.  This is simple
enough to fix with
na.action.lm-function(object,...)object$na.action
but I would expect that this would already be included in the base.
Is there a reason that it is not?  I did a search through the archives
but did not turn up anything relevant.

Thanks,
Andrew Redd

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel