Re: [Rd] Problem during "make" with the devel version R-2.3.0 under Sun OS

[Simon Penel]

Thank you very much for your help, and sorry for any inconvevience.
Your are rigth my current compiler version is  too old : 3.3.2.
I will upgrade it  immediately.
All the best and thanks again

Simon



Prof Brian Ripley wrote:

> This is a compiler error (generating invalid assembler), not an R 
> error. What compiler version is this?
>
> I have no problem compiling the current R-devel (37422) on Solaris 
> with gcc-3.4.5 or gcc-4.0.2 (and using the Sun assembler as you are).  
> I have seen problems with plot3d with earlier versions of gcc-4.
>
>
> On Thu, 23 Feb 2006, Simon Penel wrote:
>
>> Hello R users and developers,
>>
>> I had a problem when I tried to install  the last version of R-devel.
>> I know that this R version is an unstable version and that this problem
>> may be irrelevant.
>> I am  maintaining a R package  thus I check if this package can be
>> installed with the development version.
>> ( Everinthing is fine with the R-patched)
>>
>> The details are the following:
>>
>> My machine:
>> System:  SunOS
>> Release: 5.9
>> Kernel ID : Generic_117171-07
>> Machine : sun4u
>> Processor :sparc
>> Platform : SUNW Sun-Fire-880
>>
>> R version
>> 2.3.0 Under development (unstable)
>>
>> SVN:
>> Revision: 37414
>> Last Changed Date: 2006-02-22
>>
>> Resultsaffer configure:
>>
>> R is now configured for sparc-sun-solaris2.9
>>
>>  Source directory:  .
>>  Installation directory:/usr/local
>>
>>  C compiler:gcc  -g -O2 -std=gnu99
>>  Fortran 77 compiler:   g77  -g -O2
>>
>>  C++ compiler:  g++  -g -O2
>>  Fortran 90/95 compiler:f90
>>
>>  Interfaces supported:  X11, tcltk
>>  External libraries:readline
>>  Additional capabilities:   PNG, JPEG, iconv, MBCS, NLS
>>  Options enabled:   R profiling
>>
>>
>> The problem during make:
>>
>>
>> gcc -I../../src/extra/zlib -I../../src/extra/bzip2
>> -I../../src/extra/pcre  -I. -I../../src/include -I../../src/include
>> -I/usr/local/include -DHAVE_CONFIG_H   -g -O2 -std=gnu99 -c plot.c -o 
>> plot.o
>> gcc -I../../src/extra/zlib -I../../src/extra/bzip2
>> -I../../src/extra/pcre  -I. -I../../src/include -I../../src/include
>> -I/usr/local/include -DHAVE_CONFIG_H   -g -O2 -std=gnu99 -c plot3d.c -o
>> plot3d.o
>> /usr/ccs/bin/as: "/tmp/ccYv732b.s", line 7057: error: constant value
>> must be between -4096 and 4095
>> make[3]: *** [plot3d.o] Error 1
>> make[3]: Leaving directory `/bge/penel/R-devel/src/main'
>> make[2]: *** [R] Error 2
>> make[2]: Leaving directory `/bge/penel/R-devel/src/main'
>> make[1]: *** [R] Error 1
>> make[1]: Leaving directory `/bge/penel/R-devel/src'
>> make: *** [R] Error 1
>>
>> I did not found any report about this problem in the R-devel archives .
>> Should I wait and try a next version of R-devel?
>>
>> thanks for your help, I hope this mail is not irrelevant
>>
>> Simon
>>
>> __
>> R-devel@r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-devel
>>
>>
>

-- 
Simon Penel
Laboratoire de Biometrie et Biologie Evolutive   
Bat 711  -   CNRS UMR 5558  -Universite Lyon 1  
43 bd du 11 novembre 1918 69622 Villeurbanne Cedex   
Tel:   04 72 43 12 87  Fax:  04 72 43 13 88
http://pbil.univ-lyon1.fr/members/penel

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

Re: [Rd] Utilizing the internet module

[Prof Brian Ripley]

On Thu, 23 Feb 2006, Prof Brian Ripley wrote:

> On Thu, 23 Feb 2006, Jeffrey Horner wrote:
>
>> Hello all,
>>
>> I'd like to utilize the R_Sock* functions from R_ext/R-ftp-http.h in my
>> R package. The intent is to use these in conjunction with R_serialize()
>>  to store R objects in a remote data store. I'm aware that version
>> 2.2.1 of "Writing R extensions" explains that these may be undocumented
>> and unstable, but I have a couple of questions:
>>
>> 1) are they platform independent? I presume they are...
>
> Only in sense that they have a common interface.
>
>> 2) What's the appropriate way to link against them? On Linux x86, I can
>> do this with the Makevars:
>
> You can, but that is a module and not a library and so it does not work on
> MacOS X and may well not work on Windows (you would be lucky prior to R
> 2.3.0).

It also does not work in R-devel on any system that supports visibility 
attributes, for example Linux systems with gcc4, and some RedHat systems 
with gcc 3.4.4.  I am removing the declarations from R_exts/R-ftp-http.c 
for R 2.3.0.

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

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

[Rd] Minor Typo in image.Rd

[Paul Roebuck]

Currently:
==
\arguments{
[...]
  \item{xlab, ylab}{
[...]
Default to the \sQuote{call names} of \code{x} or \code{y},
or to \code{""} if these where unspecified.}
 ^

Should read:

\arguments{
[...]
  \item{xlab, ylab}{
[...]
Default to the \sQuote{call names} of \code{x} or \code{y},
or to \code{""} if these were unspecified.}

--
SIGSIG -- signature too long (core dumped)

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

Re: [Rd] Links to non-vignette documentation

[Duncan Murdoch]

On 2/23/2006 10:02 PM, hadley wickham wrote:
>> They are meant to replace the INDEX, which you shouldn't need to create
>> any more.  The DESCRIPTION file is still needed, but it contains more
>> structured information meant for mechanical reading and processing; the
>> package man page is meant to be the place to put things intended for
>> people to read.
> 
> Do I need to keep the list of functions on the package man page in
> sync myself, or will they be automatically rebuilt?  Is the intention
> to eventually change help(package=XXX) to point to the package man
> page?

No, there's no automatic building after the promptPackage call.  It's up 
to you to decide which functions need to be mentioned to users.  In 
large packages it usually doesn't make sense to list all the functions, 
so the package writer needs to use judgement here.  There are other 
mechanisms (e.g. ls("package:XXX") for a list of names, the help index 
generation for a list of names and titles) to get a list of everything.

There aren't any immediate plans to change help(package=XXX), but I 
think in the long run, if package?XXX receives wider support than it has 
now, it would make sense to make that change.

Duncan Murdoch

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

Re: [Rd] Minor Typo in image.Rd

[Duncan Murdoch]

Thanks, I'll fix this.

Duncan Murdoch

On 2/24/2006 4:12 AM, Paul Roebuck wrote:
> 
> 
> 
> Currently:
> ==
> \arguments{
> [...]
>   \item{xlab, ylab}{
> [...]
> Default to the \sQuote{call names} of \code{x} or \code{y},
> or to \code{""} if these where unspecified.}
>  ^
> 
> Should read:
> 
> \arguments{
> [...]
>   \item{xlab, ylab}{
> [...]
> Default to the \sQuote{call names} of \code{x} or \code{y},
> or to \code{""} if these were unspecified.}
> 
> --
> SIGSIG -- signature too long (core dumped)
> 
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel

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

Re: [Rd] Links to non-vignette documentation

[Romain Francois]

Le 24.02.2006 01:26, Berwin A Turlach a écrit :
> G'day all,
>
> seems as if I must have slept through most of this most interesting
> discussion. :)
>
>   
>> "BR" == Prof Brian Ripley <[EMAIL PROTECTED]> writes:
>> 
>
> BR> On Thu, 23 Feb 2006, hadley wickham wrote:
> >> How can I write an index file with a pointer to my pdf?  Should
> >> I provide a code snippet to run
> >> system(paste(getOption("pdfviewer"), system.file("doc/my.pdf",
> >> package="mypackage"), "&"))?
> BR> Just add a hyperlink in inst/doc/index.html to foo.pdf and let
> BR> the browser do the rest.  The grid/doc/index.html is a
> BR> suitable template.
> Editing this file by hand is certainly an option, but one more think
> to remember while maintaining a package.  Thus, I think it is
> preferable to automate process as much as possible.  I ran into a
> similar problem as Hadley with a package that I am currently developing
> (since some time) and offer my solution below.
>
>   
>> "DM" == Duncan Murdoch <[EMAIL PROTECTED]> writes:
>> 
>
> DM> On 2/23/2006 4:23 PM, hadley wickham wrote:
> >> What about (eg.) help(package=grid)?  This is where vignettes
> >> are listed by name (and location).  I would like to be able put
> >> my pdf into a similar list.
> DM> I don't think you can do that, but you should be using a
> DM> package man page anyway.
> I believe this can be done, albeit not directly.
>
> In my case, I wanted to include a PDF, whose source is not in Sweave
> format, with the documentation of the package and have the links to
> this documentation created automatically.  My solution, in the end was
> to create a "dummy" Rnw vignette which has a link to the pdf file.  I
> include that dummy vignette below.  Hence, in the directory inst/doc
> of my package there are the following files:
> interface96.pdf The PDF file I actually want to include
> as part of the documentation
> interface96-vignette.RnwThe dummy vignette file
> Using hyperref with a "file:" url, the dummy vignette file links to
> the actual files.
>
> For the user, this means that she/he sees the dummy vignette and
> access it first and then has to click once more on a link to get to
> the actual document.  Slightly inconvenient for the user, but I
> believe it is a fair price to pay to make my life as developer
> easier. ;-))
>
> If you want to distribute binary copies (e.g. for the various version
> of Windows that exists) of your package, then you need of course all
> the tools that are necessary to handle vignettes.
>
> Cheers,
>
> Berwin
>
> - Source of dummy vignette -
> \documentclass[a4paper]{article}
> %\VignetteIndexEntry{Interface '96 paper by Marron et al. (1997)}
> %\VignettePackage{clps}
>
> \usepackage{hyperref}
> \usepackage{natbib}
>
> \title{Interface '96 paper by \cite{mar:tur:wan:96}}
> \author{Berwin A Turlach}
> \date{September 25, 2004}
>
> \begin{document}
> \maketitle
>
> This is just a dummy vignette with a link to the 
> \href{file:interface96.pdf}{PDF file} of \cite{mar:tur:wan:96} which
> is part of the \textit{CLPS} package.  The dummy vignette should
> appear in the automatically generated index, but I did not succeed in
> getting the actual paper to appear in that index.
>
> \bibliographystyle{dcunsp}
> \bibliography{clps}
>
> \end{document}
>   
Hi,

What about using the latex package pdfpages to copy the pages from your 
PDF file `interface96.pdf` to your Sweave file. (I don't know if it is 
compatible with Sweave).

Not tested :

\documentclass[a4paper]{article}
%\VignetteIndexEntry{Interface '96 paper by Marron et al. (1997)}
%\VignettePackage{clps}

\usepackage{hyperref}
\usepackage{natbib}
\usepackage{pdfpages}

\title{Interface '96 paper by \cite{mar:tur:wan:96}}
\author{Berwin A Turlach}
\date{September 25, 2004}

\begin{document}
\maketitle

\newpage

\includepdf{interface96.pdf}


\bibliographystyle{dcunsp}
\bibliography{clps}

\end{document}


Romain
 

-- 
visit the R Graph Gallery : http://addictedtor.free.fr/graphiques
Discover the R Movies Gallery : http://addictedtor.free.fr/movies
+---+
| Romain FRANCOIS - http://francoisromain.free.fr   |
| Doctorant INRIA Futurs / EDF  |
+---+

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

Re: [Rd] Links to non-vignette documentation

[Duncan Murdoch]

On 2/24/2006 7:27 AM, Romain Francois wrote:
> 
> What about using the latex package pdfpages to copy the pages from your 
> PDF file `interface96.pdf` to your Sweave file. (I don't know if it is 
> compatible with Sweave).
> 
> Not tested :
> 
> \documentclass[a4paper]{article}
> %\VignetteIndexEntry{Interface '96 paper by Marron et al. (1997)}
> %\VignettePackage{clps}
> 
> \usepackage{hyperref}
> \usepackage{natbib}
> \usepackage{pdfpages}
> 
> \title{Interface '96 paper by \cite{mar:tur:wan:96}}
> \author{Berwin A Turlach}
> \date{September 25, 2004}
> 
> \begin{document}
> \maketitle
> 
> \newpage
> 
> \includepdf{interface96.pdf}
> 
> 
> \bibliographystyle{dcunsp}
> \bibliography{clps}
> 
> \end{document}

That's a nice hack.  You probably want the "fitpaper" option on the 
\includepdf command, so that you don't get an extra border around the 
page.  For example, this file test.Rnw

\documentclass{article}
%\VignetteIndexEntry{test include of pdf}
%\VignettePackage{ellipse}

\usepackage{pdfpages}

\begin{document}

\includepdf[fitpaper=true]{response.pdf}

\end{document}

produces an output that looks pretty much exactly like the 
"response.pdf" file I used as test input in a viewer.

The only disadvantages I see are that both the test.pdf and response.pdf 
files got built into the package (but only test.pdf shows up in the 
index), and that test.pdf is a lot larger than response.pdf.  (This may 
be because response.pdf was small; I haven't checked if the increase is 
additive or multiplicative).

For a non-hack solution:

A change to the R package build process would be to add support for a 
command like

%\VignetteExists

to the test.Rnw file, telling R not to bother trying to build the pdf, 
because it had already been built by other means.  Then I'd just have 
test.Rnw containing

%\VignetteIndexEntry{test include of pdf}
%\VignettePackage{ellipse}
%\VignetteExists

and solve both of the problems with Romain's workaround.

Duncan Murdoch

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

Re: [Rd] Links to non-vignette documentation

[hadley wickham]

> No, there's no automatic building after the promptPackage call.  It's up
> to you to decide which functions need to be mentioned to users.  In
> large packages it usually doesn't make sense to list all the functions,
> so the package writer needs to use judgement here.  There are other
> mechanisms (e.g. ls("package:XXX") for a list of names, the help index
> generation for a list of names and titles) to get a list of everything.

Ok, that seems reasonable, but perhaps promptPackage (or
documentation) could make this more clear.

> There aren't any immediate plans to change help(package=XXX), but I
> think in the long run, if package?XXX receives wider support than it has
> now, it would make sense to make that change.

When was this form of package documentation created?  How are users
supposed to know it exists?  I couldn't find any pointers to it from
?help, ?library or from help(package=XXX).

Hadley

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

Re: [Rd] Links to non-vignette documentation

[Hin-Tak Leung]

Duncan Murdoch wrote:

>>\usepackage{pdfpages}

> That's a nice hack.  You probably want the "fitpaper" option on the 
> \includepdf command, so that you don't get an extra border around the 
> page.  For example, this file test.Rnw

> The only disadvantages I see are that both the test.pdf and response.pdf 
> files got built into the package (but only test.pdf shows up in the 
> index), and that test.pdf is a lot larger than response.pdf.  (This may 
> be because response.pdf was small; I haven't checked if the increase is 
> additive or multiplicative).


I like pdfpages and do use it from time to time (as frequently as
every couple of weeks for filling expense/travel/claim forms) -
but in fact it isn't shipped with tetex 1.0 and is not in the
site-wise LaTeX installation in my work location.
(and luckily I am not using the site-wise one...). I checked and
pdfpages was added to tetex in Oct 2001 and is in tetex 2.0 which
was released in feb 2003; but sites could be slow in upgrading...
so such constructions would break on sites which hasn't upgraded
their LaTeX installation in the last 3 years.

HTL

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

Re: [Rd] Utilizing the internet module

[Jeffrey Horner]

Prof Brian Ripley wrote:
> On Thu, 23 Feb 2006, Jeffrey Horner wrote:
[...]
>> On a related note, how do I serialize() an R object to a database 
>> table column of type BLOB? I've tried using RODBC but was 
>> unsuccessfully (see R-sig-DB in Feb archive). I've also looked into 
>> RMySQL/DBI but I don't think it's supported yet.
> 
> 
> Since BLOB is not a standard SQL type (AFAIK), ODBC seems not to support 
> it.
> 

It's not standard, per se, but many ODBC drivers and many databases 
(Oracle, MS SQL Server, MySQL, Postgresql, Access, ...) support such a 
type. In fact, the structured query language standards SQL92 and SQL99 
define the type BIT and BIT VARYING to hold arbitrary bit strings, which 
I think is some sort of endorsement for this type.

-- 
Jeffrey Horner   Computer Systems Analyst School of Medicine
615-322-8606 Department of Biostatistics   Vanderbilt University

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

Re: [Rd] Links to non-vignette documentation

[Duncan Murdoch]

On 2/24/2006 9:29 AM, hadley wickham wrote:
>> No, there's no automatic building after the promptPackage call.  It's up
>> to you to decide which functions need to be mentioned to users.  In
>> large packages it usually doesn't make sense to list all the functions,
>> so the package writer needs to use judgement here.  There are other
>> mechanisms (e.g. ls("package:XXX") for a list of names, the help index
>> generation for a list of names and titles) to get a list of everything.
> 
> Ok, that seems reasonable, but perhaps promptPackage (or
> documentation) could make this more clear.
> 
>> There aren't any immediate plans to change help(package=XXX), but I
>> think in the long run, if package?XXX receives wider support than it has
>> now, it would make sense to make that change.
> 
> When was this form of package documentation created?  How are users
> supposed to know it exists?  I couldn't find any pointers to it from
> ?help, ?library or from help(package=XXX).

It's described in the Writing R Extensions Manual, in Writing R 
Documentation Files, Rd Format, Documenting Packages (section 2.1.4 in 
the PDF).

There probably should be more pointers to it...

Duncan Murdoch

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

Re: [Rd] Links to non-vignette documentation

[Duncan Murdoch]

On 2/24/2006 11:42 AM, hadley wickham wrote:
>> > When was this form of package documentation created?  How are users
>> > supposed to know it exists?  I couldn't find any pointers to it from
>> > ?help, ?library or from help(package=XXX).
>>
>> It's described in the Writing R Extensions Manual, in Writing R
>> Documentation Files, Rd Format, Documenting Packages (section 2.1.4 in
>> the PDF).
> 
> That's great for developers, but how are users supposed to find out?

I think users would be disappointed if they tried using package?foo 
right now, because mostly it tells you there's no such man page.  First 
you need a few more developers to follow the recommendations, before it 
really makes sense to advertise the feature.

An alternative approach would be for R CMD check to warn developers who 
don't have such a man page.  That would encourage adoption of this 
convention, but there were quite a few objections when I suggested it. 
It does put a load on package authors.

Another alternative would be for a default package man page to be built 
if the developer didn't supply one; that's probably a good idea, but not 
one I have time to act on before 2.3.x, so it's not coming soon.

If you feel like writing some patches to the documentation in the 
appropriate places, and it looks as though they won't mislead readers, 
please do so, and I'll review and commit them.  If you want to revise 
the package build scripts, you're going to need to find someone else to 
commit them; I will not have enough time to review things that could 
cause that much trouble if you get it wrong.

Duncan Murdoch

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

[Rd] Rcpp, best method for linking to

[Andrew Garbutt]

Dear all,

 

After a bit of reading I came across the Rcpp example package.  There
are a few classes that I would like to use and I am not sure how best to
include them in my own package.  Is it best to compile it as an
independent library and link to it? Or is there some way to `require` it
for my own package?  Re-write using the code as an example (unsure how
best to do this at this moment, as the Rcpp package is licensed under
the GPL v2 and I am unsure of the license that I wish to use for my own
package.)  Any thoughts or ideas would be appreciated.

 

Thanks,

Andy 


[[alternative HTML version deleted]]

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

Re: [Rd] Rcpp, best method for linking to

[Andrew Finley]

Hi Andy,
Follow the suggestions for c++ in the Writing R Extensions document.
Wrap your c++ code in extern "C"{}, include your classes in the includes
(e.g., #include "myclass.h") and put the myclass.h and myclass.cpp in
the src directory along with your other code. Then R CMD build ... and R
CMD INSTALL ...  This works for me. 
-Andy


On Fri, 2006-02-24 at 13:11 -0800, Andrew Garbutt wrote:
> Dear all,
> 
>  
> 
> After a bit of reading I came across the Rcpp example package.  There
> are a few classes that I would like to use and I am not sure how best to
> include them in my own package.  Is it best to compile it as an
> independent library and link to it? Or is there some way to `require` it
> for my own package?  Re-write using the code as an example (unsure how
> best to do this at this moment, as the Rcpp package is licensed under
> the GPL v2 and I am unsure of the license that I wish to use for my own
> package.)  Any thoughts or ideas would be appreciated.
> 
>  
> 
> Thanks,
> 
> Andy 
> 
> 
>   [[alternative HTML version deleted]]
> 
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
-- 
Research Fellow
Department of Forest Resources
University of Minnesota
Office: 305 Green Hall
Phone: (612) 624-1714
Fax: (612) 625-5212
web: http://blue.fr.umn.edu

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

Re: [Rd] Rcpp, best method for linking to

[Dominick Samperi]

Hi Andy (and Andy),

I'm not sure why there should be any licensing issues. R itself is GPL-ed,
so I just followed this convention.

Of course, you can do it yourself with extern "C" and all that. The
purpose of Rcpp.{cpp,hpp} is to enable you to write
readable code (for a C++ programmer) while hiding the error-prone
macro gymnastics that is required to fetch R parameters when using
the .Call interface. There is also a fair amount of type checking done
in the Rcpp package that relieves you of the trouble of putting many
checks in your R code.

If you are using the older, simpler .C interface this may not be
important to you. But note that the same functionality is available
through Rcpp, with the added convenience that list item names
are not dropped like they are when you use the .C interface.

Dominick

Andrew Finley wrote:
> Hi Andy,
> Follow the suggestions for c++ in the Writing R Extensions document.
> Wrap your c++ code in extern "C"{}, include your classes in the includes
> (e.g., #include "myclass.h") and put the myclass.h and myclass.cpp in
> the src directory along with your other code. Then R CMD build ... and R
> CMD INSTALL ...  This works for me. 
> -Andy
>
>
> On Fri, 2006-02-24 at 13:11 -0800, Andrew Garbutt wrote:
>   
>> Dear all,
>>
>>  
>>
>> After a bit of reading I came across the Rcpp example package.  There
>> are a few classes that I would like to use and I am not sure how best to
>> include them in my own package.  Is it best to compile it as an
>> independent library and link to it? Or is there some way to `require` it
>> for my own package?  Re-write using the code as an example (unsure how
>> best to do this at this moment, as the Rcpp package is licensed under
>> the GPL v2 and I am unsure of the license that I wish to use for my own
>> package.)  Any thoughts or ideas would be appreciated.
>>
>>  
>>
>> Thanks,
>>
>> Andy 
>>
>>
>>  [[alternative HTML version deleted]]
>>
>> __
>> R-devel@r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-devel
>>

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

Re: [Rd] Rcpp, best method for linking to

[Andrew Garbutt]

Dominick,

Sorry, that's not quite what I was asking.  I was asking more of a "best
practice" kind of question. My own C++ codes compile fine and are
accessible to R with some great #define magic.  I was noting that the
Rcpp package has some generic classes to handle conversion of SEXP
structures to STL and back again. As I far as I can see, using them
would require that I compile the C++ code into a library and link to
that library. Or copy the code into my own code base, but doing would
restrict myself to the GPL, as it would be a derivative work?? (IANAL)
At this point I do not want to commit to any particular licensure for my
package.  

So, to sum up my "actual" question... 
Is it better to create a libRcpp.a and link to that? Have a copy of the
Rcpp.cpp/.hpp files in my own code base compiling them directly?
Require that any particular R installation have the requirement that the
Rcpp package be installed prior?

Thanks for your time,
Andy

-Original Message-
From: Dominick Samperi [mailto:[EMAIL PROTECTED] 
Sent: Friday, February 24, 2006 2:30 PM
To: Andrew Finley
Cc: Andrew Garbutt; r-devel@r-project.org
Subject: Re: [Rd] Rcpp, best method for linking to


Hi Andy (and Andy),

I'm not sure why there should be any licensing issues. R itself is
GPL-ed,
so I just followed this convention.

Of course, you can do it yourself with extern "C" and all that. The
purpose of Rcpp.{cpp,hpp} is to enable you to write
readable code (for a C++ programmer) while hiding the error-prone
macro gymnastics that is required to fetch R parameters when using
the .Call interface. There is also a fair amount of type checking done
in the Rcpp package that relieves you of the trouble of putting many
checks in your R code.

If you are using the older, simpler .C interface this may not be
important to you. But note that the same functionality is available
through Rcpp, with the added convenience that list item names
are not dropped like they are when you use the .C interface.

Dominick

Andrew Finley wrote:
> Hi Andy,
> Follow the suggestions for c++ in the Writing R Extensions document.
> Wrap your c++ code in extern "C"{}, include your classes in the
includes
> (e.g., #include "myclass.h") and put the myclass.h and myclass.cpp in
> the src directory along with your other code. Then R CMD build ... and
R
> CMD INSTALL ...  This works for me. 
> -Andy
>
>
> On Fri, 2006-02-24 at 13:11 -0800, Andrew Garbutt wrote:
>   
>> Dear all,
>>
>>  
>>
>> After a bit of reading I came across the Rcpp example package.  There
>> are a few classes that I would like to use and I am not sure how best
to
>> include them in my own package.  Is it best to compile it as an
>> independent library and link to it? Or is there some way to `require`
it
>> for my own package?  Re-write using the code as an example (unsure
how
>> best to do this at this moment, as the Rcpp package is licensed under
>> the GPL v2 and I am unsure of the license that I wish to use for my
own
>> package.)  Any thoughts or ideas would be appreciated.
>>
>>  
>>
>> Thanks,
>>
>> Andy 
>>
>>
>>  [[alternative HTML version deleted]]
>>
>> __
>> R-devel@r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-devel
>>

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

Re: [Rd] Rcpp, best method for linking to

[Dominick Samperi]

Andy,

Any of the options you mentioned (libRcpp.a, source, etc.) sound fine
to me. If the GPL is a problem I am happy to change this to some other
open source license (I'm not entirely comfortable with GPL, and used
it because R uses it). I'm open to suggestions.

Dominick

Andrew Garbutt wrote:
> Dominick,
>
> Sorry, that's not quite what I was asking.  I was asking more of a "best
> practice" kind of question. My own C++ codes compile fine and are
> accessible to R with some great #define magic.  I was noting that the
> Rcpp package has some generic classes to handle conversion of SEXP
> structures to STL and back again. As I far as I can see, using them
> would require that I compile the C++ code into a library and link to
> that library. Or copy the code into my own code base, but doing would
> restrict myself to the GPL, as it would be a derivative work?? (IANAL)
> At this point I do not want to commit to any particular licensure for my
> package.  
>
> So, to sum up my "actual" question... 
> Is it better to create a libRcpp.a and link to that? Have a copy of the
> Rcpp.cpp/.hpp files in my own code base compiling them directly?
> Require that any particular R installation have the requirement that the
> Rcpp package be installed prior?
>
> Thanks for your time,
> Andy
>
> -Original Message-
> From: Dominick Samperi [mailto:[EMAIL PROTECTED] 
> Sent: Friday, February 24, 2006 2:30 PM
> To: Andrew Finley
> Cc: Andrew Garbutt; r-devel@r-project.org
> Subject: Re: [Rd] Rcpp, best method for linking to
>
>
> Hi Andy (and Andy),
>
> I'm not sure why there should be any licensing issues. R itself is
> GPL-ed,
> so I just followed this convention.
>
> Of course, you can do it yourself with extern "C" and all that. The
> purpose of Rcpp.{cpp,hpp} is to enable you to write
> readable code (for a C++ programmer) while hiding the error-prone
> macro gymnastics that is required to fetch R parameters when using
> the .Call interface. There is also a fair amount of type checking done
> in the Rcpp package that relieves you of the trouble of putting many
> checks in your R code.
>
> If you are using the older, simpler .C interface this may not be
> important to you. But note that the same functionality is available
> through Rcpp, with the added convenience that list item names
> are not dropped like they are when you use the .C interface.
>
> Dominick
>
> Andrew Finley wrote:
>   
>> Hi Andy,
>> Follow the suggestions for c++ in the Writing R Extensions document.
>> Wrap your c++ code in extern "C"{}, include your classes in the
>> 
> includes
>   
>> (e.g., #include "myclass.h") and put the myclass.h and myclass.cpp in
>> the src directory along with your other code. Then R CMD build ... and
>> 
> R
>   
>> CMD INSTALL ...  This works for me. 
>> -Andy
>>
>>
>> On Fri, 2006-02-24 at 13:11 -0800, Andrew Garbutt wrote:
>>   
>> 
>>> Dear all,
>>>
>>>  
>>>
>>> After a bit of reading I came across the Rcpp example package.  There
>>> are a few classes that I would like to use and I am not sure how best
>>>   
> to
>   
>>> include them in my own package.  Is it best to compile it as an
>>> independent library and link to it? Or is there some way to `require`
>>>   
> it
>   
>>> for my own package?  Re-write using the code as an example (unsure
>>>   
> how
>   
>>> best to do this at this moment, as the Rcpp package is licensed under
>>> the GPL v2 and I am unsure of the license that I wish to use for my
>>>   
> own
>   
>>> package.)  Any thoughts or ideas would be appreciated.
>>>
>>>  
>>>
>>> Thanks,
>>>
>>> Andy 
>>>
>>>
>>> [[alternative HTML version deleted]]
>>>
>>> __
>>> R-devel@r-project.org mailing list
>>> https://stat.ethz.ch/mailman/listinfo/r-devel
>>> 
>>>

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

Re: [Rd] Rcpp, best method for linking to

[Dirk Eddelbuettel]

Andrew, 

On 24 February 2006 at 15:00, Andrew Garbutt wrote:
| Sorry, that's not quite what I was asking.  I was asking more of a "best
| practice" kind of question. My own C++ codes compile fine and are
| accessible to R with some great #define magic.  I was noting that the
| Rcpp package has some generic classes to handle conversion of SEXP
| structures to STL and back again. As I far as I can see, using them
| would require that I compile the C++ code into a library and link to
| that library. Or copy the code into my own code base, but doing would
| restrict myself to the GPL, as it would be a derivative work?? (IANAL)
| At this point I do not want to commit to any particular licensure for my
| package.  

I may be misunderstanding you but here it goes: if you are using Rcpp as a
means to get to R, you still end up linking with R itself.  It is my
understanding that this implies the GPL -- or a suitable GPL-compatible
license -- for your code.

I do not see any _additional restriction_ coming in via the addition of
Rcpp. You already use GPL'ed object files / libraries via R itself. Plus
you're presumably building with R toolchain via 'R CMD INSTALL '

Hth, Dirk
 
-- 
Hell, there are no rules here - we're trying to accomplish something. 
  -- Thomas A. Edison

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

Re: [Rd] Links to non-vignette documentation

[Berwin A Turlach]

G'day all,

> "DM" == Duncan Murdoch <[EMAIL PROTECTED]> writes:

DM> On 2/24/2006 7:27 AM, Romain Francois wrote:
>> 
>> What about using the latex package pdfpages to copy the pages from your 
>> PDF file `interface96.pdf` to your Sweave file. 
Merci beaucoup, I wasn't aware that this style file exists, it
definitely seems to be useful.

DM> That's a nice hack.  You probably want the "fitpaper" option on the 
DM> \includepdf command, so that you don't get an extra border around the 
DM> page.  For example, this file test.Rnw [...]

DM> \includepdf[fitpaper=true]{response.pdf}
Additionally, if response.pdf has several pages and you want to
include them all, you should also include a "pages" options, such as:

\includepdf[fitpaper=true,pages=-]{interface96.pdf}

More details can be found in the pdfpages documentation, but by
default only the first page is included.

DM> produces an output that looks pretty much exactly like the 
DM> "response.pdf" file I used as test input in a viewer.
Perhaps interface96.pdf was created too long ago (it says PDF 1.2 at
the top of that file), but the result looks strange in xpdf (the
included pages are quite small and in the upper left corner, selecting
"fit to page" creates an acceptable viewing results); no problem with
acroread.  This is on a linux box.

DM> The only disadvantages I see are that both the test.pdf and
DM> response.pdf files got built into the package (but only
DM> test.pdf shows up in the index),
That is a potential disadvantage as it duplicates material.  But I
guess .Rbuildignore in the main directory of the package can help in
this case.  I have put the line "inst/doc/interface96.pdf" into the
.Rbuildignore file of that package.

DM> and that test.pdf is a lot larger than response.pdf.  (This
DM> may be because response.pdf was small; I haven't checked if
DM> the increase is additive or multiplicative).
I didn't check this either, but here are some results on including a 6
page pdf file (extracts from looking at the .tar.gz file produced by
the build process).  First, the old solution with a separate PDF file
and a dummy vignette:

 drwxr-xr-x  berwin/berwin0 clps/inst/
 drwxr-xr-x  berwin/berwin0 clps/inst/doc/
 -rw-r--r--  berwin/berwin  649 clps/inst/doc/clps.bib
 -rw-r--r--  berwin/berwin  670 clps/inst/doc/interface96-vignette.Rnw
 -rw-r--r--  berwin/berwin   105035 clps/inst/doc/interface96.pdf
 -rw-r--r--  berwin/berwin49242 clps/inst/doc/interface96-vignette.pdf
 
Second, with \includepdf and .Rbuildignore:

 drwxr-xr-x  berwin/berwin0 clps/inst/
 drwxr-xr-x  berwin/berwin0 clps/inst/doc/
 -rw-r--r--  berwin/berwin  649 clps/inst/doc/clps.bib
 -rw-r--r--  berwin/berwin  440 clps/inst/doc/interface96-vignette.Rnw
 -rw-r--r--  berwin/berwin   191589 clps/inst/doc/interface96-vignette.pdf

Looks like an increase of about 40 kB to me which I would find acceptable.

DM> A change to the R package build process would be to add support for a 
DM> command like

DM> %\VignetteExists

DM> to the test.Rnw file, telling R not to bother trying to build the pdf, 
DM> because it had already been built by other means.  Then I'd just have 
DM> test.Rnw containing
Searching the "Writing R Extensions" manual for vignette, I noticed
the following:

  Unless @kbd{R CMD build} is invoked with the
  @option{--no-vignettes} option, it will attempt to rebuild the
  vignettes (@pxref{Writing package vignettes}) in the package.
  To do so it installs the current package/bundle into a temporary
  library tree, but any dependent packages need to be installed in
  an available library tree (see the Note: below).

Thus there is already a mechanism to avoid (automatic) rebuilding of
vignettes.  But it seems to be a "all-or-nothing" solution and I could
imagine that some packages might have "real" vignettes that the
maintainer would like to have rebuild automatically and "dummy"
vignettes that should not be rebuild.  So a fine-grained control,
along the way that you suggest, would be a nice way.

> "HT" == Hin-Tak Leung <[EMAIL PROTECTED]> writes:

HT> I like pdfpages and do use it from time to time [...]  so such
HT> constructions would break on sites which hasn't upgraded their
HT> LaTeX installation in the last 3 years.
The "Writing R Extensions" manual states on page 15:

  @code{R CMD build} will automatically create PDF versions of the
  vignettes for distribution with the package sources.  By
  including the PDF version in the package sources it is not
  necessary that the vignettes can be compiled at install time,
  i.e., the package author can use private @LaTeX{} extensions
  which are only available on his machine.  Only the @R{} code
  inside the vignettes is part of the checking procedure,
  typesetting manuals is not part of the package QC.

T