[Rd] question on why Rigroup package moved to Archive on CRAN
Hi, Who should I ask about my package Rigroup_0.83 being moved to Archive status on CRAN and no longer available via install.package? I have no problems with the move if this was simply because of low demand. However, if there was a build issue with the newest releases that caused problems, I would be happy to address it. I'll just ask my students to install it from my own locally hosted source archive. Thanks, Kevin __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] question on why Rigroup package moved to Archive on CRAN
Hi, Thanks for that info. It works/builds without error or warnings on my RedHat Enterprise 6 with R 2.15.2 version which I use but must be broken somehow on later versions. I will see if I can find the autobuild warnings error report someplace. Kevin Sent from my iPad On 2013-03-09, at 4:00 PM, Henrik Bengtsson wrote: > On Sat, Mar 9, 2013 at 12:25 PM, Kevin Hendricks > wrote: >> Hi, >> >> Who should I ask about my package Rigroup_0.83 being moved to Archive status >> on CRAN and no longer available via install.package? I have no problems >> with the move if this was simply because of low demand. However, if there >> was a build issue with the newest releases that caused problems, I would be >> happy to address it. I'll just ask my students to install it from my own >> locally hosted source archive. > > Most likely yourself; from the 'CRAN Repository Policy' > [http://cran.r-project.org/web/packages/policies.html]: > > "Packages will not normally be removed from CRAN: however, they may be > archived, including at the maintainer's request. > > Packages for which R CMD check gives an ‘ERROR’ when a new R x.y.0 > version is released will be archived (or in exceptional circumstances > updated by the CRAN team) unless the maintainer has set a firm > deadline for an upcoming update (and keeps to it). > > Maintainers will be asked to update packages which show any warnings > or significant notes, especially at around the time of a new x.y.0 > release. Packages which are not updated are liable to be archived." > > /Henrik > >> >> Thanks, >> >> Kevin >> __ >> 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] question on why Rigroup package moved to Archive on CRAN
Hi, One last quick question ... does anyone archive older CRAN package check summaries? I searched the web but could not find any. My package was archived in February of this year so any package check summary from earlier than that should help me figure out what is broken on MacOSX or Windows. Thanks, Kevin Sent from my iPad On 2013-03-09, at 4:38 PM, Kevin Hendricks wrote: > Hi, > Thanks for that info. It works/builds without error or warnings on my RedHat > Enterprise 6 with R 2.15.2 version which I use but must be broken somehow on > later versions. I will see if I can find the autobuild warnings error report > someplace. > > Kevin > > > Sent from my iPad > > On 2013-03-09, at 4:00 PM, Henrik Bengtsson wrote: > >> On Sat, Mar 9, 2013 at 12:25 PM, Kevin Hendricks >> wrote: >>> Hi, >>> >>> Who should I ask about my package Rigroup_0.83 being moved to Archive >>> status on CRAN and no longer available via install.package? I have no >>> problems with the move if this was simply because of low demand. However, >>> if there was a build issue with the newest releases that caused problems, I >>> would be happy to address it. I'll just ask my students to install it from >>> my own locally hosted source archive. >> >> Most likely yourself; from the 'CRAN Repository Policy' >> [http://cran.r-project.org/web/packages/policies.html]: >> >> "Packages will not normally be removed from CRAN: however, they may be >> archived, including at the maintainer's request. >> >> Packages for which R CMD check gives an ‘ERROR’ when a new R x.y.0 >> version is released will be archived (or in exceptional circumstances >> updated by the CRAN team) unless the maintainer has set a firm >> deadline for an upcoming update (and keeps to it). >> >> Maintainers will be asked to update packages which show any warnings >> or significant notes, especially at around the time of a new x.y.0 >> release. Packages which are not updated are liable to be archived." >> >> /Henrik >> >>> >>> Thanks, >>> >>> Kevin >>> __ >>> 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] question on why Rigroup package moved to Archive on CRAN
Hi Dan,
Thank you! I dig up a Mac at work and recreate this.
Kevin
On 2013-03-09, at 5:52 PM, Dan Tenenbaum wrote:
> On Sat, Mar 9, 2013 at 2:17 PM, Kevin Hendricks
> wrote:
>> Hi,
>> One last quick question ... does anyone archive older CRAN package check
>> summaries? I searched the web but could not find any. My package was
>> archived in February of this year so any package check summary from earlier
>> than that should help me figure out what is broken on MacOSX or Windows.
>
> FWIW, it fails check on my Mac as follows:
>
> * checking examples ... ERROR
> Running examples in 'Rigroup-Ex.R' failed
> The error most likely occurred in:
>
>> ### Name: igroupAlls
>> ### Title: calculates logical All for small integer groups of logical
>> ### vectors
>> ### Aliases: igroupAlls
>> ### Keywords: utilities
>>
>> ### ** Examples
>>
>> y <- rnorm(100)
>> i <- rep(1:25,4)
>> x <- (y > 1.0)
>> alls <- igroupAlls(x,i)
> Error in .External("igroupFuns", x, i, R_IGFMINS, na.rm, PACKAGE = "Rigroup")
> :
> Incorrect number of arguments (4), expecting 1 for 'igroupFuns'
> Calls: igroupAlls -> .External
> Execution halted
>
>
> Dan
>
>
>> Thanks,
>> Kevin
>>
>>
>> Sent from my iPad
>>
>> On 2013-03-09, at 4:38 PM, Kevin Hendricks
>> wrote:
>>
>>> Hi,
>>> Thanks for that info. It works/builds without error or warnings on my
>>> RedHat Enterprise 6 with R 2.15.2 version which I use but must be broken
>>> somehow on later versions. I will see if I can find the autobuild warnings
>>> error report someplace.
>>>
>>> Kevin
>>>
>>>
>>> Sent from my iPad
>>>
>>> On 2013-03-09, at 4:00 PM, Henrik Bengtsson wrote:
>>>
>>>> On Sat, Mar 9, 2013 at 12:25 PM, Kevin Hendricks
>>>> wrote:
>>>>> Hi,
>>>>>
>>>>> Who should I ask about my package Rigroup_0.83 being moved to Archive
>>>>> status on CRAN and no longer available via install.package? I have no
>>>>> problems with the move if this was simply because of low demand.
>>>>> However, if there was a build issue with the newest releases that caused
>>>>> problems, I would be happy to address it. I'll just ask my students to
>>>>> install it from my own locally hosted source archive.
>>>>
>>>> Most likely yourself; from the 'CRAN Repository Policy'
>>>> [http://cran.r-project.org/web/packages/policies.html]:
>>>>
>>>> "Packages will not normally be removed from CRAN: however, they may be
>>>> archived, including at the maintainer's request.
>>>>
>>>> Packages for which R CMD check gives an ‘ERROR’ when a new R x.y.0
>>>> version is released will be archived (or in exceptional circumstances
>>>> updated by the CRAN team) unless the maintainer has set a firm
>>>> deadline for an upcoming update (and keeps to it).
>>>>
>>>> Maintainers will be asked to update packages which show any warnings
>>>> or significant notes, especially at around the time of a new x.y.0
>>>> release. Packages which are not updated are liable to be archived."
>>>>
>>>> /Henrik
>>>>
>>>>>
>>>>> Thanks,
>>>>>
>>>>> Kevin
>>>>> __
>>>>> 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] question on why Rigroup package moved to Archive on CRAN
Hi Dan,
In case this catches anyone else ...
FWIW, I found the issue ... in my Rinit.c, my package uses the .External call
which actually takes one SEXP which points to a "varargs-like" list.
Under 2.15.X and earlier, I thought the proper entry for an .External call was
as below since it only does take one pointer as an argument:
#include "Rigroup.h"
/* Automate using sed or something. */
#if _MSC_VER >= 1000
__declspec(dllexport)
#endif
static const R_ExternalMethodDef R_ExtDef[] = {
{"igroupFuns", (DL_FUNC)&igroupFuns, 1},
{NULL, NULL, 0},
};
void R_init_Rigroup(DllInfo *info)
{
R_registerRoutines(info,NULL,NULL,NULL,R_ExtDef);
}
But now according to the latest online docs on building your own package it
says:
"For routines with a variable number of arguments invoked viathe .External
interface, one specifies -1 for the number of arguments which tells R not to
check the actual number passed. Note that the number of arguments passed to
.External are not currently checked but they will be in R 3.0.0."
So I need to change my Rinit.c to change the "1" to a "-1" and that error
should go away.
Thanks again for all your help with this. I will update my package and
resubmit it once version 3.0 gets released and I get a chance to verify that
this does in fact fix the problem.
Kevin
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] question on why Rigroup package moved to Archive on CRAN
Sorry if you considered this a waste of bandwidth. I did not know CRAN had its
own mailing list. The reason I never responded to any mail is that I never
received any message in January (I searched my inbox for it and found
nothing). It probably was stripped out by the sympatico mail server as spam.
The reason I asked here was that my package seemed to pass all tests on the
current version and I was honestly confused as to why it was removed. In
addition, I thought others in a similar situation may benefit. Years ago
people here were quite helpful when I first designed the package (and from the
responses many still are). My question was not meant as an attack on you or
your processes, it was honest confusion as to why it was removed.
Kevin
On 2013-03-10, at 11:18 AM, Uwe Ligges wrote:
> I wonder why you do not ask on CRAN@...? List members here cannot know the
> answer. And we typically do not discuss such matters in public.
>
> I wonder why you do not read the e-mail message you get from the CRAN team?
>
> Please see the message with subject line "Registering .External entry points"
> you got on January 20. You never answered nor fixed the package, hence the
> package has been archived.
>
> Best,
> Uwe Ligges
>
>
>
>
> On 10.03.2013 02:43, Kevin Hendricks wrote:
>> Hi Dan,
>>
>> In case this catches anyone else ...
>>
>> FWIW, I found the issue ... in my Rinit.c, my package uses the .External
>> call which actually takes one SEXP which points to a "varargs-like" list.
>>
>> Under 2.15.X and earlier, I thought the proper entry for an .External call
>> was as below since it only does take one pointer as an argument:
>>
>> #include "Rigroup.h"
>>
>> /* Automate using sed or something. */
>> #if _MSC_VER >= 1000
>> __declspec(dllexport)
>> #endif
>>
>>static const R_ExternalMethodDef R_ExtDef[] = {
>> {"igroupFuns", (DL_FUNC)&igroupFuns, 1},
>> {NULL, NULL, 0},
>>};
>>
>> void R_init_Rigroup(DllInfo *info)
>> {
>> R_registerRoutines(info,NULL,NULL,NULL,R_ExtDef);
>> }
>>
>>
>> But now according to the latest online docs on building your own package it
>> says:
>>
>> "For routines with a variable number of arguments invoked viathe .External
>> interface, one specifies -1 for the number of arguments which tells R not to
>> check the actual number passed. Note that the number of arguments passed to
>> .External are not currently checked but they will be in R 3.0.0."
>>
>> So I need to change my Rinit.c to change the "1" to a "-1" and that error
>> should go away.
>>
>> Thanks again for all your help with this. I will update my package and
>> resubmit it once version 3.0 gets released and I get a chance to verify that
>> this does in fact fix the problem.
>>
>> Kevin
>>
>> __
>> R-devel@r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-devel
>>
>
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Withdrawal of package Rigroup-0.84.0 from CRAN
Hi Brian and Uwe,
Given my package passes all checks but I have received no further responses
since your initial reply, I assume you are no longer interested in the package
Rigroup-0.84.0. Your concerns about my chosen license being too vague "GPL |
LGPL" is in direct contradiction to what your own documents say about not
changing your license after a package has been accepted at CRAN. This is the
same license this package has had since it was first accepted in 2006 ("GPL or
LGPL your choice"). Your additional requirement was that I explain why I did
not reply to your January e-mail thereby forcing you to do "extra work to
archive the package" was already met on this very list. As I explained back in
March, I never received it (and no Uwe that does not mean I am claiming you
never sent it - just that I did not receive it!). Not quite the "thank you for
contributing to R" I hoped for, but after 7 years or so, it is unfortunately
what I expected...
Therefore this is to let you know that I am hereby withdrawing my package
Rigroup-0.84.0 from CRAN consideration. You can obviously keep using the
previous (now-archived) version under its license. But since I will no longer
be supporting the package and as its author I ask you to remove all versions
from CRAN. This is of course your choice given the original license Rigroup
was released under. If anyone's package depends on Rigroup, please feel free to
absorb it into your own packages in any way you want under any GPL *, BSD,
LGPL * licenses.
One thing the developers of R might want to consider is to add the very basic
optimization that Rigroup uses to base R so that it can better handle very very
large datasets (ala BigData) more effieciently. That is assuming there is not
some other package that does this that I am unaware of or that a similar
capability hasn't already been added to R-3.X since 2006.
The primary idea is simple and time worn ...
Given a large unsorted vector of data whose elements have been assigned to n
groups and whose group membership is represented by a second vector of equal
length whoses values are members of {1,...,n}, you can easily calculate
multiple group statistics for all n groups in just one pass through the
unsorted data vector by using the group membership as an index into one or
multiple vectors of statistics such as count, sum, max, min, all, any, average,
second moment, variance standard deviation, higher moments, etc Since
this is meant for very large vectors, it was implemented in C for speed.
For very very large unsorted data vectors, this one pass approach of using the
group membership as an offset into potentially multiple "statistics vectors" is
much much faster than trying to sort, or index, or subset the large unsorted
data vector using the typical approaches of R and then calculating the stats
and will work even if the group membership indicators do not span the set.
This is all that Rigroup did. Pretty much just common sense to any old
programmer who wanted to build portfolios and calculate basic portfolio stats
but who has to deal with large amounts of data.Perhaps sometime over the
last 7 years, you have already added something similar, if so, please ignore
this.
Given my withdrawl of this package I will also be removing myself from the
R-devel mailing list so if you want to contact me for any reason please CC me
directly (hopefully the sympatico.ca spam filter will not lose too many of
you)! It was an interesting 7 years. Good luck to you all.
Take care,
Kevin
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] New package test results available
Hi, I am the maintainer for the Rigroup package. Based on the e-mail below, I found and fixed a warning (spurious right brace) in the manual for my package under the new parser. It has been a number of years since I last revised the package and I am not sure where and how to upload it. I looked on the "developer" page but did not see anything that said where to upload revised packages. Sorry for the inconvenience but could someone please direct me to where I find the instructions for uploading revised packages. Thank you. Kevin On 7-Feb-09, at 2:22 AM, Prof Brian Ripley wrote: We've added a column at http://cran.r-project.org/web/checks/check_summary.html of test results using the Sun Studio compiler: it is intended that these will be updated weekly. The Sun Studio compiler is that used on Solaris: these runs were on the Linux version. All the other platforms are using gcc 4, so this provides an opportunity for checking for use of gcc-specific features and also standards conformance (the Sun compilers have a long-time reputation for close conformance to the language standards). There are known problems where packages use C++ or JNI interfaces (e.g. rgdal and EBImage) as the libraries and JVM were compiled under gcc's conventions (even though a Sun JVMi is used). About half the packages using rJava segfault, which seems to a JNI issue. Some packages use gcc-specific compiler flags: LogConcDEAD Matching amap geometry memisc taskPR but the vast majority of the errors reported are C++ errors. One class that may not be immediately obvious is the use of C headers in C++: you are supposed to write e.g. #includd NOT #include Symptoms of this can be seen for packages BayesTree EMCC MCMCfglmm MarkedPointProcess Matching Matrix RQuantlib RandomFields Rcpp SoPhy compHclust dpmix igraph minet mixer modeest monomvm multic pcaPP rgenoud robfilter segclust simecol subselect -- Brian D. Ripley, rip...@stats.ox.ac.uk Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/ University of Oxford, Tel: +44 1865 272861 (self) 1 South Parks Road, +44 1865 272866 (PA) Oxford OX1 3TG, UKFax: +44 1865 272595 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] New package test results available
Hi, Please ignore this request .. I found it in the Rext.pdf manual ... DUH! The revised package Rigroup_0.83.0.tar.gz has been uploaded. It passes R CMD check on version R 2.8.0 and hopefully with the new parser in the development tree as well. Sorry for the noise. Kevin On 7-Feb-09, at 11:39 AM, Kevin Hendricks wrote: Hi, I am the maintainer for the Rigroup package. Based on the e-mail below, I found and fixed a warning (spurious right brace) in the manual for my package under the new parser. It has been a number of years since I last revised the package and I am not sure where and how to upload it. I looked on the "developer" page but did not see anything that said where to upload revised packages. Sorry for the inconvenience but could someone please direct me to where I find the instructions for uploading revised packages. Thank you. Kevin On 7-Feb-09, at 2:22 AM, Prof Brian Ripley wrote: We've added a column at http://cran.r-project.org/web/checks/check_summary.html of test results using the Sun Studio compiler: it is intended that these will be updated weekly. The Sun Studio compiler is that used on Solaris: these runs were on the Linux version. All the other platforms are using gcc 4, so this provides an opportunity for checking for use of gcc-specific features and also standards conformance (the Sun compilers have a long-time reputation for close conformance to the language standards). There are known problems where packages use C++ or JNI interfaces (e.g. rgdal and EBImage) as the libraries and JVM were compiled under gcc's conventions (even though a Sun JVMi is used). About half the packages using rJava segfault, which seems to a JNI issue. Some packages use gcc-specific compiler flags: LogConcDEAD Matching amap geometry memisc taskPR but the vast majority of the errors reported are C++ errors. One class that may not be immediately obvious is the use of C headers in C++: you are supposed to write e.g. #includd NOT #include Symptoms of this can be seen for packages BayesTree EMCC MCMCfglmm MarkedPointProcess Matching Matrix RQuantlib RandomFields Rcpp SoPhy compHclust dpmix igraph minet mixer modeest monomvm multic pcaPP rgenoud robfilter segclust simecol subselect -- Brian D. Ripley, rip...@stats.ox.ac.uk Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/ University of Oxford, Tel: +44 1865 272861 (self) 1 South Parks Road, +44 1865 272866 (PA) Oxford OX1 3TG, UKFax: +44 1865 272595 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel __ 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] R thread safe
Hi, I don't think so, because IMHO it makes no sense - you're missing the main point that R is not thread safe. There are ways to use threads from within R very cautiously (see Luke's parallelized vector math operations for R for example). There are many good methods to use threads in general (pthreads, OpenMP, GCD, ...) and you can do that as long as you don't use memory allocation in R and don't call any R functions that may do that (which is most of them ;)). Making R thread-safe is not really an issue of a threading toolkit... Memory allocation does not necessarily make a function non-reentrant unless non-shared static variables are involved. There are a number of thread-safe malloc implementations.I admit, I have not looked at the R-internals in a long time. Based on converting code to be thread safe when I helped port the JDK to Linux, I was amazed about how much code was already reentrant capable and therefore basically thread-safe (or could be made so with small effort - adding a few locks). In fact the original JVM (jdk 1.0) had a "green-threads" implementation that basically ended up adding wrappers to most of the memory allocation and io system calls system calls to make the whole thing work. How much of the code itself is now reentrant safe - I noticed that some of the R-internal routines actually used reentrant code and even recursion? How hard would it be to make the internal object/memory allocation scheme thread-safe? As you noted there are many posix threads (pthreads) implmentations out there. Is there any official effort underway to make R thread-safe? If so, are they looking for volunteers. Would making R fully thread-safe really make that much sense given you can parallelize vector/matrix operations now (as you noted) which probably provides the most bang for the buck. Thanks, Kevin __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
