[R-pkg-devel] windows and configure scripts

[Tim Keitt]

As configure is not run on windows, but according to the writing extensions
docs you can run commands in Makevars, is that not preferable for simple
cases?

What shell is active in Makevars? Is it "/bin/sh" or is make the
interpreter here?

Can we use $(shell ...cmd...) in Makevars on windows? I'm not sure where to
look for what syntax is in-play in the Makevars file during package
building other than trial-and-error.

THK

[[alternative HTML version deleted]]

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

Re: [R-pkg-devel] Ongoing CXX17 woes

[Tim Keitt]

Fixed. Thanks.

THK

On Fri, Aug 6, 2021 at 4:33 PM Tim Keitt  wrote:

>
>
> On Fri, Aug 6, 2021 at 4:22 PM Tim Keitt  wrote:
>
>>
>>
>> On Fri, Aug 6, 2021 at 4:05 PM Ivan Krylov  wrote:
>>
>>> On Fri, 6 Aug 2021 15:51:37 -0500
>>> Tim Keitt  wrote:
>>>
>>> > CXX17=`${R_HOME}/bin/R CMD config --all | awk '{print $1}' | grep \
>>> > "^CXX17$"`
>>>
>>> This seems to output "CXX17" on a machine with no C++17 support. On the
>>> other hand, running `${R_HOME}/bin/R CMD config CXX17` here gives me an
>>> empty string.
>>>
>>
> Actually, you are right -- from the shell it does return a string. I'll
> try the alternative version.
>
> THK
>
>
>>
>> Not on my machine. But perhaps this is the issue with Solaris? You can
>> check the comments at
>> https://github.com/eddelbuettel/rcppsimdjson/blob/master/configure that
>> suggest the grep method is more robust. But perhaps that's no longer the
>> case or on all platforms.
>>
>> THK
>>
>>
>>>
>>> --
>>> Best regards,
>>> Ivan
>>>
>>

[[alternative HTML version deleted]]

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

Re: [R-pkg-devel] Ongoing CXX17 woes

[Tim Keitt]

On Fri, Aug 6, 2021 at 4:22 PM Tim Keitt  wrote:

>
>
> On Fri, Aug 6, 2021 at 4:05 PM Ivan Krylov  wrote:
>
>> On Fri, 6 Aug 2021 15:51:37 -0500
>> Tim Keitt  wrote:
>>
>> > CXX17=`${R_HOME}/bin/R CMD config --all | awk '{print $1}' | grep \
>> > "^CXX17$"`
>>
>> This seems to output "CXX17" on a machine with no C++17 support. On the
>> other hand, running `${R_HOME}/bin/R CMD config CXX17` here gives me an
>> empty string.
>>
>
Actually, you are right -- from the shell it does return a string. I'll try
the alternative version.

THK


>
> Not on my machine. But perhaps this is the issue with Solaris? You can
> check the comments at
> https://github.com/eddelbuettel/rcppsimdjson/blob/master/configure that
> suggest the grep method is more robust. But perhaps that's no longer the
> case or on all platforms.
>
> THK
>
>
>>
>> --
>> Best regards,
>> Ivan
>>
>

[[alternative HTML version deleted]]

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

Re: [R-pkg-devel] Ongoing CXX17 woes

[Tim Keitt]

On Fri, Aug 6, 2021 at 4:05 PM Ivan Krylov  wrote:

> On Fri, 6 Aug 2021 15:51:37 -0500
> Tim Keitt  wrote:
>
> > CXX17=`${R_HOME}/bin/R CMD config --all | awk '{print $1}' | grep \
> > "^CXX17$"`
>
> This seems to output "CXX17" on a machine with no C++17 support. On the
> other hand, running `${R_HOME}/bin/R CMD config CXX17` here gives me an
> empty string.
>

Not on my machine. But perhaps this is the issue with Solaris? You can
check the comments at
https://github.com/eddelbuettel/rcppsimdjson/blob/master/configure that
suggest the grep method is more robust. But perhaps that's no longer the
case or on all platforms.

THK


>
> --
> Best regards,
> Ivan
>

[[alternative HTML version deleted]]

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

[R-pkg-devel] Ongoing CXX17 woes

[Tim Keitt]

Hi Folks,

I have a package that compiles fine under C++11 but it throws an "Error:
C++17 standard requested but CXX17 is not defined" error when checking
under Solaris.

My configure looks like:

#!/bin/sh

# Borrowed from
https://github.com/eddelbuettel/rcppsimdjson/blob/master/configure

: ${R_HOME=`R RHOME`}
if test -z "${R_HOME}"; then
echo Could not determine R_HOME.
exit 1
fi

CXX17=`${R_HOME}/bin/R CMD config --all | awk '{print $1}' | grep "^CXX17$"`

if test "x${CXX17}" = "x"; then
   sed -e 's/@CXXSTD@/CXX11/' -e 's/@NOCXX17@/-DNO_CXX17/' src/Makevars.in
> src/Makevars
else
   sed -e 's/@CXXSTD@/CXX17/' -e 's/@NOCXX17@//' src/Makevars.in >
src/Makevars
fi

exit 0

If I change the grep match to something nonsensical (forcing c++11), then
the package builds and checks just fine on my machine.

So it seems that there is some checking code that searches for c++17
statements in the package and throws an error. If that is the case, then
those checks should be removed as they cannot account for conditional
compilation. For example, in my vignettes, I have c++17 code but those
chunks are not evaluated if c++17 is not available.

Is the checking code available for inspection? I'd like to find exactly
where the error is coming from.

THK

[[alternative HTML version deleted]]

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

Re: [R-pkg-devel] C++17

[Tim Keitt]

Kind of figured that out looking around on github. I added a config
(borrowed from one of your repos) to test for CXX17. I'm not sure its quite
working for me yet but I will figure it out. A couple of questions:

1) I had C++17 in the system requirements in the description file but might
remove it as I hope to make it check without CXX17. Does that have any
impact on installation or is it only informative/notification?
2) If we need to adjust a package currently on CRAN owing to platform
errors, should we keep the version the same or submit with a version bump?

Thanks.

THK

On Fri, Jul 30, 2021 at 2:06 PM Dirk Eddelbuettel  wrote:

>
> Section 2.7.3 'C++ Support' of the R Admin manual says, "C++ is not used
> by R
> itself, but support is provided ...".  This is all stored from when R
> itself
> is configure (prior to compiling) and override-able in package
> configuration
> (Section 2.7.3 covers that) but as that in other places _it all depends on
> what the user has installed in terms of C++ compilers_.
>
> So packages need to test. R 4.1.0 ensure that _if_ C++ is present it is at
> least C++11, R 4.2.0 (aka r-devel now) is currently set to roll this to
> C++14.  Which is ... actually rather nice and way better than what had
> only a
> few short years ago. But local system may still need to look after their
> local compilers.  I still get bug reports from folks "blessed" with a
> particularl Linux distro that seems to persist long enough so that people
> aren't even yet at g++ 4.8 or 4.9 (though that environment has workarounds
> too). Similarly even when R 4.2.0 comes our there will still be people
> trying
> to build our packages on R 3.6.* or R 3.5.*. Such is life.
>
> So in short, for my money, _assuming_ C++17 is present is still a wee bit
> far
> out. Test for it, enjoy it when it is present and deal with it if not.
>
> Dirk
>
> --
> https://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
>
> __
> R-package-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel
>

[[alternative HTML version deleted]]

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

[R-pkg-devel] C++17

[Tim Keitt]

Hi Folks,

It appears that c++17 is not supported on all platforms used by CRAN. Is
there a workaround?

I have CXX_STD = CXX17 in the package Makevars file, but see
https://cran.r-project.org/web/checks/check_results_kdtools.html

I assume if CXX17 is not defined, it is not available on that build owing
to the compiler. I'm curious to know if anyone else has solved that problem.

Thanks.

THK

[[alternative HTML version deleted]]

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

Re: [R-pkg-devel] import 'as' from another package

[Tim Keitt]

Thanks for pointing to the bug.

Now I am finding I cannot use the 'as' definitions from 'raster' without
loading the package. Do I need an @import directive that specifies the
definitions in the 'raster' package? My understanding is that the 'setAs'
function generates a 'coerce,...' signature but I'm not sure how to import
it to my package.

Thanks again.

THK

On Mon, Jul 20, 2020 at 2:25 PM Sebastian Meyer  wrote:

