Re: [R-pkg-devel] Replicate solaris errors

[Iñaki Úcar]

El sáb., 11 ago. 2018 a las 20:41, Thibault Vatter
() escribió:
>
> Yes, the non-portable call to log which causes the current build to fail on 
> solaris has been corrected in a development version. However, the segfault 
> that we don't understand and were asked to correct was present in the 
> previous versions (e.g., 0.2.8.1.0 and 0.2.7.1.0), and we believe that it is 
> likely to reappear if we resubmit with only the non-portable log call 
> corrected.
>
> This is why, in order to avoid resubmitting with the segfault still there and 
> having the package removed from CRAN, we would like to be able to replicate 
> the solaris build.

I see. About rhub, you could ask Gábor to add udunits2 to that machine
(this is part of the external software installed on CRAN). Or you can
remove that dependency until you find that bug: your package suggests
ggraph, which depends on ggforce, which depends on units, which needs
udunits2.

The last time I dealt with an error with compiled code on Solaris was
on the SPARC machine (now dead; I won't miss it). I managed to recover
an old SPARC server from a forgotten room, install everything and test
it, but I don't remember the installation procedure, sorry. But I'd
rather try rhub before following that path again.

Iñaki

>
> On Sat, Aug 11, 2018 at 2:17 PM Iñaki Úcar  wrote:
>>
>> El sáb., 11 ago. 2018 a las 19:30, Thibault Vatter
>> () escribió:
>> >
>> > Dear package developers,
>> >
>> > We've recently received an email letting us know that our package
>> > rvinecopulib (
>> > https://cran.r-project.org/web/packages/rvinecopulib/index.html) would be
>> > removed from CRAN unless the errors from the solaris build were corrected.
>> >
>> > Note that the package compile and the unit tests pass on the other test
>> > platforms from CRAN and even a local R devel build with ASAN / UBSAN
>> > sanitizers. On solaris, the package compiles but a segfault is produced by
>> > one unit test for a reason that we still don't understand.
>>
>> Are you talking about a new development version that is not still on
>> CRAN? Because the current CRAN version fails to install.
>>
>> Iñaki
>>
>> >
>> > To replicate the issue, I tried to mimic CRAN's solaris config (
>> > https://www.stats.ox.ac.uk/pub/bdr/Rconfig/r-patched-solaris-x86) in a
>> > virtual machine following the steps in the gist below (based on Jeroen's):
>> >
>> > https://gist.github.com/tvatter/b2503f03fcd604ff764ffe4b979afcb6
>> >
>> > Note that the "--with-readline=no" configure option at the end was added
>> > because I got "configure: error: --with-readline=yes (default) and
>> > headers/libs are not available" without it.
>> >
>> > Unfortunately, I then got the "configure: error: a suitable iconv is
>> > essential" and could not proceed to build R.
>> >
>> > I know that I should get GNU iconv as specified in the installation manual,
>> > hence the "/opt/csw/bin/pkgutil -y -i libiconv_dev" in the gist above. I
>> > verified that iconv is in /opt/csw/lib as expected and I thought that
>> > adding /opt/csw/lib to R_LD_LIBRARY_PATH as suggested in the manual would
>> > then do the trick, but it does not seem to be the case.
>> >
>> > Two questions:
>> >
>> > 1) What did I miss or do wrong?
>> >
>> > 2) Anyone found a way to replicate solaris CRAN builds to test packages? I
>> > tried to use https://builder.r-hub.io/, but some of my package's
>> > dependencies fail to install because of udunits2 is missing on their system
>> > if I recall correctly.
>> >
>> > Thibault
>> >
>> > [[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

Re: [R-pkg-devel] Replicate solaris errors

[Iñaki Úcar]

El sáb., 11 ago. 2018 a las 19:30, Thibault Vatter
() escribió:
>
> Dear package developers,
>
> We've recently received an email letting us know that our package
> rvinecopulib (
> https://cran.r-project.org/web/packages/rvinecopulib/index.html) would be
> removed from CRAN unless the errors from the solaris build were corrected.
>
> Note that the package compile and the unit tests pass on the other test
> platforms from CRAN and even a local R devel build with ASAN / UBSAN
> sanitizers. On solaris, the package compiles but a segfault is produced by
> one unit test for a reason that we still don't understand.

Are you talking about a new development version that is not still on
CRAN? Because the current CRAN version fails to install.

Iñaki

>
> To replicate the issue, I tried to mimic CRAN's solaris config (
> https://www.stats.ox.ac.uk/pub/bdr/Rconfig/r-patched-solaris-x86) in a
> virtual machine following the steps in the gist below (based on Jeroen's):
>
> https://gist.github.com/tvatter/b2503f03fcd604ff764ffe4b979afcb6
>
> Note that the "--with-readline=no" configure option at the end was added
> because I got "configure: error: --with-readline=yes (default) and
> headers/libs are not available" without it.
>
> Unfortunately, I then got the "configure: error: a suitable iconv is
> essential" and could not proceed to build R.
>
> I know that I should get GNU iconv as specified in the installation manual,
> hence the "/opt/csw/bin/pkgutil -y -i libiconv_dev" in the gist above. I
> verified that iconv is in /opt/csw/lib as expected and I thought that
> adding /opt/csw/lib to R_LD_LIBRARY_PATH as suggested in the manual would
> then do the trick, but it does not seem to be the case.
>
> Two questions:
>
> 1) What did I miss or do wrong?
>
> 2) Anyone found a way to replicate solaris CRAN builds to test packages? I
> tried to use https://builder.r-hub.io/, but some of my package's
> dependencies fail to install because of udunits2 is missing on their system
> if I recall correctly.
>
> Thibault
>
> [[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

Re: [R-pkg-devel] Building my R package: issue when importing two functions with the same name

[Iñaki Úcar]

El mar., 7 ago. 2018 a las 9:32, Gianmarco Alberti
() escribió:
>
> I am building a R package, and I am facing an issue caused (as far as I 
> understand) by the fact that some functions out of my package rely on two 
> fuctions having the same name and coming from 2 different packages:
>
> pROC::roc
> spatstat::roc
>
> When checking the package via devtools::check(), I get the following warning:
>
> Warning: replacing previous import ‘spatstat::roc’ by ‘pROC::roc’ when 
> loading ‘GmAMisc’
>
> Note that both packages are listed among the Imports in my package's 
> DESCRIPTION file, and that (within my functions) I have actually used 
> spatstat::roc and pROC::roc where needed.

I see:

Depends: R (>= 3.4.0), ggplot2, ggrepel, rgdal, rgeos, raster, sp,
spatstat, maptools, spatialEco, dismo, pROC, kimisc, corrplot,
InPosition, lsr, gridExtra, caTools, plyr, classInt, coin, DescTools,
rWind, shape, rworldmap, cluster, RcmdrMisc, gdistance, Hmisc

In general, it is not a good idea to depend on so many packages,
because what "Depends" do is to load and attach packages. Among other
issues, there is one that you are already experimenting: "roc" is
exported both by "spatstat" and "pROC", so one masks the other.

The solution is to list them under "Imports" instead of "Depends". In
fact, my advice is to put as many packages as possible under
"Imports". Keep in "Depends" only those you would load and attach
anyway when working with your package, because you need all the
functions along with the ones your package exports. For the rest of
them, just use them as package::function to avoid this kind of
problem, and reexport functions selectively if needed.

Iñaki

PS: I'm taking a look at other packages and I see that you always use
"Depends" and never "Imports". My general advice is against this
practice. Moreover, from the "Writing R Extensions" manual:

"Field ‘Depends’ should nowadays be used rarely, only for packages
which are intended to be put on the search path to make their
facilities available to the end user (and not to the package itself):
for example it makes sense that a user of package 'latticeExtra' would
want the functions of package 'lattice' made available."

>
> I have done some web-search but I could not locate any workaround that 
> actually fixes my issue.
>
> Do you have any suggestion on the matter?
>
> **
> Dr Gianmarco Alberti (PhD)
> (currently)
> Research Support Officer II
> Department of Classics and Archaeology
> Faculty of Arts
> University of Malta
>
> (starting from 3rd September 2018)
> Lecturer in Spatial Forensics
> Department of Criminology
> Faculty for Social Wellbeing
> University of Malta
> https://www.researchgate.net/profile/Gianmarco_Alberti4
> http://cainarchaeology.weebly.com/
> **
>
>
> [[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

Re: [R-pkg-devel] Disable a particular knitr vignette

[Iñaki Úcar]

For anyone interested, I finally managed to solve this, following a
suggestion by Baptiste Auguie. TLDR; my yaml header reads as follows:

output: if (packageVersion("rticles") < 0.5 || rmarkdown::pandoc_version() >= 2)
  rticles::jss_article else rmarkdown::html_vignette

This fallback simply ignores the fancy latex commands and produces a
HTML output, which prevents R CMD check from complaining.

Regards,
Iñaki
El jue., 2 ago. 2018 a las 10:04, Iñaki Úcar () escribió:
>
> Hi everyone,
>
> I have a JSS vignette based on the rticles package. It was compiling
> just fine until rticles v0.5 for some reason started requiring pandoc
> v2.x for such a document class, and failing otherwise. Due to this
> requirement, Windows machines on CRAN show a nasty WARN, because they
> still have pandoc v1.x.
>
> It is painful for Uwe to install pandoc v2.x there, so I was wondering
> whether there's any easy mechanism to just disable a particular
> vignette based on some condition (in this case, it would be "we are on
> CRAN, this is Windows and the pandoc version is < 2"; this is easy to
> test).
>
> I tried putting a condition for the output format in the YAML header
> and it works, i.e.:
>
> output: if (cond) rticles::jss_article else rmarkdown::pdf_document
>
> But rmarkdown::pdf_document fails to compile, because the JSS class
> has many custom macros. I tried also putting a NULL or a NA there, and
> it doesn't work.
>
> Does any knitr ninja here know if there's some easy trick to do this
> and make Uwe's life easier? Some "NULL" document format?
>
> Regards,
> Iñaki



--
Iñaki Úcar
http://www.enchufa2.es
@Enchufa2

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

Re: [R-pkg-devel] Disable a particular knitr vignette

[Iñaki Úcar]

El jue., 2 ago. 2018 a las 11:41, Henrik Bengtsson
() escribió:
>
> As a workaround, until resolved, you could precompile your vignette
> into a PDF and then use the 'R.rsp::asis' vignette engine
> (%\VignetteEngine{R.rsp::asis} etc) to include it as a static PDF.
> This is described in the vignettes
> (https://cran.r-project.org/package=R.rsp).
>
> -Henrik

Thanks for the suggestion, Henrik. I would prefer, though, not to
change the behaviour on other platforms and not to rely on another
dependency just for a workaround.

Iñaki

> On Thu, Aug 2, 2018 at 10:04 AM Iñaki Úcar  wrote:
> >
> > Hi everyone,
> >
> > I have a JSS vignette based on the rticles package. It was compiling
> > just fine until rticles v0.5 for some reason started requiring pandoc
> > v2.x for such a document class, and failing otherwise. Due to this
> > requirement, Windows machines on CRAN show a nasty WARN, because they
> > still have pandoc v1.x.
> >
> > It is painful for Uwe to install pandoc v2.x there, so I was wondering
> > whether there's any easy mechanism to just disable a particular
> > vignette based on some condition (in this case, it would be "we are on
> > CRAN, this is Windows and the pandoc version is < 2"; this is easy to
> > test).
> >
> > I tried putting a condition for the output format in the YAML header
> > and it works, i.e.:
> >
> > output: if (cond) rticles::jss_article else rmarkdown::pdf_document
> >
> > But rmarkdown::pdf_document fails to compile, because the JSS class
> > has many custom macros. I tried also putting a NULL or a NA there, and
> > it doesn't work.
> >
> > Does any knitr ninja here know if there's some easy trick to do this
> > and make Uwe's life easier? Some "NULL" document format?
> >
> > Regards,
> > Iñaki
> >
> > __
> > 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

[R-pkg-devel] Disable a particular knitr vignette

[Iñaki Úcar]

Hi everyone,

I have a JSS vignette based on the rticles package. It was compiling
just fine until rticles v0.5 for some reason started requiring pandoc
v2.x for such a document class, and failing otherwise. Due to this
requirement, Windows machines on CRAN show a nasty WARN, because they
still have pandoc v1.x.

It is painful for Uwe to install pandoc v2.x there, so I was wondering
whether there's any easy mechanism to just disable a particular
vignette based on some condition (in this case, it would be "we are on
CRAN, this is Windows and the pandoc version is < 2"; this is easy to
test).

I tried putting a condition for the output format in the YAML header
and it works, i.e.:

output: if (cond) rticles::jss_article else rmarkdown::pdf_document

But rmarkdown::pdf_document fails to compile, because the JSS class
has many custom macros. I tried also putting a NULL or a NA there, and
it doesn't work.

Does any knitr ninja here know if there's some easy trick to do this
and make Uwe's life easier? Some "NULL" document format?

Regards,
Iñaki

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

Re: [R-pkg-devel] can't reproduce cran-pretest error

[Iñaki Úcar]

Hi, a couple of things,:

1) Have you checked the rchk report for possible issues?

https://raw.githubusercontent.com/kalibera/cran-checks/master/rchk/results/epanet2toolkit.out

2) Here there's a call to RENgettimeparam, which passes an empty
character buffer:

https://github.com/bradleyjeck/epanet2toolkit/blob/1e88c805ca294f980fc9133851eb5be8239086b5/R/times.r#L74

but then this function applies a sprintf over this empty buffer (!), here:

https://github.com/bradleyjeck/epanet2toolkit/blob/ef66748de5b357bfe6bbad4b3ba7e5f271baa797/src/Repanet2.c#L81

This more or less matches the error shown in the pre-test, i.e.:

"array over-run in .C("RENgettimeparam") in character argument 2, element 1"

Regards,
Iñaki


El jue., 26 jul. 2018 a las 21:20, Brad Eck () escribió:
>
> Dear list,
>
> I'm having trouble reproducing errors from CRAN's pretests.
>
> I have a package on CRAN called epanet2toolkit that provides R bindings
> to a legacy simulation engine written in C.  So far I've released two
> versions
> to CRAN without trouble.  Now I'm making a third release, principally to
> include
> a citation for the package, but also to clean up warnings raised by new
> compilers.
>
> My latest submission fails the CRAN pretests for Debian with errors in the
> examples and tests:
> https://win-builder.r-project.org/incoming_pretest/
> epanet2toolkit_0.3.0_20180726_102947/Debian/00check.log
>
> For what it's worth, the package checks fine under R-3.4.4, R-3.5.0 and
> R-devel
> r74997 (2018-07-21) and r74923 (2018-06-20).
>
> However, when I run the debian-r-devel checks locally (albeit in Docker) I
> get
> a couple of warnings, but no errors. Since I can't reproduce the error, it's
> difficult to fix. See below the relevant lines of 00check.log:
>
> * using log directory ‘/pkg/epanet2toolkit.Rcheck’
> * using R Under development (unstable) (2018-07-25 r75006)
> * using platform: x86_64-pc-linux-gnu (64-bit)
> * using session charset: UTF-8
> * using option ‘--as-cran’
> * checking for file ‘epanet2toolkit/DESCRIPTION’ ... OK
> * checking extension type ... Package
> ...
> * checking whether package ‘epanet2toolkit’ can be installed ... WARNING
> Found the following significant warnings:
>   text.h:421:9: warning: ‘KwKw  /d’ directive writing
> 30 bytes into a region of size between 23 and 278 [-Wformat-overflow=]
> See ‘/pkg/epanet2toolkit.Rcheck/00install.out’ for details.
> ...
> * checking compilation flags used ... WARNING
> Compilation used the following non-portable flag(s):
>   ‘-Wdate-time’ ‘-Werror=format-security’ ‘-Wformat’
> * checking compiled code ... OK
> * checking examples ... OK
> * checking for unstated dependencies in ‘tests’ ... OK
> * checking tests ... OK
>   Running ‘testthat.r’
> * checking PDF version of manual ... OK
> * DONE
> Status: 2 WARNINGs, 1 NOTE
>
>
> Thanks in advance for any insights.
>
> [[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

Re: [R-pkg-devel] C++11 and deprecated warnings "noise" for auto_ptr

[Iñaki Úcar]

Great! Many thanks for sharing this, Dirk.

Iñaki
El jue., 19 jul. 2018 a las 14:37, Dirk Eddelbuettel
() escribió:
>
>
> As some of you may have noticed, or may have been told as well in kind "fix
> this or else ..." email, 'R CMD check' now also marks g++-7 / g++-8 warnings
> of 'deprecated declarations'.
>
> This can of course be addressed in the code itself, or suppressed with the
> '-Wno-deprecated-declarations' flag in compiler options in eg ~/.R/Makevars.
>
> A particularly annoying case is in all the code depending on Boost headers
> and using eg our BH package. I just installed an updated new package from
> CRAN and again had screens full of warnings for 'deprecated std::auto_ptr'.
>
> Looking at the Boost header file, it turns out that for this case one can use
> the '-DBOOST_NO_AUTO_PTR' define and the compilation will be silent! So those
> of us using Boost and BH could add the define to the headers.
>
> 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



-- 
Iñaki Úcar
http://www.enchufa2.es
@Enchufa2

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

Re: [R-pkg-devel] More on explosive dependencies

[Iñaki Úcar]

El lun., 16 jul. 2018 a las 3:24, Lenth, Russell V
() escribió:
>
> Package developers,
>
> I posted a question a couple of months ago dealing with how to reduce the 
> number of dependencies in a package. Part of the specific issue I face is 
> that I have a `cld` S3 method for which the generic is in the multcomp 
> package, but I don't want to import multcomp because it comes with a number 
> of unneeded dependencies.
>
> My solution at first appeared to be that I could just export my function 
> `cld.emmGrid`; then if users have the multcomp package, this method is 
> available. I also moved multcomp from Imports to Suggests, so that it is no 
> longer a dependency. This fix works just fine for me. It passed the 
> preliminary CRAN checks and it was accepted by CRAN. But then I was advised 
> that the package fails the CRAN checks with Debian because those checks 
> require S3 methods to actually be registered.

Is it *official* that the export() workaround won't work in future R
versions? I'm using this in at least one package and it's not failing
on those platforms.

> So what I tried next is what Duncan Murdoch suggested earlier in this thread 
> -- to register the method conditionally using the following code in my 
> NAMESPACE:
>
> if (requireNamespace("multcomp")) {
> importFrom(multcomp, cld)
> S3method(cld, emmGrid)
> }
>
> This worked fine in my initial testing, both with multcomp installed and with 
> multcomp absent.
>
> However, now the package doesn't pass the checking procedure. The reason 
> apparently is that every package mentioned in import() or importFrom() -- 
> conditionally or not -- must be listed in Imports in the DESCRIPTION file. I 
> could move multcomp back to Imports, but that defeats the whole purpose of 
> getting rid of unneeded dependencies. It's a Catch-22.
>
> Is there any recourse possible? Alas, I'm guessing there isn't, unless we can 
> convince everybody to allow unregistered S3 methods on all platforms. This 
> situation makes it really difficult for package developers to provide methods 
> for other contributors' packages and still keep theirs lightweight. Almost 
> all S3 generics are very simple functions, so being forced to load a dozen or 
> so namespaces just to register a method is crazy. Plus, the more dependencies 
> a package has, the less robust it is to other developers' updates.

There is, actually: *dynamic registration*. It's based on calling
registerS3method when the other package is loaded. This is done by
calling setHook (in this case, on the multcomp "onLoad" event) from
your package's .onLoad function. See the mechanism here:

- Call register_s3_method in .onLoad if requireNamespace returns true
(the package is available):
https://github.com/tidyverse/googledrive/blob/master/R/aaa.R#L45
- The definition of register_s3_method, which calls registerS3method:
https://github.com/tidyverse/googledrive/blob/master/R/dplyr-compat.R#L5

It seems that this mechanism will be added to roxygen2, according to
https://github.com/klutometis/roxygen/issues/623, to avoid copying
this code over from package to package.

Iñaki

> I'm now wondering how much interest there is in developing a separate package 
> just for generics, say, "S3generics". We could all collaborate to contribute 
> our own generics to that one package, move them out of our own packages, and 
> instead import just that package.
>
> Russ
>
> Russell V. Lenth  -  Professor Emeritus
> Department of Statistics and Actuarial Science
> The University of Iowa  -  Iowa City, IA 52242  USA
> Voice (319)335-0712 (Dept. office)  -  FAX (319)335-3017
> __
> 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

Re: [R-pkg-devel] compilation flags WARNING

[Iñaki Úcar]

El jue., 5 jul. 2018 a las 22:23, Göran Broström
() escribió:
>
> Thanks Heather and Iñaki: I understand.
>
> I have an old Makevars file in the src directory of the package.  I
> guess I can set the flags there? Now it only contains
>
> # PKG_CFLAGS = -Wall
> # PKG_FFLAGS = -Wall -fbounds-check
> PKG_LIBS = $(LAPACK_LIBS) $(BLAS_LIBS) $(FLIBS)

IMHO it's better to do it outside the package. The best way, without
changing the system settings, is to place a Makevars under ~/.R/

Iñaki

>
> Göran
>
> On 2018-07-05 17:43, Heather Turner wrote:
> >
> >
> > On Thu, Jul 5, 2018, at 3:39 PM, Iñaki Úcar wrote:
> >> El jue., 5 jul. 2018 a las 16:11, Göran Broström
> >> () escribió:
> >>>
> >>> I am preparing a CRAN release of eha (a trivial change due to a change
> >>> in the survival package), but when checking the build I get:
> >>>
> >>> goran@M6800:~/R$ R CMD check --as-cran eha_2.5.2.tar.gz
> >>> ...
> >>> * checking compilation flags used ... WARNING
> >>> Compilation used the following non-portable flag(s):
> >>> ‘-Wdate-time’ ‘-Werror=format-security’ ‘-Wformat’
> >>> ...
> >>
> >> AFAIK, these are new checks. I get similar warnings on Fedora for
> >> different flags.
> >>
> >>> I have never seen this before and I haven't (to my knowledge) set any
> >>> compilation flags. It is my first build and check on a newly upgraded
> >>> ubuntu 18.04 (no issues on 17.10). Should I perhaps ask on r-sig-debian,
> >>> or is that observation irrelevant?
> >>
> >> Again AFAIK (there are package maintainers for several distros here
> >> that can correct me if I'm wrong), each distro defines some policies
> >> regarding compilation flags that are applied to all packages by
> >> default. So these warnings can be safely ignored locally (or you may
> >> override them), because those flags won't be defined on CRAN.
> >>
> > Yes, by default the compilation flags are those set when R was installed. 
> > You can see the current flags via
> >
> > R CMD config CFLAGS
> >
> > which in your case should include  ‘-Wdate-time’ etc.
> >
> > As Iñaki says you can safely ignore the warning, but if you prefer to not 
> > to have any warnings you can solve this by creating a Makevars.site file 
> > with CFLAGS excluding the non-portable ones, e.g.
> >
> > CFLAGS=-Wall -g O0 -fPIC
> >
> > This should be saved in the /etc directory of R.home(), e.g. /usr/lib/R/etc.
> >
> > See 
> > https://cran.r-project.org/doc/manuals/r-release/R-admin.html#Customizing-package-compilation
> >  for more information.
> >
> > Heather
> >
> >> Iñaki
> >>
> >>>
> >>> Göran Broström
> >>
> >> __
> >> 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
> >
>
> __
> R-package-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel



-- 
Iñaki Úcar
http://www.enchufa2.es
@Enchufa2

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

Re: [R-pkg-devel] Weird error on CRAN linux check

[Iñaki Úcar]

El jue., 5 jul. 2018 21:51, David Hugh-Jones 
escribió:

> That will indeed fail everywhere.  The puzzle is why it fails (only
> sometimes) when the methods are all exported. The GitHub equivalent is tag
> v4.0.1-rc1.
>

Yeap, but the point is that exporting the methods with 'export' should be
superfluous if S3method is used.


> On Thu, 5 Jul 2018 at 20:43, Iñaki Úcar  wrote:
>
>>
>>
>> El jue., 5 jul. 2018 21:35, David Hugh-Jones 
>> escribió:
>>
>>> Installed from CRAN or github? CRAN should be OK - I hope!
>>>
>>
>> From GitHub before the patch.
>>
>>
>>> On Thu, 5 Jul 2018 at 20:33, Iñaki Úcar  wrote:
>>>
>>>> I installed huxtable in two environments, my own Fedora installation
>>>> with R 3.5.0 and all my packages and in a fresh Ubuntu system with R 3.4.4
>>>> and an empty library. In both cases, huxtable is unusable: every example I
>>>> try fails because it doesn't find the methods.
>>>>
>>>> So it has nothing to do with R checks or CRAN scripts, and it seems
>>>> improbable to me that the error comes from a corrupted dependency.
>>>>
>>>> Iñaki
>>>>
>>>>
>>>> El jue., 5 jul. 2018 20:06, Duncan Murdoch 
>>>> escribió:
>>>>
>>>>> On 05/07/2018 9:11 AM, David Hugh-Jones wrote:
>>>>> >
>>>>> > Agreed. I fixed the roxygen2 and it works fine. But yet, the
>>>>> original
>>>>> > v4.0.1 on CRAN has a namespace file which contains
>>>>> >
>>>>> > S3method(bold,huxtable)
>>>>> > export(bold)
>>>>> > export(bold.huxtable)
>>>>> >
>>>>> > and
>>>>> >
>>>>> > S3method("align<-",huxtable)
>>>>> > export("align<-")
>>>>> > export("align<-.huxtable")
>>>>> >
>>>>> > yet still fails on linux-patched and linux-release, with "no
>>>>> applicable
>>>>> > method" errors for align<- and bold. Unfortunately, I don't know how
>>>>> to
>>>>> > reproduce the error on any other platform
>>>>>
>>>>> I just got R installed on an Ubuntu VM, and ran "R CMD check
>>>>> huxtable_4.0.1.tar.gz" both with and without "--as-cran", without
>>>>> seeing
>>>>> the error you quoted.  (I did see other problems, related to not
>>>>> having
>>>>> things like pandoc installed; nothing that looked like a problem with
>>>>> the package rather than a problem with my R installation.)
>>>>>
>>>>> That looks like a bug, but without having a system that can reproduce
>>>>> it, it's hard to narrow down where:
>>>>>
>>>>>   - In R's checks?  Seems unlikely, given it is so system specific.
>>>>>   - In CRAN's scripts?  Really unlikely, since all the tests are in R.
>>>>>   - In huxtable or some package used by huxtable?  Seems possible:
>>>>> maybe memory got corrupted.  Perhaps running under some memory checker
>>>>> would be more informative.
>>>>>
>>>>> Perhaps the CRAN team could be helpful here.
>>>>>
>>>>> >
>>>>> > Anyway, meanwhile, my problem is fixed and I have learned something
>>>>> > about function environments.
>>>>>
>>>>> Given that the error is unrelated to the solution, it really looks
>>>>> like
>>>>> memory corruption somewhere or other.
>>>>>
>>>>> Duncan Murdoch
>>>>>
>>>> --
>>> Sent from Gmail Mobile
>>>
>> --
> Sent from Gmail Mobile
>

[[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] Weird error on CRAN linux check

[Iñaki Úcar]

El jue., 5 jul. 2018 21:35, David Hugh-Jones 
escribió:

> Installed from CRAN or github? CRAN should be OK - I hope!
>

>From GitHub before the patch.


> On Thu, 5 Jul 2018 at 20:33, Iñaki Úcar  wrote:
>
>> I installed huxtable in two environments, my own Fedora installation with
>> R 3.5.0 and all my packages and in a fresh Ubuntu system with R 3.4.4 and
>> an empty library. In both cases, huxtable is unusable: every example I try
>> fails because it doesn't find the methods.
>>
>> So it has nothing to do with R checks or CRAN scripts, and it seems
>> improbable to me that the error comes from a corrupted dependency.
>>
>> Iñaki
>>
>>
>> El jue., 5 jul. 2018 20:06, Duncan Murdoch 
>> escribió:
>>
>>> On 05/07/2018 9:11 AM, David Hugh-Jones wrote:
>>> >
>>> > Agreed. I fixed the roxygen2 and it works fine. But yet, the original
>>> > v4.0.1 on CRAN has a namespace file which contains
>>> >
>>> > S3method(bold,huxtable)
>>> > export(bold)
>>> > export(bold.huxtable)
>>> >
>>> > and
>>> >
>>> > S3method("align<-",huxtable)
>>> > export("align<-")
>>> > export("align<-.huxtable")
>>> >
>>> > yet still fails on linux-patched and linux-release, with "no
>>> applicable
>>> > method" errors for align<- and bold. Unfortunately, I don't know how
>>> to
>>> > reproduce the error on any other platform
>>>
>>> I just got R installed on an Ubuntu VM, and ran "R CMD check
>>> huxtable_4.0.1.tar.gz" both with and without "--as-cran", without seeing
>>> the error you quoted.  (I did see other problems, related to not having
>>> things like pandoc installed; nothing that looked like a problem with
>>> the package rather than a problem with my R installation.)
>>>
>>> That looks like a bug, but without having a system that can reproduce
>>> it, it's hard to narrow down where:
>>>
>>>   - In R's checks?  Seems unlikely, given it is so system specific.
>>>   - In CRAN's scripts?  Really unlikely, since all the tests are in R.
>>>   - In huxtable or some package used by huxtable?  Seems possible:
>>> maybe memory got corrupted.  Perhaps running under some memory checker
>>> would be more informative.
>>>
>>> Perhaps the CRAN team could be helpful here.
>>>
>>> >
>>> > Anyway, meanwhile, my problem is fixed and I have learned something
>>> > about function environments.
>>>
>>> Given that the error is unrelated to the solution, it really looks like
>>> memory corruption somewhere or other.
>>>
>>> Duncan Murdoch
>>>
>> --
> Sent from Gmail Mobile
>

[[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] Weird error on CRAN linux check

[Iñaki Úcar]

I installed huxtable in two environments, my own Fedora installation with R
3.5.0 and all my packages and in a fresh Ubuntu system with R 3.4.4 and an
empty library. In both cases, huxtable is unusable: every example I try
fails because it doesn't find the methods.

So it has nothing to do with R checks or CRAN scripts, and it seems
improbable to me that the error comes from a corrupted dependency.

Iñaki

El jue., 5 jul. 2018 20:06, Duncan Murdoch 
escribió:

> On 05/07/2018 9:11 AM, David Hugh-Jones wrote:
> >
> > Agreed. I fixed the roxygen2 and it works fine. But yet, the original
> > v4.0.1 on CRAN has a namespace file which contains
> >
> > S3method(bold,huxtable)
> > export(bold)
> > export(bold.huxtable)
> >
> > and
> >
> > S3method("align<-",huxtable)
> > export("align<-")
> > export("align<-.huxtable")
> >
> > yet still fails on linux-patched and linux-release, with "no applicable
> > method" errors for align<- and bold. Unfortunately, I don't know how to
> > reproduce the error on any other platform
>
> I just got R installed on an Ubuntu VM, and ran "R CMD check
> huxtable_4.0.1.tar.gz" both with and without "--as-cran", without seeing
> the error you quoted.  (I did see other problems, related to not having
> things like pandoc installed; nothing that looked like a problem with
> the package rather than a problem with my R installation.)
>
> That looks like a bug, but without having a system that can reproduce
> it, it's hard to narrow down where:
>
>   - In R's checks?  Seems unlikely, given it is so system specific.
>   - In CRAN's scripts?  Really unlikely, since all the tests are in R.
>   - In huxtable or some package used by huxtable?  Seems possible:
> maybe memory got corrupted.  Perhaps running under some memory checker
> would be more informative.
>
> Perhaps the CRAN team could be helpful here.
>
> >
> > Anyway, meanwhile, my problem is fixed and I have learned something
> > about function environments.
>
> Given that the error is unrelated to the solution, it really looks like
> memory corruption somewhere or other.
>
> Duncan Murdoch
>

[[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] compilation flags WARNING

[Iñaki Úcar]

El jue., 5 jul. 2018 a las 16:11, Göran Broström
() escribió:
>
> I am preparing a CRAN release of eha (a trivial change due to a change
> in the survival package), but when checking the build I get:
>
> goran@M6800:~/R$ R CMD check --as-cran eha_2.5.2.tar.gz
> ...
> * checking compilation flags used ... WARNING
> Compilation used the following non-portable flag(s):
>‘-Wdate-time’ ‘-Werror=format-security’ ‘-Wformat’
> ...

AFAIK, these are new checks. I get similar warnings on Fedora for
different flags.

> I have never seen this before and I haven't (to my knowledge) set any
> compilation flags. It is my first build and check on a newly upgraded
> ubuntu 18.04 (no issues on 17.10). Should I perhaps ask on r-sig-debian,
> or is that observation irrelevant?

Again AFAIK (there are package maintainers for several distros here
that can correct me if I'm wrong), each distro defines some policies
regarding compilation flags that are applied to all packages by
default. So these warnings can be safely ignored locally (or you may
override them), because those flags won't be defined on CRAN.

Iñaki

>
> Göran Broström

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

Re: [R-pkg-devel] Weird error on CRAN linux check

[Iñaki Úcar]

El mié., 4 jul. 2018 a las 22:47, Duncan Murdoch
() escribió:
>
> On 04/07/2018 4:04 PM, Joris Meys wrote:
> >
> >
> > On Wed, Jul 4, 2018 at 9:31 PM, Duncan Murdoch  > > wrote:
> >
> >
> > That shouldn't matter.  That function was created in a local
> > environment whose parent is 
> > (probably by the huxtable:::make_setter_getters function, but I
> > didn't check).
> >
> > Duncan Murdoch
> >
> > I would think it does matter. Methods are found on the search path, but
> > the environment where the methods are defined is not on the search path.
> > It's a child environment of the namespace, and hence cannot be reached
> > from either the global environment or the namespace if I understood it
> > correctly.
> >
>
> The environment of a function is where it looks for objects, not where
> it is stored.  That method is stored in the huxtable namespace, and
> exported from it.  That's why
> getFromNamespace("align.huxtable","huxtable") (or even
> huxtable::align.huxtable) finds it.
>
> I don't know the source of the original error.

I don't know either. But obviously it has something to do with the
function environment and how UseMethod looks for methods when they are
exported from a namespace (I tested a similar "layout" in the global
environment and the method is correctly found). So maybe this thread
belongs to r-devel instead.

Iñaki

>
> Duncan Murdoch
>

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

Re: [R-pkg-devel] Weird error on CRAN linux check

[Iñaki Úcar]

It seems Joris is right. The following patch seems to solve the issue for me:

diff --git a/R/attributes.R b/R/attributes.R
index e7f4ab9..18ebdab 100644
--- a/R/attributes.R
+++ b/R/attributes.R
@@ -156,6 +156,7 @@ make_getter_setters <- function(attr_name,
attr_type = c('cell', 'row', 'col', '
   ) # end switch

   lapply(names(funs), function (x) {
+environment(funs[[x]]) <- getNamespace('huxtable')
 assign(x, funs[[x]], envir = getNamespace('huxtable'))
   })

Iñaki
El mié., 4 jul. 2018 a las 21:34, Duncan Murdoch
() escribió:
>
> On 04/07/2018 3:23 PM, Joris Meys wrote:
> > I just took a look at your repo, and two remarks:
> >
> > - you use roxygen, and used both @export and @S3method. The latter one is
> > deprecated, so you should use only @export, or @method (see eg Hadley's
> > answer here : https://github.com/klutometis/roxygen/issues/741 )
> >
> > - You're using some code in attributes.R that should generate all the
> > getters and setters automatically, but it looks as if these objects aren't
> > generated in the right order/environment/... to be registered correctly.
> >
> > The part where I get confused, is the following. After installing:
> >
> >> ht <- huxtable(a = 1:3, b = 1:3)
> >> align(ht)
> > Error in UseMethod("align") :
> >no applicable method for 'align' applied to an object of class
> > "c('huxtable', 'data.frame')"
> >> methods(align)
> > [1] align.huxtable*
> > see '?methods' for accessing help and source code
> >> getFromNamespace("align.huxtable","huxtable")
> > function (ht)
> > attr(ht, "align")
> > 
> > 
> >
> > The last line is what bothers me. That should be
> > , like this:
> >
> >> environment(huxtable)
> > 
> >
> > So you generate the functions, they somehow get registered but they get
> > created in the wrong environment as far as I can tell. That's where I would
> > start looking.
> >
>
> That shouldn't matter.  That function was created in a local environment
> whose parent is  (probably by the
> huxtable:::make_setter_getters function, but I didn't check).
>
> Duncan Murdoch
>
>
>
> > CHeers
> > Joris
> >
> >
> > On Wed, Jul 4, 2018 at 8:12 PM, David Hugh-Jones 
> > wrote:
> >
> >> I figured that. Actually I just tried this. I now get the interesting
> >> result that all calls to a generic fail with the UseMethod error...?
> >>
> >> On Wed, 4 Jul 2018 at 16:12, Joris Meys  wrote:
> >>
> >>> On Wed, Jul 4, 2018 at 4:22 PM, Hadley Wickham 
> >>> wrote:
> >>>
> >>>> I don't think it's related to the error, but you shouldn't be exporting
> >>>> this:
> >>>>
> >>>> export("align<-.huxtable")
> >>>>
> >>>> You should generally only export the method.
> >>>>
> >>>
> >>> Hadley means to say that you should generally only export the generic,
> >>> not the individual methods.
> >>> More information here:
> >>>
> >>> https://cran.r-project.org/doc/manuals/R-exts.html#Registering-S3-methods
> >>>
> >>> Cheers
> >>> Joris
> >>> --
> >>> Joris Meys
> >>> Statistical consultant
> >>>
> >>> Department of Data Analysis and Mathematical Modelling
> >>> Ghent University
> >>> Coupure Links 653, B-9000 Gent (Belgium)
> >>>
> >>> <https://maps.google.com/?q=Coupure+links+653,%C2%A0B-9000+Gent,%C2%A0Belgium=gmail=g>
> >>>
> >>> tel: +32 (0)9 264 61 79
> >>> ---
> >>> Biowiskundedagen 2017-2018
> >>> http://www.biowiskundedagen.ugent.be/
> >>>
> >>> ---
> >>> Disclaimer : http://helpdesk.ugent.be/e-maildisclaimer.php
> >>>
> >> --
> >> Sent from Gmail Mobile
> >>
> >
> >
> >
>
> __
> R-package-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel



-- 
Iñaki Úcar
http://www.enchufa2.es
@Enchufa2

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

Re: [R-pkg-devel] Compiled code checks raise a WARNING in Fedora 28

[Iñaki Úcar]

2018-05-23 17:40 GMT+02:00 Dirk Eddelbuettel <e...@debian.org>:
>
> On 23 May 2018 at 17:22, Iñaki Úcar wrote:
> | Hi,
> |
> | For other Fedora users that may be struggling with this too...
> |
> | Fedora 28 introduced new hardening flags for compiled code (see [1]).
> | Particularly, -D_GLIBCXX_ASSERTIONS is added to the default CXXFLAGS
> | (verify the output of 'R CMD config CXXFLAGS'), which enables range
> | checks for C++ arrays, vectors and strings. As a consequence, you may
> | see the following after running 'R CMD check' on your package with C++
> | code:
> |
> | checking compiled code ... WARNING
> | Found ‘abort’, possibly from ‘abort’ (C)
> | Found ‘printf’, possibly from ‘printf’ (C)
> |
> | I'm not sure whether this is a false positive or not. Anyway, a quick
> | workaround is to disable this flag by including -U_GLIBCXX_ASSERTIONS
> | in your local Makevars.
>
> AFAICT that has little do with Fedora, it is just R being picky. Writing R
> Extensions told you about abort() et al for years:
>
>   Under no circumstances should your compiled code ever call @code{abort}
>   or @code{exit}@footnote{or where supported the variants @code{_Exit} and
>   @code{_exit}.}: these terminate the user's @R{} process, quite possibly
>   including all his unsaved work.  One usage that could call @code{abort}
>   is the @code{assert} macro in C or C++ functions, which should never be
>   active in production code.  The normal way to ensure that is to define
>   the macro @code{NDEBUG}, and @command{R CMD INSTALL} does so as part of
>   the compilation flags.  If you wish to use @code{assert} during
>   development. you can include @code{-UNDEBUG} in @code{PKG_CPPFLAGS}.
>   Note that your own @file{src/Makefile} or makefiles in sub-directories
>   may also need to define @code{NDEBUG}.
>
> (Quoted from R-release's manual source)

Yes, I know. The thing is that, with -D_GLIBCXX_ASSERTIONS, I see

$ strings src/*.o | grep abort | sort | uniq
abort
__builtin_abort
__cxa_guard_abort

and without it, the first two lines go away. So it seems that those
assertions may result in a call to 'abort'. I don't know whether R is
right or not in its *pickiness* for this particular case.

Iñaki

>
> Also:
>
> edd@rob:~/deb/r-base$ ag "Found " src/library/tools/R/sotools.R
> 481: c(strwrap(gettextf("Found %s, possibly from %s",
> 702:  strwrap(paste("Found non-API calls to R:",
> 705:  } else paste("  Found non-API call to R:", sQuote(x))
> 716:  strwrap(paste("Found no calls to:",
> 719:  } else paste("  Found no call to:", sQuote(x))
> edd@rob:~/deb/r-base$
>
> I am kinda surprised you had not seen these before :)
>
> 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

[R-pkg-devel] Compiled code checks raise a WARNING in Fedora 28

[Iñaki Úcar]

Hi,

For other Fedora users that may be struggling with this too...

Fedora 28 introduced new hardening flags for compiled code (see [1]).
Particularly, -D_GLIBCXX_ASSERTIONS is added to the default CXXFLAGS
(verify the output of 'R CMD config CXXFLAGS'), which enables range
checks for C++ arrays, vectors and strings. As a consequence, you may
see the following after running 'R CMD check' on your package with C++
code:

checking compiled code ... WARNING
Found ‘abort’, possibly from ‘abort’ (C)
Found ‘printf’, possibly from ‘printf’ (C)

I'm not sure whether this is a false positive or not. Anyway, a quick
workaround is to disable this flag by including -U_GLIBCXX_ASSERTIONS
in your local Makevars.

Regards,
Iñaki

[1] https://fedoraproject.org/wiki/Changes/HardeningFlags28

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

Re: [R-pkg-devel] CRAN pretest archived because of 2 NOTEs

[Iñaki Úcar]

2018-04-18 22:49 GMT+02:00 Gertjan van den Burg :
> Thanks for your comment. Your suggestion wouldn't solve my original problem
> unfortunately, because then I'd have to reverse engineer R's RNG for my
> Python package. Besides, the quality of the random numbers doesn't really
> matter here, it only matters that they're the same across my packages.

You could instead write a vignette instructing the user on how to
replace the default RNG with your SyncRNG. Wouldn't this solve the
problem?

Iñaki

>
> Gertjan
>
> On 04/18/2018 08:00 PM, Dirk Eddelbuettel wrote:
>>
>> On 18 April 2018 at 11:36, Gertjan van den Burg wrote:
>> | While waiting to get this message posted to the list, I've solved the
>> | problem by copying the stdlib rand() and srand() functions into my
>> | package under a different name. This makes the check pass and ensures my
>> | RNG does not interfere with R's RNG.
>>
>> I recommend against that. The check, while dated, is valid because many
>> (old)
>> implementations of rand and srand were of (now known) poor quality.
>>
>> You have R, you should use its RNGs. Your users may expect that. Accessing
>> eg
>> runif is easy and documented, and we can trust the RNG behind it.
>>
>> Dirk
>>
>
> __
> 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

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

[Iñaki Úcar]

2018-03-20 5:12 GMT+01:00 Jennifer Bryan :
> Hi Tim,
>
> Here's a rather long thread from previous discussions of this:
>
> https://stat.ethz.ch/pipermail/r-devel/2014-May/069113.html
>
> These two lines from R CMD check suggest the two ways the vignette code
> will be run:
>
>  * checking running R code from vignettes ... OK
>  * checking re-building of vignette outputs ... OK
>
> Chunk option `purl` controls whether a chunk is extracted and rerun
> during “running R code from vignettes”.
> Chunk option `eval` controls whether a chunk is run during the
> “re-building of vignette outputs”.
>
> Perhaps your benchmarking code is still being extracted and run during
> the purl (a.k.a. "tangle") phase.

The code extracted during the purl phase is commented out for those
chunks with eval=FALSE, so they won't be run in any phase.

Iñaki

>
> -- Jenny
>
>
> On Mon, Mar 19, 2018 at 8:04 PM, Tim Keitt  wrote:
>
>> http://www.keittlab.org/
>>
>> On Mon, Mar 19, 2018 at 6:41 AM, Dirk Eddelbuettel  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
>>
>
> [[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

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

[Iñaki Úcar]

2018-03-20 4:04 GMT+01:00 Tim Keitt :
> http://www.keittlab.org/
>
> On Mon, Mar 19, 2018 at 6:41 AM, Dirk Eddelbuettel  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 see "if (require(pkg))" in that vignette, but not "eval=FALSE".

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

If "eval=FALSE" is set, code chunks are not run. If you just use "if
(require(pkg))", code chunks *are* run on CRAN, because all packages
are available on CRAN. And, as indicated in "Writing R Extensions",

"Packages used to run examples or tests conditionally (e.g. via
if(require(pkgname))) should be listed in ‘Suggests’ or ‘Enhances’."

That could be the source of the issue maybe?

The idea exposed by Dirk is the same: requireNamespace will find the
package on CRAN and will set eval=TRUE. What you want though is to
avoid running a chunk on CRAN, even if the package is available. So
you need to set eval=FALSE *unconditionally*.

Iñaki

>
> 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

__
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

[Iñaki Úcar]

2018-03-19 3:57 GMT+01:00 Tim Keitt :
> http://www.keittlab.org/
>
> On Sun, Mar 18, 2018 at 8:14 PM, Dirk Eddelbuettel  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

Re: [R-pkg-devel] vignette with third party software

[Iñaki Úcar]

2018-02-26 16:16 GMT+01:00 Iñaki Úcar <i.uca...@gmail.com>:
> 2018-02-26 15:03 GMT+01:00 Dominik Leutnant <leutn...@fh-muenster.de>:
>> Dear all,
>>
>> We'd like to submit an update of the "swmmr" package to CRAN, which 
>> interfaces the rainfall runoff model SWMM from the US environmental 
>> protection agency.
>> The package also includes three vignettes which demonstrate how to run the 
>> external model from the R command line.
>> Within the vignettes, the locally installed SWMM model is executed. Of 
>> course, the model is not available on CRAN. My question therefore is:
>>
>> How can we pass the incoming checks although processing the vignettes would 
>> fail?
>
> If the size of the Example1.inp file is reasonable, you may include it
> under the inst directory and retrieve it as follows in your vignettes:
>
> inp_file <- system.file("Example1.inp", package="swmmr")

Let me add a couple more comments about this. In case you can include
the data file, this has the benefit that you can use it in your tests
too (I've seen that you simply skip_on_cran and skip_on_travis). Also,
I've seen that you write files in one vignette. Note that you should
use the tempdir() for that.

>
> Otherwise, you may set knitr::opts_chunk$set(eval=FALSE) in the first
> chunk for each vignette, so that your code is not executed and thus it
> won't fail.
>
>>
>> Thanks in advance!
>> Best,
>> Dominik
>>
>> Dominik Leutnant M.Sc.
>>
>
> Iñaki

Iñaki

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

Re: [R-pkg-devel] vignette with third party software

[Iñaki Úcar]

2018-02-26 15:03 GMT+01:00 Dominik Leutnant :
> Dear all,
>
> We'd like to submit an update of the "swmmr" package to CRAN, which 
> interfaces the rainfall runoff model SWMM from the US environmental 
> protection agency.
> The package also includes three vignettes which demonstrate how to run the 
> external model from the R command line.
> Within the vignettes, the locally installed SWMM model is executed. Of 
> course, the model is not available on CRAN. My question therefore is:
>
> How can we pass the incoming checks although processing the vignettes would 
> fail?

If the size of the Example1.inp file is reasonable, you may include it
under the inst directory and retrieve it as follows in your vignettes:

inp_file <- system.file("Example1.inp", package="swmmr")

Otherwise, you may set knitr::opts_chunk$set(eval=FALSE) in the first
chunk for each vignette, so that your code is not executed and thus it
won't fail.

>
> Thanks in advance!
> Best,
> Dominik
>
> Dominik Leutnant M.Sc.
>

Iñaki

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

Re: [R-pkg-devel] author field in description problem

[Iñaki Úcar]

2018-02-25 23:49 GMT+01:00 William Revelle :
> Hi,
>
> I am trying to take advantage of the Authors@R: field in my description file 
> for the psych package to add an ORCID address (as discussed in the R journal).
>
> When I R CMD check with R development on my Mac, or with win builder it 
> passes all checks. (R Under development (unstable) (2018-02-23 r74298)  )
>
> But, when I test with current R on a Mac or at win builder it throws a note:
>
> Author field differs from that derived from Authors@R
>   Author:'William Revelle [aut, cre] 
> ()'
>   Authors@R: 'William Revelle [aut, cre] (-0003-4880-9610)’
>
>
> Is there a way to fix this or should I just go ahead and submit to CRAN with 
> a note saying that it works on R development but gives a note on R 3.4.3 ?
>
> The offending line in the Description file seems to be
>
> Authors@R:  person("William", "Revelle", role =c("aut","cre"), 
> email="reve...@northwestern.edu", comment=c(ORCID  = "-0003-4880-9610") )
>
> Thanks for any suggestions.

You can use ‘Authors@R’ only to fix this NOTE. According to "Writing R
Extensions":

"Both ‘Author’ and ‘Maintainer’ fields can be omitted if a suitable
‘Authors@R’ field is given. [...] The ‘Author’ and ‘Maintainer’ fields
are auto-generated from it if needed when building or installing."

Iñaki

>
> Bill
>
>

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

Re: [R-pkg-devel] [Rd] How to address the following: CRAN packages not using Suggests conditionally

[Iñaki Úcar]

Re-sending, since I forgot to include the list, sorry. I'm including
r-package-devel too this time, as it seems more appropriate for this list.


El 22 ene. 2018 10:11, "Iñaki Úcar" <i.uca...@gmail.com> escribió:

>
>
> El 22 ene. 2018 8:12, "Ulrich Bodenhofer" <bodenho...@bioinf.jku.at>
> escribió:
>
> Dear colleagues, dear members of the R Core Team,
>
> This was an issue raised by Prof. Brian Ripley and sent privately to all
> developers of CRAN packages that suggest Bioconductor packages (see
> original message below). As mentioned in my message enclosed below, it was
> easy for me to fix the error in examples (new version not submitted to CRAN
> yet), but it might turn into a major effort for the warnings raised by the
> package vignette. Since I have not gotten any advice yet, I take the
> liberty to post it here on this list - hoping that we reach a conclusion
> here how to deal with this matter.
>
>
> Just disable code chunk evaluation if suggested packages are missing (see
> [1]). As explained by Prof. Ripley, it will only affect Fedora checks on
> r-devel, i.e., your users will still see fully evaluated vignettes on CRAN.
>
> [1] https://www.enchufa2.es/archives/suggests-and-vignettes.html
>
> Iñaki
>
>
> Thanks in advance for your kind assistance,
> Ulrich Bodenhofer
>
>
>
>  Forwarded Message 
> Subject:Re: CRAN packages not using Suggests conditionally
> Date:   Mon, 15 Jan 2018 08:44:40 +0100
> From:   Ulrich Bodenhofer <bodenho...@bioinf.jku.at>
> To: Prof Brian Ripley <rip...@stats.ox.ac.uk>
> CC: [...stripped for the sake of privacy ...]
>
>
>
> Dear Prof. Ripley,
>
> Thank you very much for bringing this important issue to my attention. I
> am the maintainer of the 'apcluster' package. My package refers to
> 'Biostrings' in an example section of a help page (a quite insignificant
> one, by the way), which creates errors on some platforms. It also refers
> to 'kebabs' in the package vignette, which leads to warnings.
>
> I could fix the first, more severe, problem quite easily, (1) since it
> is relatively easy to wrap an entire examples section in a conditional,
> and (2), as I have mentioned, it is not a particularly important help page.
>
> Regarding the vignette, I want to ask for your advice now, since the
> situation appears more complicated to me. While it is, of course, only
> one code chunk that loads the 'kebabs' package, five more code chunks
> depend on the package (more specifically, the data objects created by a
> method implemented in the package) - with quite some text in between. So
> the handling of the conditional loading of the package would propagate
> to multiple code chunks and also affect the validity of the explanations
> in between. I would see the following options:
>
> 1. Remove the entire section of the vignette. That would be a pity,
> since I can no longer point the users to an otherwise interesting
> application of my package.
> 2. Replace the code chunks by static LaTeX code such that it appears in
> the PDF as if there were code chunks that had been run. This sort of
> undermines the philosophy of vignettes and also creates extra effort for
> me to maintain the vignette.
> 3. Use the functionality of 'kernlab' instead of 'kebabs' if the latter
> is not available. This would be technically possible, but (1) the code
> in the vignette will look much more complicated to the user and (2)
> 'kernlab' does not implement the necessary functionality fully correctly
> and also has much longer run times. Needless to say, the issue with
> conditional loading will then simply propagate to 'kernlab'.
>
> Which of the three solutions would you prefer? Do you see any fourth
> alternative? Or would you tolerate the warnings on some platforms
> arising from the non-availability of packages suggested by the package
> vignette?
>
> Thanks for your time and best regards,
> Ulrich Bodenhofer
>
> P.S.: @all: I hope it is acceptable that I replied to all. I thought the
> discussion would be interesting for some of you having similar issues.
>
>
>
> On 01/14/2018 09:20 AM, Prof Brian Ripley wrote:
>
>> as required by §1.1.3.1 of the manual.
>>
>> The Bioconductor branch used by R-devel has been very unstable recently,
>> and it has been decided not to use it for the Fedora checks on R-devel. As
>> you can see from the CRAN results pages (at least at the time of writing),
>> packages
>>
>> ACMEeqtl BoSSA CNVassoc CorShrink GRANBase GenCAT GiANT NMF PlackettLuce
>> ProFit ProFound RNAseqNet SIBERG antaresRead apcluster cherry clValid coloc
>> colorhcplot entropart filematrix fuzzyfo

Re: [R-pkg-devel] Debian: example file is no longer read correctly

[Iñaki Úcar]

2017-12-20 11:11 GMT+01:00 Blume Christine :
> Dear all,
>
> I guess I need your help again. With debian my package (nparACT) gives an 
> error message that seems to be related to loading the data:
>
>  Warning in is.na(data$activity) :
>  is.na() applied to non-(list or vector) of type 'NULL'
> Error in 1:a : argument of length 0
>
> Although I have set up a virtual machine to test the package using the R 
> devel version with Linux (Debian), it gives me a hard time to find out what 
> is wrong since I do not manage to install packages using the devel version...
>
> Does anyone know what has changed so this text file is not read in any 
> longer? The code for reading in the text file is:
>
> data <- read.table(paste(path,name, sep="/"), header = F)
> if (is.data.frame(data)==F){
>   data = as.data.frame(data)
> }
> if(ncol(data) == 2){
>   data[,1] <- as.POSIXct(data[,1])
>   data[,2] <- as.numeric(as.character(data[,2]))
>   names(data)[1] <- "time"
>   names(data)[2] <- "activity"
>}
> if(ncol(data) == 3){
>   names(data)[1] <- "date"
>   names(data)[2] <- "time"
>   names(data)[3] <- "activity"
>   data$date <- NULL
>   data$time <- as.POSIXct(data$time, format="%H:%M:%S")
>   data$activity <- as.numeric(as.character(data$activity))
> }
>
> Or can someone tell me how to install the package using R devel on Linux?

You can try on rhub: https://github.com/r-hub/rhub

Iñaki

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

Re: [R-pkg-devel] nparACT package: "working directory was changed to...resetting"

[Iñaki Úcar]

2017-12-19 16:27 GMT+01:00 Blume Christine :
> Hi Duncan,
>
> Thanks a lot! Good to see that you had a similar idea, I did just that...in 
> my example it looks like this, however, that does not help, i.e. that is the 
> code that is associated with the warning…
>
> data(sleepstudy)
>
> wd <- getwd()
>
> name <- "sleepstudy_example"
>
> newdir <- paste(wd,name, sep="/")
>
> if (dir.exists(newdir)){
>
> setwd(newdir)
>
> write.table(sleepstudy, file = "sleepstudy.txt", row.names=FALSE, col.names = 
> FALSE)
>
> r <- nparACT_flex_loop(newdir, SR = 4/60, minutes = 435)
>
> } else {
>
> dir.create(newdir)
>
> setwd(newdir)
>
> write.table(sleepstudy, file = "sleepstudy.txt", row.names=FALSE, col.names = 
> FALSE)
>
> r <- nparACT_flex_loop(newdir, SR = 4/60, minutes = 435)
>
> }
>
> setwd(wd)
>
> }

I see:

$ wget https://cran.r-project.org/src/contrib/nparACT_0.7.tar.gz
$ tar xf nparACT_0.7.tar.gz
$ grep -r setwd nparACT
nparACT/man/nparACT_flex_loop.Rd:setwd(newdir)
nparACT/man/nparACT_base_loop.Rd:setwd(newdir)

so two examples don't restore the wd as Duncan was pointing out.

Iñaki

>
>
>
> Best,
>
> Christine
>
>

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

[R-pkg-devel] CRAN check FAIL due to pragmas in headers and code

[Iñaki Úcar]

Hi all,

Three days ago, Patrick Perry posted the following on R-devel:

2017-12-11 16:32 GMT+01:00 Patrick Perry :
> A recent change to r-devel causes an R CMD check warning when a C file
> includes a "#pragma GCC diagnostic ignored" pragma:
> https://github.com/wch/r-source/commit/b76c8fd355a0f5b23d42aaf44a879cac0fc31fa4
> . This causes the CRAN checks for the "corpus" package to emit a warning:
> https://www.r-project.org/nosvn/R.check/r-devel-linux-x86_64-fedora-clang/corpus-00check.html

I didn't pay much attention, but today I received a couple of emails
warning about my package failing on r-devel-linux-x86_64-debian (gcc
and clang) with the following message:

Check: pragmas in C/C++ headers and code
Result: FAIL

My package has no pragmas, but Rcpp, on which it depends, does. So
basically Rcpp and all packages depending on Rcpp are failing on that
flavors. Is this a new requirement for new submissions? Or should I
ignore these FAILs?

Regards,
Iñaki

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

Re: [R-pkg-devel] creating indelible file during unit test

[Iñaki Úcar]

2017-12-12 15:47 GMT+01:00 Barry Rowlingson :
> I think unix makes it impossible for you to create something that even you
> can't delete. You may need higher powers ("root") to change the ownership
> of the thing you've created.

In a Unix system with administrator rights, you can set the immutable flag:

$ touch foo
$ chmod a-w foo
$ sudo chattr +i foo
$ rm foo
Operation not permitted

Otherwise, you can always remove your own files. Moreover, Thierry may
want the test to be cross-platform... So I think the easiest way to go
is to bypass the R function used to remove the files (file.remove,
unlink, whatever), run the test and then restore it.

Iñaki

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

Re: [R-pkg-devel] (no subject)

[Iñaki Úcar]

2017-12-05 18:38 GMT+01:00 Uwe Ligges <lig...@statistik.tu-dortmund.de>:
>
>
> On 05.12.2017 18:35, Iñaki Úcar wrote:
>>
>> 2017-12-05 10:04 GMT+01:00 Jose Manuel Vera <vera.joseman...@gmail.com>:
>>>
>>> Hi all
>>>
>>> Submitted my package to CRAN but I got some notes I cannot understand.
>>>
>>> First NOTE is regarding possibly mis-spelled words in DESCRIPTION. Taken
>>> into account that these are not mispelled words (catastro is a spanish
>>> word
>>> for "Property registry office") I leave it for now.
>>>
>>>catastro (18:64)
>>>kml (18:39)
>>>spanish (12:70, 17:37)
>>
>>
>> You can ignore this if they are false positives. However, you may
>> consider using \emph{catastro},
>
>
>
> No, not in Title nor Description fields.

Correct, I was thinking about Rd files. Sorry, I skimmed through and
didn't read DESCRIPTION, despite being quite big.

Iñaki

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

Re: [R-pkg-devel] (no subject)

[Iñaki Úcar]

2017-12-05 10:04 GMT+01:00 Jose Manuel Vera :
> Hi all
>
> Submitted my package to CRAN but I got some notes I cannot understand.
>
> First NOTE is regarding possibly mis-spelled words in DESCRIPTION. Taken
> into account that these are not mispelled words (catastro is a spanish word
> for "Property registry office") I leave it for now.
>
>   catastro (18:64)
>   kml (18:39)
>   spanish (12:70, 17:37)

You can ignore this if they are false positives. However, you may
consider using \emph{catastro}, with italics, given that it's a
Spanish word. Also "spanish" should be "Spanish", and I suppose "kml"
is KML, the markup language.

> The rest of notes are the ones I cannot understand. All tests are ok.
> Examples are running Ok. Tests raised no error, all seems ok but i get
> this:
>
>
> ** running examples for arch 'i386' ... [36s] NOTE
> Examples with CPU or elapsed time > 10s
>  user system elapsed
> cadastral_references 0.58   0.16   17.75
> geocode_cadastral0.11   0.00   16.61
>
> ** running examples for arch 'x64' ... [37s] NOTE
> Examples with CPU or elapsed time > 10s
>  user system elapsed
> cadastral_references 0.69   0.15   17.24
> geocode_cadastral0.13   0.03   17.73

This means that your examples are taking too much time to run. You
should explain this in your submission, or you may consider
simplifying your examples a little bit to get shorter run times. Also
you may use \dontrun{} to avoid running a specially heavy example.

Iñaki

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

Re: [R-pkg-devel] adding rPython as a suggested package

[Iñaki Úcar]

2017-12-01 7:50 GMT+01:00 Slava Lyubchich :
> Hello,
>
> I have a package on CRAN (funtimes) and I am trying to add a function
> that uses some Python code (only one function in the package needs
> Python, others do not). In order to do that, I
> 1) add in the DESCRIPTION
> Suggests: rPython
> 2) in the R function, use
> rPython::python.load("CRAD.py")
> 3) put CRAD.py  in the top folder of the package (together with
> DESCRIPTION and NAMESPACE).
>
> The automatic CRAN check returns it with notes:
> -- Package suggested but not available for checking: 'rPython'

rPython is not available for Windows. You can see "OS_type: unix" in
its DESCRIPTION. If you want to support Windows systems, take a look
at the reticulate package, which is another R interface to Python.

> -- Non-standard file/directory found at top level:   'CRAD.py'

Create an inst/ directory and put it there, as suggested in "1.1.7
Non-R scripts in packages" in the "Writing R Extensions" manual.

Iñaki

>
> Could you recommend how to fix that? Where should I move to the
> additional file with code?
> https://cran.r-project.org/package=rPython
> 
>
> Best regards,
> Slava
>
> --
> V. Lyubchich
> Research Assistant Professor
> Chesapeake Biological Laboratory
> University of Maryland Center for Environmental Science
>
>
> [[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

Re: [R-pkg-devel] Package valgrind problem I can't solve: Direction?

[Iñaki Úcar]

2017-11-06 0:09 GMT+01:00 Peter Dunn :
> Impossible or not… it just happened (unless I am being really stupid, which
> is entirely possible, indeed probable). I confirmed again this morning:
> After rebuilding (R CMD build) and checking (R CMD check) without any
> errors, I used rhub and the command line again:
>
>
> Running valgrind at the command line, I get this error:
>
> ==5097== Conditional jump or move depends on uninitialised value(s)
> ==5097== at 0x1118F61FB: smallp_ (in
> /Users/pdunn2/Library/R/3.4/library/tweedie/libs/tweedie.so)

What I meant is that, if you run the script in tweedie.Rcheck from the
command line, Rscript uses your *installed* version of tweedie, not
the tarball you built with R CMD build. So if you didn't run R CMD
INSTALL, Rscript is running an old version without any fix, hence the
disagreement with R CMD check.

Iñaki

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

Re: [R-pkg-devel] Package valgrind problem I can't solve: Direction?

[Iñaki Úcar]

2017-11-03 6:01 GMT+01:00 Peter Dunn :
> Iñaki and all
>
> Well, thanks for pointers to rhub. Wonderful. Moving things to github, but
> have to go home now…
>
> So, when I download CRAN code, initialise w and lambda (which workled for
> Iñaki), and run
>
> rhub::check_with_valgrind()
>
> on the code, I get no errors
> (https://builder.r-hub.io/status/tweedie_2.2.5.tar.gz-c8873979fcf84b4f8a0a4d5a47175f63).
>
>
> But running
>
> R -d "valgrind --tool=memcheck --leak-check=full --track-origins=yes"
> --vanilla < tweedie-Ex.R
>
> from the command line *still* gives me errors about “Conditional jump or
> move depends on uninitialised value(s)” in the subroutine smallp”.

That's impossible. Did you rebuild and reinstall the package after
making those changes?

Iñaki

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

Re: [R-pkg-devel] Package valgrind problem I can't solve: Direction?

[Iñaki Úcar]

2017-11-01 5:56 GMT+01:00 Peter Dunn :
> Wow: Thanks again. You are going above and beyond Iñaki which I appreciate
> greatly.
>
> But same error message appears, even after fixing (both the relerr, which I
> had already attended to, and the lambda issue).

All I can say is that initialising both lambda and w (from CRAN
version) solved the issue for me. As a matter of fact, I did see
another message about uninitialised values, but the back trace was
empty (no function names, I mean), which means that the problem is
somewhere else.

> I have since initialised *every* variable in the subroutine smallp (even the
> *input* variables to some arbitrary value to try to work out what is causing
> the issue) yet the error persists. There surely cannot be any uninitialized
> variables now *every* var in the subroutine is explicitly initialised.
>
> That tells me that there is nothing I can do to remove the error. If
> everything is initialised…
>
> Frustrated… And wasting so much time!

If you set up a public repo (GitHub or similar) where everyone can see
your current code base and changes made, it would be easier to help.
It would be even easier if you check your changes using a public build
system and share the results here. I don't know whether win-builder
uses valgrind, but you can use r-hub (https://github.com/r-hub/rhub)
by Gábor Csárdi. There is a function rhub::check_with_valgrind which
requires no further explanation.

Iñaki

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

Re: [R-pkg-devel] Package valgrind problem I can't solve: Direction?

[Iñaki Úcar]

2017-10-30 0:54 GMT+01:00 Peter Dunn :
> Thanks for this direction.
>
> But I am still confused, as the problem persists after attending to any
> possible issue: That piece of identified code only has four variables, and I
> can account for them all.
>
> The two variables its and aimrerr are now explicitly initialised. So they
> cannot be the problem.
>
> The variables maxit and relerr are inputs to the subroutine... and both are
> explicitly initialised in the only subroutine which calls smallp. So I can’t
> see how that can be a problem. (Clearly they cannot be initialised in the
> subroutine smallp or their input values are overwritten.)

Found it. "relerr" may be uninitialised because "w" is uninitialised
in smallp (tweedie 2.2.5, line 2169).

When you try to debug this kind of things, you must track not only
explicit initialisations, but also all the assignments with possibly
uninitialised variables.

BTW, I also see:

tweedie.f:335:0:

 if ( funvalue .LT. exp(-lambda) ) then

Warning: 'lambda' may be used uninitialized in this function
[-Wmaybe-uninitialized]

Regards,
Iñaki

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

Re: [R-pkg-devel] Package valgrind problem I can't solve: Direction?

[Iñaki Úcar]

2017-10-30 0:54 GMT+01:00 Peter Dunn :
> Thanks for this direction.
>
> But I am still confused, as the problem persists after attending to any
> possible issue: That piece of identified code only has four variables, and I
> can account for them all.
>
> The two variables its and aimrerr are now explicitly initialised. So they
> cannot be the problem.
>
> The variables maxit and relerr are inputs to the subroutine... and both are
> explicitly initialised in the only subroutine which calls smallp. So I can’t
> see how that can be a problem. (Clearly they cannot be initialised in the
> subroutine smallp or their input values are overwritten.)

Maybe the location is wrong. What about the "result" variable in the
"smallp" subroutine? Shouldn't it be initialised?

> Any more idea for where I should be looking, or how I can progress this?
> Using the flags below when gfortran is called, with -O0 –g included,
> produced no errors or warnings at all.

Given that the issue disappears depending on the optimisation level,
maybe it is a false error.

Iñaki

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

Re: [R-pkg-devel] Package valgrind problem I can't solve: Direction?

[Iñaki Úcar]

Hi,

2017-10-26 5:16 GMT+02:00 Peter Dunn :
> Hi all
>
> I am trying to compile (on my Mac) an R package (tweedie) which includes 
> Fortran 77 code. I’m not much of a programmer, but can still manage to write 
> and update F77 code. I’m new to valgrind.
>
> In checking my package (which passes the build-and-check with no errors), I 
> use valgrind like this:
>
> R -d "valgrind  --tool=memcheck --leak-check=full --track-origins=yes" 
> --vanilla  < tweedie-Ex.R
>
>
> …on my package example, which gives me a series of messages like this:
>
> ==53843== Conditional jump or move depends on uninitialised value(s)
> ==53843==at 0x1118F61FB: smallp_ (in 
> /Users/pdunn2/Library/R/3.4/library/tweedie/libs/tweedie.so)
> ==53843==by 0xBFA4FB88FFEB: ???
> ==53843==by 0x3FF91CB2DA3A50E7: ???
> ==53843==by 0x104888757: ???
> ==53843==by 0xFFEC03E375AF: ???
> ==53843==by 0x3FE18C2EE1BE47CB: ???
> ==53843==by 0x104885DEF: ???
> ==53843==by 0x104885DF7: ???
> ==53843==by 0x3FE518F314C67BE7: ???
> ==53843==by 0x11364CEAF: ???
> ==53843==by 0x104885DBF: ???
> ==53843==by 0x10007: ??? (in 
> /Library/Frameworks/R.framework/Resources/bin/exec/R)
> ==53843==  Uninitialised value was created by a stack allocation
> ==53843==at 0x1118F59A6: smallp_ (in 
> /Users/pdunn2/Library/R/3.4/library/tweedie/libs/tweedie.so)

CRAN shows a complete backtrace:
https://www.stats.ox.ac.uk/pub/bdr/memtests/valgrind/tweedie/tweedie-Ex.Rout

According to it, the offending conditional jump seems to be this one:

 if ( ( its .LT. 3 )
 & .OR.
 &( ( its .LT. maxit ) .AND.
 &  ( abs(relerr) .GT. aimrerr )
 &)
 &  ) then

> I can see the piece of R code in the example from which this comes.  The 
> subroutine  smallp  is mentioned in the second line of the output.
>
> I simply cannot find the issue.  (Spent days looking so far.)  There are only 
> a few conditional jumps, and everything not passed to the subroutine  smallp  
> is initialised. I have checked the calls to  smallp  as well. I have compiled 
> the fortran code separately (after wrapping into a complete program), with 
> all kinds of flags:
>
> gfortran -O2 -fimplicit-none  -Wall  -Wline-truncation  
> -Wcharacter-truncation  -Wsurprising  -Waliasing  -Wunused-parameter  
> -fwhole-file  -fcheck=all  -std=f2008  -pedantic  -fbacktrace),

Did you try "-O0 -g" instead of "-O2"?

Regards,
Iñaki

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

Re: [R-pkg-devel] Where do demos fit in?

[Iñaki Úcar]

2017-10-20 5:42 GMT+02:00 Neal Fultz :
> A graduate student just asked me (copied below), in response to a bug I
> wrote (
> https://github.com/DeclareDesign/estimatr/pull/38/commits/99e82e253979d1307714632e9dc05d2e2c9c66df
> ):
>
> How do demos normally relate to tests and vignettes? Is the purpose simply
>> to have manually run tests that check the things work in the global
>> environment?

There is a good definition and description here:
http://r-pkgs.had.co.nz/misc.html

Personally, I'm not a fan of demos, because I prefer to copy
from vignettes as I read and understand the different parts of the
problem in question.

Iñaki

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

Re: [R-pkg-devel] r-quantities seeking feedback

[Iñaki Úcar]

2017-10-06 22:28 GMT+02:00 David Hugh-Jones :
> Many measurements have no unit, but some uncertainty - e.g. the b and se
> from an arbitrary regression. Can you give specific examples of the
> advantages from binding these packages tightly together?

As Duncan already pointed out, the units of b and se from an arbitrary
regression depend on the units of your variables. The advantages from
integrating both packages are the combination of advantages from each
one with the same workflow as if you were working with bare numbers.

It seems that you are already aware of the advantages of automatic
error propagation. Regarding the units package, it is very useful for
painless conversion of units. A conversion from kg to g is elementary,
but some others require more care, for example J to eV, or N.m-1 to
dyn.cm-1. In electromagnetism, it is very common to work with the CGS
units system, and an automatic conversion from/to the SI comes in
handy.

If you are not persuaded already, we can also talk about the Mars
Climate Orbiter, a robotic space probe launched by NASA on 1998 which
disintegrated in Mars' upper atmosphere due to a computation with
wrong units.

Iñaki

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

Re: [R-pkg-devel] r-quantities seeking feedback

[Iñaki Úcar]

El 6 oct. 2017 19:13, "David Hugh-Jones" <davidhughjo...@gmail.com>
escribió:

One question that comes to mind: what's the synergy? I e why are units and
errors best handled together? I use standard errors a lot, but never
units... I would like a standard way to represent uncertainty but don't
think I need the other stuff.


You will always be able to use errors (or units) alone if you wish, but
every measurement has a unit and some uncertainty, so we think it's
interesting to have the possibility of handling them in a unified way (I/O,
propagation, automatic axes and error bars in plots...).

Iñaki

Cheers,
D

On Fri, 6 Oct 2017 at 17:25, Iñaki Úcar <i.uca...@gmail.com> wrote:

> Dear all,
>
> Edzer Pebesma and I are combining forces into a new GitHub
> organisation called "r-quantities", to which we have moved the CRAN
> packages 'units', 'errors' and 'constants'. The idea is to write a new
> package called 'quantities' to integrate 'units' and 'errors' into a
> comprehensive solution for dealing with quantity values + uncertainty
> calculus.
>
> Given that a significant fraction of R users, both practitioners and
> researchers, use R to analyse measurements, we believe that the R
> community would benefit from such a project. Moreover, to the best of
> our knowledge, there exists no such an integrated and automated
> framework outside the R language.
>
> We would like to share a proposal [1] to be submitted to the R
> Consortium before October 15. Until then, we kindly invite the R
> package developers to review it. Any feedback or contribution would be
> very helpful.
>
> [1] https://github.com/r-quantities/proposal
>
> Regards,
> Iñaki
>
> __
> R-package-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel

-- 
Sent from Gmail Mobile

[[alternative HTML version deleted]]

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

[R-pkg-devel] r-quantities seeking feedback

[Iñaki Úcar]

Dear all,

Edzer Pebesma and I are combining forces into a new GitHub
organisation called "r-quantities", to which we have moved the CRAN
packages 'units', 'errors' and 'constants'. The idea is to write a new
package called 'quantities' to integrate 'units' and 'errors' into a
comprehensive solution for dealing with quantity values + uncertainty
calculus.

Given that a significant fraction of R users, both practitioners and
researchers, use R to analyse measurements, we believe that the R
community would benefit from such a project. Moreover, to the best of
our knowledge, there exists no such an integrated and automated
framework outside the R language.

We would like to share a proposal [1] to be submitted to the R
Consortium before October 15. Until then, we kindly invite the R
package developers to review it. Any feedback or contribution would be
very helpful.

[1] https://github.com/r-quantities/proposal

Regards,
Iñaki

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

Re: [R-pkg-devel] tibbles are not data frames

[Iñaki Úcar]

2017-09-26 13:41 GMT+02:00 Holger Hoefling :
> Hi Thierry,
>
> You write:
>
> "If a package requires a data.frame, then it is up to the _user_ to
> provide a data.frame (and a tibble is not a data.frame). "
>
> Actually, as pointed out before, calling
>
> is.data.frame
>
> on a tibble returns TRUE. So I think that R says - yes, a tibble is a data
> frame. What would be the point of having a "is.data.frame" function, if you
> can't trust its answer?

is.data.frame is just a wrapper for inherits(x, "data.frame"). As
Daniel pointed out before, inherits(x, "data.frame", TRUE) == 1
returns TRUE for data frames and FALSE for tibbles.

Iñaki

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

Re: [R-pkg-devel] Directing package feedback to Github issues

[Iñaki Úcar]

Hi,

2017-08-23 1:37 GMT+02:00 Bruce Hoff :
> The official instructions for writing an R package (https://cran.r-project.
> org/doc/manuals/r-release/R-exts.html) states, in part,
>
> "The mandatory ‘Maintainer’ field should give a *single* name followed by a
> *valid* (RFC 2822) email address in angle brackets For a CRAN package
> it should be a *person*, not a mailing list and not a corporate entity: do
> ensure that it is valid and will remain valid for the lifetime of the
> package."
>
>
> It seems like user feedback for a package (e.g. bug reports and feature
> requests) to the maintainer would best be provided in terms of issues
> opened in an issue tracking system rather than an email sent to a "person,
> not a mailing list".  A prominent example is Github issue tracking, where
> the Github repository for the issues could be the same issue.
>
> Is there an accepted approach among R package authors to direct users of a
> package to an issue tracking system?

See 8 paragraphs ahead of that quote:

"The ‘BugReports’ field may contain a single URL to which bug reports
about the package should be submitted. This URL will be used by
bug.report instead of sending an email to the maintainer."

Iñaki

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

Re: [R-pkg-devel] Question on Notes for Package Submission

[Iñaki Úcar]

Hi,

The messages are quite clear:

2017-08-17 10:14 GMT+02:00 Chu-Lan Kao :
> Dear Sir,
>
> We've just uploaded a package with two notes that we couldn't figure out
> how to deal with it. They are:
>
> 1) * checking R code for possible problems ... NOTE
>
> est.changepoints: no visible global function definition for
>   'prior_normal_A'
> est.changepoints: no visible binding for global variable 'data.X'
> est.changepoints: no visible global function definition for
>   'prior_pois'
> Undefined global functions or variables:
>   data.X prior_normal_A prior_pois

These are checks for undefined functions and variables. Sometimes,
non-standard evaluation causes this kind of message, but without a
link to the source code, it's impossible for me to assess the problem.
There are dozens of excellent posts about this topic though, so I
shall not elaborate on it any further.

For instance: https://stackoverflow.com/q/9439256/6788081

> 2) * checking compiled code ... NOTE
>
> File 'StepSignalMargiLike/libs/i386/StepSignalMargiLike.dll':
>   Found no calls to: 'R_registerRoutines', 'R_useDynamicSymbols'
> File 'StepSignalMargiLike/libs/x64/StepSignalMargiLike.dll':
>   Found no calls to: 'R_registerRoutines', 'R_useDynamicSymbols'
>
> It is good practice to register native routines and to disable symbol
> search.
>
> See 'Writing portable packages' in the 'Writing R Extensions' manual.

This is mandatory since v3.4.0 and should issue a warning if I'm not
mistaken. Please, read "Writing R Extensions" carefully as the message
is exhorting you. This and further readings:

https://cran.r-project.org/doc/manuals/r-release/R-exts.html#Registering-native-routines
http://dirk.eddelbuettel.com/blog/2017/03/29/#001_easy_package_registration
http://dirk.eddelbuettel.com/blog/2017/03/30/#002_even_easier_package_registration

Regards,
Iñaki

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

Re: [R-pkg-devel] CRAN submission pretest warning about Rcpp version used to build dplyr

[Iñaki Úcar]

2017-07-13 20:19 GMT+02:00 Dirk Eddelbuettel <e...@debian.org>:
>
> On 13 July 2017 at 19:52, Iñaki Úcar wrote:
> | Or, in other words, Brooke, now you have to wait until Rcpp 0.12.12
> | appears on CRAN and then one or two days more until dplyr is rebuilt.
> | Then, try to resubmit your package.
>
> I disagree.
>
> That was a false alert, and it can be ignored.  News at 11pm.

So you just uploaded the package to win-builder? I thought you were
already submitting a new release.

Sorry, Brooke, then you can resubmit right away.

Iñaki

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

Re: [R-pkg-devel] best approach to getting an external library to *not* use stdout, stderr, etc.

[Iñaki Úcar]

2017-06-28 16:29 GMT+02:00 Simon Barthelmé :
> Dear list,
>
> I'm trying to wrap an external C++ library that has the bad habit of
> printing errors to std::cerr, a behaviour which will lead to CRAN issuing
> warnings. I was wondering if people had come up with a solution to this
> problem that's better than patching everything by hand?
>
> Thanks
>
> Simon

Hi, take a look at freopen: http://www.cplusplus.com/reference/cstdio/freopen/

Iñaki

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

Re: [R-pkg-devel] Linking external libraries in non-standard locations

[Iñaki Úcar]

2017-06-17 18:00 GMT+02:00 Dirk Eddelbuettel <e...@debian.org>:
>
> On 17 June 2017 at 17:30, Iñaki Úcar wrote:
> | Hi all,
> |
> | After googling around for a while, I found that this is a common
> | problem, but still it is not clear to me how I should handle this.
> |
> | I have a package A, with C++ code via Rcpp, that needs an external C++
> | library libB. I have a configure script that sets
> |
> | PKG_CPPFLAGS=-I/path/to/B/include
> | PKG_LIBS=-L/path/to/B/lib -lB
> |
> | in src/Makevars. Compilation and linking seem to go just fine. But then,
> |
> | ** testing if installed package can be loaded
> | Error in dyn.load(file, DLLpath = DLLpath, ...) :
> |   unable to load shared object
> | '/home/xxx/R/x86_64-redhat-linux-gnu-library/3.3/A/libs/A.so':
> |   libB.so: cannot open shared object file: No such file or directory
> |
> | If I set LD_LIBRARY_PATH=/path/to/B/lib, the error above is solved and
> | the package is installed. But then I try to load the package with
> | library(A), with LD_LIBRARY_PATH still set, and the same error
> | reappears.
> |
> | So what is the proper and more portable way of linking a external
> | library in a non-standard location?
>
> In short, I fear there is none.
>
> The _dynamic_ linker needs to know where the library is. There are defaults,
> and there are ways to extend this (i.e. /etc/ld.so.conf.d/*conf on the OS I
> use, or LD_LIBRARY_PATH as you used) but _none of those means are accessible
> to an R package_. This is system dependent.
>
> A static library you can control for yourself in your package.
>
> Dirk
>
> --
> http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org

Thanks, Dirk, as I had feared. However, I was wondering whether,
instead of relying on the OS, it would be possible to save this
non-standard location of the library at installation time and then to
call dyn.load() before loading the package.

Iñaki

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

[R-pkg-devel] Linking external libraries in non-standard locations

[Iñaki Úcar]

Hi all,

After googling around for a while, I found that this is a common
problem, but still it is not clear to me how I should handle this.

I have a package A, with C++ code via Rcpp, that needs an external C++
library libB. I have a configure script that sets

PKG_CPPFLAGS=-I/path/to/B/include
PKG_LIBS=-L/path/to/B/lib -lB

in src/Makevars. Compilation and linking seem to go just fine. But then,

** testing if installed package can be loaded
Error in dyn.load(file, DLLpath = DLLpath, ...) :
  unable to load shared object
'/home/xxx/R/x86_64-redhat-linux-gnu-library/3.3/A/libs/A.so':
  libB.so: cannot open shared object file: No such file or directory

If I set LD_LIBRARY_PATH=/path/to/B/lib, the error above is solved and
the package is installed. But then I try to load the package with
library(A), with LD_LIBRARY_PATH still set, and the same error
reappears.

So what is the proper and more portable way of linking a external
library in a non-standard location?

Regards,
Iñaki

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

[R-pkg-devel] Logging data to disk from C++ using a DBMS

[Iñaki Úcar]

Hi all,

We have a simulator, 'simmer', implemented as a C++ object (with Rcpp).
This simulator generates a bunch of data, and there are some functions
defined to bring this data to R space as data frames. The memory usage can
be a problem depending on the simulation model, so we would like to add
support for logging data directly to disk while being as transparent as
possible from the user perspective.

Our idea is to define a reusable chunk size and periodically append the
chunk to a DBIConnection by calling DBI::dbWriteTable from C++. In this
way, the subsequent analysis may be performed with dplyr no matter which
storage method is selected, memory or database.

The question is whether there is a better, more efficient, way of achieving
this goal. Is there any package already doing something similar? Ideas and
alternatives welcome. Thanks in advance.

Regards,
-- 
Iñaki Úcar
http://www.enchufa2.es
@Enchufa2

[[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] run a function from a list

[Iñaki Úcar]

Hi Glenn,

Try this:

my_list <- list(func = eval(parse(text=paste0("function()",
"print('this is a function')"
my_list$func()
#> "this is a function"

Regards,
Iñaki

2017-05-27 14:49 GMT+02:00 Glenn Schultz <glennmschu...@me.com>:
> All,
> I have a function to split a fixed rate bond into a floater/inverse floater
> combination (something typically done in mortgage securtizations).  The
> function returns a list which serves as the deal structure over which
> principal payment rules will iterate.  However, I would like to call the
> functions as they drive the interest coupon payments.  I am using paste0()
> to piece together the function and I think the problem is the quotes but not
> sure.
>
> I have tried source, do.call, list$foo(), list[[]]().  None of these have
> worked.  Any advice on structuring this problem is appreciated.
>
> Thanks,
> Glenn
>
> structure(list(floater.balance = 30.78, floater.cap = 6.67,
> floater.floor = 0.3, floater.index = "1mLIBOR", floater.formula =
> "function(index){min(6.67,max((1mLIBOR+0.3)0.3))}", inverse.balance = 20.52,
> inverse.cap = 9.55, inverse.multipler = 1.5, inverse.floor = 0,
> inverse.floater.formula = "(function(index)
> {min(9.55,max((-1.5*1mLIBOR)+9.55,0))})"), .Names = c("floater.balance",
> "floater.cap", "floater.floor", "floater.index", "floater.formula",
> "inverse.balance", "inverse.cap", "inverse.multipler", "inverse.floor",
> "inverse.floater.formula"))
>
>
>
>
> __
> R-package-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel



-- 
Iñaki Úcar
http://www.enchufa2.es
@Enchufa2

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