[Rd] how to return a matrix of strings from c to R ?
I am a bit confused about usage of R internal functions. I am able to send a
char vector from C to R but not sure on how to send a vector of strings etc.
My code looks like this.
SEXP result =
PROTECT(Rf_allocMatrix(STRSXP,s->n_rics,s->n_fields));
int i,j;
for (i=0; i < s->n_rics; i++)
{
for (j=0; j < s->n_fields; j++)
{
std::string text = s->data[j][i];
result[j][i] = R_alloc( text.length(),
sizeof(char));
//strcpy(result[j][i], text.c_str());
SET_STRING_ELT(result[j][i],0,Rf_mkChar(text.c_str()));
}
}
// memcpy(result,s->data.ref(),s->n_fields*s->n_rics*sizeof(200));
UNPROTECT(1);
return result;
Can someone please make me understand this usecase and how to resolve it?
thanks,
Alok
--
View this message in context:
http://r.789695.n4.nabble.com/how-to-return-a-matrix-of-strings-from-c-to-R-tp3900763p3900763.html
Sent from the R devel mailing list archive at Nabble.com.
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] NOTE: unstated dependencies in examples
On 10/13/2011 11:34 AM, Uwe Ligges wrote:
I looked at the code and since this is not that trivial to change, I
think we can well live with typing
grep -r gplots ./man
which is not too hard to run on the source package, I believe.
Best wishes,
Uwe
Yes, that's quite easy, if I wanted to search for files mentioning
gplots. However, the NOTE was misleading:
'library' or 'require' calls not declared from:
gplots sp
suggesting that I had used a function from those packages somewhere
without a library() or require(). It turned out that I had just omitted
those packages from the Suggests: line in DESCRIPTION. So,
perhaps it would be more informative to say:
'library' or 'require' calls not declared in Depends: or Suggests: from:
gplots sp
-Michael
On 13.10.2011 03:00, Yihui Xie wrote:
You have this in Jevons.Rd:
# show as balloonplots
if (require(gplots)) {
and this in Snow.Rd:
%\dontrun{
library(sp)
It will certainly be helpful if R CMD check can provide more
informative messages (in this case, e.g, point out the Rd files).
Regards,
Yihui
--
Yihui Xie
Phone: 515-294-2465 Web: http://yihui.name
Department of Statistics, Iowa State University
2215 Snedecor Hall, Ames, IA
On Wed, Oct 12, 2011 at 11:33 AM, Michael Friendly
wrote:
Using R 2.13.1, I am now getting the following NOTE when I run R CMD
check
on my HistData
package
* checking for unstated dependencies in examples ... NOTE
'library' or 'require' calls not declared from:
gplots sp
Under R 2.12.x, I didn't get these notes.
I have ~ 25 .Rd files in this package, and AFAICS, every example uses
library or require for the
functions used; the DESCRIPTION file has the long list of Suggests,
which
previously was sufficient
for packages used in examples.
Suggests: gtools, KernSmooth, maps, ggplot2, proto, grid, reshape, plyr,
lattice, ReadImages, car
But I have no way to find the .Rd file(s) that triggered this note.
What is the tool used in R CMD check to make this diagnosis? It would be
better
if this reported the .Rd file(s) that triggered this note.
Is it possible that this note could be specious?
-Michael
--
Michael Friendly Email: friendly AT yorku DOT ca
Professor, Psychology Dept.
York University Voice: 416 736-5115 x66249 Fax: 416 736-5814
4700 Keele Street Web: http://www.datavis.ca
Toronto, ONT M3J 1P3 CANADA
__
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
--
Michael Friendly Email: friendly AT yorku DOT ca
Professor, Psychology Dept.
York University Voice: 416 736-5115 x66249 Fax: 416 736-5814
4700 Keele StreetWeb: http://www.datavis.ca
Toronto, ONT M3J 1P3 CANADA
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] NOTE: unstated dependencies in examples
On Thu, 2011-10-13 at 17:34 +0200, Uwe Ligges wrote:
> I looked at the code and since this is not that trivial to change, I
> think we can well live with typing
>
> grep -r gplots ./man
>
> which is not too hard to run on the source package, I believe.
>
> Best wishes,
> Uwe
>
Uwe & others,
This is OK if you want to identify the cause of the problems. However,
the basic problem was that checking required something that is not
required: there was one example that was not run, and one case where the
loading of the package was not necessary (if(require())). I do
believe that handling this kind of cases is difficult in automatic
checking. However, I think they need not be checked: there should be a
new case of package reference in addition to 'depends', 'suggests' and
'enhances' -- something like 'benefitsfrom'.
This is now actual to me, since I'm adding 'parallel' support to my
package, but there seems to be no clean way of doing this with the
current checking procedures. I use the 'parallel' support only if the
package is available (in R >= 2.14.0, not yet released), and there are
multiple cores. If there is only once cpu or there is not yet
'parallel' package, nothing bad will happen: things will only work like
they worked earlier without 'parallel' package. I haven't found out how
to do this cleanly for R CMD check (it is clean for my code since there
the usage is checked). If I add "suggests: parallel" I get R CMD check
error for the current and previous R -- for no reason. So currently I
don't mention 'parallel' at all in DESCRIPTION: I get a NOTE and
Warnings ('require' call not declared, no visible definitions), but this
is a smaller problem than having a spurious failure, and failing to
have this package for a system where it works quite normally.
The new DESCRIPTION keyword could be used for packages that are useful
but not necessary, so that the package can be quite well be used without
these packages, but it may have some extra options or functionality with
those packages. This sounds like a suggestion to me, but in R language
suggestions cannot be refused.
Cheers, jari oksanen
>
> On 13.10.2011 03:00, Yihui Xie wrote:
> > You have this in Jevons.Rd:
> >
> > # show as balloonplots
> >
> > if (require(gplots)) {
> >
> >
> > and this in Snow.Rd:
> >
> > %\dontrun{
> >
> > library(sp)
> >
> >
> > It will certainly be helpful if R CMD check can provide more
> > informative messages (in this case, e.g, point out the Rd files).
> >
> > Regards,
> > Yihui
> > --
> > Yihui Xie
> > Phone: 515-294-2465 Web: http://yihui.name
> > Department of Statistics, Iowa State University
> > 2215 Snedecor Hall, Ames, IA
> >
> >
> >
> > On Wed, Oct 12, 2011 at 11:33 AM, Michael Friendly
> > wrote:
> >> Using R 2.13.1, I am now getting the following NOTE when I run R CMD check
> >> on my HistData
> >> package
> >>
> >> * checking for unstated dependencies in examples ... NOTE
> >> 'library' or 'require' calls not declared from:
> >> gplots sp
> >>
> >> Under R 2.12.x, I didn't get these notes.
> >>
> >> I have ~ 25 .Rd files in this package, and AFAICS, every example uses
> >> library or require for the
> >> functions used; the DESCRIPTION file has the long list of Suggests, which
> >> previously was sufficient
> >> for packages used in examples.
> >>
> >> Suggests: gtools, KernSmooth, maps, ggplot2, proto, grid, reshape, plyr,
> >> lattice, ReadImages, car
> >>
> >> But I have no way to find the .Rd file(s) that triggered this note.
> >>
> >> What is the tool used in R CMD check to make this diagnosis? It would be
> >> better
> >> if this reported the .Rd file(s) that triggered this note.
> >> Is it possible that this note could be specious?
> >>
> >> -Michael
> >>
> >> --
> >> Michael Friendly Email: friendly AT yorku DOT ca
> >> Professor, Psychology Dept.
> >> York University Voice: 416 736-5115 x66249 Fax: 416 736-5814
> >> 4700 Keele StreetWeb: http://www.datavis.ca
> >> Toronto, ONT M3J 1P3 CANADA
> >>
> >> __
> >> 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
>
> __
> 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] NOTE: unstated dependencies in examples
On 14/10/2011 9:18 AM, Jari Oksanen wrote:
On Thu, 2011-10-13 at 17:34 +0200, Uwe Ligges wrote:
> I looked at the code and since this is not that trivial to change, I
> think we can well live with typing
>
> grep -r gplots ./man
>
> which is not too hard to run on the source package, I believe.
>
> Best wishes,
> Uwe
>
Uwe& others,
This is OK if you want to identify the cause of the problems. However,
the basic problem was that checking required something that is not
required: there was one example that was not run, and one case where the
loading of the package was not necessary (if(require())). I do
believe that handling this kind of cases is difficult in automatic
checking. However, I think they need not be checked: there should be a
new case of package reference in addition to 'depends', 'suggests' and
'enhances' -- something like 'benefitsfrom'.
Users use those declarations when they ask to install dependencies. If
you don't declare a dependence on a contributed package, users will have
to manually install it.
This is now actual to me, since I'm adding 'parallel' support to my
package, but there seems to be no clean way of doing this with the
current checking procedures. I use the 'parallel' support only if the
package is available (in R>= 2.14.0, not yet released), and there are
multiple cores.
Temporarily maintain two releases of your package: one for R < 2.14.0
that doesn't mention parallel, and one for R >= 2.14.0 that does. The
second one should declare its dependence on R >= 2.14.0. If support for
parallel is your only change, you don't need to do anything for the
previous one: CRAN will not replace it in the 2.13.x repository if the
new one needs a newer R.
Duncan Murdoch
If there is only once cpu or there is not yet
'parallel' package, nothing bad will happen: things will only work like
they worked earlier without 'parallel' package. I haven't found out how
to do this cleanly for R CMD check (it is clean for my code since there
the usage is checked). If I add "suggests: parallel" I get R CMD check
error for the current and previous R -- for no reason. So currently I
don't mention 'parallel' at all in DESCRIPTION: I get a NOTE and
Warnings ('require' call not declared, no visible definitions), but this
is a smaller problem than having a spurious failure, and failing to
have this package for a system where it works quite normally.
The new DESCRIPTION keyword could be used for packages that are useful
but not necessary, so that the package can be quite well be used without
these packages, but it may have some extra options or functionality with
those packages. This sounds like a suggestion to me, but in R language
suggestions cannot be refused.
Cheers, jari oksanen
>
> On 13.10.2011 03:00, Yihui Xie wrote:
> > You have this in Jevons.Rd:
> >
> > # show as balloonplots
> >
> > if (require(gplots)) {
> >
> >
> > and this in Snow.Rd:
> >
> > %\dontrun{
> >
> > library(sp)
> >
> >
> > It will certainly be helpful if R CMD check can provide more
> > informative messages (in this case, e.g, point out the Rd files).
> >
> > Regards,
> > Yihui
> > --
> > Yihui Xie
> > Phone: 515-294-2465 Web: http://yihui.name
> > Department of Statistics, Iowa State University
> > 2215 Snedecor Hall, Ames, IA
> >
> >
> >
> > On Wed, Oct 12, 2011 at 11:33 AM, Michael Friendly
wrote:
> >> Using R 2.13.1, I am now getting the following NOTE when I run R CMD
check
> >> on my HistData
> >> package
> >>
> >> * checking for unstated dependencies in examples ... NOTE
> >> 'library' or 'require' calls not declared from:
> >>gplots sp
> >>
> >> Under R 2.12.x, I didn't get these notes.
> >>
> >> I have ~ 25 .Rd files in this package, and AFAICS, every example uses
> >> library or require for the
> >> functions used; the DESCRIPTION file has the long list of Suggests,
which
> >> previously was sufficient
> >> for packages used in examples.
> >>
> >> Suggests: gtools, KernSmooth, maps, ggplot2, proto, grid, reshape, plyr,
> >> lattice, ReadImages, car
> >>
> >> But I have no way to find the .Rd file(s) that triggered this note.
> >>
> >>What is the tool used in R CMD check to make this diagnosis? It would
be
> >> better
> >> if this reported the .Rd file(s) that triggered this note.
> >> Is it possible that this note could be specious?
> >>
> >> -Michael
> >>
> >> --
> >> Michael Friendly Email: friendly AT yorku DOT ca
> >> Professor, Psychology Dept.
> >> York University Voice: 416 736-5115 x66249 Fax: 416 736-5814
> >> 4700 Keele StreetWeb: http://www.datavis.ca
> >> Toronto, ONT M3J 1P3 CANADA
> >>
> >> __
> >> R-devel@r-project.org mailing list
> >> https://stat.ethz.ch/mailman/listinfo/r-devel
> >>
> >
> > __
> > R-devel@r-project.org mailing list
> > https
Re: [Rd] how to return a matrix of strings from c to R ?
On Oct 13, 2011, at 3:20 AM, Alok Jadhav wrote:
> I am a bit confused about usage of R internal functions. I am able to send a
> char vector from C to R but not sure on how to send a vector of strings etc.
>
> My code looks like this.
>
>
>
>SEXP result =
> PROTECT(Rf_allocMatrix(STRSXP,s->n_rics,s->n_fields));
>
> int i,j;
> for (i=0; i < s->n_rics; i++)
> {
> for (j=0; j < s->n_fields; j++)
> {
> std::string text = s->data[j][i];
> result[j][i] = R_alloc( text.length(),
> sizeof(char));
> //strcpy(result[j][i], text.c_str());
>
> SET_STRING_ELT(result[j][i],0,Rf_mkChar(text.c_str()));
> }
> }
>
> //memcpy(result,s->data.ref(),s->n_fields*s->n_rics*sizeof(200));
> UNPROTECT(1);
> return result;
>
>
>
> Can someone please make me understand this usecase and how to resolve it?
>
It's more simple than that:
int rows = s->n_rics, cols = s->n_fields;
SEXP result = PROTECT(Rf_allocMatrix(STRSXP, rows, cols));
for (int i = 0; i < rows; i++) for (int j = 0; j < cols; j++)
SET_STRING_ELT(result, i + j * rows, Rf_mkChar(s->data[j][i].c_str()));
UNPROTECT(1);
return result;
Cheers,
Simon
> thanks,
> Alok
>
> --
> View this message in context:
> http://r.789695.n4.nabble.com/how-to-return-a-matrix-of-strings-from-c-to-R-tp3900763p3900763.html
> Sent from the R devel mailing list archive at Nabble.com.
>
> __
> 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] NOTE: unstated dependencies in examples
On 14/10/11 16:26 PM, "Duncan Murdoch" wrote: > On 14/10/2011 9:18 AM, Jari Oksanen wrote: >>> >> Uwe& others, >> >> This is OK if you want to identify the cause of the problems. However, >> the basic problem was that checking required something that is not >> required: there was one example that was not run, and one case where the >> loading of the package was not necessary (if(require())). I do >> believe that handling this kind of cases is difficult in automatic >> checking. However, I think they need not be checked: there should be a >> new case of package reference in addition to 'depends', 'suggests' and >> 'enhances' -- something like 'benefitsfrom'. > > Users use those declarations when they ask to install dependencies. If > you don't declare a dependence on a contributed package, users will have > to manually install it. > Howdy, This is a pretty weak argument in this particular case: 'parallel' is not a contributed package so that you cannot install it. You either have it or you don't have it. In latter case, nothing happens, but everything works like usual. In the former case, you may have some new things. (Having 'parallel' as a contributed package for R < 2.14.0 would be a great idea but not something I dare to suggest.) >> This is now actual to me, since I'm adding 'parallel' support to my >> package, but there seems to be no clean way of doing this with the >> current checking procedures. I use the 'parallel' support only if the >> package is available (in R>= 2.14.0, not yet released), and there are >> multiple cores. > > Temporarily maintain two releases of your package: one for R < 2.14.0 > that doesn't mention parallel, and one for R >= 2.14.0 that does. The > second one should declare its dependence on R >= 2.14.0. If support for > parallel is your only change, you don't need to do anything for the > previous one: CRAN will not replace it in the 2.13.x repository if the > new one needs a newer R. > Forking my package was indeed one of the three alternatives I have considered. In this case forking sounds really weird: for R < 2.13.0 both forks would work identically. The only difference being how they are handled by R checkers. Cheers, Jari Oksanen -- Jari Oksanen, Dept Biology, Univ Oulu, 90014 Finland jari.oksa...@oulu.fi, Ph. +358 400 408593, http://cc.oulu.fi/~jarioksa __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] NOTE: unstated dependencies in examples
On 14/10/2011 10:10 AM, Jari Oksanen wrote: On 14/10/11 16:26 PM, "Duncan Murdoch" wrote: > On 14/10/2011 9:18 AM, Jari Oksanen wrote: >>> >> Uwe& others, >> >> This is OK if you want to identify the cause of the problems. However, >> the basic problem was that checking required something that is not >> required: there was one example that was not run, and one case where the >> loading of the package was not necessary (if(require())). I do >> believe that handling this kind of cases is difficult in automatic >> checking. However, I think they need not be checked: there should be a >> new case of package reference in addition to 'depends', 'suggests' and >> 'enhances' -- something like 'benefitsfrom'. > > Users use those declarations when they ask to install dependencies. If > you don't declare a dependence on a contributed package, users will have > to manually install it. > Howdy, This is a pretty weak argument in this particular case: 'parallel' is not a contributed package so that you cannot install it. You either have it or you don't have it. In latter case, nothing happens, but everything works like usual. In the former case, you may have some new things. (Having 'parallel' as a contributed package for R< 2.14.0 would be a great idea but not something I dare to suggest.) >> This is now actual to me, since I'm adding 'parallel' support to my >> package, but there seems to be no clean way of doing this with the >> current checking procedures. I use the 'parallel' support only if the >> package is available (in R>= 2.14.0, not yet released), and there are >> multiple cores. > > Temporarily maintain two releases of your package: one for R< 2.14.0 > that doesn't mention parallel, and one for R>= 2.14.0 that does. The > second one should declare its dependence on R>= 2.14.0. If support for > parallel is your only change, you don't need to do anything for the > previous one: CRAN will not replace it in the 2.13.x repository if the > new one needs a newer R. > Forking my package was indeed one of the three alternatives I have considered. In this case forking sounds really weird: for R< 2.13.0 both forks would work identically. The only difference being how they are handled by R checkers. I don't see why it's weird to require that a version that uses a facility that is in 2.14.0 but no earlier versions should have to declare that. Sure, you can put all sorts of conditional tests into your code so that it avoids using the new facility in older versions, but isn't it simpler to just declare the dependency and avoid cluttering your code with those tests? Duncan Murdoch __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] NOTE: unstated dependencies in examples
On 14.10.2011 16:15, Duncan Murdoch wrote: On 14/10/2011 10:10 AM, Jari Oksanen wrote: On 14/10/11 16:26 PM, "Duncan Murdoch" wrote: > On 14/10/2011 9:18 AM, Jari Oksanen wrote: >>> >> Uwe& others, >> >> This is OK if you want to identify the cause of the problems. However, >> the basic problem was that checking required something that is not >> required: there was one example that was not run, and one case where the >> loading of the package was not necessary (if(require())). I do >> believe that handling this kind of cases is difficult in automatic >> checking. However, I think they need not be checked: there should be a >> new case of package reference in addition to 'depends', 'suggests' and >> 'enhances' -- something like 'benefitsfrom'. > > Users use those declarations when they ask to install dependencies. If > you don't declare a dependence on a contributed package, users will have > to manually install it. > Howdy, This is a pretty weak argument in this particular case: 'parallel' is not a contributed package so that you cannot install it. You either have it or you don't have it. In latter case, nothing happens, but everything works like usual. In the former case, you may have some new things. (Having 'parallel' as a contributed package for R< 2.14.0 would be a great idea but not something I dare to suggest.) >> This is now actual to me, since I'm adding 'parallel' support to my >> package, but there seems to be no clean way of doing this with the >> current checking procedures. I use the 'parallel' support only if the >> package is available (in R>= 2.14.0, not yet released), and there are >> multiple cores. > > Temporarily maintain two releases of your package: one for R< 2.14.0 > that doesn't mention parallel, and one for R>= 2.14.0 that does. The > second one should declare its dependence on R>= 2.14.0. If support for > parallel is your only change, you don't need to do anything for the > previous one: CRAN will not replace it in the 2.13.x repository if the > new one needs a newer R. > Forking my package was indeed one of the three alternatives I have considered. In this case forking sounds really weird: for R< 2.13.0 both forks would work identically. The only difference being how they are handled by R checkers. I don't see why it's weird to require that a version that uses a facility that is in 2.14.0 but no earlier versions should have to declare that. Sure, you can put all sorts of conditional tests into your code so that it avoids using the new facility in older versions, but isn't it simpler to just declare the dependency and avoid cluttering your code with those tests? Indeed, I think you should update your package and declare the dependency on R >= 2.14.0. This seems to be a cleanest possible approach. Distributing a contributed parallel package without functionality for R < 2.14.0 is not, why should anybody develop code for R versions that won't be supported any more in due course? Best, Uwe Ligges Duncan Murdoch __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] NOTE: unstated dependencies in examples
On 14/10/11 19:00 PM, "Uwe Ligges" wrote: > > > On 14.10.2011 16:15, Duncan Murdoch wrote: >> On 14/10/2011 10:10 AM, Jari Oksanen wrote: >>> On 14/10/11 16:26 PM, "Duncan Murdoch" wrote: >>> On 14/10/2011 9:18 AM, Jari Oksanen wrote: >>> >> > Uwe& others, > > This is OK if you want to identify the cause of the problems. However, > the basic problem was that checking required something that is not > required: there was one example that was not run, and one case >>> where the > loading of the package was not necessary (if(require())). >>> I do > believe that handling this kind of cases is difficult in automatic > checking. However, I think they need not be checked: there should be a > new case of package reference in addition to 'depends', 'suggests' and > 'enhances' -- something like 'benefitsfrom'. Users use those declarations when they ask to install dependencies. If you don't declare a dependence on a contributed package, users will >>> have to manually install it. >>> Howdy, >>> >>> This is a pretty weak argument in this particular case: 'parallel' is >>> not a >>> contributed package so that you cannot install it. You either have it >>> or you >>> don't have it. In latter case, nothing happens, but everything works like >>> usual. In the former case, you may have some new things. >>> >>> (Having 'parallel' as a contributed package for R< 2.14.0 would be a >>> great >>> idea but not something I dare to suggest.) >>> > This is now actual to me, since I'm adding 'parallel' support to my > package, but there seems to be no clean way of doing this with the > current checking procedures. I use the 'parallel' support only if the > package is available (in R>= 2.14.0, not yet released), and there are > multiple cores. Temporarily maintain two releases of your package: one for R< 2.14.0 that doesn't mention parallel, and one for R>= 2.14.0 that does. The second one should declare its dependence on R>= 2.14.0. If support for parallel is your only change, you don't need to do anything for the previous one: CRAN will not replace it in the 2.13.x repository if the new one needs a newer R. >>> Forking my package was indeed one of the three alternatives I have >>> considered. In this case forking sounds really weird: for R< 2.13.0 both >>> forks would work identically. The only difference being how they are >>> handled >>> by R checkers. >> >> I don't see why it's weird to require that a version that uses a >> facility that is in 2.14.0 but no earlier versions should have to >> declare that. Sure, you can put all sorts of conditional tests into your >> code so that it avoids using the new facility in older versions, but >> isn't it simpler to just declare the dependency and avoid cluttering >> your code with those tests? > > Indeed, I think you should update your package and declare the > dependency on R >= 2.14.0. This seems to be a cleanest possible > approach. Distributing a contributed parallel package without > functionality for R < 2.14.0 is not, why should anybody develop code for > R versions that won't be supported any more in due course? Here one reason: Our PC labs have now R version 2.12.something and it is not in my power to upgrade R, but that depends on the will of our computing centre. If it will upgraded, it will not be 2.14.something. A simple desire to be able to use the package in the environment were I work sounds a valid personal reason. A second point is that the package would not *depend* or anything on R >= 2.14.0. It could be faster in some cases, but not in all. It would just as legitimate to have a condition, that the package cannot be used by those poor sods who don't have but one processor (and I was one just a short time ago). Indeed, this is exactly the same condition: you *must* have a hardware I want you to have, and the version of R I want to have. I won't make that requirement. Like I wrote in my previous message, I had considered three choices. One was forking, another was delaying the release of these features till 2.14.* is old, and the third was to depend on 'snow' *and* 'multicore' instead of 'paralle'. Now the second choice sounds the best. Cheers, Jari Oksanen -- Jari Oksanen, Dept Biology, Univ Oulu, 90014 Finland jari.oksa...@oulu.fi, Ph. +358 400 408593, http://cc.oulu.fi/~jarioksa __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] NOTE: unstated dependencies in examples
On 14.10.2011 18:52, Jari Oksanen wrote: On 14/10/11 19:00 PM, "Uwe Ligges" wrote: On 14.10.2011 16:15, Duncan Murdoch wrote: On 14/10/2011 10:10 AM, Jari Oksanen wrote: On 14/10/11 16:26 PM, "Duncan Murdoch" wrote: On 14/10/2011 9:18 AM, Jari Oksanen wrote: Uwe& others, This is OK if you want to identify the cause of the problems. However, the basic problem was that checking required something that is not required: there was one example that was not run, and one case where the loading of the package was not necessary (if(require())). I do believe that handling this kind of cases is difficult in automatic checking. However, I think they need not be checked: there should be a new case of package reference in addition to 'depends', 'suggests' and 'enhances' -- something like 'benefitsfrom'. Users use those declarations when they ask to install dependencies. If you don't declare a dependence on a contributed package, users will have to manually install it. Howdy, This is a pretty weak argument in this particular case: 'parallel' is not a contributed package so that you cannot install it. You either have it or you don't have it. In latter case, nothing happens, but everything works like usual. In the former case, you may have some new things. (Having 'parallel' as a contributed package for R< 2.14.0 would be a great idea but not something I dare to suggest.) This is now actual to me, since I'm adding 'parallel' support to my package, but there seems to be no clean way of doing this with the current checking procedures. I use the 'parallel' support only if the package is available (in R>= 2.14.0, not yet released), and there are multiple cores. Temporarily maintain two releases of your package: one for R< 2.14.0 that doesn't mention parallel, and one for R>= 2.14.0 that does. The second one should declare its dependence on R>= 2.14.0. If support for parallel is your only change, you don't need to do anything for the previous one: CRAN will not replace it in the 2.13.x repository if the new one needs a newer R. Forking my package was indeed one of the three alternatives I have considered. In this case forking sounds really weird: for R< 2.13.0 both forks would work identically. The only difference being how they are handled by R checkers. I don't see why it's weird to require that a version that uses a facility that is in 2.14.0 but no earlier versions should have to declare that. Sure, you can put all sorts of conditional tests into your code so that it avoids using the new facility in older versions, but isn't it simpler to just declare the dependency and avoid cluttering your code with those tests? Indeed, I think you should update your package and declare the dependency on R>= 2.14.0. This seems to be a cleanest possible approach. Distributing a contributed parallel package without functionality for R< 2.14.0 is not, why should anybody develop code for R versions that won't be supported any more in due course? Here one reason: Our PC labs have now R version 2.12.something and it is not in my power to upgrade R,but that depends on the will of our computing centre. So other people from the administration tell you which software to use for teaching? And what happens if they tell you only Excel is available? ... weird ... If it will upgraded, it will not be 2.14.something. A simple desire to be able to use the package in the environment were I work sounds a valid personal reason. You can still use the old version there, if the new version depends on R >= 2.14.0. The old version will stay in the binary repositories for old versions of R and in the package archives of the source repository as well. I think Duncan explained that already. A second point is that the package would not *depend* or anything on R>= 2.14.0. But it depends on it: it won't pass the checks for R < 2.14.0. It could be faster in some cases, but not in all. It would just as legitimate to have a condition, that the package cannot be used by those poor sods who don't have but one processor (and I was one just a short time ago). Indeed, this is exactly the same condition: you *must* have a hardware I want you to have, and the version of R I want to have. I won't make that requirement. Why is the hardware relevant to use the parallel (or your) package? You can also use it with one cpu. Best, Uwe Like I wrote in my previous message, I had considered three choices. One was forking, another was delaying the release of these features till 2.14.* is old, and the third was to depend on 'snow' *and* 'multicore' instead of 'paralle'. Now the second choice sounds the best. Cheers, Jari Oksanen __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] NOTE: unstated dependencies in examples
> > So other people from the administration tell you which software to use > for teaching? And what happens if they tell you only Excel is > available? > ... weird ... > On the contrary, I should say: very common. We have hardly any control over what is installed on the application servers at our university (let alone how well it is installed). > You can still use the old version there, if the new version depends on > R > >= 2.14.0. The old version will stay in the binary repositories for > old > versions of R and in the package archives of the source repository as > well. I think Duncan explained that already. Then what about new features that don't depend on parallel? Maintenance hell is born, just because you effectively force somebody to fork (True, the R builders are not the ones forcing people to stay on some "old" version, yet this scenario is not that strange that it should be ditched without regard). > > > > A second point is that the package would not *depend* or anything on > R>= > > 2.14.0. > > But it depends on it: it won't pass the checks for R < 2.14.0. Somewhat silly if it only depends on it because of the check, no? Nick Sabbe -- ping: nick.sa...@ugent.be link: http://biomath.ugent.be wink: A1.056, Coupure Links 653, 9000 Gent ring: 09/264.59.36 -- Do Not Disapprove __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] NOTE: unstated dependencies in examples
On 14.10.2011 20:53, Nick Sabbe wrote: So other people from the administration tell you which software to use for teaching? And what happens if they tell you only Excel is available? ... weird ... On the contrary, I should say: very common. We have hardly any control over what is installed on the application servers at our university (let alone how well it is installed). You can still use the old version there, if the new version depends on R >= 2.14.0. The old version will stay in the binary repositories for old versions of R and in the package archives of the source repository as well. I think Duncan explained that already. Then what about new features that don't depend on parallel? What I do not understand (both in the reasoning of this thread and in practise): How do you install the package with its new features if you cannot install a new version of R with its new features? And why is it so important to get the new features of the package but not to get a new version of R with new features and many bugfixes? If it is possible for you to install a new version of that package in your labs, you are also able to install a new version of R, right? Maintenance hell is born, just because you effectively force somebody to fork (True, the R builders are not the ones forcing people to stay on some "old" version, yet this scenario is not that strange that it should be ditched without regard). A second point is that the package would not *depend* or anything on R>= 2.14.0. But it depends on it: it won't pass the checks for R< 2.14.0. Somewhat silly if it only depends on it because of the check, no? Yes, somewhat, but actually I still do not see the reason why the new package should be able to work under R < 2.14.0 (see above). Also note that the package would be accepted on CRAN as is, if you declared "parallel" as a Suggests, as far as I understand Jari. At least binaries for Windows for old R versions will be built, since I am checking with _R_CHECK_FORCE_SUGGESTS_=FALSE on Windows. Therefore, I believe (I haven't seen the package) this discussion is meaningless anyway. Best, Uwe Ligges Nick Sabbe -- ping: nick.sa...@ugent.be link: http://biomath.ugent.be wink: A1.056, Coupure Links 653, 9000 Gent ring: 09/264.59.36 -- Do Not Disapprove __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Creating a package skeleton with no flesh
Hi,
Wouldn't it be awesome if package.skeleton() could be used to
produce, well... a package skeleton? In a fresh R session:
> package.skeleton("mypkg")
Error in !have : invalid argument type
This (not very informative) error message seems to occur because
I'm trying to create a skeleton with no flesh on it:
> foo <- function() {}
> package.skeleton("mypkg")
Creating directories ...
Creating DESCRIPTION ...
Creating NAMESPACE ...
Creating Read-and-delete-me ...
Saving functions and data ...
Making help files ...
Done.
Further steps are described in './mypkg/Read-and-delete-me'.
A package with nothing defined in it is still a valid package.
Thanks,
H.
--
Hervé Pagès
Program in Computational Biology
Division of Public Health Sciences
Fred Hutchinson Cancer Research Center
1100 Fairview Ave. N, M1-B514
P.O. Box 19024
Seattle, WA 98109-1024
E-mail: hpa...@fhcrc.org
Phone: (206) 667-5791
Fax:(206) 667-1319
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] .onLoad failing because could not find function "loadMethod"
Hi,
This strange warning happen sometimes when running 'R CMD check':
* checking whether the package can be loaded with stated dependencies
... WARNING
Error : .onLoad failed in loadNamespace() for ‘pkgB’, details:
call: length(new("A"))
error: could not find function "loadMethod"
Error: package/namespace load failed for ‘pkgB’
Execution halted
It looks like this package (or one of its dependent packages) has an
unstated dependence on a standard package. All dependencies must be
declared in DESCRIPTION.
See the information on DESCRIPTION files in the chapter ‘Creating R
packages’ of the ‘Writing R Extensions’ manual.
The same warning is reported during the 2 next checks:
* checking whether the package can be unloaded cleanly ... WARNING
* checking whether the namespace can be loaded with stated
dependencies ... WARNING
It seems to happen when pkgB has code in its .onLoad hook that
tries to call a method defined in pkgA (pkgB imports pkgA) on an object
'x' that is an instance of a class defined in pkgA. For some obscure
reason it seems that, at the time the .onLoad hook is executed, the
methods package (which is imported in both packages) is not working
properly.
I've put 2 toy packages here that illustrate the problem:
https://rapidshare.com/files/4043144391/pkgA_1.0.tar.gz
https://rapidshare.com/files/1959508331/pkgB_1.0.tar.gz
I'm using R version 2.14.0 alpha (2011-10-10 r57211).
The .onLoad hook in pkgB is:
.onLoad <- function(libname, pkgname)
{
showMethods("length")
length(new("A"))
}
Class A and the length method for this class is defined in pkgA.
Because of the showMethods("length") statement, you should see this
when running R CMD check pkgB_1.0.tar.gz:
* checking whether the package can be loaded with stated dependencies
... WARNING
Function: length (package base)
x="A"
Error : .onLoad failed in loadNamespace() for ‘pkgB’, details:
call: length(new("A"))
error: could not find function "loadMethod"
Error: package/namespace load failed for ‘pkgB’
Execution halted
Any insight on this would be appreciated.
Thanks,
H.
--
Hervé Pagès
Program in Computational Biology
Division of Public Health Sciences
Fred Hutchinson Cancer Research Center
1100 Fairview Ave. N, M1-B514
P.O. Box 19024
Seattle, WA 98109-1024
E-mail: hpa...@fhcrc.org
Phone: (206) 667-5791
Fax:(206) 667-1319
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] .onLoad failing because could not find function "loadMethod"
On 11-10-14 05:46 PM, Hervé Pagès wrote: [...] I've put 2 toy packages here that illustrate the problem: https://rapidshare.com/files/4043144391/pkgA_1.0.tar.gz https://rapidshare.com/files/1959508331/pkgB_1.0.tar.gz arghh, sorry for the broken links. I'll try to put those packages somewhere else. H. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] .onLoad failing because could not find function "loadMethod"
On 11-10-14 05:47 PM, Hervé Pagès wrote: On 11-10-14 05:46 PM, Hervé Pagès wrote: [...] I've put 2 toy packages here that illustrate the problem: https://rapidshare.com/files/4043144391/pkgA_1.0.tar.gz https://rapidshare.com/files/1959508331/pkgB_1.0.tar.gz arghh, sorry for the broken links. I'll try to put those packages somewhere else. You can download the packages with: wget --no-check-certificate https://rapidshare.com/files/4043144391/pkgA_1.0.tar.gz wget --no-check-certificate https://rapidshare.com/files/1959508331/pkgB_1.0.tar.gz Cheers, H. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] NOTE: unstated dependencies in examples
Hello folks,
To get it short, I cut out most of the spurious controversy, and go to the
key point (and it also helps to go to sauna and then sleep well all night):
On 14/10/11 22:30 PM, "Uwe Ligges" wrote:
>
> Also note that the package would be accepted on CRAN as is, if you
> declared "parallel" as a Suggests, as far as I understand Jari. At least
> binaries for Windows for old R versions will be built, since I am
> checking with
> _R_CHECK_FORCE_SUGGESTS_=FALSE
> on Windows. Therefore, I believe (I haven't seen the package) this
> discussion is meaningless anyway.
This is fine and solve the problems I anticipated. I did not know about this
possibility. It was not shown in R CMD check --help, nor in the usual
manuals I read: it seems to be mentioned in R-ints.texi, but not in
R-exts.texi nor in R-admin.texi.
Although I feel well at the moment, I return to the old team: about the kind
of keyword describing packages that you don't necessarily need, and which
are used in style
if(require(foo)) {do_something_fancy_with_foo::foo()}
They are "Sugar: parallel, foo". They are not necessarily needed, if you
don't have you don't necessarily even know you need them.
Then about old R and new packages: many of us are in situations where we
must use an old version of R. However, we can still install packages in
private libraries without admin privileges. They may not be system-wide, and
they can be wiped out in the next boot, or you may need to have them in your
USB stick, but installing a package is rather a light operation which can
be be done except in most paranoid systems. One year I burned an R
installation to a CD that I distributed to the students so that they could
run R in a PC class with too ancient R. In one occasion I gave students
temporary usernames to my personal Linux desktop so that they could log in
to my desktop from the class for one analysis (but that is in general too
clumsy as Windows did not have good X11).
New package versions can contain bug fixed and some enhanced functionality
in addition to radical new features that require bleeding edge R.
Personally, I try to keep my release versions such that they work in
current, previous and future major versions of R. Currently I test the
package more or less regularly in R 2.13.2 and R-to-be-2.14.0 in MacOS, and
in 2.12.2 and R-to-be-2.15.0 in Linux, and I expect the release version to
pass all these. The development version can fail in older R, but then we
(the team) must judge if we merge such failing features to the release.
Cheers, Jari Oksanen
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