> Yes, indeed, it is confusing. You don't need to file a new bug report,
> though. There is one already:
>
> https://bugs.r-project.org/bugzilla/show_bug.cgi?id=17179
>
> Please feel free to comment there. This thread could serve as another
> confirmation. :-)
>
> Best regards,
> Sebastian
>
> Am 20. Juli 2020 18:36:21 MESZ schrieb Ben Bolker :
> >I think this is a classic confusing R message.  Try adding methods
> >to the Imports: statement in your DESCRIPTION file and see if that
> >helps. (Maybe I should file a bug report about that error message - it
> >confuses me every time.)
> >
> >On 7/20/20 12:34 PM, Tim Keitt wrote:
> >> It works but "check" gives
> >>
> >> > checking package dependencies ... ERROR
> >>   Namespace dependency not required: ‘methods’
> >>
> >> THK
> >>
> >> On Mon, Jul 20, 2020 at 11:24 AM Ben Bolker  >> <mailto:bbol...@gmail.com>> wrote:
> >>
> >> @importFrom methods as
> >>
> >> ?
> >>
> >> On 7/20/20 12:06 PM, Tim Keitt wrote:
> >> > I have
> >> >
> >> >if (!inherits(x, "RasterLayer")) x <- as(x, "RasterLayer")
> >> >
> >> > in a package and its not finding the coerce definition from the
> >> raster
> >> > package. I know I need to add an @import roxygen2 directive of
> >> some kind,
> >> > but I'm not sure the correct syntax. My first try generated a
> >> warning that
> >> > it was not needed.
> >> >
> >> > What is the correct way to do this? Or does raster need to
> >> export this
> >> > definition?
> >> >
> >> > THK
> >> >
> >> >   [[alternative HTML version deleted]]
> >> >
> >> > __
> >> > R-package-devel@r-project.org
> >> <mailto:R-package-devel@r-project.org> mailing list
> >> > https://stat.ethz.ch/mailman/listinfo/r-package-devel
> >>
> >> __
> >> R-package-devel@r-project.org
> >> <mailto:R-package-devel@r-project.org> mailing list
> >> https://stat.ethz.ch/mailman/listinfo/r-package-devel
> >>
> >
> >   [[alternative HTML version deleted]]
> >
> >__
> >R-package-devel@r-project.org mailing list
> >https://stat.ethz.ch/mailman/listinfo/r-package-devel
>

[[alternative HTML version deleted]]

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

Re: [R-pkg-devel] import 'as' from another package

[Tim Keitt]

That did it. Thanks Ben.

THK

On Mon, Jul 20, 2020 at 11:36 AM Ben Bolker  wrote:

>I think this is a classic confusing R message.  Try adding methods to
> the Imports: statement in your DESCRIPTION file and see if that helps.
> (Maybe I should file a bug report about that error message - it confuses me
> every time.)
> On 7/20/20 12:34 PM, Tim Keitt wrote:
>
> It works but "check" gives
>
> > checking package dependencies ... ERROR
>   Namespace dependency not required: ‘methods’
>
> THK
>
> On Mon, Jul 20, 2020 at 11:24 AM Ben Bolker  wrote:
>
>>     @importFrom methods as
>>
>> ?
>>
>> On 7/20/20 12:06 PM, Tim Keitt wrote:
>> > I have
>> >
>> >if (!inherits(x, "RasterLayer")) x <- as(x, "RasterLayer")
>> >
>> > in a package and its not finding the coerce definition from the raster
>> > package. I know I need to add an @import roxygen2 directive of some
>> kind,
>> > but I'm not sure the correct syntax. My first try generated a warning
>> that
>> > it was not needed.
>> >
>> > What is the correct way to do this? Or does raster need to export this
>> > definition?
>> >
>> > THK
>> >
>> >   [[alternative HTML version deleted]]
>> >
>> > __
>> > R-package-devel@r-project.org mailing list
>> > https://stat.ethz.ch/mailman/listinfo/r-package-devel
>>
>> __
>> R-package-devel@r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-package-devel
>>
>

[[alternative HTML version deleted]]

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

Re: [R-pkg-devel] import 'as' from another package

[Tim Keitt]

It works but "check" gives

> checking package dependencies ... ERROR
  Namespace dependency not required: ‘methods’

THK

On Mon, Jul 20, 2020 at 11:24 AM Ben Bolker  wrote:

> @importFrom methods as
>
> ?
>
> On 7/20/20 12:06 PM, Tim Keitt wrote:
> > I have
> >
> >if (!inherits(x, "RasterLayer")) x <- as(x, "RasterLayer")
> >
> > in a package and its not finding the coerce definition from the raster
> > package. I know I need to add an @import roxygen2 directive of some kind,
> > but I'm not sure the correct syntax. My first try generated a warning
> that
> > it was not needed.
> >
> > What is the correct way to do this? Or does raster need to export this
> > definition?
> >
> > THK
> >
> >   [[alternative HTML version deleted]]
> >
> > __
> > R-package-devel@r-project.org mailing list
> > https://stat.ethz.ch/mailman/listinfo/r-package-devel
>
> __
> R-package-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel
>

[[alternative HTML version deleted]]

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

[R-pkg-devel] import 'as' from another package

[Tim Keitt]

I have

  if (!inherits(x, "RasterLayer")) x <- as(x, "RasterLayer")

in a package and its not finding the coerce definition from the raster
package. I know I need to add an @import roxygen2 directive of some kind,
but I'm not sure the correct syntax. My first try generated a warning that
it was not needed.

What is the correct way to do this? Or does raster need to export this
definition?

THK

[[alternative HTML version deleted]]

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

[R-pkg-devel] Vignette depends on BH

[Tim Keitt]

I have an RMarkdown vignette in a package that uses Rcpp and depends on BH.
I added BH to the Suggests list. It is still generating warnings about BH.
What is the correct way to handle this?

Thanks.

THK

[[alternative HTML version deleted]]

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

Re: [Rd] R not running under lldb? (osx)

[Tim Keitt]

Thanks Simon. I'll probably just switch to rocker when needing to debug in
that case.

THK

On Tue, Apr 21, 2020 at 6:51 PM Simon Urbanek 
wrote:

> Tim,
>
> as a security precaution Apple has disabled the ability to debug notarized
> applications*. It means any software distributed on macOS Catalina (and
> they may have retro-actively enabled it for recent updates of Mojave)
> cannot be run in a debugger.
>
> If you want to debug R, you have to use non-release binaries that are not
> notarized and install them by hand, e.g.:
>
> curl -L
> http://mac.r-project.org/high-sierra/R-4.0-branch/x86_64/R-4.0-branch.tar.gz
> | tar fxz - -C /
>
> Of course, this disables the Apple protections and thus is not recommended
> for casual users.
>
> Cheers,
> Simon
>
> * - more technical details: Apple requires notarization of any application
> that will be distributed via an Apple installer. Apple no longer allows
> installation of macOS applications that are not notarized. In order to
> obtain notarization, the application has to be fully signed, has to use
> hardened run-time and may not enable debugging entitlements. One part of
> the hardened run-time is that no debugger is allowed to attach to the
> application.
>
>
> > On 22/04/2020, at 8:59 AM, Tim Keitt  wrote:
> >
> > I see:
> >
> > Tims-Air:~ tkeitt$ R --version
> >
> > R version 3.6.3 (2020-02-29) -- "Holding the Windsock"
> >
> > Copyright (C) 2020 The R Foundation for Statistical Computing
> >
> > Platform: x86_64-apple-darwin15.6.0 (64-bit)
> >
> >
> > R is free software and comes with ABSOLUTELY NO WARRANTY.
> >
> > You are welcome to redistribute it under the terms of the
> >
> > GNU General Public License versions 2 or 3.
> >
> > For more information about these matters see
> >
> > https://www.gnu.org/licenses/.
> >
> >
> > Tims-Air:~ tkeitt$ R -d lldb
> >
> > (lldb) target create
> "/Library/Frameworks/R.framework/Resources/bin/exec/R"
> >
> > Current executable set to
> > '/Library/Frameworks/R.framework/Resources/bin/exec/R' (x86_64).
> >
> > (lldb) run --vanilla
> >
> > error: process exited with status -1 (Error 1)
> >
> > Never happened before. Is this a known issue?
> >
> > Thanks.
> >
> > THK
> >
> >   [[alternative HTML version deleted]]
> >
> > __
> > 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] R not running under lldb? (osx)

[Tim Keitt]

I see:

Tims-Air:~ tkeitt$ R --version

R version 3.6.3 (2020-02-29) -- "Holding the Windsock"

Copyright (C) 2020 The R Foundation for Statistical Computing

Platform: x86_64-apple-darwin15.6.0 (64-bit)


R is free software and comes with ABSOLUTELY NO WARRANTY.

You are welcome to redistribute it under the terms of the

GNU General Public License versions 2 or 3.

For more information about these matters see

https://www.gnu.org/licenses/.


Tims-Air:~ tkeitt$ R -d lldb

(lldb) target create "/Library/Frameworks/R.framework/Resources/bin/exec/R"

Current executable set to
'/Library/Frameworks/R.framework/Resources/bin/exec/R' (x86_64).

(lldb) run --vanilla

error: process exited with status -1 (Error 1)

Never happened before. Is this a known issue?

Thanks.

THK

[[alternative HTML version deleted]]

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

[Rd] r-project.org dns

[Tim Keitt]

Sorry if this was already discussed. I notice that r-project.org is not
found in dns lookups today. (At least for me -- I tried some online web
look services as well.)

THK

[[alternative HTML version deleted]]

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

Re: [R-pkg-devel] Travis/appveyor with CXX14/17

[Tim Keitt]

On Fri, Jun 7, 2019 at 11:09 AM Dirk Eddelbuettel  wrote:

