Re: [Rd] Fwd: Re: RSiteSearch, sos, rdocumentation.org, ...?

[Jonathan Baron]

The site is working again, although for some reason it did not
download any vignettes. I think that is OK.

On 12/21/16 18:22, Jonathan Baron wrote:

Unfortunately, I am unable to get this search site working again. (The
message below explains why I had to rebuild it.)


--
Jonathan Baron, Professor of Psychology, University of Pennsylvania
Home page: http://www.sas.upenn.edu/~baron
Editor: Judgment and Decision Making (http://journal.sjdm.org)

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

Re: [R-pkg-devel] Including Rcpp in an existing package

[Dirk Eddelbuettel]

On 22 December 2016 at 14:15, Duncan Murdoch wrote:
| On 22/12/2016 1:55 PM, Glenn Schultz wrote:
| > All,
| > My package was not initially built with the rcpp use in mind.  I have to 
include C++ source code for a particular project so I will have edit the 
description file add src files, etc.  by hand.  I an going over the rcpp 
documentation now and reviewing the R documentation on extensions as well.  Is 
there anything in particular that I should keep in mind while doing this or is 
this relatively straightforward.
| 
| It should be pretty straightforward.  There are lots of examples of 
| packages that do it (not all of which are simple); see the list of 
| "reverse " on https://CRAN.R-project.org/package=Rcpp (where  is 
| Depends, Imports, Suggests, or LinkingTo).

Exactly. I also (still) hand-edit a chronological list at

http://dirk.eddelbuettel.com/code/rcpp.cranusers.html

which contains a mix of 'fresh packages' (starting from scratch with Rcpp)
and 'converted packages' (which is what you are after). Sadly the latter set
is not indexed, so you have 'know' when a packages was pre-existing when it
made the list.

On 22 December 2016 at 14:22, Ben Bolker wrote:
| 
|  A mistake that I have made repeatedly is forgetting to add an
| appropriate UseDynLib() call to the NAMESPACE file.

Exactly, as well (though really an issue about going from no src/ to having
src).

For the issue here I recommend creating two _minimal_ packages via, say,

setwd("/tmp")  # alter as neded
package.skeleton("fooR")
Rcpp.package.skeleton("fooRcpp")

and the study where/how they differ.  And maybe try to convert fooR into
fooRwithRcpp.

There is a dedicated list for Rcpp questions too.

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] Including Rcpp in an existing package

[Ben Bolker]

 A mistake that I have made repeatedly is forgetting to add an
appropriate UseDynLib() call to the NAMESPACE file.

On 16-12-22 02:15 PM, Duncan Murdoch wrote:
> On 22/12/2016 1:55 PM, Glenn Schultz wrote:
>> All,
>> My package was not initially built with the rcpp use in mind.  I have
>> to include C++ source code for a particular project so I will have
>> edit the description file add src files, etc.  by hand.  I an going
>> over the rcpp documentation now and reviewing the R documentation on
>> extensions as well.  Is there anything in particular that I should
>> keep in mind while doing this or is this relatively straightforward.
> 
> It should be pretty straightforward.  There are lots of examples of
> packages that do it (not all of which are simple); see the list of
> "reverse " on https://CRAN.R-project.org/package=Rcpp (where  is
> Depends, Imports, Suggests, or LinkingTo).
> 
> Duncan Murdoch
> 
> __
> 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] Including Rcpp in an existing package

[Duncan Murdoch]

On 22/12/2016 1:55 PM, Glenn Schultz wrote:

All,
My package was not initially built with the rcpp use in mind.  I have to 
include C++ source code for a particular project so I will have edit the 
description file add src files, etc.  by hand.  I an going over the rcpp 
documentation now and reviewing the R documentation on extensions as well.  Is 
there anything in particular that I should keep in mind while doing this or is 
this relatively straightforward.


It should be pretty straightforward.  There are lots of examples of 
packages that do it (not all of which are simple); see the list of 
"reverse " on https://CRAN.R-project.org/package=Rcpp (where  is 
Depends, Imports, Suggests, or LinkingTo).


Duncan Murdoch

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

[R-pkg-devel] Including Rcpp in an existing package

[Glenn Schultz]

All,
My package was not initially built with the rcpp use in mind.  I have to 
include C++ source code for a particular project so I will have edit the 
description file add src files, etc.  by hand.  I an going over the rcpp 
documentation now and reviewing the R documentation on extensions as well.  Is 
there anything in particular that I should keep in mind while doing this or is 
this relatively straightforward.

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

Re: [R-pkg-devel] lfftw3 error

[Rampal Etienne]

Problem solved:

1. I installed the fftw library dlls from http://www.fftw.org/

2. I told the package where to find this library in the makevars.win file.

Regards,

Rampal


