Re: [Rd] NAMESPACE file generation issue R 2.14.0 on Debian Squeeze
2011/11/8 Uwe Ligges lig...@statistik.tu-dortmund.de: On 08.11.2011 19:08, Gabor Grothendieck wrote: 2011/11/8 Uwe Liggeslig...@statistik.tu-dortmund.de: On 08.11.2011 17:56, Gabor Grothendieck wrote: 2011/11/8 Uwe Liggeslig...@statistik.tu-dortmund.de: On 08.11.2011 17:04, Gabor Grothendieck wrote: 2011/11/8 Uwe Liggeslig...@statistik.tu-dortmund.de: On 08.11.2011 16:31, Gabor Grothendieck wrote: 2011/11/8 Uwe Liggeslig...@statistik.tu-dortmund.de: I think many people like to help, but we cannot: You say you are under R-2.14.0 and whn you R CMD INSTALL a package with that version of R, it does not have a NAMESPACE in the end? Then - your R installation is broken or - you are looking into a library where you have old versios of the packages or - you belive you are using R-2.14.0 but you are actually using an older version. This is even reproduced on CRAN. All platforms work except one: http://cran.r-project.org/web/checks/check_results_sqldf.html No, that one is completely unrelated (and already solved, but not yet synced to CRAN master) to the original question you have removed in your reply. OK. One would have thought that the checks on CRAN would be consistent with the package pages which link to them. I only see consistent information on that page. If you go to: http://cran.r-project.org/web/packages/sqldf/index.html then the tar.gz file was created using R-2.14.0 but if you then click on the check results link on the same page it takes you to this: Yes. the tar.gz was created with R-2.14.0. http://cran.r-project.org/web/checks/check_results_sqldf.html On the last link on that page it says ERROR and if click on that it takes you to the output of the check which reveals that it was run with R 2.13.2. Yes, ince it is checked with different flavors of R, R-oldrelease, R-release, R-devel. See the first column! A source package can be created with an version of R and checked under another version. There is onlyone source package on CRAN, but - just as an exmaple - binaries for R-2.13.x and R-2.14.x. Of course, the checks are applied with the versions stated on the check page. I think you haven't got the whole point of checking with different versions of R. The Version column on check_results_sqldf.html page refers to the package's version, not the R version. To get the R version you must know to click on each link. No, no, no, no! See the first column! It definitely states if R-olrelease, R-release, R-pacthed or R-devel is used! OK. That wasn't clear. It would be better if it actually identified the release as R 2.13.2, etc. We do not want to change those fields daily: R-devel and R-patched typically change from day to day - and then things will really become inconsistent in some place. The inconsistencies are less important if they are obvious but more important if they are not. How about indicating R-2.14.0 but not the (2011-09-30 r57179) part. That only changes a few times a year. Also it would be helpful if the R version number that was used to build the .tar.gz file and the .zip file were shown right on the package's CRAN page. This entire discussion and all the associated confusion probably would not have occurred since it would be much clearer which versions were involved. -- Statistics Software Consulting GKX Group, GKX Associates Inc. tel: 1-877-GKX-GROUP email: ggrothendieck at gmail.com __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] NAMESPACE file generation issue R 2.14.0 on Debian Squeeze
On 09.11.2011 13:52, Gabor Grothendieck wrote: 2011/11/8 Uwe Liggeslig...@statistik.tu-dortmund.de: On 08.11.2011 19:08, Gabor Grothendieck wrote: 2011/11/8 Uwe Liggeslig...@statistik.tu-dortmund.de: On 08.11.2011 17:56, Gabor Grothendieck wrote: 2011/11/8 Uwe Liggeslig...@statistik.tu-dortmund.de: On 08.11.2011 17:04, Gabor Grothendieck wrote: 2011/11/8 Uwe Liggeslig...@statistik.tu-dortmund.de: On 08.11.2011 16:31, Gabor Grothendieck wrote: 2011/11/8 Uwe Liggeslig...@statistik.tu-dortmund.de: I think many people like to help, but we cannot: You say you are under R-2.14.0 and whn you R CMD INSTALL a package with that version of R, it does not have a NAMESPACE in the end? Then - your R installation is broken or - you are looking into a library where you have old versios of the packages or - you belive you are using R-2.14.0 but you are actually using an older version. This is even reproduced on CRAN. All platforms work except one: http://cran.r-project.org/web/checks/check_results_sqldf.html No, that one is completely unrelated (and already solved, but not yet synced to CRAN master) to the original question you have removed in your reply. OK. One would have thought that the checks on CRAN would be consistent with the package pages which link to them. I only see consistent information on that page. If you go to: http://cran.r-project.org/web/packages/sqldf/index.html then the tar.gz file was created using R-2.14.0 but if you then click on the check results link on the same page it takes you to this: Yes. the tar.gz was created with R-2.14.0. http://cran.r-project.org/web/checks/check_results_sqldf.html On the last link on that page it says ERROR and if click on that it takes you to the output of the check which reveals that it was run with R 2.13.2. Yes, ince it is checked with different flavors of R, R-oldrelease, R-release, R-devel. See the first column! A source package can be created with an version of R and checked under another version. There is onlyone source package on CRAN, but - just as an exmaple - binaries for R-2.13.x and R-2.14.x. Of course, the checks are applied with the versions stated on the check page. I think you haven't got the whole point of checking with different versions of R. The Version column on check_results_sqldf.html page refers to the package's version, not the R version. To get the R version you must know to click on each link. No, no, no, no! See the first column! It definitely states if R-olrelease, R-release, R-pacthed or R-devel is used! OK. That wasn't clear. It would be better if it actually identified the release as R 2.13.2, etc. We do not want to change those fields daily: R-devel and R-patched typically change from day to day - and then things will really become inconsistent in some place. The inconsistencies are less important if they are obvious but more important if they are not. How about indicating R-2.14.0 but not the (2011-09-30 r57179) part. Honestly, that (svn revision) is the only part that we do not have on the front pages but they are given in the log files. Uwe That only changes a few times a year. Also it would be helpful if the R version number that was used to build the .tar.gz file and the .zip file were shown right on the package's CRAN page. This entire discussion and all the associated confusion probably would not have occurred since it would be much clearer which versions were involved. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] NAMESPACE file generation issue R 2.14.0 on Debian Squeeze
2011/11/9 Uwe Ligges lig...@statistik.tu-dortmund.de: On 09.11.2011 13:52, Gabor Grothendieck wrote: 2011/11/8 Uwe Liggeslig...@statistik.tu-dortmund.de: On 08.11.2011 19:08, Gabor Grothendieck wrote: 2011/11/8 Uwe Liggeslig...@statistik.tu-dortmund.de: On 08.11.2011 17:56, Gabor Grothendieck wrote: 2011/11/8 Uwe Liggeslig...@statistik.tu-dortmund.de: On 08.11.2011 17:04, Gabor Grothendieck wrote: 2011/11/8 Uwe Liggeslig...@statistik.tu-dortmund.de: On 08.11.2011 16:31, Gabor Grothendieck wrote: 2011/11/8 Uwe Liggeslig...@statistik.tu-dortmund.de: I think many people like to help, but we cannot: You say you are under R-2.14.0 and whn you R CMD INSTALL a package with that version of R, it does not have a NAMESPACE in the end? Then - your R installation is broken or - you are looking into a library where you have old versios of the packages or - you belive you are using R-2.14.0 but you are actually using an older version. This is even reproduced on CRAN. All platforms work except one: http://cran.r-project.org/web/checks/check_results_sqldf.html No, that one is completely unrelated (and already solved, but not yet synced to CRAN master) to the original question you have removed in your reply. OK. One would have thought that the checks on CRAN would be consistent with the package pages which link to them. I only see consistent information on that page. If you go to: http://cran.r-project.org/web/packages/sqldf/index.html then the tar.gz file was created using R-2.14.0 but if you then click on the check results link on the same page it takes you to this: Yes. the tar.gz was created with R-2.14.0. http://cran.r-project.org/web/checks/check_results_sqldf.html On the last link on that page it says ERROR and if click on that it takes you to the output of the check which reveals that it was run with R 2.13.2. Yes, ince it is checked with different flavors of R, R-oldrelease, R-release, R-devel. See the first column! A source package can be created with an version of R and checked under another version. There is onlyone source package on CRAN, but - just as an exmaple - binaries for R-2.13.x and R-2.14.x. Of course, the checks are applied with the versions stated on the check page. I think you haven't got the whole point of checking with different versions of R. The Version column on check_results_sqldf.html page refers to the package's version, not the R version. To get the R version you must know to click on each link. No, no, no, no! See the first column! It definitely states if R-olrelease, R-release, R-pacthed or R-devel is used! OK. That wasn't clear. It would be better if it actually identified the release as R 2.13.2, etc. We do not want to change those fields daily: R-devel and R-patched typically change from day to day - and then things will really become inconsistent in some place. The inconsistencies are less important if they are obvious but more important if they are not. How about indicating R-2.14.0 but not the (2011-09-30 r57179) part. Honestly, that (svn revision) is the only part that we do not have on the front pages but they are given in the log files. The R version is not on the package's CRAN page, e.g. http://cran.r-project.org/web/packages/sqldf/index.html I was thinking of something like this for the Package source line: Package built source:sqldf_0.4-3.tar.gz (built with R version 2.14.0 Patched (2011-10-10 r12345) This seems important since that line truly is not the source but is the built source. The actual source is not uploaded to CRAN or shown. A transformation has been applied to it so rightfully that should be tracked back via the R version. This would make it very clear not only which version of the R package you are dealing with but which version of R built it and that can in certain circumstances be important for precisely identifying it. This could also be done for the .zip file, etc. shown on that page. If that level of detail is not feasible then this would be next best (just showing the R x.y.z version): Package built source: sqldf_0.4-3.tar.gz (built with R version 2.14.0) -- Statistics Software Consulting GKX Group, GKX Associates Inc. tel: 1-877-GKX-GROUP email: ggrothendieck at gmail.com __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] NAMESPACE file generation issue R 2.14.0 on Debian Squeeze
On 09.11.2011 15:23, Gabor Grothendieck wrote: 2011/11/9 Uwe Liggeslig...@statistik.tu-dortmund.de: On 09.11.2011 13:52, Gabor Grothendieck wrote: 2011/11/8 Uwe Liggeslig...@statistik.tu-dortmund.de: On 08.11.2011 19:08, Gabor Grothendieck wrote: 2011/11/8 Uwe Liggeslig...@statistik.tu-dortmund.de: On 08.11.2011 17:56, Gabor Grothendieck wrote: 2011/11/8 Uwe Liggeslig...@statistik.tu-dortmund.de: On 08.11.2011 17:04, Gabor Grothendieck wrote: 2011/11/8 Uwe Liggeslig...@statistik.tu-dortmund.de: On 08.11.2011 16:31, Gabor Grothendieck wrote: 2011/11/8 Uwe Liggeslig...@statistik.tu-dortmund.de: I think many people like to help, but we cannot: You say you are under R-2.14.0 and whn you R CMD INSTALL a package with that version of R, it does not have a NAMESPACE in the end? Then - your R installation is broken or - you are looking into a library where you have old versios of the packages or - you belive you are using R-2.14.0 but you are actually using an older version. This is even reproduced on CRAN. All platforms work except one: http://cran.r-project.org/web/checks/check_results_sqldf.html No, that one is completely unrelated (and already solved, but not yet synced to CRAN master) to the original question you have removed in your reply. OK. One would have thought that the checks on CRAN would be consistent with the package pages which link to them. I only see consistent information on that page. If you go to: http://cran.r-project.org/web/packages/sqldf/index.html then the tar.gz file was created using R-2.14.0 but if you then click on the check results link on the same page it takes you to this: Yes. the tar.gz was created with R-2.14.0. http://cran.r-project.org/web/checks/check_results_sqldf.html On the last link on that page it says ERROR and if click on that it takes you to the output of the check which reveals that it was run with R 2.13.2. Yes, ince it is checked with different flavors of R, R-oldrelease, R-release, R-devel. See the first column! A source package can be created with an version of R and checked under another version. There is onlyone source package on CRAN, but - just as an exmaple - binaries for R-2.13.x and R-2.14.x. Of course, the checks are applied with the versions stated on the check page. I think you haven't got the whole point of checking with different versions of R. The Version column on check_results_sqldf.html page refers to the package's version, not the R version. To get the R version you must know to click on each link. No, no, no, no! See the first column! It definitely states if R-olrelease, R-release, R-pacthed or R-devel is used! OK. That wasn't clear. It would be better if it actually identified the release as R 2.13.2, etc. We do not want to change those fields daily: R-devel and R-patched typically change from day to day - and then things will really become inconsistent in some place. The inconsistencies are less important if they are obvious but more important if they are not. How about indicating R-2.14.0 but not the (2011-09-30 r57179) part. Honestly, that (svn revision) is the only part that we do not have on the front pages but they are given in the log files. The R version is not on the package's CRAN page, e.g. http://cran.r-project.org/web/packages/sqldf/index.html I was thinking of something like this for the Package source line: Package built source:sqldf_0.4-3.tar.gz (built with R version 2.14.0 Patched (2011-10-10 r12345) Not relevant for the majority of cases. Version number of the package is relevant, not the R used to build it (well, there are cornercases, e.g. for knowing which version was used to generate the vignette). And in addition, we to not have the information. Where do you think we can get that from? Even if we change R to provide the information now, we'd only know if it was built with R = 2.14.0 or later. This seems important since that line truly is not the source but is the built source. The actual source is not uploaded to CRAN or shown. He? What is the difference between the source and the built source? A source package has always undergone R CMD build on the submitters machine. We do only have only one kind of source packages on CRAN. A transformation has been applied to it Where and why do you want to apply transformations? so rightfully that should be tracked back via the R version. This would make it very clear not only which version of the R package you are dealing with but which version of R built it and that can in certain circumstances be important for precisely identifying it. This could also be done for the .zip file, etc. shown on that page. The zip file shown *there* is always R-release or R-patched (hence currently R-2.14.0 given your request) for ALL packages. We do not list zip files for non R-release *there*. I thought you were still talking about the check page. If that level of
Re: [Rd] NAMESPACE file generation issue R 2.14.0 on Debian Squeeze
2011/11/9 Uwe Ligges lig...@statistik.tu-dortmund.de: Honestly, that (svn revision) is the only part that we do not have on the front pages but they are given in the log files. The R version is not on the package's CRAN page, e.g. http://cran.r-project.org/web/packages/sqldf/index.html I was thinking of something like this for the Package source line: Package built source: sqldf_0.4-3.tar.gz (built with R version 2.14.0 Patched (2011-10-10 r12345) Not relevant for the majority of cases. Version number of the package is relevant, not the R used to build it (well, there are cornercases, e.g. for knowing which version was used to generate the vignette). The point is that the answer to the poster's question does not really resolve it except for that one person. To really solve the problem the process needs to be changed so that its unlikely to occur again. And in addition, we to not have the information. Where do you think we can get that from? Even if we change R to provide the information now, we'd only know if it was built with R = 2.14.0 or later. Yes, I realize that but it would have to be added during the build process in the same way that certain other information is added already. This seems important since that line truly is not the source but is the built source. The actual source is not uploaded to CRAN or shown. He? What is the difference between the source and the built source? A source package has always undergone R CMD build on the submitters machine. We do only have only one kind of source packages on CRAN. The built source has been processed by R CMD build and the true source has not. What CRAN labels the source is not the true source but is really the built source. There has been a transformation applied to the true source to get the built source and some version of R was used to do that. Furthermore, what the result looks like can depend on what version of R was used for this. That its different for different versions of R was one of the things that precipitated this entire thread. A transformation has been applied to it Where and why do you want to apply transformations? By transformation I am referring to the existing process of transforming the true source to the built source. I was not suggesting other transformations (other than the fact that it implies that it would be necessary to identify the R version that built any given built source in the built source itself). so rightfully that should be tracked back via the R version. This would make it very clear not only which version of the R package you are dealing with but which version of R built it and that can in certain circumstances be important for precisely identifying it. This could also be done for the .zip file, etc. shown on that page. The zip file shown *there* is always R-release or R-patched (hence currently R-2.14.0 given your request) for ALL packages. We do not list zip files for non R-release *there*. I thought you were still talking about the check page. Originally I was referring to the check page but then expanded it to the main page as well since it seemed relevant in both places. I find this whole area is confusing (and clearly I am not the only one hence this thread) and it could use some clarification right on the web pages themselves to avoid these sorts of problems. I think the most desirable from a user's viewpoint is to actually stick the R version right there but if its not feasible some other way of addressing this would be nice. If that level of detail is not feasible then this would be next best (just showing the R x.y.z version): Package built source: sqldf_0.4-3.tar.gz (built with R version 2.14.0) I give up. uwe -- Statistics Software Consulting GKX Group, GKX Associates Inc. tel: 1-877-GKX-GROUP email: ggrothendieck at gmail.com __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Define S4 methods for 'plot'
Hi the list
I am creating a package and I have a problem to define a S4 method for plot.
I define a class 'A' and a class 'B'. I want to define a function plot for
signature c(A,missing) and another method plot for signature c(A,B). My code
is the following :
In /package/R/ directory:
--- main.R ---
setGeneric(plot,function(x,y,...){standardGeneric(plot)})
Aplot - function(x,paramTraj=3){. . . .}
setMethod(plot,signature=c(x=A,y=missing),Aplot)
ABplot - function(x,y,paramTraj=5){. . . .}
setMethod(plot,signature=c(x=A,y=B),ABplot)
---
In the root directory /package/
--- NAMESPACE ---
exportMethods(plot,. . . .)
exportClasses(A,B)
--
When I run the code (source(main.r)), every thinks works fine, either plot
on object of class 'A', on 'A,B' or on numeric plot(3).
The R CMD check bug on an example using plot(3).
The R CMD build works just fine. But if I try to install the package from
the builded file, I get the message:
The following object(s) are masked from 'package:graphics':
plot.
And then, I cannot use the classical function plot: plot on object 'A'
works, but plot(1) does not.
I try, reading some recent post on r-devel to remove the line 'setGeneric'
but it does not works (which does not surprise me since getGeneric(plot)
gives a NULL results).
Any idea of what goes wrong?
Christophe
--
View this message in context:
http://r.789695.n4.nabble.com/Define-S4-methods-for-plot-tp4020750p4020750.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
[Rd] exporting isChild in package parallel
I was wondering if there is any interest in making the function isChild() exported from the package parallel? This would be of great help to anyone writing R packages that use thread-level parallelism, and would like to throttle the spawning of threads whenever the R process is detected to be a child process that was constructed by mcfork(). Cheers, --Michael __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Define S4 methods for 'plot'
You probably need the directive
importFrom(graphics, plot)
in your NAMESPACE file. This lets the system know that you are using
the same plot function that it already knows about. And your code
should be careful not to trash a previous conversion of plot to an S4
generic function, usually by something like
if (!isGeneric(plot))
setGeneric(plot, function(x, y, ...) standardGeneric(plot))
Best,
Kevin
On 11/9/2011 12:08 PM, cgenolin wrote:
Hi the list
I am creating a package and I have a problem to define a S4 method for plot.
I define a class 'A' and a class 'B'. I want to define a function plot for
signature c(A,missing) and another method plot for signature c(A,B). My code
is the following :
In /package/R/ directory:
--- main.R ---
setGeneric(plot,function(x,y,...){standardGeneric(plot)})
Aplot- function(x,paramTraj=3){. . . .}
setMethod(plot,signature=c(x=A,y=missing),Aplot)
ABplot- function(x,y,paramTraj=5){. . . .}
setMethod(plot,signature=c(x=A,y=B),ABplot)
---
In the root directory /package/
--- NAMESPACE ---
exportMethods(plot,. . . .)
exportClasses(A,B)
--
When I run the code (source(main.r)), every thinks works fine, either plot
on object of class 'A', on 'A,B' or on numeric plot(3).
The R CMD check bug on an example using plot(3).
The R CMD build works just fine. But if I try to install the package from
the builded file, I get the message:
The following object(s) are masked from 'package:graphics':
plot.
And then, I cannot use the classical function plot: plot on object 'A'
works, but plot(1) does not.
I try, reading some recent post on r-devel to remove the line 'setGeneric'
but it does not works (which does not surprise me since getGeneric(plot)
gives a NULL results).
Any idea of what goes wrong?
Christophe
--
View this message in context:
http://r.789695.n4.nabble.com/Define-S4-methods-for-plot-tp4020750p4020750.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] Moderating consequences of garbage collection when in C
Martin Morgan mtmor...@fhcrc.org wrote: Allocating many small objects triggers numerous garbage collections as R grows its memory, seriously degrading performance. The specific use case is in creating a STRSXP of several 1,000,000's of elements of 60-100 characters each; a simplified illustration understating the effects (because there is initially little to garbage collect, in contrast to an R session with several packages loaded) is below. What a coincidence -- I was just going to post a question about why it is so slow to create a STRSXP of ~10,000,000 unique elements, each ~10 characters long. I had noticed that this seemed to show much worse than linear scaling. I had not thought of garbage collection as the culprit -- but indeed it is. By manipulating the GC trigger, I can make this operation take as little as 3 seconds (with no GC) or as long as 76 seconds (with 31 garbage collections). -- Dave __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
