Re: [R-pkg-devel] Setting up R-devel in Linux Mint 17.1 64-bit
> On 21 Jul 2015, at 08:12 , Johannes Ranke wrote: > >>> >>> Could you guys move to r-devel? This has nothing to do with _package_ >>> development. > > OK, the details of how to configure a build are maybe a bit too far off... > But > in general, testing with a recent development build is an important part of > submitting packages to CRAN, so it seems to me that this list may serve to > collect information on how this can be done? In a word: No. So is getting R installed in the first place, running it on a Mac, sorting out library dependencies, etc. All of these things have their own mailing lists, full of people that know about stuff. We do not want to duplicate their content here, possibly with lesser competence. Plus, it clogs up the archives of _this_ list. -pd -- Peter Dalgaard, Professor, Center for Statistics, Copenhagen Business School Solbjerg Plads 3, 2000 Frederiksberg, Denmark Phone: (+45)38153501 Email: pd@cbs.dk Priv: pda...@gmail.com __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] Help needed to setting custom packages for R 3.1.2
Hi Jennifer,
Following your suggestions and after a couple of trial-and-error steps,
I believe the syntax is the following:
\code{\link[name_of_package:name_of_Rd_file]{alias_or_text}}
For instance, to link to panel.abline or strip.custom from the lattice
package, I used:
\code{\link[lattice:panel.functions]{panel.abline}}
\code{\link[lattice:strip.default]{panel.custom}}
Using this notation I was able to make all warnings disappear upon
installation of my package.
Typically, you can extract the name of the Rd file from the ? help page
(upper left corner info). But this is not 100% reliable if the
maintainer of the package is not consistent in the way (s)he documents
the package.
Thanks a lot for your help.
Sebastien
On 7/20/2015 5:45 PM, Jennifer Bryan wrote:
Hi Sebastien,
This note about Rd warnings reminded me that I recently had the same problem.
So I recreated it and, I think, have found a solution.
I will explain in my specific example to be clear.
I need to link to the docs for the Token2.0 class from the httr package. First
thing you try:
\code{\link[httr]{Token2.0}}
but then you get the warnings you describe upon installation. As in your case,
the Token2.0 class doesn’t have it’s own .Rd file but is, rather, documented in
the topic titled “Token-class”.
Next thing you try:
\code{\link[httr]{Token-class}}
which works, but I don’t like this display text — it doesn’t really make sense
in the context of *my* documentation.
Finally you do this:
\code{\link[=Token-class]{Token2.0}}
to link to the correct topic but get the desired display text. However, I am no
longer specifying that this topic is from the httr package, but it seems to
work.
Maybe someone else can weigh in with more insight about the need / desirability
of specifying the associated package.
— Jenny
On Jul 20, 2015, at 2:05 PM, sbihorel
wrote:
Hi,
Thanks to your suggestions and those of other responders, I was able to get rid
of the warning messages returned during R CMD check.
However I am still confused by the .Rd file-related warnings I get when we
install the packages. For instance:
Rd warning: /tmp/some/path/man/pkgC_function_009.Rd:21: missing file link
"panel.abline"
I typed: \code{\link[lattice]{panel.abline}} on line 21 for the Rd file.
My NAMESPACE file includes:
importFrom(lattice,panel.abline)
Surprisingly, other cross-references to lattice functions also imported using
importFrom do not generate warning upon installation.
When I consider the full list of function links that generate warnings, it
looks like all of them are associated with alias rather than name tags in the
target .Rd file (for instance, panel.abline is documented in a .Rd file with
\name{panel.functions}).
The CRAN manual is not clear on this point. Is there a specific syntax to use
to document this types of links?
Thank you again for your time
Sebastien
On 7/15/2015 9:24 AM, Duncan Murdoch wrote:
On 15/07/2015 9:07 AM, sbihorel wrote:
Hi,
I saw a few recent posts on topics related to mine (eg
https://stat.ethz.ch/pipermail/r-package-devel/2015q3/000238.html). It
looks like I need to import more packages in my NAMESPACE, correct?
However, I thought that imports would be recursive, ie imports would
also get the info from dependent packages.
I haven't been following this thread, but the 2nd para above makes it
sound as though an explanation of the NAMESPACE directives would be helpful.
If you say
importFrom(Hmisc, latex)
it acts as though you have made a copy of the Hmisc::latex function
within your package environment. (It isn't exported, unless you ask to
export it.)
If you say
import(Hmisc)
it acts as though you have made copies of every exported function from
Hmisc within your package environment. This is why we recommend
importing only the functions you need; otherwise your package
environment gets bloated.
No recursive copies are made, unless Hmisc happens to import something
and re-exports it.
When I say "acts as though", I don't mean it literally makes copies; it
implements this in a more efficient way, basically only copying pointers
to those functions -- but from a user point of view, you shouldn't be
able to tell the difference, since you're not allowed to modify
Hmisc::latex.
Duncan Murdoch
Sebastien
On 7/13/2015 9:42 PM, sbihorel wrote:
Hi,
Sorry about the table. It looked good when displayed using a fixed
width font. Let me try to linearize it:
* pkgA
o DESCRIPTION:
+ Depends: methods, lattice, grid, gam
+ Imports: Hmisc, survival
o NAMESPACE:
+ import: lattice, grid, gam, methods
+ importFrom: Hmisc (one function)
* pkgB
o DESCRIPTION:
+ Depends: pkgA
+ Imports:
o NAMESPACE:
+ import: pkgA
+ importFrom:
o NAMESPACE:
+ import: methods, pkgB
+ importFrom:
Are you exporting the functions from pkgB and pk
[R-pkg-devel] Appropriate place to post about CRAN check environments etc.
There has been some disagreement on where it is appropriate to post questions about package checking procedures, including the building of the environment e.g., R-devel under Linux Mint. In looking at https://www.r-project.org/mail.html, it seems to me that the procedures belong with r-package-devel, but there doesn't seem to be a good home for the consequent need to build R-devel to do this. Have I missed the appropriate list? It seems to me that the volume of queries of this sort, and the success of WinBuilder, suggest we could seriously use similar a Linbuilder and MacBuilder (and possibly others). There's a lot of duplicated effort being wasted on the R-devel side in particular. Is there sufficient interest to - make the effort to emulate Winbuilder for Linux and/or Mac - coordinate the volunteer effort - fund/support the necessary infrastructure (it could be worth a modest contribution to save effort)? For the record, I'm willing to participate. I've managed to set up Linux Mint VirtualBox instances that run R current and R devel for testing, though I find I must do more work than I'd like to maintain things, likely as a result of my own limited skills. JN __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] Appropriate place to post about CRAN check environments etc.
On 21/07/2015 9:01 AM, ProfJCNash wrote: > > There has been some disagreement on where it is appropriate to post > questions about package checking procedures, including the building of > the environment e.g., R-devel under Linux Mint. > > In looking at https://www.r-project.org/mail.html, it seems to me that > the procedures belong with r-package-devel, but there doesn't seem to be > a good home for the consequent need to build R-devel to do this. Have I > missed the appropriate list? > > It seems to me that the volume of queries of this sort, and the success > of WinBuilder, suggest we could seriously use similar a Linbuilder and > MacBuilder (and possibly others). There's a lot of duplicated effort > being wasted on the R-devel side in particular. > > Is there sufficient interest to > - make the effort to emulate Winbuilder for Linux and/or Mac > - coordinate the volunteer effort > - fund/support the necessary infrastructure (it could be worth a modest > contribution to save effort)? > > For the record, I'm willing to participate. I've managed to set up Linux > Mint VirtualBox instances that run R current and R devel for testing, > though I find I must do more work than I'd like to maintain things, > likely as a result of my own limited skills. That sounds like the sort of project the R Consortium would support. They are just getting started, but soon they will have a committee set up to decide on projects, and presumably soon after that will have a process in place to solicit them. Duncan Murdoch __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] Appropriate place to post about CRAN check environments etc.
On 21 July 2015 at 11:46, Duncan Murdoch wrote: > On 21/07/2015 9:01 AM, ProfJCNash wrote: >> >> There has been some disagreement on where it is appropriate to post >> questions about package checking procedures, including the building of >> the environment e.g., R-devel under Linux Mint. >> >> In looking at https://www.r-project.org/mail.html, it seems to me that >> the procedures belong with r-package-devel, but there doesn't seem to be >> a good home for the consequent need to build R-devel to do this. Have I >> missed the appropriate list? >> >> It seems to me that the volume of queries of this sort, and the success >> of WinBuilder, suggest we could seriously use similar a Linbuilder and >> MacBuilder (and possibly others). There's a lot of duplicated effort >> being wasted on the R-devel side in particular. >> >> Is there sufficient interest to >> - make the effort to emulate Winbuilder for Linux and/or Mac >> - coordinate the volunteer effort >> - fund/support the necessary infrastructure (it could be worth a modest >> contribution to save effort)? >> >> For the record, I'm willing to participate. I've managed to set up Linux >> Mint VirtualBox instances that run R current and R devel for testing, >> though I find I must do more work than I'd like to maintain things, >> likely as a result of my own limited skills. > > That sounds like the sort of project the R Consortium would support. > They are just getting started, but soon they will have a committee set > up to decide on projects, and presumably soon after that will have a > process in place to solicit them. > > Duncan Murdoch In my humble opinion, such a project could be of great utility to several people that is starting to migrate to GNU/Linux, or to people willing to test their packages with the latest development version of R but without all the knowledge to properly set up the environment on their local machines. If I can contribute to a "LinBuilder" (e.g., testing), I would be willing to do it. Kind regards, Mauricio Zambrano-Bigiarini, PhD = Dept. of Civil Engineering Faculty of Engineering and Sciences Universidad de La Frontera PO Box 54-D, Temuco, Chile = mailto : mauricio.zambr...@ufrontera.cl work-phone : +56 45 259 2812 http://ingenieriacivil.ufro.cl/ = "When the pupil is ready, the master arrives." (Zen proverb) = Linux user #454569 -- Linux Mint user > > __ > 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] Appropriate place to post about CRAN check environments etc.
Perhaps I have missed some detail, but would Gabor Csardi's r-builder code not provide this (or something close to it) for Linux at least? See: https://github.com/metacran/r-builder This builds on the R support for Travis CI, and allows for testing against R-release and R-devel (plus R-oldrelease IIRC) It's pretty trivial to set-up but you do need your code in a github repo (for the Travis deployment - I don't know anything about Semaphore, the other option r-builder allows for). G On 21 July 2015 at 09:04, MAURICIO ZAMBRANO BIGIARINI < mauricio.zambr...@ufrontera.cl> wrote: > On 21 July 2015 at 11:46, Duncan Murdoch wrote: > > On 21/07/2015 9:01 AM, ProfJCNash wrote: > >> > >> There has been some disagreement on where it is appropriate to post > >> questions about package checking procedures, including the building of > >> the environment e.g., R-devel under Linux Mint. > >> > >> In looking at https://www.r-project.org/mail.html, it seems to me that > >> the procedures belong with r-package-devel, but there doesn't seem to be > >> a good home for the consequent need to build R-devel to do this. Have I > >> missed the appropriate list? > >> > >> It seems to me that the volume of queries of this sort, and the success > >> of WinBuilder, suggest we could seriously use similar a Linbuilder and > >> MacBuilder (and possibly others). There's a lot of duplicated effort > >> being wasted on the R-devel side in particular. > >> > >> Is there sufficient interest to > >> - make the effort to emulate Winbuilder for Linux and/or Mac > >> - coordinate the volunteer effort > >> - fund/support the necessary infrastructure (it could be worth a modest > >> contribution to save effort)? > >> > >> For the record, I'm willing to participate. I've managed to set up Linux > >> Mint VirtualBox instances that run R current and R devel for testing, > >> though I find I must do more work than I'd like to maintain things, > >> likely as a result of my own limited skills. > > > > That sounds like the sort of project the R Consortium would support. > > They are just getting started, but soon they will have a committee set > > up to decide on projects, and presumably soon after that will have a > > process in place to solicit them. > > > > Duncan Murdoch > > In my humble opinion, such a project could be of great utility to > several people that is starting to migrate to GNU/Linux, or to people > willing to test their packages with the latest development version of > R but without all the knowledge to properly set up the environment on > their local machines. > > If I can contribute to a "LinBuilder" (e.g., testing), I would be > willing to do it. > > Kind regards, > > > Mauricio Zambrano-Bigiarini, PhD > > = > Dept. of Civil Engineering > Faculty of Engineering and Sciences > Universidad de La Frontera > PO Box 54-D, Temuco, Chile > = > mailto : mauricio.zambr...@ufrontera.cl > work-phone : +56 45 259 2812 > http://ingenieriacivil.ufro.cl/ > = > "When the pupil is ready, the master arrives." > (Zen proverb) > = > Linux user #454569 -- Linux Mint user > > > > > __ > > 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 > -- Gavin Simpson, PhD [[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] Appropriate place to post about CRAN check environments etc.
On Tue, Jul 21, 2015 at 2:35 PM, Gavin Simpson wrote: > Perhaps I have missed some detail, but would Gabor Csardi's r-builder code > not provide this (or something close to it) for Linux at least? See: > https://github.com/metacran/r-builder It does, although it only does Ubuntu 12.04 if you use Travis, because that's what Travis has. IMHO this does not really matter for 95% of the packages, and having R-devel in addition to R-release and R-oldrel is more important. > This builds on the R support for Travis CI, and allows for testing against > R-release and R-devel (plus R-oldrelease IIRC) It actually does not build on R support for Travis CI. Since it needs its own R installations, it does not make much sense to use the built-in R support. > It's pretty trivial to set-up but you do need your code in a github repo > (for the Travis deployment - I don't know anything about Semaphore, the > other option r-builder allows for). Yeah, it needs to be on GitHub. Gabor > G > > On 21 July 2015 at 09:04, MAURICIO ZAMBRANO BIGIARINI < > mauricio.zambr...@ufrontera.cl> wrote: > >> On 21 July 2015 at 11:46, Duncan Murdoch wrote: >> > On 21/07/2015 9:01 AM, ProfJCNash wrote: >> >> >> >> There has been some disagreement on where it is appropriate to post >> >> questions about package checking procedures, including the building of >> >> the environment e.g., R-devel under Linux Mint. >> >> >> >> In looking at https://www.r-project.org/mail.html, it seems to me that >> >> the procedures belong with r-package-devel, but there doesn't seem to be >> >> a good home for the consequent need to build R-devel to do this. Have I >> >> missed the appropriate list? >> >> >> >> It seems to me that the volume of queries of this sort, and the success >> >> of WinBuilder, suggest we could seriously use similar a Linbuilder and >> >> MacBuilder (and possibly others). There's a lot of duplicated effort >> >> being wasted on the R-devel side in particular. >> >> >> >> Is there sufficient interest to >> >> - make the effort to emulate Winbuilder for Linux and/or Mac >> >> - coordinate the volunteer effort >> >> - fund/support the necessary infrastructure (it could be worth a modest >> >> contribution to save effort)? >> >> >> >> For the record, I'm willing to participate. I've managed to set up Linux >> >> Mint VirtualBox instances that run R current and R devel for testing, >> >> though I find I must do more work than I'd like to maintain things, >> >> likely as a result of my own limited skills. >> > >> > That sounds like the sort of project the R Consortium would support. >> > They are just getting started, but soon they will have a committee set >> > up to decide on projects, and presumably soon after that will have a >> > process in place to solicit them. >> > >> > Duncan Murdoch >> >> In my humble opinion, such a project could be of great utility to >> several people that is starting to migrate to GNU/Linux, or to people >> willing to test their packages with the latest development version of >> R but without all the knowledge to properly set up the environment on >> their local machines. >> >> If I can contribute to a "LinBuilder" (e.g., testing), I would be >> willing to do it. >> >> Kind regards, >> >> >> Mauricio Zambrano-Bigiarini, PhD >> >> = >> Dept. of Civil Engineering >> Faculty of Engineering and Sciences >> Universidad de La Frontera >> PO Box 54-D, Temuco, Chile >> = >> mailto : mauricio.zambr...@ufrontera.cl >> work-phone : +56 45 259 2812 >> http://ingenieriacivil.ufro.cl/ >> = >> "When the pupil is ready, the master arrives." >> (Zen proverb) >> = >> Linux user #454569 -- Linux Mint user >> >> > >> > __ >> > 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 >> > > > > -- > Gavin Simpson, PhD > > [[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] Help needed to setting custom packages for R 3.1.2
Sebastien: thanks for sharing the definitive solution!
To the people on this list with the power to edit "Writing R Extensions":
When a discussion here suggests a specific improvement, what is the best way
for the community to propose a revision? So that knowledge gets transferred
from this list to the relevant reference document and heads off future
questions.
In this thread, we converged on cross-reference via \link[pkg:bar]{foo}.
Section “2.5 Cross-references” in "Writing R Extensions” describes this type of
cross-reference like so:
"These are rarely needed, perhaps to refer to not-yet-installed packages or in
the normally undesirable event that more than one package offers help on a
topic.”
But it can also be necessary when the author of package “pkg" has documented
multiple things, including “foo”, in a single file, such as “bar”. This seems
to be a sufficiently distinct and common scenario to merit a mention.
— Jenny
> On Jul 21, 2015, at 5:59 AM, sbihorel
> wrote:
>
> Hi Jennifer,
>
> Following your suggestions and after a couple of trial-and-error steps, I
> believe the syntax is the following:
>
> \code{\link[name_of_package:name_of_Rd_file]{alias_or_text}}
>
> For instance, to link to panel.abline or strip.custom from the lattice
> package, I used:
>
> \code{\link[lattice:panel.functions]{panel.abline}}
> \code{\link[lattice:strip.default]{panel.custom}}
>
> Using this notation I was able to make all warnings disappear upon
> installation of my package.
>
> Typically, you can extract the name of the Rd file from the ? help page
> (upper left corner info). But this is not 100% reliable if the maintainer of
> the package is not consistent in the way (s)he documents the package.
>
> Thanks a lot for your help.
>
> Sebastien
>
>
> On 7/20/2015 5:45 PM, Jennifer Bryan wrote:
>> Hi Sebastien,
>>
>> This note about Rd warnings reminded me that I recently had the same
>> problem. So I recreated it and, I think, have found a solution.
>>
>> I will explain in my specific example to be clear.
>>
>> I need to link to the docs for the Token2.0 class from the httr package.
>> First thing you try:
>>
>> \code{\link[httr]{Token2.0}}
>>
>> but then you get the warnings you describe upon installation. As in your
>> case, the Token2.0 class doesn’t have it’s own .Rd file but is, rather,
>> documented in the topic titled “Token-class”.
>>
>> Next thing you try:
>>
>> \code{\link[httr]{Token-class}}
>>
>> which works, but I don’t like this display text — it doesn’t really make
>> sense in the context of *my* documentation.
>>
>> Finally you do this:
>>
>> \code{\link[=Token-class]{Token2.0}}
>>
>> to link to the correct topic but get the desired display text. However, I am
>> no longer specifying that this topic is from the httr package, but it seems
>> to work.
>>
>> Maybe someone else can weigh in with more insight about the need /
>> desirability of specifying the associated package.
>>
>> — Jenny
>>
>>> On Jul 20, 2015, at 2:05 PM, sbihorel
>>> wrote:
>>>
>>> Hi,
>>>
>>> Thanks to your suggestions and those of other responders, I was able to get
>>> rid of the warning messages returned during R CMD check.
>>>
>>> However I am still confused by the .Rd file-related warnings I get when we
>>> install the packages. For instance:
>>>
>>> Rd warning: /tmp/some/path/man/pkgC_function_009.Rd:21: missing file link
>>> "panel.abline"
>>>
>>> I typed: \code{\link[lattice]{panel.abline}} on line 21 for the Rd file.
>>>
>>> My NAMESPACE file includes:
>>>
>>> importFrom(lattice,panel.abline)
>>>
>>> Surprisingly, other cross-references to lattice functions also imported
>>> using importFrom do not generate warning upon installation.
>>>
>>> When I consider the full list of function links that generate warnings, it
>>> looks like all of them are associated with alias rather than name tags in
>>> the target .Rd file (for instance, panel.abline is documented in a .Rd file
>>> with \name{panel.functions}).
>>>
>>> The CRAN manual is not clear on this point. Is there a specific syntax to
>>> use to document this types of links?
>>>
>>> Thank you again for your time
>>>
>>> Sebastien
>>>
>>>
>>> On 7/15/2015 9:24 AM, Duncan Murdoch wrote:
On 15/07/2015 9:07 AM, sbihorel wrote:
> Hi,
>
> I saw a few recent posts on topics related to mine (eg
> https://stat.ethz.ch/pipermail/r-package-devel/2015q3/000238.html). It
> looks like I need to import more packages in my NAMESPACE, correct?
>
> However, I thought that imports would be recursive, ie imports would
> also get the info from dependent packages.
I haven't been following this thread, but the 2nd para above makes it
sound as though an explanation of the NAMESPACE directives would be
helpful.
If you say
importFrom(Hmisc, latex)
it acts as though you have made a copy of the Hmisc::latex function
within your packa
Re: [R-pkg-devel] Help needed to setting custom packages for R 3.1.2
On 21/07/2015 2:08 PM, Jennifer Bryan wrote:
> Sebastien: thanks for sharing the definitive solution!
>
> To the people on this list with the power to edit "Writing R Extensions":
>
> When a discussion here suggests a specific improvement, what is the best way
> for the community to propose a revision? So that knowledge gets transferred
> from this list to the relevant reference document and heads off future
> questions.
The best way is to use svn to get a copy of the manual from R-devel,
make the change yourself and test it, and use "svn diff" to produce a
patch file. Post a description of why you made the change and include a
copy of the patch to the R-devel list. The source for WRE is in
https://svn.r-project.org/R/trunk/doc/manual/R-exts.texi
Nearly as good is to just grab the source and make the change, using
some other diff method, and post about it on R-devel. But then the
change should be very simple.
Also good from your point of view is to convince someone with write
access that the change is a good idea and get them to do all the work,
but you'd be surprised how hard that is.
Duncan Murdoch
> In this thread, we converged on cross-reference via \link[pkg:bar]{foo}.
> Section “2.5 Cross-references” in "Writing R Extensions” describes this type
> of cross-reference like so:
>
> "These are rarely needed, perhaps to refer to not-yet-installed packages or
> in the normally undesirable event that more than one package offers help on a
> topic.”
>
> But it can also be necessary when the author of package “pkg" has documented
> multiple things, including “foo”, in a single file, such as “bar”. This seems
> to be a sufficiently distinct and common scenario to merit a mention.
>
> — Jenny
>
>> On Jul 21, 2015, at 5:59 AM, sbihorel
>> wrote:
>>
>> Hi Jennifer,
>>
>> Following your suggestions and after a couple of trial-and-error steps, I
>> believe the syntax is the following:
>>
>> \code{\link[name_of_package:name_of_Rd_file]{alias_or_text}}
>>
>> For instance, to link to panel.abline or strip.custom from the lattice
>> package, I used:
>>
>> \code{\link[lattice:panel.functions]{panel.abline}}
>> \code{\link[lattice:strip.default]{panel.custom}}
>>
>> Using this notation I was able to make all warnings disappear upon
>> installation of my package.
>>
>> Typically, you can extract the name of the Rd file from the ? help page
>> (upper left corner info). But this is not 100% reliable if the maintainer of
>> the package is not consistent in the way (s)he documents the package.
>>
>> Thanks a lot for your help.
>>
>> Sebastien
>>
>>
>> On 7/20/2015 5:45 PM, Jennifer Bryan wrote:
>>> Hi Sebastien,
>>>
>>> This note about Rd warnings reminded me that I recently had the same
>>> problem. So I recreated it and, I think, have found a solution.
>>>
>>> I will explain in my specific example to be clear.
>>>
>>> I need to link to the docs for the Token2.0 class from the httr package.
>>> First thing you try:
>>>
>>> \code{\link[httr]{Token2.0}}
>>>
>>> but then you get the warnings you describe upon installation. As in your
>>> case, the Token2.0 class doesn’t have it’s own .Rd file but is, rather,
>>> documented in the topic titled “Token-class”.
>>>
>>> Next thing you try:
>>>
>>> \code{\link[httr]{Token-class}}
>>>
>>> which works, but I don’t like this display text — it doesn’t really make
>>> sense in the context of *my* documentation.
>>>
>>> Finally you do this:
>>>
>>> \code{\link[=Token-class]{Token2.0}}
>>>
>>> to link to the correct topic but get the desired display text. However, I
>>> am no longer specifying that this topic is from the httr package, but it
>>> seems to work.
>>>
>>> Maybe someone else can weigh in with more insight about the need /
>>> desirability of specifying the associated package.
>>>
>>> — Jenny
>>>
On Jul 20, 2015, at 2:05 PM, sbihorel
wrote:
Hi,
Thanks to your suggestions and those of other responders, I was able to
get rid of the warning messages returned during R CMD check.
However I am still confused by the .Rd file-related warnings I get when we
install the packages. For instance:
Rd warning: /tmp/some/path/man/pkgC_function_009.Rd:21: missing file link
"panel.abline"
I typed: \code{\link[lattice]{panel.abline}} on line 21 for the Rd file.
My NAMESPACE file includes:
importFrom(lattice,panel.abline)
Surprisingly, other cross-references to lattice functions also imported
using importFrom do not generate warning upon installation.
When I consider the full list of function links that generate warnings, it
looks like all of them are associated with alias rather than name tags in
the target .Rd file (for instance, panel.abline is documented in a .Rd
file with \name{panel.functions}).
The CRAN manual is not clear on this point. Is there a specific syntax to
use to document this types of
Re: [R-pkg-devel] Appropriate place to post about CRAN check environments etc.
Probably I'm too distrustful, but yesterday I tried to use Travis CI and at the end I didn't do it, because of the permissions you're requested to give to the application: Review permissions: Personal user data : Email addresses (read-only) Repository webhooks and services: Read and write access Commit statuses : Read and write access Deployments : Manage deployments and deployment status Organizations and teams: Read-only access Mauricio = "When the pupil is ready, the master arrives." (Zen proverb) = Linux user #454569 -- Linux Mint user On 21 July 2015 at 15:45, Gábor Csárdi wrote: > On Tue, Jul 21, 2015 at 2:35 PM, Gavin Simpson wrote: >> Perhaps I have missed some detail, but would Gabor Csardi's r-builder code >> not provide this (or something close to it) for Linux at least? See: >> https://github.com/metacran/r-builder > > It does, although it only does Ubuntu 12.04 if you use Travis, because > that's what Travis has. IMHO this does not really matter for 95% of > the packages, and having R-devel in addition to R-release and R-oldrel > is more important. > >> This builds on the R support for Travis CI, and allows for testing against >> R-release and R-devel (plus R-oldrelease IIRC) > > It actually does not build on R support for Travis CI. Since it needs > its own R installations, it does not make much sense to use the > built-in R support. > >> It's pretty trivial to set-up but you do need your code in a github repo >> (for the Travis deployment - I don't know anything about Semaphore, the >> other option r-builder allows for). > > Yeah, it needs to be on GitHub. > > Gabor > >> G >> >> On 21 July 2015 at 09:04, MAURICIO ZAMBRANO BIGIARINI < >> mauricio.zambr...@ufrontera.cl> wrote: >> >>> On 21 July 2015 at 11:46, Duncan Murdoch wrote: >>> > On 21/07/2015 9:01 AM, ProfJCNash wrote: >>> >> >>> >> There has been some disagreement on where it is appropriate to post >>> >> questions about package checking procedures, including the building of >>> >> the environment e.g., R-devel under Linux Mint. >>> >> >>> >> In looking at https://www.r-project.org/mail.html, it seems to me that >>> >> the procedures belong with r-package-devel, but there doesn't seem to be >>> >> a good home for the consequent need to build R-devel to do this. Have I >>> >> missed the appropriate list? >>> >> >>> >> It seems to me that the volume of queries of this sort, and the success >>> >> of WinBuilder, suggest we could seriously use similar a Linbuilder and >>> >> MacBuilder (and possibly others). There's a lot of duplicated effort >>> >> being wasted on the R-devel side in particular. >>> >> >>> >> Is there sufficient interest to >>> >> - make the effort to emulate Winbuilder for Linux and/or Mac >>> >> - coordinate the volunteer effort >>> >> - fund/support the necessary infrastructure (it could be worth a modest >>> >> contribution to save effort)? >>> >> >>> >> For the record, I'm willing to participate. I've managed to set up Linux >>> >> Mint VirtualBox instances that run R current and R devel for testing, >>> >> though I find I must do more work than I'd like to maintain things, >>> >> likely as a result of my own limited skills. >>> > >>> > That sounds like the sort of project the R Consortium would support. >>> > They are just getting started, but soon they will have a committee set >>> > up to decide on projects, and presumably soon after that will have a >>> > process in place to solicit them. >>> > >>> > Duncan Murdoch >>> >>> In my humble opinion, such a project could be of great utility to >>> several people that is starting to migrate to GNU/Linux, or to people >>> willing to test their packages with the latest development version of >>> R but without all the knowledge to properly set up the environment on >>> their local machines. >>> >>> If I can contribute to a "LinBuilder" (e.g., testing), I would be >>> willing to do it. >>> >>> Kind regards, >>> >>> >>> Mauricio Zambrano-Bigiarini, PhD >>> >>> = >>> Dept. of Civil Engineering >>> Faculty of Engineering and Sciences >>> Universidad de La Frontera >>> PO Box 54-D, Temuco, Chile >>> = >>> mailto : mauricio.zambr...@ufrontera.cl >>> work-phone : +56 45 259 2812 >>> http://ingenieriacivil.ufro.cl/ >>> = >>> "When the pupil is ready, the master arrives." >>> (Zen proverb) >>> = >>> Linux user #454569 -- Linux Mint user >>> >>> > >>> > __ >>> > 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-packag
[R-pkg-devel] Packages from other maintainers with win-builder
Hello all, As I can only easily access computers with Linux, I am very grateful for the existence of win-builder to test my packages with Windows. Today I encountered an issue with win-builder that took me a while to figure out. My package was failing unit tests on win-builder but I couldn't reproduce the problem with my setup. It turned out that win-builder was using an unstable version of a package (with a bug) my package depended on that must have been uploaded by its maintainer recently. I realize that it's the side effect of the very useful feature of being able to upload packages serially. However, I am wondering if it would be possible to implement a way to avoid this kind of situation and to have an option to ask win-builder to only use the CRAN version of the packages listed in DESCRIPTION? Thanks, -- François __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] Packages from other maintainers with win-builder
Sounds like a good proposal, but currently this is not implemented. Best, Uwe Ligges On 22.07.2015 01:10, François Michonneau wrote: Hello all, As I can only easily access computers with Linux, I am very grateful for the existence of win-builder to test my packages with Windows. Today I encountered an issue with win-builder that took me a while to figure out. My package was failing unit tests on win-builder but I couldn't reproduce the problem with my setup. It turned out that win-builder was using an unstable version of a package (with a bug) my package depended on that must have been uploaded by its maintainer recently. I realize that it's the side effect of the very useful feature of being able to upload packages serially. However, I am wondering if it would be possible to implement a way to avoid this kind of situation and to have an option to ask win-builder to only use the CRAN version of the packages listed in DESCRIPTION? Thanks, -- François __ 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