On 22-Dec-16 11:28, Rampal Etienne wrote:
> When trying to build a package with RStudio (newest R-devel and Rtools 
> installed, and all packages updated), I get the following error.
>
> C:/Rtools/mingw_64/bin/../lib/gcc/x86_64-w64-mingw32/4.9.3/../../../../x86_64-w64-mingw32/bin/ld.exe:
>  
> cannot find -lfftw3 collect2.exe: error: ld returned 1 exit status no 
> DLL was created
>
> I suppose lfftw3 should be included in Rtools or in the package? If 
> not, how do I add this, under Windows?
>
> Kind regards,
>
> Rampal Etienne


[[alternative HTML version deleted]]

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

Re: [Rd] Unexpected I(NULL) output

[Martin Maechler]

> Florent Angly 
> on Tue, 20 Dec 2016 13:42:37 +0100 writes:

> Hi all,
> I believe there is an issue with passing NULL to the function I().

> class(NULL)  # "NULL"  (as expected)
> print(NULL)   # NULL  (as expected)
> is.null(NULL) # TRUE  (as expected)

> According to the documentation I() should return a copy of its input
> with class "AsIs" preprended:

> class(I(NULL))  # "AsIs"  (as expected)
> print(I(NULL))   # list()  (not expected! should be NULL)
> is.null(I(NULL)) # FALSE  (not expected! should be TRUE)

> So, I() does not behave according to its documentation. 

yes.

> In R, it is
> not possible to give NULL attributes, but I(NULL) attempts to do that
> nonetheless, using the structure() function. Probably:
> 1/ structure() should not accept NULL as input since the goal of
> structure() is to set some attributes, something cannot be done on
> NULL.

I tend to agree.  However if we gave an error now, I notice that
even our own code, e.g., in stats:::formula.default()  would fail.

Still, I think we should consider *deprecating*  structure(NULL, *),
so it would give a *warning* (and continue working otherwise)
(for a while before giving an error a year later).

> 2/ I() could accept NULL, but, as an exception, not set an "AsIs"
> class attribute on it. This would be in line with the philosophy of
> the I() function to return an object that is functionally equivalent
> to the input object.

If we'd adopt 2, the I(.) function would become slightly more
complicated and slower...  but possibly not practically
noticeable.

A last option would be

3/  The help page for I() could note what happens in the NULL case.

That would be the least work for everyone,
but at the moment, I tend to agree that '1/' is worth the pain to
have R's structure() become more consistent.

Martin Maechler
ETH Zurich

> My sessionInfo() returns:
>> sessionInfo()
> R version 3.3.2 (2016-10-31)
> Platform: x86_64-w64-mingw32/x64 (64-bit)
> Running under: Windows 7 x64 (build 7601) Service Pack 1

> locale:
> [1] LC_COLLATE=German_Switzerland.1252
> LC_CTYPE=German_Switzerland.1252
> LC_MONETARY=German_Switzerland.1252 LC_NUMERIC=C
> [5] LC_TIME=German_Switzerland.1252

> attached base packages:
> [1] stats graphics  grDevices utils datasets  methods   base

> Best regards,

> Florent

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

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

[Rd] Is it possible to increase MAX_NUM_DLLS in future R releases?

[Dan Dillon]

I have read both the historical r-devel threads and the most recent one
regarding this.  After reviewing the code, it would seem to beg for a
linked-list implementation vs. an array implementation.

This has several interesting consequences.

Cons:

1) We pay for dynamic allocation every time we register a DLL.  This isn't
a problem in the grand scheme of things as registering a DLL results in
other allocations (and is fairly infrequent).
2) Traversing the linked list is marginally more expensive than traversing
an array due to memory locality and prefetching.

Pros:

1) For the average R usage we decrease the memory footprint as we only
allocate what is needed.
2) For extreme use cases, we support it, but user beware (as symbol lookup
time will scale with number of loaded DLLs)
3) We open up the possibility of more dynamic ordering of the LoadedDLL
structure.  Essentially we can very cheaply move the most recently "used"
DLL to the front of the list.

The cons, I think, are small in this situation.  We already dynamically
allocate strings and arrays in the DllInfo strucutre so those are already
not memory-local.  Additionally, R is frequently operating on large
datasets so cache thrashing is almost a given.  The negligible time
increase in traversing the list, I believe, will be offset by the more
dynamic sorting that we are able to give that list.

I have written a patch that does this, however, I have not yet extensively
tested it.  If there is interest in including this in R for the future, I
am more than happy to do the testing necessary, however, if there is a
compelling reason to avoid this sort of implementation, I don't want to
spend hours testing.

The patch is available at
https://gist.github.com/dcdillon/814e769adbf53ff43961f106008b3312

Additionally, this will require cleanup at shutdown which I haven't yet
added, but will add it if it gets any traction.

Any feedback you have would be wonderful, and thank you for your time.

Dan Dillon

[[alternative HTML version deleted]]

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