>
> On 7 June 2019 at 10:13, Tim Keitt wrote:
> | I bumped a package to CXX14/17 and it failed on Travis/Appveyor while
> | checking fine locally. I assume I need to request different compilers or
>
> Correct.
>
> Working with a seriously outdated base layer of Ubuntu is a key
> bug^Hfeature
> of Travis.  Maddening, really.
>
> | something like that. Anyone have a quick recipe for that?
>
> Yes.  In fact, two different ways.
>
> i)  If you use the old Travis set up which is more shell-script alike, then
> one way is to use a PPA for nighlies/more current gcc or clang
> versions. I used to do that some client packages that needed newer
> compilers. An older example is still here
>
> https://github.com/eddelbuettel/cpptoml/blob/master/.travis.yml
>
> ii) Screw Travis and use the fact that you can now bring your own Docker
> container.  That is much preferable as you are in _complete_ control of
> the test environment. I switched a few packages to this, particularly
> when they needed additional libraries which I was building / providing
> via a PPA anyway. Two examples:
>
>   https://github.com/eddelbuettel/rquantlib/blob/master/.travis.yml
>   https://github.com/rcppmlpack/rcppmlpack2/blob/master/.travis.yml
>
> If you don't need extra libraries then something like this container
> have
> R, recent toolchain and support for PPAs. I have been meaning to blog
> about it with an example:
>
>   https://hub.docker.com/r/rocker/r-apt
>
> Obviously you can also start from vanilla Rocker's r-base, or any other
> Debian container.  Again,  your control, possibly also your initial
> work.
>
> A scheme I found helpful in a few repos is to create
>
>   docker/ci/Dockerfile -- base layer for CI, used by Travis
>   docker/run/Dockerfile-- above plus the actual repo code
>
> where the latter one is a simple container for users of the package.
>

That's super helpful. Thanks.

THK


>
> Hth, Dirk
>
> --
> http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
>

[[alternative HTML version deleted]]

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

[R-pkg-devel] Travis/appveyor with CXX14/17

[Tim Keitt]

I bumped a package to CXX14/17 and it failed on Travis/Appveyor while
checking fine locally. I assume I need to request different compilers or
something like that. Anyone have a quick recipe for that?

THK

[[alternative HTML version deleted]]

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

[Rd] Experimental package for asan-usan checks

[Tim Keitt]

I've been trying to replicate Brian's excellent work on sanity checks so we
can get that information before submitting. I've put together an
experimental package here: https://github.com/thk686/sanitycheckr

It uses a modified rocker r-devel-san image and attempts to install all
dependencies before running a check.

This would probably be better integrated into TravisCI, et al. It was
nonetheless a good opportunity to learn a bit about docker + asan/usan.
Happy to have people kick the tires, make suggestions or make pull requests.

THK

http://www.keittlab.org/

[[alternative HTML version deleted]]

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

Re: [R-pkg-devel] Avoid reprocessing Rmd vignette

[Tim Keitt]

http://www.keittlab.org/

On Mon, Mar 19, 2018 at 6:41 AM, Dirk Eddelbuettel <e...@debian.org> wrote:

>
> On 18 March 2018 at 21:57, Tim Keitt wrote:
> | That's a great idea, however my problem is with building a vignette, not
> | running tests, unless they are linked in some way I'm not understanding.
>
> Similar idea applies: condition, just as Inaki and Thierry suggested.  An
> example for a conditional vignette evaluation is
>
> ```{r echo = FALSE, message = FALSE}`r ''`
> hasData <- requireNamespace("hurricaneexposuredata", quietly = TRUE)
>   #1
> if (!hasData) {
>  #2
> knitr::opts_chunk$set(eval = FALSE)
>  #3
> msg <- paste("Note: Examples in this vignette require that the",
>  "`hurricaneexposuredata` package be installed. The
> system",
>  "currently running this vignette does not have that
> package",
>  "installed, so code examples will not be evaluated.")
> msg <- paste(strwrap(msg), collapse="\n")
> message(msg)
>   #4
> }
> ```
>

That's a great solution. I've used something similar eg
https://raw.githubusercontent.com/thk686/strider/master/vignettes/strider.Rmd

I'm still confused however as I was sure that my code chunks were run
during CRAN check even when the eval option was set to false. But its
sounding like I made the wrong assumption. Not sure why it did not work
before.

THK


>
> and the paper (https://journal.r-project.org/archive/2017/RJ-2017-026/) by
> Brooke Anderson and myself discusses #1 to #4.
>
> Dirk
>
> --
> http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
>

[[alternative HTML version deleted]]

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

Re: [R-pkg-devel] Avoid reprocessing Rmd vignette

[Tim Keitt]

http://www.keittlab.org/

On Mon, Mar 19, 2018 at 3:29 AM, Thierry Onkelinx <thierry.onkel...@inbo.be>
wrote:

> You can make things even a bit easier by setting "eval=myeval" and set
> "myeval <- FALSE" at the top of the vignette. In case you want to update
> the figures, you only have to set "myeval <- TRUE" and run the vignette.
>

Thanks. Yes, that is quite useful. I was thinking of making the entire
vignette "asis" but this approach is an alternative. As in my other email,
I ran into some problems with CRAN using this but perhaps I got it wrong.

THK


>
>
> ir. Thierry Onkelinx
> Statisticus / Statistician
>
> Vlaamse Overheid / Government of Flanders
> INSTITUUT VOOR NATUUR- EN BOSONDERZOEK / RESEARCH INSTITUTE FOR NATURE AND
> FOREST
> Team Biometrie & Kwaliteitszorg / Team Biometrics & Quality Assurance
> thierry.onkel...@inbo.be
> Havenlaan 88 bus 73, 1000 Brussel
> www.inbo.be
>
> 
> ///
> To call in the statistician after the experiment is done may be no more
> than asking him to perform a post-mortem examination: he may be able to say
> what the experiment died of. ~ Sir Ronald Aylmer Fisher
> The plural of anecdote is not data. ~ Roger Brinner
> The combination of some data and an aching desire for an answer does not
> ensure that a reasonable answer can be extracted from a given body of data.
> ~ John Tukey
> 
> ///////
>
> <https://www.inbo.be>
>
> 2018-03-19 8:18 GMT+01:00 Iñaki Úcar <i.uca...@gmail.com>:
>
> > 2018-03-19 3:57 GMT+01:00 Tim Keitt <tke...@utexas.edu>:
> > > http://www.keittlab.org/
> > >
> > > On Sun, Mar 18, 2018 at 8:14 PM, Dirk Eddelbuettel <e...@debian.org>
> > wrote:
> > >
> > >>
> > >> Tim,
> > >>
> > >> On 18 March 2018 at 18:58, Tim Keitt wrote:
> > >> | I have an Rmd vignette that runs some benchmarks. It takes long
> enough
> > >> (20+
> > >> | minutes) that eg TravisCI will choke. I've not tried submitting to
> > CRAN.
> > >> | What is the best practice for handling this situation? Do I generate
> > >> | HTML/PDF output locally and try to make them static? The vignette
> > builder
> > >> | is knitr. I know about the R.rsp package but I do not know if it
> > handles
> > >> | Rmd files.
> > >>
> > >> Tests are tickled from a runner script such as either one of
> > >>
> > >>   tests/doRUnit.R
> > >>   tests/testthat.R
> > >>
> > >> so you have an entry point to control for environment variables.
> > >>
> > >> Travis clearly documents what theirs are -- so you could just turn it
> > off
> > >> --
> > >> and I have opted (years ago) for a more endogeneous scheme of
> > suppressing
> > >> tests on CRAN based on version numbers (as I suppress tests when
> version
> > >> numbers are "release-style" form 'a.b.c', but then run the tests when
> > the
> > >> version number is "dev-style" ie a.b.c.d).
> > >>
> > >
> > > That's a great idea, however my problem is with building a vignette,
> not
> > > running tests, unless they are linked in some way I'm not
> understanding.
> >
> > One of my packages on CRAN contains a vignette with a benchmark. You
> > can check what I do here (search for "microbenchmark"):
> >
> > https://raw.githubusercontent.com/r-simmer/simmer/master/
> > vignettes/simmer-07-ctmc.Rmd
> >
> > Basically, those chunks that use microbenchmark are marked as
> > "eval=FALSE", and the resulting figures are static images. I run those
> > manually and update the images from time to time if something relevant
> > changed. Apart from saving compilation time, this way I don't need to
> > include microbenchmark as a dependency.
> >
> > Iñaki
> >
> > >
> > > THK
> > >
> > >
> > >>
> > >> You can alternatively check for CRAN via an env.var; I forget what it
> is
> > >> called and cannot grep for it as my scheme does not need it. WRE may
> > tell
> > >> you
> > >> what it is.
> > >>
> > >> Hth,  Dirk
> > >>
> > >> --
> > >> http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
> >
> > __
> > R-package-devel@r-project.org mailing list
> > https://stat.ethz.ch/mailman/listinfo/r-package-devel
> >
>
> [[alternative HTML version deleted]]
>
> __
> R-package-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel
>

[[alternative HTML version deleted]]

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

Re: [R-pkg-devel] Avoid reprocessing Rmd vignette

[Tim Keitt]

http://www.keittlab.org/

On Mon, Mar 19, 2018 at 2:18 AM, Iñaki Úcar <i.uca...@gmail.com> wrote:

> 2018-03-19 3:57 GMT+01:00 Tim Keitt <tke...@utexas.edu>:
> > http://www.keittlab.org/
> >
> > On Sun, Mar 18, 2018 at 8:14 PM, Dirk Eddelbuettel <e...@debian.org>
> wrote:
> >
> >>
> >> Tim,
> >>
> >> On 18 March 2018 at 18:58, Tim Keitt wrote:
> >> | I have an Rmd vignette that runs some benchmarks. It takes long enough
> >> (20+
> >> | minutes) that eg TravisCI will choke. I've not tried submitting to
> CRAN.
> >> | What is the best practice for handling this situation? Do I generate
> >> | HTML/PDF output locally and try to make them static? The vignette
> builder
> >> | is knitr. I know about the R.rsp package but I do not know if it
> handles
> >> | Rmd files.
> >>
> >> Tests are tickled from a runner script such as either one of
> >>
> >>   tests/doRUnit.R
> >>   tests/testthat.R
> >>
> >> so you have an entry point to control for environment variables.
> >>
> >> Travis clearly documents what theirs are -- so you could just turn it
> off
> >> --
> >> and I have opted (years ago) for a more endogeneous scheme of
> suppressing
> >> tests on CRAN based on version numbers (as I suppress tests when version
> >> numbers are "release-style" form 'a.b.c', but then run the tests when
> the
> >> version number is "dev-style" ie a.b.c.d).
> >>
> >
> > That's a great idea, however my problem is with building a vignette, not
> > running tests, unless they are linked in some way I'm not understanding.
>
> One of my packages on CRAN contains a vignette with a benchmark. You
> can check what I do here (search for "microbenchmark"):
>
> https://raw.githubusercontent.com/r-simmer/simmer/master/
> vignettes/simmer-07-ctmc.Rmd
>
> Basically, those chunks that use microbenchmark are marked as
> "eval=FALSE", and the resulting figures are static images. I run those
> manually and update the images from time to time if something relevant
> changed. Apart from saving compilation time, this way I don't need to
> include microbenchmark as a dependency.
>

Thanks. That is helpful.

I thought I had tried this method with a recent package and still ran into
problems with CRAN. The issue seemed to be that the R code is extracted
from the knitted output and run a second time where the chunk options no
longer apply. At least I thought that was what was happening. Glad to hear
this can work if so.

(Incidentally, I don't use microbenchmark for this one as I need to
generate random data per trial and don't want to include that in the
timing. A few lines of C++ does the trick.)

THK


>
> Iñaki
>
> >
> > THK
> >
> >
> >>
> >> You can alternatively check for CRAN via an env.var; I forget what it is
> >> called and cannot grep for it as my scheme does not need it. WRE may
> tell
> >> you
> >> what it is.
> >>
> >> Hth,  Dirk
> >>
> >> --
> >> http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
>

[[alternative HTML version deleted]]

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

[R-pkg-devel] (no subject)

[Tim Keitt]

I'm seeing:

* checking re-building of vignette outputs ... [3s] WARNING
> Error in re-building vignettes:
> ...
> Quitting from lines 24-60 (strider.Rmd)
> Error: processing vignette 'strider.Rmd' failed with diagnostics:
> package 'dplyr' is not installed for 'arch = x64'
> Execution halted



I'm a little confused because my vignette avoids loading any packages that
are not available. Is this because the "eval" option is not available in
the version of knitr used by CRAN?

Here's the vignette code:

>
> ---
> title: "The Strider Package"
> author: "Timothy H. Keitt"
> date: "`r Sys.Date()`"
> output: rmarkdown::html_vignette
> vignette: >
>   %\VignetteIndexEntry{Vignette Title}
>   %\VignetteEngine{knitr::rmarkdown}
>   %\VignetteEncoding{UTF-8}
> ---
> ```{r include=FALSE}
> has_packages = all(c("dplyr", "ggplot2", "microbenchmark") %in%
> rownames(installed.packages()))
> not_has_packages = !has_packages
> ```
> ```{r echo=FALSE, eval=not_has_packages}
> cat("Error: You must install dplyr, ggplot2 and microbenchmark to run the
> code in this vignette.")
> ```
> ```{r include=FALSE, message=FALSE, warning=FALSE, eval=has_packages}
> library(dplyr)
> library(ggplot2)
> library(microbenchmark)
> ...


This works fine on my computer even if I uninstall dplyr, etc. But it
appears that when CRAN tries to rebuild the vignette, the "eval" flag is
ignored?

Tricky to reproduce as the exact code used to regenerate the vignette is
not part of the output.

THK


http://www.keittlab.org/

[[alternative HTML version deleted]]

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

[R-pkg-devel] -Wlong-long

[Tim Keitt]

Anyone have a fix for:

Found the following significant warnings:
  ../windows/libpq-9.5.2/include/pg_config_ext.h:8:28: warning: ISO
C++ 1998 does not support 'long long' [-Wlong-long]


? I tried prepending __extension__ to the definition and adding CXX_STD =
CXX11 to Makevars. This is external code from postgres that is used to
build libpq.

THK


http://www.keittlab.org/

[[alternative HTML version deleted]]

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

Re: [R-pkg-devel] Package Submission: issues with R_registerRoutines', 'R_useDynamicSymbols'

[Tim Keitt]

On Thu, Apr 13, 2017 at 10:14 AM, Vineetha Warriyar Kodalore Vijayan <
vineethawarriyar@ucalgary.ca> wrote:

> Can someone help to resolve this issue?


I wrote a short R script that will read your RcppExports.cpp and emit the
corresponding init.c file. I call it from my configure script, but if your
code does not change, then you can just call it once (in your package
directory) and be done with it.

The R script is here:
https://github.com/thk686/rpg/blob/master/src/gen_init_c.R

THK

http://www.keittlab.org/

[[alternative HTML version deleted]]

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

Re: [Rd] Transferring ownership of R-managed buffer

[Tim Keitt]

On Thu, Mar 30, 2017 at 3:15 PM, Gabriel Becker 
wrote:

> technically possible


So the garbage collector knows the buffer length independently of the
SEXPREC length field? Then, yes, its doable, but as you say not advisable.

THK

http://www.keittlab.org/

[[alternative HTML version deleted]]

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

Re: [Rd] Transferring ownership of R-managed buffer

[Tim Keitt]

On Wed, Mar 29, 2017 at 4:56 PM, Gabriel Becker 
wrote:

> The concept of having a vector which is a "window" into another vector
> without duplication ( which I suspect is at least related to your use-case,
> though I could be wrong) is a special case of one of alt-representations I
>  have implemented there.
>

Nice. That is exactly what I need. I was trying out a little experiment,
but I think its not possible right now because the length of an R vector is
identical to the buffer length. I can do everything I need except force the
length of the returned R vector to be only a portion of the allocated
storage.

THK

http://www.keittlab.org/

[[alternative HTML version deleted]]

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

Re: [Rd] Transferring ownership of R-managed buffer

[Tim Keitt]

http://www.keittlab.org/

On Wed, Mar 29, 2017 at 1:04 PM, Hervé Pagès <hpa...@fredhutch.org> wrote:

> Hi Tim,
>
> On 03/29/2017 08:24 AM, Tim Keitt wrote:
>
>> I have a use case where I would like to create an SEXP around an existing
>> buffer that is managed by R, thus avoiding a copy operation.
>>
>
> What to you mean exactly by "an existing buffer managed by R"?
>

Not allocated from the general heap, but rather allocated using R's
allocator and therefore returnable (hypothesis!) to the R interpreter as a
vector (not external pointer) without a copy operation.


>
> If I have
>> something like:
>>
>> void *p = (void*) RAW(PROTECT(Rf_allocVector(RAWSXP, n)));
>> ... additional maniupulation ...
>> SEXP x = somefunc(SXPTYPE, n, p);  // 
>>
>> Is there a "placement" constructor available?
>>
>
> What's a "placement" constructor?
>

Function that constructs an object using previously allocated memory (for
example provided by a 3rd party library). In some cases, responsibility for
further management of the buffer is transferred to the new object.


>
> (I have arranged for the
>> corresponding UNPROTECT.) I've looked at and experimented with R_allocator
>> and allocVector3, but can't quite get it right. I know this is odd, but it
>> makes sense for my use case.
>>
>
> Not sure I follow what you are trying to do. Note that an SEXP is a
> pointer to a C struct called SEXPREC. I think that trying to point an
> SEXPREC struct to data pointed to by an existing SEXPREC struct is very
> likely to lead to a disaster.
>

Possibly (although that is not what I am proposing). I'm still trying to
grok where the state resides (all in the SEXPREC or between that and the
allocator).


>
> Note that if the existing buffer managed by R is an SEXP (e.g. b) and
> your code has access to this SEXP then you don't need to create another
> SEXP around its data. Since SEXPs are pointers doing
>
>   SEXP x = b;
>
> is fine and doesn't generate any copy.
>

The buffer in this case might be resized and reallocated and the original
SEXP will have gone out of scope.


>
> And if your code only has access to a "naked" pointer to the buffer
> managed by R (e.g. to RAW(b) is the buffer is actually in an SEXP)
> then why would you need to wrap it inside an SEXP?
>

I'm working with 3rd party structures that can work with a pointer and
buffer length, but cannot track the original SEXP. I just need to construct
an SEXP (SEXPREC) and point it at the buffer, set the vector length and
data type. I was checking to see if there is an API for that (and that wont
interfere with Rcpp declarations as it pulls in parts of Rinternals.h, but
as far as I can tell, not the parts that I need to work with SEXPRECs at a
low-level).

THK


> H.
>
>
>> Thanks for any pointers.
>>
>> THK
>>
>> https://urldefense.proofpoint.com/v2/url?u=http-3A__www.keit
>> tlab.org_=DwICAg=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWd
>> GbWY_wJYbW0WYiZvSXAJJKaaPhzWA=Ceu5dLU_mdGwmpIk_iUqE0dPNjqw
>> y8wiRy6hS_lWF9k=h04DJujKDfqzbLz4FmP3_fZ5bYS3t7UEjSwpLrW5mL0=
>>
>> [[alternative HTML version deleted]]
>>
>> __
>> R-devel@r-project.org mailing list
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__stat.et
>> hz.ch_mailman_listinfo_r-2Ddevel=DwICAg=eRAMFD45gAfqt84V
>> tBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=Ceu5d
>> LU_mdGwmpIk_iUqE0dPNjqwy8wiRy6hS_lWF9k=WpLxtWWwjoZ7TjW6oW-
>> vxE6s3LY5kZCG1H5h0xb0Bbs=
>>
>>
> --
> Hervé Pagès
>
> Program in Computational Biology
> Division of Public Health Sciences
> Fred Hutchinson Cancer Research Center
> 1100 Fairview Ave. N, M1-B514
> P.O. Box 19024
> Seattle, WA 98109-1024
>
> E-mail: hpa...@fredhutch.org
> Phone:  (206) 667-5791
> Fax:(206) 667-1319
>

[[alternative HTML version deleted]]

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

Re: [R-pkg-devel] AppVeyor with LinkingTo: field

[Tim Keitt]

On Mon, Feb 13, 2017 at 10:31 AM, Tim Keitt <tke...@utexas.edu> wrote:

> I am almost there -- only failing on devel in Travis CI. It failing at the
> "R CMD build" phase.
>
> * installing *source* package ‘odeintr’ ...
>> ** libs
>> I/home/travis/R-bin/lib/R/include -DNDEBUG -I"../inst/include"
>> -I"/home/travis/R/Library/Rcpp/include" -I"/home/travis/R/Library/BH/include"
>> -I/home/travis/R-bin/include  -c RcppExports.cpp -o RcppExports.o
>> /bin/bash: I/home/travis/R-bin/lib/R/include: No such file or directory
>> make: [RcppExports.o] Error 127 (ignored)
>
>
> I think my PKG_CPPFLAGS or some such is not right. Is there something
> about the devel branch of R I am missing?
>

Known Travis bug.

Finally everything works!

THK

http://www.keittlab.org/

[[alternative HTML version deleted]]

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

Re: [R-pkg-devel] AppVeyor with LinkingTo: field

[Tim Keitt]

On Mon, Feb 13, 2017 at 10:36 AM, Dirk Eddelbuettel  wrote:

> Not true.
>

It seems to be a work-around for Travis, but as you say not a general
packaging requirement.

THK

http://www.keittlab.org/

[[alternative HTML version deleted]]

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

Re: [R-pkg-devel] AppVeyor with LinkingTo: field

[Tim Keitt]

On Mon, Feb 13, 2017 at 9:19 AM, Dirk Eddelbuettel  wrote:

> [1] http://eddelbuettel.github.io/r-travis/
>

This looks useful. I'll have to investigate.

THK

http://www.keittlab.org/

[[alternative HTML version deleted]]

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

Re: [Rd] What happened to Ross Ihaka's proposal for a Common Lisp based R successor?

[Tim Keitt]

My latest project in R + Rcpp + RcppParallel + RcppEigen ran so fast when I
tested it, I thought it was a short-circuit. Not as clean as pure Julia but
if you like C++ its a pretty sweet environment.

(Incidentally, several of the ideas in Julia came from a discussion about
rewriting R I had with Viral many years ago. Its nice to see them come to
life.)

THK

On Fri, Aug 5, 2016 at 12:41 PM Ista Zahn  wrote:

> But you can easily fall back to R from within Julia; see
> http://juliastats.github.io/RCall.jl/latest/
>
> On Aug 5, 2016 1:27 PM, "Hadley Wickham"  wrote:
>
> > No.
> >
> > Hadley
> >
> > On Fri, Aug 5, 2016 at 11:12 AM, Kenny Bell  wrote:
> > > Is it conceivable that Julia could be ported to use R syntax in a way
> > that
> > > would allow the vastly larger numbers of R programmers to seamlessly
> > switch?
> > > Or equivalently, could an iteration of R itself do this?
> > >
> > >
> > > On Fri, Aug 5, 2016, 9:00 AM Hadley Wickham 
> wrote:
> > >>
> > >> When it was being actively worked on, it had the advantage of
> existing.
> > >>
> > >> Hadley
> > >>
> > >> On Fri, Aug 5, 2016 at 10:48 AM, Kenny Bell 
> wrote:
> > >> > Why is the described system preferable to Julia?
> > >> >
> > >> > On Fri, Aug 5, 2016, 4:50 AM peter dalgaard 
> wrote:
> > >> >
> > >> >>
> > >> >> On 05 Aug 2016, at 06:41 , Andrew Judson  wrote:
> > >> >>
> > >> >> > I read this paper
> > >> >> >  > 2008.pdf>
> > >> >> > and
> > >> >> > haven't been able to find out what happened - I have seen some
> > >> >> > sporadic
> > >> >> > mention in message groups but nothing definitive. Does anyone
> know?
> > >> >>
> > >> >> Presumably Ross does...
> > >> >>
> > >> >> You get a hint if you go one level up and look for the newest file:
> > >> >>
> > >> >> https://www.stat.auckland.ac.nz/~ihaka/downloads/New-System.pdf
> > >> >>
> > >> >>
> > >> >> --
> > >> >> Peter Dalgaard, Professor,
> > >> >> Center for Statistics, Copenhagen Business School
> > >> >> Solbjerg Plads 3, 2000 Frederiksberg, Denmark
> > >> >> Phone: (+45)38153501
> > >> >> Office: A 4.23
> > >> >> Email: pd@cbs.dk  Priv: pda...@gmail.com
> > >> >>
> > >> >> __
> > >> >> 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
> > >>
> > >>
> > >>
> > >> --
> > >> http://hadley.nz
> >
> >
> >
> > --
> > http://hadley.nz
> >
> > __
> > 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
>

[[alternative HTML version deleted]]

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

Re: [R-pkg-devel] Force namespace prefix for a loaded package function

[Tim Keitt]

http://www.keittlab.org/

On Mon, Jun 27, 2016 at 3:22 AM, Joris Meys <jorism...@gmail.com> wrote:

> If you want to call a non exported function, you need three colons
>
> X:::f ()
>
> And frankly, that is a bad idea.
>
I think you missed the point (and stated the obvious).

A well-designed namespace feature would give control of imports to the code
user, not the code writer.

Right now, I have to avoid all the function names in base because I will
cause a collision. If I want to have an "options" function in my package, I
have to make it "pkgname_options" rather than pkgname::options, which is
greatly preferable and would allow the user to decide whether they want to
import it and then simply use "options" and "base::options".

I've always considered this all-or-nothing approach to imports a bug in the
implementation of namespaces in R. I was trying to suggest that it be
fixed. (Probably should have sent this to r-devel actually.)

THK



> Cheers
> Joris
> On 26 Jun 2016 19:37, "Tim Keitt" <tke...@utexas.edu> wrote:
>
>> It would be rather nice if we could define functions in our packages that
>> must be called with the namespace prefix.
>>
>> I'd like to do
>>
>> #' @protected (or some such)
>> f = function(...) list(...)
>>
>> in package scope and then
>>
>> library(x)
>> f(1) # fails
>> x::f(1) # succeeds
>>
>> Currently unless I am missing something, a function is either exported to
>> global scope or not available. This could be done if package loading made
>> two environments, one in the path and another not in the path, and then
>> have the namespace prefix search both in succession.
>>
>> Yes, you could do
>>
>> #' @export
>> x_f = function(...) list(...)
>>
>> library(x)
>> x_f(1)
>>
>> but I would prefer reusing the namespace prefix syntax.
>>
>> This would also avoid name collisions between package, which ideally is
>> the
>> purpose of a namespace.
>>
>> I suppose also you could make two packages and list one in Imports: but I
>> find that less satisfying because it requires a different namespace
>> prefix.
>>
>> Or am I missing something obvious here.
>>
>> THK
>>
>> http://www.keittlab.org/
>>
>> [[alternative HTML version deleted]]
>>
>> __
>> R-package-devel@r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-package-devel
>>
>

[[alternative HTML version deleted]]

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

[R-pkg-devel] Force namespace prefix for a loaded package function

[Tim Keitt]

It would be rather nice if we could define functions in our packages that
must be called with the namespace prefix.

I'd like to do

#' @protected (or some such)
f = function(...) list(...)

in package scope and then

library(x)
f(1) # fails
x::f(1) # succeeds

Currently unless I am missing something, a function is either exported to
global scope or not available. This could be done if package loading made
two environments, one in the path and another not in the path, and then
have the namespace prefix search both in succession.

Yes, you could do

#' @export
x_f = function(...) list(...)

library(x)
x_f(1)

but I would prefer reusing the namespace prefix syntax.

This would also avoid name collisions between package, which ideally is the
purpose of a namespace.

I suppose also you could make two packages and list one in Imports: but I
find that less satisfying because it requires a different namespace prefix.

Or am I missing something obvious here.

THK

http://www.keittlab.org/

[[alternative HTML version deleted]]

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

Re: [Rd] Suggestion: mkString(NULL) should be NA

[Tim Keitt]

http://www.keittlab.org/

On Wed, May 25, 2016 at 10:43 AM, <luke-tier...@uiowa.edu> wrote:

> On Wed, 25 May 2016, Tim Keitt wrote:
>
> On Wed, May 25, 2016 at 7:22 AM, Michael Lawrence <
>> lawrence.mich...@gene.com
>>
>>> wrote:
>>>
>>
>> On Wed, May 25, 2016 at 4:23 AM, Jeroen Ooms <jeroen.o...@stat.ucla.edu>
>>> wrote:
>>>
>>>
>> I'm not disagreeing with what's been said in this thread, but I can't help
>> but recall that I brought up this exact issue probably 15 years ago and
>> was
>> told (by Brian, I believe) "don't do that" (pass a null pointer), which
>> was
>> perfectly fine. The real issue was not the behavior but that it was not
>> documented or consistent. I've lived by the mantra since that you can
>> never
>> trust a pointer in R code. User must always check for NULL.
>>
>
> In _C_ code.  This is true whether you are calling into the R C API or
> any other C library: you as the C programmer need to make sure either
> that passing NULL is OK or make sure you don't do that.
>

I agree -- I meant it was "perfectly fine" to remind us we need to check
pointers. Its really a documentation issue.

THK




>
> I wouldn't object to mkXXX checking for NULL and signaling an error
> instead of segfaulting, but good C code calling mkXXX should still
> typically do its own check and handle the situation in an appropriate
> way.
>
> Best,
>
> luke
>
>
>
>> I just wrote my own functions mkXXX_safe that wrap the internals and check
>> the pointer.
>>
>> THK
>>
>> http://www.keittlab.org/
>>
>> [[alternative HTML version deleted]]
>>
>> __
>> R-devel@r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-devel
>>
>>
> --
> Luke Tierney
> Ralph E. Wareham Professor of Mathematical Sciences
> University of Iowa  Phone: 319-335-3386
> Department of Statistics andFax:   319-335-3017
>Actuarial Science
> 241 Schaeffer Hall  email:   luke-tier...@uiowa.edu
> Iowa City, IA 52242 WWW:  http://www.stat.uiowa.edu
>

[[alternative HTML version deleted]]

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

Re: [Rd] Suggestion: mkString(NULL) should be NA

[Tim Keitt]

On Wed, May 25, 2016 at 7:22 AM, Michael Lawrence  wrote:

> On Wed, May 25, 2016 at 4:23 AM, Jeroen Ooms 
> wrote:
>

I'm not disagreeing with what's been said in this thread, but I can't help
but recall that I brought up this exact issue probably 15 years ago and was
told (by Brian, I believe) "don't do that" (pass a null pointer), which was
perfectly fine. The real issue was not the behavior but that it was not
documented or consistent. I've lived by the mantra since that you can never
trust a pointer in R code. User must always check for NULL.

I just wrote my own functions mkXXX_safe that wrap the internals and check
the pointer.

THK

http://www.keittlab.org/

[[alternative HTML version deleted]]

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

Re: [R-pkg-devel] What to do with build-time-only utility scripts in package

[Tim Keitt]

http://www.keittlab.org/

On Fri, Apr 15, 2016 at 11:40 AM, Dirk Eddelbuettel <e...@debian.org> wrote:

>
> On 15 April 2016 at 10:27, Tim Keitt wrote:
> | I created a couple of R scripts to assist my package 'configure' script.
> I
> | put them in the top-level of the package and that gives a check error
> | obviously. So I added them to .Rbuildignore and then the package would
> not
> | build (at least on Travis CI) saying the script files were not found.
> | That's counter to how I thought .Rbuildignore worked. Where should these
> | utility script go? Should they not be in .Rbuildignore?
>
> The legal name of '.Rbuildignore' is 'do not put these files into the
> tarball'.
>
> As the check uses the tarball as source  well I guess you can fill in
> the rest.
>

Got it. Thought it was "do not install these files with package".

I guess I'll stick them in /src.

THK


>
> Dirk
>
> --
> http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
>

[[alternative HTML version deleted]]

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

[R-pkg-devel] What to do with build-time-only utility scripts in package

[Tim Keitt]

I created a couple of R scripts to assist my package 'configure' script. I
put them in the top-level of the package and that gives a check error
obviously. So I added them to .Rbuildignore and then the package would not
build (at least on Travis CI) saying the script files were not found.
That's counter to how I thought .Rbuildignore worked. Where should these
utility script go? Should they not be in .Rbuildignore?

THK

http://www.keittlab.org/

[[alternative HTML version deleted]]

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

Re: [Rd] authorship and citation

[Tim Keitt]

On Wed, Oct 7, 2015 at 2:39 PM, Duncan Murdoch 
wrote:

> I think it was easier to (ab)use that role than to get a "Maintainer"
> role added to the standard ones.
>

Why bother with the relators list at all?

THK

http://www.keittlab.org/

[[alternative HTML version deleted]]

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

Re: [Rd] authorship and citation

[Tim Keitt]

On Wed, Oct 7, 2015 at 11:29 AM, Spencer Graves  wrote:

> Another example:  The "Author" of the Ecdat package is Yves Croissant <
> yves.croiss...@let.ish-lyon.cnrs.fr>.  I'm the Maintainer.  At some
> point, I may add my name to the list of Authors but I certainly would never
> remove Yves' name.  That package is, I think, exclusively data sets.  I
> added functions, which I later spun off into a separate Edfun package;  I'm
> listed as the Author and Maintainer of that.
>

This reminded me of something I have always found curious about roles
listed in the DESCRIPTION file. Since there is no "maintainer" role in this
list: http://www.loc.gov/marc/relators/relaterm.html, which was used to get
the role names, you will be listed as the "creator" of the package when you
list yourself as maintainer even if you did not initiate the package or
even contribute code.

THK

http://www.keittlab.org/

[[alternative HTML version deleted]]

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

[R-pkg-devel] CRAN and CMake

[Tim Keitt]

I am thinking of writing an R wrapper for some code that uses cmake. If I
include that code under the src directory (ie in src/the_other_project/),
am I likely to run into problems with CRAN? Never been down that road and
would like to know if this is feasible. I guess I would have to call cmake
in the configure script.

I know I can simply keep the other project code separate. Just wondering if
the above setup makes any sense.

THK

http://www.keittlab.org/

[[alternative HTML version deleted]]

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

Re: [Rd] Reading exit code of pipe()

[Tim Keitt]

Not sure if it helps for your use case, but I have an experimental package
for controlling bidirectional pipe streams from R. Just thought I'd mention
it. Its at

https://github.com/thk686/pipestreamr

THK

On Thu, May 14, 2015 at 9:30 AM, William Dunlap wdun...@tibco.com wrote:

 The difference in the return value of close(pipeConnectionObject)
 seems to depend on whether the pipe connection was opened via
 the pipe() or open() functions (close() returns NULL)
 con - pipe(ls)
 open(con, r)
 readLines(con, n=1)
[1] 1032.R
 print(close(con))
NULL
 con - pipe(ls, r)
 scan(con, n=1, what=)
   Read 1 item
   [1] 1032.R
print(close(con))
   NULL
 or via something like readLines() or scan() (close() returns status
 integer).
con - pipe(ls)
scan(con, n=1, what=)
   Read 1 item
   [1] 1032.R
print(close(con))
   [1] 36096
sprintf(0x%x, .Last.value)
   [1] 0x8d00






 Bill Dunlap
 TIBCO Software
 wdunlap tibco.com

 On Wed, May 13, 2015 at 10:27 PM, Kevin Ushey kevinus...@gmail.com
 wrote:

  Hi Jeroen,
 
  I think `pipe` might just be returning the status code of the
  underlying command executed; for example, I get a status code of '0'
  when I test a pipe on `ls`:
 
  conn - pipe(ls)
  stream - readLines(conn)
  print(close(conn))
 
  Similarly, I get an error code if I try to `ls` a non-existent
  directory (512 in my case), e.g.
 
  conn - pipe(ls /no/path/here/sir)
  stream - readLines(conn)
  print(close(conn))
 
  So maybe `cat` just doesn't set a status code, and so there's nothing
  for R to forward back (ergo -- NULL)?
 
  Kevin
 
  On Wed, May 13, 2015 at 5:24 PM, Jeroen Ooms jeroen.o...@stat.ucla.edu
  wrote:
   Is there a way to get the status code of a pipe() command? The
   documentation suggests that it might be returned by close, however
   this does not seem to be the case.
  
 con - pipe(cat /etc/passwd, r)
 stream - readLines(con, n = 10)
 err - close(con)
 print(err)
  
   __
   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
 

 [[alternative HTML version deleted]]

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




-- 
Timothy H. Keitt
http://www.keittlab.org/

[[alternative HTML version deleted]]

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

[Rd] Typo in src/scripts/config

[Tim Keitt]

Was writing a short R script to modify compile flags and saw this typo:

Index: config
===
--- config (revision 68217)
+++ config (working copy)
@@ -61,7 +61,7 @@
   CXX1X C++ compiler command for C++11 code
   CXX1XSTD  flag used to enable C++11 support
   CXX1XFLAGSC++11 compiler flags
-  CXX1XXPICFLAGS
+  CXX1XPICFLAGS
 special flags for compiling C++11 code to be turned into
 a shared library
   DYLIB_EXT file extension (including '.') for dynamic libraries

-- 
http://www.keittlab.org/

[[alternative HTML version deleted]]

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

[Rd] Documentation for reg.finalizer

[Tim Keitt]

Documentation says (emphasis mine):

Registers an R function to be called upon garbage collection of
 object OR (optionally) at the end of an R session.

Should this say and and not or?

THK

-- 
http://www.keittlab.org/

[[alternative HTML version deleted]]

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

Re: [Rd] :: and ::: as .Primitives?

[Tim Keitt]

On Thu, Jan 22, 2015 at 1:44 PM, luke-tier...@uiowa.edu wrote:

 I'm not convinced that how to make :: faster is the right question. If
 you are finding foo::bar being called often enough to matter to your
 overall performance then to me the question is: why are you calling
 foo::bar more than once? Making :: a bit faster by making it a
 primitive will remove some overhead, but your are still left with a
 lot of work that shouldn't need to happen more than once.

 For default methods there ought to be a way to create those so the
 default method is computed at creation or load time and stored in an
 environment. For other cases if I want to use foo::bar many times, say
 in a loop, I would do

 foo_bar - foo::bar

 and use foo_bar, or something along those lines.

 When :: and ::: were introduce they were intended primarily for
 reflection and debugging, so speed was not an issue. ::: is still
 really only reliably usable that way, and making it faster may just
 encourage bad practice. :: is different and there are good arguments
 for using it in code, but I'm not yet seeing good arguments for use in
 ways that would be performance-critical, but I'm happy to be convinced
 otherwise. If there is a need for a faster :: then going to a
 SPECIALSXP is fine; it would also be good to make the byte code
 compiler aware of it, and possibly to work on ways to improve the
 performance further e.g. through cacheing.


I think you will find that no matter how much it does not matter in terms
of performance, folks will avoid :: out of principle if they think its
slower. We're conditioned to write efficient code even when it does not
really impact real world usage. As using :: is good practice in many
contexts, making it fast will encourage folks to use it.

THK



 Best,

 luke


 On Thu, 22 Jan 2015, Peter Haverty wrote:


  Hi all,

 When S4 methods are defined on base function (say, match), the
 function becomes a method with the body base::match(x,y). A call to
 such a function often spends more time doing :: than in the function
 itself.  I always assumed that :: was a very low-level thing, but it
 turns out to be a plain old function defined in base/R/namespace.R.
 What would you all think about making :: and ::: .Primitives?  I
 have submitted some examples, timings, and a patch to the R bug
 tracker (https://bugs.r-project.org/bugzilla3/show_bug.cgi?id=16134).
 I'd be very interested to hear your thoughts on the matter.

 Regards,
 Pete

 
 Peter M. Haverty, Ph.D.
 Genentech, Inc.
 phave...@gene.com

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


 --
 Luke Tierney
 Ralph E. Wareham Professor of Mathematical Sciences
 University of Iowa  Phone: 319-335-3386
 Department of Statistics andFax:   319-335-3017
Actuarial Science
 241 Schaeffer Hall  email:   luke-tier...@uiowa.edu
 Iowa City, IA 52242 WWW:  http://www.stat.uiowa.edu


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




-- 
http://www.keittlab.org/

[[alternative HTML version deleted]]

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

Re: [Rd] testing dontrun examples

[Tim Keitt]

On Wed, Nov 26, 2014 at 12:45 PM, Paul Gilbert pgilbert...@gmail.com
wrote:

 Is there a good strategy for testing examples which should not be run by
 default? For instance, I have examples which get data from the Internet. If
 I wrap them in try() then they can be skipped if the Internet is not
 available, but may not be tested in cases when I would like to know about
 the failure. (Not to mention that the example syntax is ugly.)

 If I mark them \dontrun or \donttest then they are not tested. I could
 mark them \dontrun and then use example() but for this, in addition to
 run.dontrun=TRUE, I would need to specify all topics for a package, and I
 don't see how to do this, missing topic does not work.

 Wishlist: what I would really like is R CMD check --run-dontrun   pkg


I agree that would be nice to have.

My solution was just to have a private function (pkg:::run_examples()) that
runs all the examples. It has to be manually updated when adding a new
example however.

The devtools solution has not always worked for me when there are external
dependencies (like internet download, etc.)

THK



 Suggestions?

 Thanks,
 Paul

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




-- 
http://www.keittlab.org/

[[alternative HTML version deleted]]

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

[Rd] Excluding objects from save.image

[Tim Keitt]

When dealing with object holding pointers that are only valid during a
single session, it would be convenient to exclude them from being saved
with the session image. (I am assuming that `quit` calls `save.image`
before quitting or is it internal?) Currently they are saved with the
pointer converted to NULL. Its a bit surprising for users not realizing the
object is no longer valid.

My thought is to designate a class name (perhaps no.save) and exclude
anything that inherits from that. I've hacked a quick implementation below.
I did not issue a warning, but it would be a simple fix.

Does anyone else see this as useful?

THK

-- 
http://www.keittlab.org/

.new.save.image = function (file = .RData, version = NULL, ascii = FALSE,
compress = !ascii,
safe = TRUE, omit.no.save = TRUE)   # added
omit.no.save argument
{
  if (!is.character(file) || file == )
stop('file' must be non-empty string)
  opts - getOption(save.image.defaults)
  if (is.null(opts))
opts - getOption(save.defaults)
  if (missing(safe)  !is.null(opts$safe))
safe - opts$safe
  if (missing(ascii)  !is.null(opts$ascii))
ascii - opts$ascii
  if (missing(compress)  !is.null(opts$compress))
compress - opts$compress
  if (missing(version))
version - opts$version
  if (safe) {
outfile - paste0(file, Tmp)
i - 0
while (file.exists(outfile)) {
  i - i + 1
  outfile - paste0(file, Tmp, i)
}
  }
  else outfile - file
  on.exit(file.remove(outfile))

  ### Omit objects inheriting from no.save ###

  objns - ls(envir = .GlobalEnv, all.names = TRUE)

  if ( omit.no.save )  ### make part of options?
objns - subset(objns, sapply(objns, function(x)
{
  ! inherits(get(x, envir = .GlobalEnv), no.save)
}))

  save(list = objns, file = outfile,
   version = version, ascii = ascii, compress = compress,
   envir = .GlobalEnv, precheck = FALSE)

  ### End code changes ###

  if (safe)
if (!file.rename(outfile, file)) {
  on.exit()
  stop(gettextf(image could not be renamed and is left in %s,
outfile), domain = NA)
}
  on.exit()
}

setClass(no.save)
setClass(test.class, slots = c(s1 = externalptr))
setIs(test.class, no.save)
reg.obj = regular object
no.save.obj = new(test.class)
.image.file = tempfile()
save.image(.image.file)
rm(reg.obj, no.save.obj)
load(.image.file)
print(ls())
unlink(.image.file)
.new.save.image(.image.file)
rm(reg.obj, no.save.obj)
load(.image.file)
print(ls())
unlink(.image.file)

[[alternative HTML version deleted]]

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

Re: [Rd] Excluding objects from save.image

[Tim Keitt]

On Thu, May 22, 2014 at 9:19 AM, Simon Urbanek
simon.urba...@r-project.orgwrote:

 Tim,

 On May 21, 2014, at 9:54 PM, Tim Keitt tke...@utexas.edu wrote:

  When dealing with object holding pointers that are only valid during a
 single session, it would be convenient to exclude them from being saved
 with the session image. (I am assuming that `quit` calls `save.image`
 before quitting or is it internal?) Currently they are saved with the
 pointer converted to NULL. Its a bit surprising for users not realizing the
 object is no longer valid.
 

 than's not surprising - it's actually very useful, because it tells you
 that the object has been restored. Typically, packages using external
 pointers use this to re-inilitialize the object from serialized data or
 other sources if possible.


Automatically or with user intervention?




  My thought is to designate a class name (perhaps no.save) and exclude
 anything that inherits from that.

 Why would you want to not save it? It exists, so saving it makes it
 possible to decide on the behavior as needed - as opposed to not saving it
 and thus losing the information.


That's a valid argument. I don't necessarily disagree, but it does depend
on the situation and the author's intentions.

My question was not about enforcing policy on authors, rather it was about
whether this would add value for those that would like to use it for cases
where they deem it a benefit. I see those as separate issues.

Incidentally, I suggested many years ago hooks in load to make
reinitialization possible. Is there some infrastructure for that in R? (And
actually hooks on save would be quite useful as well eg one could
substitute an object designed to reinitialize the original object on load.)

Cheers,
THK



 Cheers,
 Simon



  I've hacked a quick implementation below.
  I did not issue a warning, but it would be a simple fix.
 
  Does anyone else see this as useful?
 
  THK
 
  --
  http://www.keittlab.org/
 
  .new.save.image = function (file = .RData, version = NULL, ascii =
 FALSE,
  compress = !ascii,
 safe = TRUE, omit.no.save = TRUE)   # added
  omit.no.save argument
  {
   if (!is.character(file) || file == )
 stop('file' must be non-empty string)
   opts - getOption(save.image.defaults)
   if (is.null(opts))
 opts - getOption(save.defaults)
   if (missing(safe)  !is.null(opts$safe))
 safe - opts$safe
   if (missing(ascii)  !is.null(opts$ascii))
 ascii - opts$ascii
   if (missing(compress)  !is.null(opts$compress))
 compress - opts$compress
   if (missing(version))
 version - opts$version
   if (safe) {
 outfile - paste0(file, Tmp)
 i - 0
 while (file.exists(outfile)) {
   i - i + 1
   outfile - paste0(file, Tmp, i)
 }
   }
   else outfile - file
   on.exit(file.remove(outfile))
 
   ### Omit objects inheriting from no.save ###
 
   objns - ls(envir = .GlobalEnv, all.names = TRUE)
 
   if ( omit.no.save )  ### make part of options?
 objns - subset(objns, sapply(objns, function(x)
 {
   ! inherits(get(x, envir = .GlobalEnv), no.save)
 }))
 
   save(list = objns, file = outfile,
version = version, ascii = ascii, compress = compress,
envir = .GlobalEnv, precheck = FALSE)
 
   ### End code changes ###
 
   if (safe)
 if (!file.rename(outfile, file)) {
   on.exit()
   stop(gettextf(image could not be renamed and is left in %s,
 outfile), domain = NA)
 }
   on.exit()
  }
 
  setClass(no.save)
  setClass(test.class, slots = c(s1 = externalptr))
  setIs(test.class, no.save)
  reg.obj = regular object
  no.save.obj = new(test.class)
  .image.file = tempfile()
  save.image(.image.file)
  rm(reg.obj, no.save.obj)
  load(.image.file)
  print(ls())
  unlink(.image.file)
  .new.save.image(.image.file)
  rm(reg.obj, no.save.obj)
  load(.image.file)
  print(ls())
  unlink(.image.file)
 
[[alternative HTML version deleted]]
 
  __
  R-devel@r-project.org mailing list
  https://stat.ethz.ch/mailman/listinfo/r-devel
 




-- 
http://www.keittlab.org/

[[alternative HTML version deleted]]

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

Re: [Rd] Excluding objects from save.image

[Tim Keitt]

On Thu, May 22, 2014 at 10:47 AM, Simon Urbanek simon.urba...@r-project.org
 wrote:

 On May 22, 2014, at 11:33 AM, Tim Keitt tke...@utexas.edu wrote:

  On Thu, May 22, 2014 at 9:19 AM, Simon Urbanek 
 simon.urba...@r-project.org wrote:
  Tim,
 
  On May 21, 2014, at 9:54 PM, Tim Keitt tke...@utexas.edu wrote:
 
   When dealing with object holding pointers that are only valid during a
 single session, it would be convenient to exclude them from being saved
 with the session image. (I am assuming that `quit` calls `save.image`
 before quitting or is it internal?) Currently they are saved with the
 pointer converted to NULL. Its a bit surprising for users not realizing the
 object is no longer valid.
  
 
  than's not surprising - it's actually very useful, because it tells you
 that the object has been restored. Typically, packages using external
 pointers use this to re-inilitialize the object from serialized data or
 other sources if possible.
 
  Automatically or with user intervention?


 Automatically - that is the point :).


Have an example? Do you save a promise?




   My thought is to designate a class name (perhaps no.save) and
 exclude anything that inherits from that.
 
  Why would you want to not save it? It exists, so saving it makes it
 possible to decide on the behavior as needed - as opposed to not saving it
 and thus losing the information.
 
  That's a valid argument. I don't necessarily disagree, but it does
 depend on the situation and the author's intentions.
 
  My question was not about enforcing policy on authors, rather it was
 about whether this would add value for those that would like to use it for
 cases where they deem it a benefit. I see those as separate issues.
 
  Incidentally, I suggested many years ago hooks in load to make
 reinitialization possible. Is there some infrastructure for that in R? (And
 actually hooks on save would be quite useful as well eg one could
 substitute an object designed to reinitialize the original object on load.)
 

 Load time is typically not an issue, since you can just do it lazily.
 (Incidentally, doing that eagerly at load time is the hard part since you'd
 have to load the packages necessary in the right order which is not always
 possible to determine from the serialization alone. It's a full can of
 worms, because R doesn't know anything about sharing and dependencies on
 the native side etc.).

 However, having a proper save hook for ext ptrs would be very useful. When
 I was asking for it few years ago, Luke mentioned there were issues - maybe
 it's something that could be re-visited.


I'd be interested. I can see it might be tricky deciding when to call the
hook.

THK



 Cheers,
 Simon



  Cheers,
  THK
 
 
  Cheers,
  Simon
 
 
 
   I've hacked a quick implementation below.
   I did not issue a warning, but it would be a simple fix.
  
   Does anyone else see this as useful?
  
   THK
  
   --
   http://www.keittlab.org/
  
   .new.save.image = function (file = .RData, version = NULL, ascii =
 FALSE,
   compress = !ascii,
  safe = TRUE, omit.no.save = TRUE)   # added
   omit.no.save argument
   {
if (!is.character(file) || file == )
  stop('file' must be non-empty string)
opts - getOption(save.image.defaults)
if (is.null(opts))
  opts - getOption(save.defaults)
if (missing(safe)  !is.null(opts$safe))
  safe - opts$safe
if (missing(ascii)  !is.null(opts$ascii))
  ascii - opts$ascii
if (missing(compress)  !is.null(opts$compress))
  compress - opts$compress
if (missing(version))
  version - opts$version
if (safe) {
  outfile - paste0(file, Tmp)
  i - 0
  while (file.exists(outfile)) {
i - i + 1
outfile - paste0(file, Tmp, i)
  }
}
else outfile - file
on.exit(file.remove(outfile))
  
### Omit objects inheriting from no.save ###
  
objns - ls(envir = .GlobalEnv, all.names = TRUE)
  
if ( omit.no.save )  ### make part of options?
  objns - subset(objns, sapply(objns, function(x)
  {
! inherits(get(x, envir = .GlobalEnv), no.save)
  }))
  
save(list = objns, file = outfile,
 version = version, ascii = ascii, compress = compress,
 envir = .GlobalEnv, precheck = FALSE)
  
### End code changes ###
  
if (safe)
  if (!file.rename(outfile, file)) {
on.exit()
stop(gettextf(image could not be renamed and is left in %s,
  outfile), domain = NA)
  }
on.exit()
   }
  
   setClass(no.save)
   setClass(test.class, slots = c(s1 = externalptr))
   setIs(test.class, no.save)
   reg.obj = regular object
   no.save.obj = new(test.class)
   .image.file = tempfile()
   save.image(.image.file)
   rm(reg.obj, no.save.obj)
   load(.image.file)
   print(ls())
   unlink(.image.file)
   .new.save.image(.image.file)
   rm(reg.obj, no.save.obj)
   load(.image.file)
   print(ls())
   unlink(.image.file)
  
 [[alternative

[Rd] Can a package override the default color palette?

[Tim Keitt]

Is it is possible for a package to override the default color palette
used by image. I've tried a few different ways, but was curious if
there is an approved method.

THK

-- 
Timothy H. Keitt, University of Texas at Austin
Contact info and schedule at http://www.keittlab.org/tkeitt/
Reprints at http://www.keittlab.org/tkeitt/papers/
ODF attachment? See http://www.openoffice.org/

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