[Rd] feature and bug in wilcox.test
Dear Developers Team,
I have two items:
1. wilcox.test with the paired=T option appears to delete zeros
before ranking absolute differences.
Would it be possible to add the feature of removing
zeros after ranking, which is given in Lehmann's Nonparametrics
as the preferred choice. See also Pratt (1959), JASA 54, 655-667.
It is given in wilcoxsign_test of the coin package as an
option through the argument ties="Pratt" as opposed to
ties="HollanderWolfe" (default). I understand this this might
be more difficult for wilcox.test because of the method
for calculating the null distribution.
2. For the following two samples
Augmenters <- c(17.94,13.32,11.31,10.62,7.56,
5.73,5.61,5.40,3.30,3.09,.93)
Reducers <- c(7.74,5.04,1.68,0.0,-3.03,-3.09,-10.53)
I get the following strange confidence percentage of 91.46556
together with a warning message, when asking for a 95% lower bound.
I had the impression that wilcox.test would only echo back the input
confidence level.
When I ask for a 90% interval I get the same correct lower bound
without the strange percentage and without warnings. The actual
confidence coefficient of the lower bound 3.09 is 0.9573
(conservatively) and one gets lower bound 3.3 with confidence
coefficient 0.9479 if the achievable confidence level closest to
.95 is desired.
wilcox.test(Augmenters,Reducers,conf.int=T,conf.level=.95,alternative="greater",exact=T)
Wilcoxon rank sum test
data: Augmenters and Reducers
W = 66, p-value = 0.005688
alternative hypothesis: true location shift is greater than 0
91.46556 percent confidence interval:
3.09 Inf
sample estimates:
difference in location
7.56
Warning message:
In switch(alternative, two.sided = { : Requested conf.level not
achievable
wilcox.test(Augmenters,Reducers,conf.int=T,conf.level=.9,alternative="two.sided",exact=T)
Wilcoxon rank sum test
data: Augmenters and Reducers
W = 66, p-value = 0.01138
alternative hypothesis: true location shift is not equal to 0
90 percent confidence interval:
3.09 13.62
sample estimates:
difference in location
7.56
Thanks very much for any help or fix, especially with regard to
item 2.
Fritz Scholz
fsch...@u.washington.edu
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Problem using model.frame with argument subset in own function
Gavin,
I ran into the same cryptic "invalid subscript type 'closure'" message in
a slightly less complicated scenario, and wanted to post the cause in
my case (the root cause is probably the same either way).
Similarly to your case, I was subsetting a data frame. I had a list
of variable names corresponding to columns in the frame.
Unfortunately the variable name I had assigned to this list, var,
coincided with the name of a base package function in R for variance.
When I attempted to subset df[, var], I got the 'closure' error message,
but if I renamed the list of variable names so the collision didn't occur,
e.g. df[, vars] instead of df[, var], it worked as expected.
Sincerely,
Greg B. Hill
Gavin Simpson wrote:
>
> Dear List,
>
> I am writing a formula method for a function in a package I maintain. I
> want the method to return a data.frame that potentially only contains
> some of the variables in 'data', as specified by the formula.
>
> The problem I am having is in writing the function and wrapping it
> around model.frame. Consider the following data frame:
>
> dat <- data.frame(A = runif(10), B = runif(10), C = runif(10))
>
> And the wrapper function:
>
> foo <- function(formula, data = NULL, ..., subset = NULL,
> na.action = na.pass) {
> mt <- terms(formula, data = data, simplify = TRUE)
> mf <- model.frame(formula(mt), data = data, subset = subset,
> na.action = na.action)
> ## real function would do more stuff here and pass mf on to
> ## other functions
> mf
> }
>
> This is how I envisage the function being called. The real world use
> would have a data.frame with tens or hundreds of components where only a
> few need to be excluded. Hence wanting formulas of the form below to
> work.
>
> foo(~ . - B, data = dat)
>
> The aim is to return only columns A and C in an object returned by
> model.frame. However, when I run the above, I get the following error:
>
>> foo(~ A + B, data = dat)
> Error in xj[i] : invalid subscript type 'closure'
>
> I've tracked this down to the line in model.frame.default
>
> subset <- eval(substitute(subset), data, env)
>
> After evaluating this line, subset contains:
>
> Browse[1]> subset
> function (x, ...)
> UseMethod("subset")
>
>
> Not NULL, and hence the error later on when calling the internal
> model.frame code.
>
> So the question is, what am I doing wrong?
>
> If I leave the subset argument out of the definition of foo and rely
> upon the default in model.frame.default, the function works as
> expected.
>
> Perhaps the question should be, how do I modify foo() to allow it to
> have a formal subset argument, passed to model.frame?
>
> Any other suggestions gratefully accepted.
>
> Thanks in advance,
>
> G
> --
> %~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%
> Dr. Gavin Simpson [t] +44 (0)20 7679 0522
> ECRC, UCL Geography, [f] +44 (0)20 7679 0565
> Pearson Building, [e] gavin.simpsonATNOSPAMucl.ac.uk
> Gower Street, London [w] http://www.ucl.ac.uk/~ucfagls/
> UK. WC1E 6BT. [w] http://www.freshwaters.org.uk
> %~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>
>
--
View this message in context:
http://www.nabble.com/Problem-using-model.frame-with-argument-subset-in-own-function-tp24880908p25373059.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] Package that does not work until I re write the exactly the same code
Martin Morgan find the solution. Before
setMethod("kml","ClusterizLongData",func)
kml was in environment kml, After, kml is in environment global.
So, using traceback(), we find that kml use an object Partition that is
define in another package and that was export to the global environment
but not to kml environment.
Adding import or importForm in NAMESPACE solve the problem.
Christophe
Hi the list,
I am writing a package in S4 and I do not manage to understand a bug.
The "R CMD check" and the "R CMD build" both work. Here is links to
the package (not on CRAN yet for the raison that I explain bellow):
http://christophe.genolini.free.fr/aTelecharger/kml_0.5.zip
http://christophe.genolini.free.fr/aTelecharger/kml_0.5.tar.gz
Then I install the package and I try an example:
--- 8< --
library(kml)
dn <- as.cld(gald())
kml(dn)
# XXX ~ Fast KmL ~
# Erreur dans as.vector(x, mode) : argument 'mode' incorrect
--- 8< --
So I make some verifications:
--- 8<
class(dn)
# [1] "ClusterizLongData"
# attr(,"package")
# [1] "kml"
getMethod("kml","ClusterizLongData")
# Method Definition:
#
# function (Object, nbClusters = 2:6, nbRedrawing = 20, saveFreq = 100,
# maxIt = 200, trajMinSize = 2, print.cal = FALSE, print.traj = FALSE,
#imputationMethod = "copyMean", distance, power = 2, centerMethod
= meanNA,
#startingCond = "allMethods", distanceStartingCond = "euclidean",
# ...)
#{
# nbIdFull <- nrow(Object["traj"])
# .. [[[The full code is available below]]]
# }
#
#
#Signatures:
# Object# target "ClusterizLongData"
# defined "ClusterizLongData"
--- 8<
Everything seems fine. The code is correct.
So I copy-and-paste the code that I get with
getMethods("kml","ClusterizLongData") and I affect it to a function
"func". Then I define again the method "kml".
Then I run again the example that does not work before and it works...
Any explanations?
Christophe Genolini
--- 8< --
###
### Affecting to func the code that
getMethod("kml","ClusterizLongData") delivers
###
func <- function (Object, nbClusters = 2:6, nbRedrawing = 20, saveFreq
= 100,
maxIt = 200, trajMinSize = 2, print.cal = FALSE, print.traj = FALSE,
imputationMethod = "copyMean", distance, power = 2, centerMethod =
meanNA,
startingCond = "allMethods", distanceStartingCond = "euclidean",
...)
{
nbIdFull <- nrow(Object["traj"])
convergenceTime <- 0
noNA <- selectSupTrajMinSize(Object, trajMinSize)
trajNoNA <- Object["traj"][noNA, ]
nbTime <- length(Object["time"])
nbId <- nrow(trajNoNA)
saveCld <- 0
scr <- plotAll(Object, print.cal = print.cal, print.traj = print.traj,
print.sub = FALSE, col = "black", type.mean = "n")
if (length(startingCond) == 1) {
if (startingCond == "allMethods") {
startingCond <- c("maxDist", "randomAll", rep("randomK",
nbRedrawing))[1:nbRedrawing]
}
else {
startingCond <- rep(startingCond, nbRedrawing)
}
}
else {
}
if (missing(distance)) {
distance <- "euclidean"
}
if (is.character(distance)) {
distInt <- pmatch(distance, METHODS)
}
else {
distInt <- NA
}
if (print.traj) {
cat(" ~ Slow KmL ~\n")
fast <- FALSE
screenPlot <- scr[2]
if (!is.na(distInt)) {
distanceSlow <- function(x, y) {
dist(rbind(x, y), method = distance)
}
}
else {
distanceSlow <- distance
}
}
else {
screenPlot <- NA
if (is.na(distInt)) {
cat(" ~ Slow KmL ~\n")
fast <- FALSE
distanceSlow <- distance
}
else {
cat(" ~ Fast KmL ~\n")
fast <- TRUE
}
}
nameObject <- deparse(substitute(Object))
for (iRedraw in 1:nbRedrawing) {
for (iNbClusters in nbClusters) {
saveCld <- saveCld + 1
clustersInit <- partitionInitialise(nbClusters = iNbClusters,
method = startingCond[iRedraw], lengthPart = nbId,
matrixDist = as.matrix(dist(trajNoNA, method =
distanceStartingCond)))
clust <- rep(NA, nbIdFull)
if (fast) {
resultKml <- .C("kml1", as.double(t(trajNoNA)),
iNbInd = as.integer(nbId), iNbTime = as.integer(nbTime),
iNbCluster = as.integer(iNbClusters), maxIt =
as.integer(maxIt),
distance = as.integer(distInt), power =
as.numeric(power),
vClusterAffectation1 =
as.integer(clustersInit["clusters"]),
convergenceTime = as.integer(convergenceTime),
NAOK = TRUE, PACKAGE = "kml")[c(8, 9)]
clust[noNA] <- resultKml[[1]]
}
else {
resultKml <- trajKmlSlow(traj = trajNoNA,
clusterAffectation = clustersInit,
nbId = nbId, nbTime = nbTime, maxIt = maxIt,
[Rd] findLineNum and setBreakpoint added
I've just added a couple of functions to R-devel to help with
debugging. findLineNum() finds which line of which function corresponds
to a particular line of source code; setBreakpoint() takes the output of
findLineNum, and calls trace() to set a breakpoint there.
These rely on having source reference debug information in the code.
This is the default for code read by source(), but not for packages. To
get the source references in package code, set the environment variable
R_KEEP_PKG_SOURCE=yes, or within R, set options(keep.source.pkgs=TRUE),
then install the package from source code. Read ?findLineNum for
details on how to
tell it to search within packages, rather than limiting the search to
the global environment.
For example,
x <- " f <- function(a, b) {
if (a > b) {
a
} else {
b
}
}"
eval(parse(text=x)) # Normally you'd use source() to read a file...
findLineNum("#3") # is a dummy filename used by parse(text=)
This will print
f step 2,3,2 in
and you can use
setBreakpoint("#3")
to set a breakpoint there.
There are still some limitations (and probably bugs) in the code; I'll
be fixing those over the next while.
Duncan Murdoch
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] 'make install' fails on Solaris (PR#13946)
Sorry, typo.
Yes, it is confusing sed. And, yes, I am also using /usr/xpg4/bin/sed. Here
is the error:
bash-3.00# make install
installing doc ...
../tools/install-sh -c -m 644 ../NEWS
"/home/dev/scratch/bbownes/R/lib/R/doc"
installing doc/html ...
installing doc/html/search ...
installing doc/manual ...
installing etc ...
installing share ...
cc -I. -I../../src/include -I../../src/include -I/usr/local/include
-DHAVE_CONFIG_H -g -DR_HOME='"/home/dev/scratch/bbownes/R/lib/R"' -o
Rscript \
./Rscript.c
sed: command garbled: s:@libsprivate:-L/home/dev/scratch/bbownes/R/lib/R/lib
-lRblas
-R/home/dev/forte/10.0/SUNWspro/lib/v8plus:/home/dev/forte/10.0/SUNWspro/lib:/opt/SUNWspro/lib/v8plus:/opt/SUNWspro/lib
-L/home/dev/forte/10.0/SUNWspro/lib/v8plus
-L/home/dev/forte/10.0/SUNWspro/prod/lib/v8plus
-L/home/dev/forte/10.0/SUNWspro/lib -L/home/dev/forte/10.0/SUNWspro/prod/lib
-L/usr/ccs/lib -lfui -lfai -lfai2 -lfsumai -lfprodai -lfminlai -lfmaxlai
-lfminvai -lfmaxvai -lfsu -lsunmath -lmtsk -lm-lnsl -lsocket -ldl -lm
-licuuc -licui18n:
*** Error code 2
The following command caused the error:
/usr/xpg4/bin/sed -e "s:@rhome:/home/dev/scratch/bbownes/R/lib/R:" -e
"s:@rincludedir:/home/dev/scratch/bbownes/R/lib/R/include:" \
-e 's:@libsprivate:-L/home/dev/scratch/bbownes/R/lib/R/lib -lRblas
-R/home/dev/forte/10.0/SUNWspro/lib/v8plus:/home/dev/forte/10.0/SUNWspro/lib:/opt/SUNWspro/lib/v8plus:/opt/SUNWspro/lib
-L/home/dev/forte/10.0/SUNWspro/lib/v8plus
-L/home/dev/forte/10.0/SUNWspro/prod/lib/v8plus
-L/home/dev/forte/10.0/SUNWspro/lib -L/home/dev/forte/10.0/SUNWspro/prod/lib
-L/usr/ccs/lib -lfui -lfai -lfai2 -lfsumai -lfprodai -lfminlai -lfmaxlai
-lfminvai -lfmaxvai -lfsu -lsunmath -lmtsk -lm-lnsl -lsocket -ldl -lm
-licuuc -licui18n:' \
-e 's/@VERSION/2.9.2/' ./libR.pc.in \
> "/home/dev/scratch/bbownes/R/lib/pkgconfig/libR.pc"
make: Fatal error: Command failed for target `install-pc'
Current working directory /home/dev/scratch/bbownes/R-2.9.2/src/unix
*** Error code 1
The following command caused the error:
for d in scripts include extra appl nmath unix main modules library; do \
(cd ${d} && make install) || exit 1; \
done
make: Fatal error: Command failed for target `install'
Current working directory /home/dev/scratch/bbownes/R-2.9.2/src
*** Error code 1
The following command caused the error:
for d in m4 tools doc etc share src tests po; do \
(cd ${d} && make install) || exit 1; \
done
make: Fatal error: Command failed for target `install'
bash-3.00#
and the configure that started it all:
./configure --with-readline=no --with-iconv=no --with-x=no
--enable-static=yes --enable-R-static-lib
--prefix=/home/dev/scratch/bbownes/R
On Thu, Sep 10, 2009 at 2:34 AM, Peter Dalgaard wrote:
> Prof Brian Ripley wrote:
>
>> On Thu, 10 Sep 2009, bow...@gmail.com wrote:
>>
>> Full_Name: Bob Bownes
>>> Version: 2.9.2
>>> OS: Solaris 10
>>> Submission from: (NULL) (164.55.254.106)
>>>
>>>
>>> The sed lines in src/unix/Makefile confuse the grep distributed with
>>> Solaris
>>> that gets configured by ./configure.
>>>
>>
>> Well, it calls sed not grep! Which version was that -- it works for me
>> and for several others. I have SED = /usr/xpg4/bin/sed (see file Makeconf),
>> and that is 'distributed with Solaris': perhaps you do not have it
>> installed?
>>
>> The danger of changing R to fix a broken OS tool is that the change may
>> break on other people's tools -- better to fix the tool.
>>
>
>
> Is this a tool problem at all? The most common reason for separator
> breakage is that one of the substitution strings contains the separator.
>
> E.g., the sed line may break if @rhome contains a colon, and after the fix
> it will break if it contains a comma...
>
>
>>
>> Switching from a separator of ':' to a separator of ',' fixes the
>>> problem.
>>>
>>> 76,77c76,77
>>> < @$(SED) -e "s:@rhome:$(rhome):" -e "s:@rincludedir:$(rincludedir):"
>>> \
>>> < -e 's:@libsprivate:$(STATIC_LIBR_PC):' \
>>> ---
>>>
@$(SED) -e "s,@rhome,$(rhome)," -e "s,@rincludedir,$(rincludedir),"
\
-e 's,@libsprivate,$(STATIC_LIBR_PC),' \
>>>
>>
>
> --
> O__ Peter Dalgaard Øster Farimagsgade 5, Entr.B
> c/ /'_ --- Dept. of Biostatistics PO Box 2099, 1014 Cph. K
> (*) \(*) -- University of Copenhagen Denmark Ph: (+45) 35327918
> ~~ - (p.dalga...@biostat.ku.dk) FAX: (+45) 35327907
>
[[alternative HTML version deleted]]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] 'make install' fails on Solaris (PR#13946)
Sorry, typo.
Yes, it is confusing sed. And, yes, I am also using /usr/xpg4/bin/sed. Here
is the error:
bash-3.00# make install
installing doc ...
../tools/install-sh -c -m 644 ../NEWS
"/home/dev/scratch/bbownes/R/lib/R/doc"
installing doc/html ...
installing doc/html/search ...
installing doc/manual ...
installing etc ...
installing share ...
cc -I. -I../../src/include -I../../src/include -I/usr/local/include
-DHAVE_CONFIG_H -g -DR_HOME=3D'"/home/dev/scratch/bbownes/R/lib/R"' -o
Rscript \
./Rscript.c
sed: command garbled: s:@libsprivate:-L/home/dev/scratch/bbownes/R/lib/R/lib
-lRblas
-R/home/dev/forte/10.0/SUNWspro/lib/v8plus:/home/dev/forte/10.0/SUNWspro/li=
b:/opt/SUNWspro/lib/v8plus:/opt/SUNWspro/lib
-L/home/dev/forte/10.0/SUNWspro/lib/v8plus
-L/home/dev/forte/10.0/SUNWspro/prod/lib/v8plus
-L/home/dev/forte/10.0/SUNWspro/lib -L/home/dev/forte/10.0/SUNWspro/prod/lib
-L/usr/ccs/lib -lfui -lfai -lfai2 -lfsumai -lfprodai -lfminlai -lfmaxlai
-lfminvai -lfmaxvai -lfsu -lsunmath -lmtsk -lm-lnsl -lsocket -ldl -lm
-licuuc -licui18n:
*** Error code 2
The following command caused the error:
/usr/xpg4/bin/sed -e "s:@rhome:/home/dev/scratch/bbownes/R/lib/R:" -e
"s:@rincludedir:/home/dev/scratch/bbownes/R/lib/R/include:" \
-e 's:@libsprivate:-L/home/dev/scratch/bbownes/R/lib/R/lib -lRblas
-R/home/dev/forte/10.0/SUNWspro/lib/v8plus:/home/dev/forte/10.0/SUNWspro/li=
b:/opt/SUNWspro/lib/v8plus:/opt/SUNWspro/lib
-L/home/dev/forte/10.0/SUNWspro/lib/v8plus
-L/home/dev/forte/10.0/SUNWspro/prod/lib/v8plus
-L/home/dev/forte/10.0/SUNWspro/lib -L/home/dev/forte/10.0/SUNWspro/prod/lib
-L/usr/ccs/lib -lfui -lfai -lfai2 -lfsumai -lfprodai -lfminlai -lfmaxlai
-lfminvai -lfmaxvai -lfsu -lsunmath -lmtsk -lm-lnsl -lsocket -ldl -lm
-licuuc -licui18n:' \
-e 's/@VERSION/2.9.2/' ./libR.pc.in \
> "/home/dev/scratch/bbownes/R/lib/pkgconfig/libR.pc"
make: Fatal error: Command failed for target `install-pc'
Current working directory /home/dev/scratch/bbownes/R-2.9.2/src/unix
*** Error code 1
The following command caused the error:
for d in scripts include extra appl nmath unix main modules library; do \
(cd ${d} && make install) || exit 1; \
done
make: Fatal error: Command failed for target `install'
Current working directory /home/dev/scratch/bbownes/R-2.9.2/src
*** Error code 1
The following command caused the error:
for d in m4 tools doc etc share src tests po; do \
(cd ${d} && make install) || exit 1; \
done
make: Fatal error: Command failed for target `install'
bash-3.00#
and the configure that started it all:
./configure --with-readline=3Dno --with-iconv=3Dno --with-x=3Dno
--enable-static=3Dyes --enable-R-static-lib
--prefix=3D/home/dev/scratch/bbownes/R
On Thu, Sep 10, 2009 at 2:34 AM, Peter Dalgaard w=
rote:
> Prof Brian Ripley wrote:
>
>> On Thu, 10 Sep 2009, bow...@gmail.com wrote:
>>
>> Full_Name: Bob Bownes
>>> Version: 2.9.2
>>> OS: Solaris 10
>>> Submission from: (NULL) (164.55.254.106)
>>>
>>>
>>> The sed lines in src/unix/Makefile confuse the grep distributed with
>>> Solaris
>>> that gets configured by ./configure.
>>>
>>
>> Well, it calls sed not grep! Which version was that -- it works for me
>> and for several others. I have SED =3D /usr/xpg4/bin/sed (see file Make=
conf),
>> and that is 'distributed with Solaris': perhaps you do not have it
>> installed?
>>
>> The danger of changing R to fix a broken OS tool is that the change may
>> break on other people's tools -- better to fix the tool.
>>
>
>
> Is this a tool problem at all? The most common reason for separator
> breakage is that one of the substitution strings contains the separator.
>
> E.g., the sed line may break if @rhome contains a colon, and after the f=
ix
> it will break if it contains a comma...
>
>
>>
>> Switching from a separator of ':' to a separator of ',' fixes the
>>> problem.
>>>
>>> 76,77c76,77
>>> < @$(SED) -e "s:@rhome:$(rhome):" -e "s:@rincludedir:$(rincludedi=
r):"
>>> \
>>> < -e 's:@libsprivate:$(STATIC_LIBR_PC):' \
>>> ---
>>>
@$(SED) -e "s,@rhome,$(rhome)," -e "s,@rincludedir,$(rincludedir)=
,"
\
-e 's,@libsprivate,$(STATIC_LIBR_PC),' \
>>>
>>
>
> --
> O__ Peter Dalgaard =D8ster Farimagsgade 5, Entr.B
> c/ /'_ --- Dept. of Biostatistics PO Box 2099, 1014 Cph. K
> (*) \(*) -- University of Copenhagen Denmark Ph: (+45) 35327918
> ~~ - (p.dalga...@biostat.ku.dk) FAX: (+45) 35327907
>
[[alternative HTML version deleted]]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] 'make install' fails on Solaris (PR#13946)
This message is in MIME format. The first part should be readable text,
while the remaining parts are likely unreadable without MIME-aware tools.
--27464147-1085614336-1252597171=:13955
Content-Type: TEXT/PLAIN; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8BIT
I can see what has happened: one of the paths contains : as Peter
suggested. By not why, and there seem to be more wrong with it: look
at the lines I've enclosed in ===. There is no space after -Rblas,
and other odd things, so changing the sed script would not help here.
As Peter say, -Wlfoo,bar is just as likely as : in there if things go
this badly wrong. (Of course mailer may have garbled this.)
I have
STATIC_LIBR_PC = $(BLAS_LIBS) $(FLIBS) $(LIBINTL) -lreadline -ltermcap $(LIBS)
and nothing strange in the expansion.
Try not using --enable-R-static-lib.
What we could do it to allow the script to fail: having libR.pc is a
convenience, and --enable-R-static-lib is rarely used.
On Thu, 10 Sep 2009, Bob Bownes wrote:
> Sorry, typo.
>
> Yes, it is confusing sed. And, yes, I am also using /usr/xpg4/bin/sed. Here
> is the error:
>
> bash-3.00# make install
> installing doc ...
> ../tools/install-sh -c -m 644 ../NEWS
> "/home/dev/scratch/bbownes/R/lib/R/doc"
> installing doc/html ...
> installing doc/html/search ...
> installing doc/manual ...
> installing etc ...
> installing share ...
> cc -I. -I../../src/include -I../../src/include -I/usr/local/include
> -DHAVE_CONFIG_H -g -DR_HOME='"/home/dev/scratch/bbownes/R/lib/R"' -o
> Rscript \
> ./Rscript.c
> sed: command garbled: s:@libsprivate:-L/home/dev/scratch/bbownes/R/lib/R/lib
===
> -lRblas-R/home/dev/forte/10.0/SUNWspro/lib/v8plus:/home/dev/forte/10.0/SUNWspro/li
> b:/opt/SUNWspro/lib/v8plus:/opt/SUNWspro/lib
===
> -L/home/dev/forte/10.0/SUNWspro/lib/v8plus
> -L/home/dev/forte/10.0/SUNWspro/prod/lib/v8plus
> -L/home/dev/forte/10.0/SUNWspro/lib -L/home/dev/forte/10.0/SUNWspro/prod/lib
> -L/usr/ccs/lib -lfui -lfai -lfai2 -lfsumai -lfprodai -lfminlai -lfmaxlai
> -lfminvai -lfmaxvai -lfsu -lsunmath -lmtsk -lm -lnsl -lsocket -ldl -lm
> -licuuc -licui18n:
> *** Error code 2
> The following command caused the error:
> /usr/xpg4/bin/sed -e "s:@rhome:/home/dev/scratch/bbownes/R/lib/R:" -e
> "s:@rincludedir:/home/dev/scratch/bbownes/R/lib/R/include:" \
> -e 's:@libsprivate:-L/home/dev/scratch/bbownes/R/lib/R/lib
> -lRblas-R/home/dev/forte/10.0/SUNWspro/lib/v8plus:/home/dev/forte/10.0/SUNWspro/li
> b:/opt/SUNWspro/lib/v8plus:/opt/SUNWspro/lib
> -L/home/dev/forte/10.0/SUNWspro/lib/v8plus
> -L/home/dev/forte/10.0/SUNWspro/prod/lib/v8plus
> -L/home/dev/forte/10.0/SUNWspro/lib -L/home/dev/forte/10.0/SUNWspro/prod/lib
> -L/usr/ccs/lib -lfui -lfai -lfai2 -lfsumai -lfprodai -lfminlai -lfmaxlai
> -lfminvai -lfmaxvai -lfsu -lsunmath -lmtsk -lm -lnsl -lsocket -ldl -lm
> -licuuc -licui18n:' \
> -e 's/@VERSION/2.9.2/' ./libR.pc.in \
> > "/home/dev/scratch/bbownes/R/lib/pkgconfig/libR.pc"
> make: Fatal error: Command failed for target `install-pc'
> Current working directory /home/dev/scratch/bbownes/R-2.9.2/src/unix
> *** Error code 1
> The following command caused the error:
> for d in scripts include extra appl nmath unix main modules library; do \
> (cd ${d} && make install) || exit 1; \
> done
> make: Fatal error: Command failed for target `install'
> Current working directory /home/dev/scratch/bbownes/R-2.9.2/src
> *** Error code 1
> The following command caused the error:
> for d in m4 tools doc etc share src tests po; do \
> (cd ${d} && make install) || exit 1; \
> done
> make: Fatal error: Command failed for target `install'
> bash-3.00#
>
> and the configure that started it all:
> ./configure --with-readline=no --with-iconv=no --with-x=no
> --enable-static=yes --enable-R-static-lib
> --prefix=/home/dev/scratch/bbownes/R
>
>
>
>
> On Thu, Sep 10, 2009 at 2:34 AM, Peter Dalgaard
> wrote:
> Prof Brian Ripley wrote:
> On Thu, 10 Sep 2009, bow...@gmail.com wrote:
>
> Full_Name: Bob Bownes
> Version: 2.9.2
> OS: Solaris 10
> Submission from: (NULL) (164.55.254.106)
>
>
> The sed lines in src/unix/Makefile
> confuse the grep distributed with
> Solaris
> that gets configured by ./configure.
>
>
> Well, it calls sed not grep! Which version was that
> -- it works for me and for several others. I have
> SED = /usr/xpg4/bin/sed (see file Makeconf), and
> that is 'distributed with Solaris': perhaps you do
> not have it installed?
>
> The danger of changing R to fix a broken OS tool is
> that the change may break on other people's tools --
> better to fix the tool.
>
>
>
> Is this a tool problem at all? The most common reason for separator
> breakage is that one of the substitution s
Re: [Rd] 'make install' fails on Solaris (PR#13946)
I can see what has happened: one of the paths contains : as Peter
suggested. By not why, and there seem to be more wrong with it: look
at the lines I've enclosed in ===. There is no space after -Rblas,
and other odd things, so changing the sed script would not help here.
As Peter say, -Wlfoo,bar is just as likely as : in there if things go
this badly wrong. (Of course mailer may have garbled this.)
I have
STATIC_LIBR_PC = $(BLAS_LIBS) $(FLIBS) $(LIBINTL) -lreadline -ltermcap $(LIBS)
and nothing strange in the expansion.
Try not using --enable-R-static-lib.
What we could do it to allow the script to fail: having libR.pc is a
convenience, and --enable-R-static-lib is rarely used.
On Thu, 10 Sep 2009, Bob Bownes wrote:
Sorry, typo.
Yes, it is confusing sed. And, yes, I am also using /usr/xpg4/bin/sed. Here
is the error:
bash-3.00# make install
installing doc ...
../tools/install-sh -c -m 644 ../NEWS
"/home/dev/scratch/bbownes/R/lib/R/doc"
installing doc/html ...
installing doc/html/search ...
installing doc/manual ...
installing etc ...
installing share ...
cc -I. -I../../src/include -I../../src/include -I/usr/local/include
-DHAVE_CONFIG_H -g -DR_HOME='"/home/dev/scratch/bbownes/R/lib/R"' -o
Rscript \
./Rscript.c
sed: command garbled: s:@libsprivate:-L/home/dev/scratch/bbownes/R/lib/R/lib
===
-lRblas-R/home/dev/forte/10.0/SUNWspro/lib/v8plus:/home/dev/forte/10.0/SUNWspro/li
b:/opt/SUNWspro/lib/v8plus:/opt/SUNWspro/lib
===
-L/home/dev/forte/10.0/SUNWspro/lib/v8plus
-L/home/dev/forte/10.0/SUNWspro/prod/lib/v8plus
-L/home/dev/forte/10.0/SUNWspro/lib -L/home/dev/forte/10.0/SUNWspro/prod/lib
-L/usr/ccs/lib -lfui -lfai -lfai2 -lfsumai -lfprodai -lfminlai -lfmaxlai
-lfminvai -lfmaxvai -lfsu -lsunmath -lmtsk -lm -lnsl -lsocket -ldl -lm
-licuuc -licui18n:
*** Error code 2
The following command caused the error:
/usr/xpg4/bin/sed -e "s:@rhome:/home/dev/scratch/bbownes/R/lib/R:" -e
"s:@rincludedir:/home/dev/scratch/bbownes/R/lib/R/include:" \
-e 's:@libsprivate:-L/home/dev/scratch/bbownes/R/lib/R/lib
-lRblas-R/home/dev/forte/10.0/SUNWspro/lib/v8plus:/home/dev/forte/10.0/SUNWspro/li
b:/opt/SUNWspro/lib/v8plus:/opt/SUNWspro/lib
-L/home/dev/forte/10.0/SUNWspro/lib/v8plus
-L/home/dev/forte/10.0/SUNWspro/prod/lib/v8plus
-L/home/dev/forte/10.0/SUNWspro/lib -L/home/dev/forte/10.0/SUNWspro/prod/lib
-L/usr/ccs/lib -lfui -lfai -lfai2 -lfsumai -lfprodai -lfminlai -lfmaxlai
-lfminvai -lfmaxvai -lfsu -lsunmath -lmtsk -lm -lnsl -lsocket -ldl -lm
-licuuc -licui18n:' \
-e 's/@VERSION/2.9.2/' ./libR.pc.in \
> "/home/dev/scratch/bbownes/R/lib/pkgconfig/libR.pc"
make: Fatal error: Command failed for target `install-pc'
Current working directory /home/dev/scratch/bbownes/R-2.9.2/src/unix
*** Error code 1
The following command caused the error:
for d in scripts include extra appl nmath unix main modules library; do \
(cd ${d} && make install) || exit 1; \
done
make: Fatal error: Command failed for target `install'
Current working directory /home/dev/scratch/bbownes/R-2.9.2/src
*** Error code 1
The following command caused the error:
for d in m4 tools doc etc share src tests po; do \
(cd ${d} && make install) || exit 1; \
done
make: Fatal error: Command failed for target `install'
bash-3.00#
and the configure that started it all:
./configure --with-readline=no --with-iconv=no --with-x=no
--enable-static=yes --enable-R-static-lib
--prefix=/home/dev/scratch/bbownes/R
On Thu, Sep 10, 2009 at 2:34 AM, Peter Dalgaard
wrote:
Prof Brian Ripley wrote:
On Thu, 10 Sep 2009, bow...@gmail.com wrote:
Full_Name: Bob Bownes
Version: 2.9.2
OS: Solaris 10
Submission from: (NULL) (164.55.254.106)
The sed lines in src/unix/Makefile
confuse the grep distributed with
Solaris
that gets configured by ./configure.
Well, it calls sed not grep! Which version was that
-- it works for me and for several others. I have
SED = /usr/xpg4/bin/sed (see file Makeconf), and
that is 'distributed with Solaris': perhaps you do
not have it installed?
The danger of changing R to fix a broken OS tool is
that the change may break on other people's tools --
better to fix the tool.
Is this a tool problem at all? The most common reason for separator
breakage is that one of the substitution strings contains the
separator.
E.g., the sed line may break if �...@rhome contains a colon, and after
the fix it will break if it contains a comma...
Switching from a separator of ':' to a
separator of ',' fixes the problem.
76,77c76,77
< @$(SED) -e "s:@rhome:$(rhome):" -e
"s:@rincludedir:$(rincludedir):" \
< -e
's:@libsprivate:$(STATIC_LIBR_PC):' \
---
Re: [Rd] 'make install' fails on Solaris (PR#13946)
Interesting. None of my paths have ':' in them.
make install without --enable-R-static-lib works fine.
On Thu, Sep 10, 2009 at 11:39 AM, Prof Brian Ripley
wrote:
> I can see what has happened: one of the paths contains : as Peter
> suggested. By not why, and there seem to be more wrong with it: look at the
> lines I've enclosed in ===. There is no space after -Rblas, and other odd
> things, so changing the sed script would not help here.
> As Peter say, -Wlfoo,bar is just as likely as : in there if things go this
> badly wrong. (Of course mailer may have garbled this.)
>
> I have
>
> STATIC_LIBR_PC = $(BLAS_LIBS) $(FLIBS) $(LIBINTL) -lreadline -ltermcap
> $(LIBS)
>
> and nothing strange in the expansion.
>
> Try not using --enable-R-static-lib.
>
> What we could do it to allow the script to fail: having libR.pc is a
> convenience, and --enable-R-static-lib is rarely used.
>
>
>
> On Thu, 10 Sep 2009, Bob Bownes wrote:
>
> Sorry, typo.
>>
>> Yes, it is confusing sed. And, yes, I am also using /usr/xpg4/bin/sed.
>> Here
>> is the error:
>>
>> bash-3.00# make install
>> installing doc ...
>> ../tools/install-sh -c -m 644 ../NEWS
>> "/home/dev/scratch/bbownes/R/lib/R/doc"
>> installing doc/html ...
>> installing doc/html/search ...
>> installing doc/manual ...
>> installing etc ...
>> installing share ...
>> cc -I. -I../../src/include -I../../src/include -I/usr/local/include
>> -DHAVE_CONFIG_H -g -DR_HOME='"/home/dev/scratch/bbownes/R/lib/R"' -o
>> Rscript \
>> ./Rscript.c
>> sed: command garbled: s:@libsprivate
>> :-L/home/dev/scratch/bbownes/R/lib/R/lib
>>
> ===
>
>>
>> -lRblas-R/home/dev/forte/10.0/SUNWspro/lib/v8plus:/home/dev/forte/10.0/SUNWspro/li
>> b:/opt/SUNWspro/lib/v8plus:/opt/SUNWspro/lib
>>
> ===
>
>> -L/home/dev/forte/10.0/SUNWspro/lib/v8plus
>> -L/home/dev/forte/10.0/SUNWspro/prod/lib/v8plus
>> -L/home/dev/forte/10.0/SUNWspro/lib
>> -L/home/dev/forte/10.0/SUNWspro/prod/lib
>> -L/usr/ccs/lib -lfui -lfai -lfai2 -lfsumai -lfprodai -lfminlai -lfmaxlai
>> -lfminvai -lfmaxvai -lfsu -lsunmath -lmtsk -lm-lnsl -lsocket -ldl -lm
>> -licuuc -licui18n:
>> *** Error code 2
>> The following command caused the error:
>> /usr/xpg4/bin/sed -e "s:@rhome:/home/dev/scratch/bbownes/R/lib/R:" -e
>> "s:@rincludedir:/home/dev/scratch/bbownes/R/lib/R/include:" \
>> -e 's:@libsprivate:-L/home/dev/scratch/bbownes/R/lib/R/lib
>> -lRblas-R/home/dev/forte/10.0/SUNWspro/lib/v8plus:/home/dev/forte/10.0/SUNWspro/li
>> b:/opt/SUNWspro/lib/v8plus:/opt/SUNWspro/lib
>> -L/home/dev/forte/10.0/SUNWspro/lib/v8plus
>> -L/home/dev/forte/10.0/SUNWspro/prod/lib/v8plus
>> -L/home/dev/forte/10.0/SUNWspro/lib
>> -L/home/dev/forte/10.0/SUNWspro/prod/lib
>> -L/usr/ccs/lib -lfui -lfai -lfai2 -lfsumai -lfprodai -lfminlai -lfmaxlai
>> -lfminvai -lfmaxvai -lfsu -lsunmath -lmtsk -lm-lnsl -lsocket -ldl -lm
>> -licuuc -licui18n:' \
>> -e 's/@VERSION/2.9.2/' ./libR.pc.in \
>> > "/home/dev/scratch/bbownes/R/lib/pkgconfig/libR.pc"
>> make: Fatal error: Command failed for target `install-pc'
>> Current working directory /home/dev/scratch/bbownes/R-2.9.2/src/unix
>> *** Error code 1
>> The following command caused the error:
>> for d in scripts include extra appl nmath unix main modules library; do \
>> (cd ${d} && make install) || exit 1; \
>> done
>> make: Fatal error: Command failed for target `install'
>> Current working directory /home/dev/scratch/bbownes/R-2.9.2/src
>> *** Error code 1
>> The following command caused the error:
>> for d in m4 tools doc etc share src tests po; do \
>> (cd ${d} && make install) || exit 1; \
>> done
>> make: Fatal error: Command failed for target `install'
>> bash-3.00#
>>
>> and the configure that started it all:
>> ./configure --with-readline=no --with-iconv=no --with-x=no
>> --enable-static=yes --enable-R-static-lib
>> --prefix=/home/dev/scratch/bbownes/R
>>
>>
>>
>>
>> On Thu, Sep 10, 2009 at 2:34 AM, Peter Dalgaard > >
>> wrote:
>> Prof Brian Ripley wrote:
>>On Thu, 10 Sep 2009, bow...@gmail.com wrote:
>>
>> Full_Name: Bob Bownes
>> Version: 2.9.2
>> OS: Solaris 10
>> Submission from: (NULL) (164.55.254.106)
>>
>>
>> The sed lines in src/unix/Makefile
>> confuse the grep distributed with
>> Solaris
>> that gets configured by ./configure.
>>
>>
>>Well, it calls sed not grep! Which version was that
>>-- it works for me and for several others. I have
>>SED = /usr/xpg4/bin/sed (see file Makeconf), and
>>that is 'distributed with Solaris': perhaps you do
>>not have it installed?
>>
>>The danger of changing R to fix a broken OS tool is
>>that the change may break on other people's tools --
>>better to fix the tool.
>>
>>
>>
>> Is this a tool problem at all? The most common reason for separator
>> breakage is that one of the
Re: [Rd] 'make install' fails on Solaris (PR#13946)
Interesting. None of my paths have ':' in them.
make install without --enable-R-static-lib works fine.
On Thu, Sep 10, 2009 at 11:39 AM, Prof Brian Ripley
wrote:
> I can see what has happened: one of the paths contains : as Peter
> suggested. By not why, and there seem to be more wrong with it: look at =
the
> lines I've enclosed in =3D=3D=3D. There is no space after -Rblas, and ot=
her odd
> things, so changing the sed script would not help here.
> As Peter say, -Wlfoo,bar is just as likely as : in there if things go this
> badly wrong. (Of course mailer may have garbled this.)
>
> I have
>
> STATIC_LIBR_PC =3D $(BLAS_LIBS) $(FLIBS) $(LIBINTL) -lreadline -ltermcap
> $(LIBS)
>
> and nothing strange in the expansion.
>
> Try not using --enable-R-static-lib.
>
> What we could do it to allow the script to fail: having libR.pc is a
> convenience, and --enable-R-static-lib is rarely used.
>
>
>
> On Thu, 10 Sep 2009, Bob Bownes wrote:
>
> Sorry, typo.
>>
>> Yes, it is confusing sed. And, yes, I am also using /usr/xpg4/bin/sed.
>> Here
>> is the error:
>>
>> bash-3.00# make install
>> installing doc ...
>> ../tools/install-sh -c -m 644 ../NEWS
>> "/home/dev/scratch/bbownes/R/lib/R/doc"
>> installing doc/html ...
>> installing doc/html/search ...
>> installing doc/manual ...
>> installing etc ...
>> installing share ...
>> cc -I. -I../../src/include -I../../src/include -I/usr/local/include
>> -DHAVE_CONFIG_H -g -DR_HOME=3D'"/home/dev/scratch/bbownes/R/lib/R"' -o
>> Rscript \
>> ./Rscript.c
>> sed: command garbled: s:@libsprivate
>> :-L/home/dev/scratch/bbownes/R/lib/R/lib
>>
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>
>>
>> -lRblas-R/home/dev/forte/10.0/SUNWspro/lib/v8plus:/home/dev/forte/10.0/S=
UNWspro/li
>> b:/opt/SUNWspro/lib/v8plus:/opt/SUNWspro/lib
>>
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>
>> -L/home/dev/forte/10.0/SUNWspro/lib/v8plus
>> -L/home/dev/forte/10.0/SUNWspro/prod/lib/v8plus
>> -L/home/dev/forte/10.0/SUNWspro/lib
>> -L/home/dev/forte/10.0/SUNWspro/prod/lib
>> -L/usr/ccs/lib -lfui -lfai -lfai2 -lfsumai -lfprodai -lfminlai -lfmaxlai
>> -lfminvai -lfmaxvai -lfsu -lsunmath -lmtsk -lm-lnsl -lsocket -ldl -lm
>> -licuuc -licui18n:
>> *** Error code 2
>> The following command caused the error:
>> /usr/xpg4/bin/sed -e "s:@rhome:/home/dev/scratch/bbownes/R/lib/R:" -e
>> "s:@rincludedir:/home/dev/scratch/bbownes/R/lib/R/include:" \
>> -e 's:@libsprivate:-L/home/dev/scratch/bbownes/R/lib/R/lib
>> -lRblas-R/home/dev/forte/10.0/SUNWspro/lib/v8plus:/home/dev/forte/10.0/S=
UNWspro/li
>> b:/opt/SUNWspro/lib/v8plus:/opt/SUNWspro/lib
>> -L/home/dev/forte/10.0/SUNWspro/lib/v8plus
>> -L/home/dev/forte/10.0/SUNWspro/prod/lib/v8plus
>> -L/home/dev/forte/10.0/SUNWspro/lib
>> -L/home/dev/forte/10.0/SUNWspro/prod/lib
>> -L/usr/ccs/lib -lfui -lfai -lfai2 -lfsumai -lfprodai -lfminlai -lfmaxlai
>> -lfminvai -lfmaxvai -lfsu -lsunmath -lmtsk -lm-lnsl -lsocket -ldl -lm
>> -licuuc -licui18n:' \
>> -e 's/@VERSION/2.9.2/' ./libR.pc.in \
>> > "/home/dev/scratch/bbownes/R/lib/pkgconfig/libR.pc"
>> make: Fatal error: Command failed for target `install-pc'
>> Current working directory /home/dev/scratch/bbownes/R-2.9.2/src/unix
>> *** Error code 1
>> The following command caused the error:
>> for d in scripts include extra appl nmath unix main modules library; do \
>> (cd ${d} && make install) || exit 1; \
>> done
>> make: Fatal error: Command failed for target `install'
>> Current working directory /home/dev/scratch/bbownes/R-2.9.2/src
>> *** Error code 1
>> The following command caused the error:
>> for d in m4 tools doc etc share src tests po; do \
>> (cd ${d} && make install) || exit 1; \
>> done
>> make: Fatal error: Command failed for target `install'
>> bash-3.00#
>>
>> and the configure that started it all:
>> ./configure --with-readline=3Dno --with-iconv=3Dno --with-x=3Dno
>> --enable-static=3Dyes --enable-R-static-lib
>> --prefix=3D/home/dev/scratch/bbownes/R
>>
>>
>>
>>
>> On Thu, Sep 10, 2009 at 2:34 AM, Peter Dalgaard > >
>> wrote:
>> Prof Brian Ripley wrote:
>>On Thu, 10 Sep 2009, bow...@gmail.com wrote:
>>
>> Full_Name: Bob Bownes
>> Version: 2.9.2
>> OS: Solaris 10
>> Submission from: (NULL) (164.55.254.106)
>>
>>
>> The sed lines in src/unix/Makefile
>> confuse the grep distributed with
>> Solaris
>> that gets configured by ./configure.
>>
>>
>>Well, it calls sed not grep! Which version was that
>>-- it works for me and for several others. I have
>>SED =3D /usr/xpg4/bin/sed (see file Makeconf), and
>>that is 'distributed with Solaris': perhaps you do
>>not have it installed?
>>
>>The danger of changing R to fix a broken OS tool is
>>that the change may break on other people's tools --
>>better to fix the tool.
>>
>>
>>
>> Is this a tool problem a
[Rd] Non-GPL packages for R
Subject: Non-GPL packages for R Packages that are not licensed in a way that permits re-distribution on CRAN are frequently a source of comment and concern on R-help and other lists. A good example of this problem is the Rdonlp2 package that has caused a lot of annoyance for a number of optimization users in R. They are also an issue for efforts like Dirk Eddelbuettel's cran2deb. There are, however, a number of circumstances where non-GPL equivalent packages may be important to users. This can imply that users need to both install an R package and one or more dependencies that must be separately obtained and licensed. One such situation is where a new program is still under development and the license is not clear, as in the recent work we pursued with respect to Mike Powell's BOBYQA. We wanted to verify if this were useful before we considered distribution, and Powell had been offering copies of his code on request. Thus we could experiment, but not redistribute. Recently Powell's approval to redistribute has been obtained. We believe that it is important that non-redistributable codes be excluded from CRAN, but that they could be available on a repository such as r-forge. However, we would like to see a clearer indication of the license status on r-forge. One possibility is an inclusion of a statement and/or icon indicating such status e.g., green for GPL or equivalent, amber for uncertain, red for restricted. Another may be a division of directories, so that GPL-equivalent packages are kept separate from uncertain or restricted licensed ones. We welcome comments and suggestions on both the concept and the technicalities. John Nash & Ravi Varadhan __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Non-GPL packages for R
The SystemRequirements: field of the DESCRIPTION file normally lists external dependencies whether free or non-free. On Thu, Sep 10, 2009 at 1:50 PM, Prof. John C Nash wrote: > Subject: Non-GPL packages for R > > Packages that are not licensed in a way that permits re-distribution on > CRAN are frequently a source of comment and concern on R-help and other > lists. A good example of this problem is the Rdonlp2 package that has caused > a lot of annoyance for a number of optimization users in R. They are also an > issue for efforts like Dirk Eddelbuettel's cran2deb. > > There are, however, a number of circumstances where non-GPL equivalent > packages may be important to users. This can imply that users need to > both install an R package and one or more dependencies that must be > separately obtained and licensed. One such situation is where a new > program is still under development and the license is not clear, as in > the recent work we pursued with respect to Mike Powell's BOBYQA. We > wanted to verify if this were useful before we considered distribution, > and Powell had been offering copies of his code on request. Thus we > could experiment, but not redistribute. Recently Powell's approval to > redistribute has been obtained. > > We believe that it is important that non-redistributable codes be > excluded from CRAN, but that they could be available on a repository > such as r-forge. However, we would like to see a clearer indication of > the license status on r-forge. One possibility is an inclusion of a > statement and/or icon indicating such status e.g., green for GPL or > equivalent, amber for uncertain, red for restricted. Another may be a > division of directories, so that GPL-equivalent packages are kept > separate from uncertain or restricted licensed ones. > > We welcome comments and suggestions on both the concept and the > technicalities. > > John Nash & Ravi Varadhan > > __ > 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] Finding the environment of a promise
One of the (many) things on my TODO list is to add some sort of
reflection mechanism for examinging the status of bindings --
standard, active, delayed but evaluated, delayed but not yet
evaluated, etc. The interface might have a flavor like
bindingStatus(name, envir) returns one of "standard", "delayed",
"delayed-evaluated"
or something along these lines. It is important not to think in terms
of promises, which happen to exist as internal implementation devices
at the moment but might not in the future.
For cases like delayed but not yet evaluated it may make sense to also
provide access to things like the expression or code (which need not
be the same), or the environment. But there are some issues. For
example, once a delayed assignment is evaluated the environment is no
longer needed, and dropping it povides opportunities for memory
reclamation (the interpreter does this now by setting the environment
field of a promise to NULL once the promise is evaluated). We
wouldn't want a reflection mechanism to make tha impossible. Also, in
cases like a call f(1) there is no good reason for creating a delayed
evaluation, since the result of evaluating the argument is clear. The
interpreter doesn't do such an optimization at this time but it might
be useful in the future, and again we would not want a reflection
mechanism to get in the way of this.
So it's worth thinking about, especially if a compelling use case is
available, but there are subtleties and it would not be a good idea to
move too hastily.
Best,
luke
On Wed, 9 Sep 2009, Duncan Murdoch wrote:
On 9/9/2009 10:53 AM, Hadley Wickham wrote:
I don't think so in R code, but C code to do it would be possible. It
needs
to be in C code to avoid forcing the promise.
Thanks Duncan - I thought that might be the case.
I think we'd be reluctant to make an R function available to do this,
because it requires non-standard evaluation, and it's not something a
normal
function should care about.
True, but there are plenty of abnormal functions in R that demonstrate
the usefulness (and danger!) of non-standard evaluation.
(The promise belongs to the caller, not to the
function: why would the function need to play with it? It should be
happy
with the value, or maybe a text representation of the promise, for
labelling
purposes.)
Is there any way to get a text representation apart from with
deparse(substitute(x))? I think I remember asking you about this some
time ago, but it is still the case that blocks/promises don't store
srcref information? This come up recently while trying to make a
function that would both run a block or code and save it to a separate
file (a sort of poor man's sweave when you just want to include a
small portion of your code in a report). With blocks, the best I
could come up with was:
Promises don't store srcrefs, but the evaluator does (in R-devel), a
statement at a time. So you might be able to look back through the call
stack to find where the call came from. (I forget whether any of this is
accessible from within R. Look at the implementation of traceback() and
browser(), which both access this information.)
Duncan Murdoch
named_block <- function(name, code) {
text <- deparse(substitute(code), width = 100)
# evaluate code
force(code)
# construct valid filename
filename <- gsub("[^a-z0-9]+", "-", tolower(name))
filename <- gsub("^-|-$", "", filename)
filename <- paste(filename, ".r", sep = "")
out <- text[!grepl("\\{|\\}", text)]
out <- gsub("^", "", out)
writeLines(out, filename)
}
b <- 1
named_block("test", {
# This is a comment
a <- 1
})
print(a)
The problem of course is that this loses comments.
You can do better with functions, but it requires more typing and
messing around with environments to ensure everything is scoped
correctly:
named_block <- function(name, f) {
text <- attr(f, "source")
code <- text[!grepl("^function \\(\\)\\{$|\\}", text)]
code <- gsub("^ ", "", code)
# evaluate code
eval(parse(text = code), env = parent.frame())
# construct valid filename
filename <- gsub("[^a-z0-9]+", "-", tolower(name))
filename <- gsub("^-|-$", "", filename)
filename <- paste(filename, ".r", sep = "")
writeLines(code, filename)
}
b <- 1
named_block("test", function (){
# This is a comment
a <- 2
})
# Make sure objects created in correct environment
print(a)
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
--
Luke Tierney
Chair, Statistics and Actuarial Science
Ralph E. Wareham Professor of Mathematical Sciences
University of Iowa Phone: 319-335-3386
Department of Statistics andFax: 319-335-3017
Actuarial Science
241 Schaeffer Hall email: l...@stat.uiowa.edu
Iowa City, IA 52242 WWW: http://www.stat.uiowa.edu
___
[Rd] R_SHELL=/bin/bash causes issues (PR#13949)
Full_Name: Bob Bownes
Version: 2.9.2
OS: Solaris 10
Submission from: (NULL) (164.55.254.106)
Symptom: Setting R_SHELL=/bin/bash causes make to fail.
Reproduce with:
bash-3.00# export R_SHELL=/bin/csh;./configure --with-readline=no
--with-iconv=no --with-x=no --enable-static=yes
--prefix=/home/dev/scratch/bbownes/R
bash-3.00# make
Badly placed ()'s
*** Error code 1
The following command caused the error:
if test ! -f "./doc/FAQ" || test -f non-tarball ; then \
(cd doc/manual && make front-matter html-non-svn) ; \
touch non-tarball ; \
(cd .; LC_ALL=C TZ=GMT svn info || echo "Revision: unknown") 2> /dev/null \
| sed -n -e '/^Revision/p' -e '/^Last Changed Date/'p \
| cut -d' ' -f1,2,3,4 > SVN-REVISION-tmp ; \
/bin/csh ./tools/move-if-change SVN-REVISION-tmp SVN-REVISION ; \
rm -f SVN-REVISION-tmp ; \
else \
if test "yes" = no ; then \
for f in SVN-REVISION; do \
./tools/install-sh -c -m 644 ./${f} .; \
done \
fi \
fi
make: Fatal error: Command failed for target `svnonly'
bash-3.00#
Was the intention of R_SHELL to allow you to set a path to your own version of
csh?
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] importing/loading package without a namespace
I am developing a package that imports some functions from another package.
The imported package (qcc) does not have a namespace and this is causing
problems with loading of my package, which has a namespace. Is there a
workaround to allow loading the namespace-less package?
I searched the archives and found a suggestion that the package should be
included in the Depends list, but this has not helped.
https://stat.ethz.ch/pipermail/bioc-devel/2007-April/001079.html
Thank you.
The contents of my DESCRIPTION file are:
Package: nvQC
Type: Package
...
Depends: R(>= 2.5.0), Biobase, qcc
Imports: affy, RColorBrewer, affyio, nvNormalize
Suggests: nvCELFiles
LazyLoad: no
LazyData: yes
and those of the NAMESPACE file
export(nv.evalQC, gridQC, control.plots)
import(qcc, affy)
importFrom(RColorBrewer, brewer.pal)
importFrom(affyio, read.celfiles)
importFrom(nvNormalize, norm.options)
The output from R CMD check nvQC
* using log directory 'C:/Iatros01/Development/RPackages/nvQC/nvQC.Rcheck'
* using R version 2.9.1 (2009-06-26)
* using session charset: ISO8859-1
* checking for file 'nvQC/DESCRIPTION' ... OK
* checking extension type ... Package
* this is package 'nvQC' version '1.0.0'
* checking package name space information ... OK
* checking package dependencies ... OK
* checking if this is a source package ... OK
* checking for .dll and .exe files ... OK
* checking whether package 'nvQC' can be installed ... OK
* checking package directory ... OK
* checking for portable file names ... OK
* checking DESCRIPTION meta-information ... OK
* checking top-level files ... OK
* checking index information ... OK
* checking package subdirectories ... OK
* checking R files for non-ASCII characters ... OK
* checking R files for syntax errors ... OK
* checking whether the package can be loaded ... ERROR
Loading required package: Biobase
Welcome to Bioconductor
Vignettes contain introductory material. To view, type
'openVignette()'. To cite Bioconductor, see
'citation("Biobase")' and for packages 'citation(pkgname)'.
Loading required package: qcc
Error : package 'qcc' does not have a name space
Error: package/namespace load failed for 'nvQC'
Execution halted
It looks like this package has a loading problem: see the messages for
details.
Christos Hatzis, Ph.D.
Nuvera Biosciences, Inc.
400 West Cummings Park
Suite 5350
Woburn, MA 01801
Tel: 781-938-3830
www.nuverabio.com
Re: [Rd] importing/loading package without a namespace
Hi Christos --
Christos Hatzis wrote:
> I am developing a package that imports some functions from another package.
> The imported package (qcc) does not have a namespace and this is causing
> problems with loading of my package, which has a namespace. Is there a
> workaround to allow loading the namespace-less package?
>
> I searched the archives and found a suggestion that the package should be
> included in the Depends list, but this has not helped.
> https://stat.ethz.ch/pipermail/bioc-devel/2007-April/001079.html
>
> Thank you.
>
> The contents of my DESCRIPTION file are:
>
> Package: nvQC
> Type: Package
> ...
> Depends: R(>= 2.5.0), Biobase, qcc
> Imports: affy, RColorBrewer, affyio, nvNormalize
> Suggests: nvCELFiles
> LazyLoad: no
> LazyData: yes
>
> and those of the NAMESPACE file
>
> export(nv.evalQC, gridQC, control.plots)
> import(qcc, affy)
If I understand, qcc does not have a name space, so you cannot import()
it. The best you can do is, as you have done, Depend: qcc. In your code,
you can be unambiguous about the functions you use
qcc::someQccFunction()
> importFrom(RColorBrewer, brewer.pal)
> importFrom(affyio, read.celfiles)
> importFrom(nvNormalize, norm.options)
>
> The output from R CMD check nvQC
>
> * using log directory 'C:/Iatros01/Development/RPackages/nvQC/nvQC.Rcheck'
> * using R version 2.9.1 (2009-06-26)
> * using session charset: ISO8859-1
> * checking for file 'nvQC/DESCRIPTION' ... OK
> * checking extension type ... Package
> * this is package 'nvQC' version '1.0.0'
> * checking package name space information ... OK
> * checking package dependencies ... OK
> * checking if this is a source package ... OK
> * checking for .dll and .exe files ... OK
> * checking whether package 'nvQC' can be installed ... OK
> * checking package directory ... OK
> * checking for portable file names ... OK
> * checking DESCRIPTION meta-information ... OK
> * checking top-level files ... OK
> * checking index information ... OK
> * checking package subdirectories ... OK
> * checking R files for non-ASCII characters ... OK
> * checking R files for syntax errors ... OK
> * checking whether the package can be loaded ... ERROR
> Loading required package: Biobase
>
> Welcome to Bioconductor
>
> Vignettes contain introductory material. To view, type
> 'openVignette()'. To cite Bioconductor, see
> 'citation("Biobase")' and for packages 'citation(pkgname)'.
>
> Loading required package: qcc
> Error : package 'qcc' does not have a name space
> Error: package/namespace load failed for 'nvQC'
> Execution halted
>
> It looks like this package has a loading problem: see the messages for
> details.
>
> Christos Hatzis, Ph.D.
> Nuvera Biosciences, Inc.
> 400 West Cummings Park
> Suite 5350
> Woburn, MA 01801
> Tel: 781-938-3830
> www.nuverabio.com
Re: [Rd] importing/loading package without a namespace
Thank you Martin.
This has worked. It was perhaps the suggestion to explicitly call the qcc
functions in my code via qcc::
Thanks.
-Christos
> -Original Message-
> From: r-devel-boun...@r-project.org
> [mailto:r-devel-boun...@r-project.org] On Behalf Of Martin Morgan
> Sent: Thursday, September 10, 2009 5:12 PM
> To: chris...@nuverabio.com
> Cc: r-devel@r-project.org
> Subject: Re: [Rd] importing/loading package without a namespace
>
> Hi Christos --
>
> Christos Hatzis wrote:
> > I am developing a package that imports some functions from
> another package.
> > The imported package (qcc) does not have a namespace and this is
> > causing problems with loading of my package, which has a
> namespace.
> > Is there a workaround to allow loading the namespace-less package?
> >
> > I searched the archives and found a suggestion that the
> package should
> > be included in the Depends list, but this has not helped.
> > https://stat.ethz.ch/pipermail/bioc-devel/2007-April/001079.html
> >
> > Thank you.
> >
> > The contents of my DESCRIPTION file are:
> >
> > Package: nvQC
> > Type: Package
> > ...
> > Depends: R(>= 2.5.0), Biobase, qcc
> > Imports: affy, RColorBrewer, affyio, nvNormalize
> > Suggests: nvCELFiles
> > LazyLoad: no
> > LazyData: yes
> >
> > and those of the NAMESPACE file
> >
> > export(nv.evalQC, gridQC, control.plots) import(qcc, affy)
>
> If I understand, qcc does not have a name space, so you
> cannot import() it. The best you can do is, as you have done,
> Depend: qcc. In your code, you can be unambiguous about the
> functions you use
>
> qcc::someQccFunction()
>
> > importFrom(RColorBrewer, brewer.pal)
> > importFrom(affyio, read.celfiles)
> > importFrom(nvNormalize, norm.options)
> >
> > The output from R CMD check nvQC
> >
> > * using log directory
> 'C:/Iatros01/Development/RPackages/nvQC/nvQC.Rcheck'
> > * using R version 2.9.1 (2009-06-26)
> > * using session charset: ISO8859-1
> > * checking for file 'nvQC/DESCRIPTION' ... OK
> > * checking extension type ... Package
> > * this is package 'nvQC' version '1.0.0'
> > * checking package name space information ... OK
> > * checking package dependencies ... OK
> > * checking if this is a source package ... OK
> > * checking for .dll and .exe files ... OK
> > * checking whether package 'nvQC' can be installed ... OK
> > * checking package directory ... OK
> > * checking for portable file names ... OK
> > * checking DESCRIPTION meta-information ... OK
> > * checking top-level files ... OK
> > * checking index information ... OK
> > * checking package subdirectories ... OK
> > * checking R files for non-ASCII characters ... OK
> > * checking R files for syntax errors ... OK
> > * checking whether the package can be loaded ... ERROR Loading
> > required package: Biobase
> >
> > Welcome to Bioconductor
> >
> > Vignettes contain introductory material. To view, type
> > 'openVignette()'. To cite Bioconductor, see
> > 'citation("Biobase")' and for packages 'citation(pkgname)'.
> >
> > Loading required package: qcc
> > Error : package 'qcc' does not have a name space
> > Error: package/namespace load failed for 'nvQC'
> > Execution halted
> >
> > It looks like this package has a loading problem: see the
> messages for
> > details.
> >
> > Christos Hatzis, Ph.D.
> > Nuvera Biosciences, Inc.
> > 400 West Cummings Park
> > Suite 5350
> > Woburn, MA 01801
> > Tel: 781-938-3830
> > www.nuverabio.com
Re: [Rd] Non-GPL packages for R
On 10 September 2009 at 14:26, Gabor Grothendieck wrote: | The SystemRequirements: field of the DESCRIPTION file normally | lists external dependencies whether free or non-free. Moreover, the (aptly named) field 'License:' in DESCRIPTION is now much more parseable and contains pertinent information. A number of more 'challenging' packages basically pass the buck on with an entry License: file LICENSE which refers to a file in the sources one needs to read to decide. This is e.g. at the basis of Charles' and my decision about what we think we cannot build via cran2deb [1]: non-free, non-distributable, non-commercial or otherwise nasty licenses. There are a couple of packages we exclude for this (or related reasons), and we have been meaning to summarise them with a simple html summary from the database table we use for cran2deb, but have not yet gotten around to it. Just like John and Ravi, I would actually be in favour of somewhat stricter enforcements. If someone decides not to take part in the gift economy that brought him or her R (and many other things, including at least 1880+ CRAN packages with sane licenses) then we may as well decide not to waste our time and resources on his project either and simply exclude it. So consider this as a qualified thumbs-up for John and Ravi's suggestion of a clearer line in the sand. Dirk [1] cran2deb is at http://debian.cran.r-project.org and provides 1800+ Debian 'testing' binaries for amd64 and i386 that are continuously updated as new packages appear on CRAN. With that 'apt-get install r-cran-foo' becomes a reality for almost every value of foo out of the set of CRAN packages. | | On Thu, Sep 10, 2009 at 1:50 PM, Prof. John C Nash wrote: | > Subject: Non-GPL packages for R | > | > Packages that are not licensed in a way that permits re-distribution on | > CRAN are frequently a source of comment and concern on R-help and other | > lists. A good example of this problem is the Rdonlp2 package that has caused | > a lot of annoyance for a number of optimization users in R. They are also an | > issue for efforts like Dirk Eddelbuettel's cran2deb. | > | > There are, however, a number of circumstances where non-GPL equivalent | > packages may be important to users. This can imply that users need to | > both install an R package and one or more dependencies that must be | > separately obtained and licensed. One such situation is where a new | > program is still under development and the license is not clear, as in | > the recent work we pursued with respect to Mike Powell's BOBYQA. We | > wanted to verify if this were useful before we considered distribution, | > and Powell had been offering copies of his code on request. Thus we | > could experiment, but not redistribute. Recently Powell's approval to | > redistribute has been obtained. | > | > We believe that it is important that non-redistributable codes be | > excluded from CRAN, but that they could be available on a repository | > such as r-forge. However, we would like to see a clearer indication of | > the license status on r-forge. One possibility is an inclusion of a | > statement and/or icon indicating such status e.g., green for GPL or | > equivalent, amber for uncertain, red for restricted. Another may be a | > division of directories, so that GPL-equivalent packages are kept | > separate from uncertain or restricted licensed ones. | > | > We welcome comments and suggestions on both the concept and the | > technicalities. | > | > John Nash & Ravi Varadhan | > | > __ | > 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 -- Three out of two people have difficulties with fractions. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Non-GPL packages for R
I will offer my opinion as a user and contributer to R packages via R-Forge and CRAN: 1. How difficult would it be to split CRAN into two parts, depending on whether the package carried an acceptable license allowing free distribution? The second might carry a name like RANC (R Archive Network - Commercial), and the first would retain the CRAN name. 2. R-Forge allows public access to the source code, at least for some packages. Moreover, users applying for R-Forge support must specify the license they plan to use. Support may be denied for a project that does not use one of the standard public distribution licenses like GPL. Spencer Dirk Eddelbuettel wrote: On 10 September 2009 at 14:26, Gabor Grothendieck wrote: | The SystemRequirements: field of the DESCRIPTION file normally | lists external dependencies whether free or non-free. Moreover, the (aptly named) field 'License:' in DESCRIPTION is now much more parseable and contains pertinent information. A number of more 'challenging' packages basically pass the buck on with an entry License: file LICENSE which refers to a file in the sources one needs to read to decide. This is e.g. at the basis of Charles' and my decision about what we think we cannot build via cran2deb [1]: non-free, non-distributable, non-commercial or otherwise nasty licenses. There are a couple of packages we exclude for this (or related reasons), and we have been meaning to summarise them with a simple html summary from the database table we use for cran2deb, but have not yet gotten around to it. Just like John and Ravi, I would actually be in favour of somewhat stricter enforcements. If someone decides not to take part in the gift economy that brought him or her R (and many other things, including at least 1880+ CRAN packages with sane licenses) then we may as well decide not to waste our time and resources on his project either and simply exclude it. So consider this as a qualified thumbs-up for John and Ravi's suggestion of a clearer line in the sand. Dirk [1] cran2deb is at http://debian.cran.r-project.org and provides 1800+ Debian 'testing' binaries for amd64 and i386 that are continuously updated as new packages appear on CRAN. With that 'apt-get install r-cran-foo' becomes a reality for almost every value of foo out of the set of CRAN packages. | | On Thu, Sep 10, 2009 at 1:50 PM, Prof. John C Nash wrote: | > Subject: Non-GPL packages for R | > | > Packages that are not licensed in a way that permits re-distribution on | > CRAN are frequently a source of comment and concern on R-help and other | > lists. A good example of this problem is the Rdonlp2 package that has caused | > a lot of annoyance for a number of optimization users in R. They are also an | > issue for efforts like Dirk Eddelbuettel's cran2deb. | > | > There are, however, a number of circumstances where non-GPL equivalent | > packages may be important to users. This can imply that users need to | > both install an R package and one or more dependencies that must be | > separately obtained and licensed. One such situation is where a new | > program is still under development and the license is not clear, as in | > the recent work we pursued with respect to Mike Powell's BOBYQA. We | > wanted to verify if this were useful before we considered distribution, | > and Powell had been offering copies of his code on request. Thus we | > could experiment, but not redistribute. Recently Powell's approval to | > redistribute has been obtained. | > | > We believe that it is important that non-redistributable codes be | > excluded from CRAN, but that they could be available on a repository | > such as r-forge. However, we would like to see a clearer indication of | > the license status on r-forge. One possibility is an inclusion of a | > statement and/or icon indicating such status e.g., green for GPL or | > equivalent, amber for uncertain, red for restricted. Another may be a | > division of directories, so that GPL-equivalent packages are kept | > separate from uncertain or restricted licensed ones. | > | > We welcome comments and suggestions on both the concept and the | > technicalities. | > | > John Nash & Ravi Varadhan | > | > __ | > 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 -- Spencer Graves, PE, PhD President and Chief Operating Officer Structure Inspection and Monitoring, Inc. 751 Emerson Ct. San José, CA 95126 ph: 408-655-4567 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] (no subject)
Hi, I would also be in favor of a stronger stance on licenses. In industry, where we can really get in big trouble for violating a license, we often maintain internal repositories, or need to be careful about filtering what is used from CRAN. I think that is should really be a requirement the package authors commit to stating what the restrictions are on their packages. Nicholas On 10 September 2009 at 14:26, Gabor Grothendieck wrote: | The SystemRequirements: field of the DESCRIPTION file normally | lists external dependencies whether free or non-free. Moreover, the (aptly named) field 'License:' in DESCRIPTION is now much more parseable and contains pertinent information. A number of more 'challenging' packages basically pass the buck on with an entry License: file LICENSE which refers to a file in the sources one needs to read to decide. This is e.g. at the basis of Charles' and my decision about what we think we cannot build via cran2deb [1]: non-free, non-distributable, non-commercial or otherwise nasty licenses. There are a couple of packages we exclude for this (or related reasons), and we have been meaning to summarise them with a simple html summary from the database table we use for cran2deb, but have not yet gotten around to it. Just like John and Ravi, I would actually be in favour of somewhat stricter enforcements. If someone decides not to take part in the gift economy that brought him or her R (and many other things, including at least 1880+ CRAN packages with sane licenses) then we may as well decide not to waste our time and resources on his project either and simply exclude it. So consider this as a qualified thumbs-up for John and Ravi's suggestion of a clearer line in the sand. Dirk [1] cran2deb is at http://debian.cran.r-project.org and provides 1800+ Debian 'testing' binaries for amd64 and i386 that are continuously updated as new packages appear on CRAN. With that 'apt-get install r-cran-foo' becomes a reality for almost every value of foo out of the set of CRAN packages. | | On Thu, Sep 10, 2009 at 1:50 PM, Prof. John C Nash wrote: | > Subject: Non-GPL packages for R | > | > Packages that are not licensed in a way that permits re-distribution on | > CRAN are frequently a source of comment and concern on R-help and other | > lists. A good example of this problem is the Rdonlp2 package that has caused | > a lot of annoyance for a number of optimization users in R. They are also an | > issue for efforts like Dirk Eddelbuettel's cran2deb. | > | > There are, however, a number of circumstances where non-GPL equivalent | > packages may be important to users. This can imply that users need to | > both install an R package and one or more dependencies that must be | > separately obtained and licensed. One such situation is where a new | > program is still under development and the license is not clear, as in | > the recent work we pursued with respect to Mike Powell's BOBYQA. We | > wanted to verify if this were useful before we considered distribution, | > and Powell had been offering copies of his code on request. Thus we | > could experiment, but not redistribute. Recently Powell's approval to | > redistribute has been obtained. | > | > We believe that it is important that non-redistributable codes be | > excluded from CRAN, but that they could be available on a repository | > such as r-forge. However, we would like to see a clearer indication of | > the license status on r-forge. One possibility is an inclusion of a | > statement and/or icon indicating such status e.g., green for GPL or | > equivalent, amber for uncertain, red for restricted. Another may be a | > division of directories, so that GPL-equivalent packages are kept | > separate from uncertain or restricted licensed ones. | > | > We welcome comments and suggestions on both the concept and the | > technicalities. | > | > John Nash & Ravi Varadhan | > | > __ | > R-devel at r-project.org mailing list | > https://stat.ethz.ch/mailman/listinfo/r-devel | > | | __ | R-devel at 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] Non-GPL packages for R
With header this time On Thu, 10 Sep 2009 16:08 -0700, "Nicholas Lewin-Koh" wrote: > Hi, > I would also be in favor of a stronger stance on licenses. In > industry, where we can really get in big trouble for violating a > license, > we often maintain internal repositories, or need to be careful about > filtering > what is used from CRAN. I think that is should really be a requirement > the package > authors commit to stating what the restrictions are on their packages. > > Nicholas > > > On 10 September 2009 at 14:26, Gabor Grothendieck wrote: > | The SystemRequirements: field of the DESCRIPTION file normally > | lists external dependencies whether free or non-free. > > Moreover, the (aptly named) field 'License:' in DESCRIPTION is now much > more > parseable and contains pertinent information. A number of more > 'challenging' > packages basically pass the buck on with an entry > > License: file LICENSE > > which refers to a file in the sources one needs to read to decide. > > This is e.g. at the basis of Charles' and my decision about what we > think we > cannot build via cran2deb [1]: non-free, non-distributable, > non-commercial or > otherwise nasty licenses. There are a couple of packages we exclude for > this > (or related reasons), and we have been meaning to summarise them with a > simple html summary from the database table we use for cran2deb, but > have not > yet gotten around to it. > > Just like John and Ravi, I would actually be in favour of somewhat > stricter > enforcements. If someone decides not to take part in the gift economy > that > brought him or her R (and many other things, including at least 1880+ > CRAN > packages with sane licenses) then we may as well decide not to waste our > time > and resources on his project either and simply exclude it. > > So consider this as a qualified thumbs-up for John and Ravi's suggestion > of a > clearer line in the sand. > > Dirk > > [1] cran2deb is at http://debian.cran.r-project.org and provides 1800+ > Debian > 'testing' binaries for amd64 and i386 that are continuously updated as > new > packages appear on CRAN. With that 'apt-get install r-cran-foo' becomes > a > reality for almost every value of foo out of the set of CRAN packages. > > > | > | On Thu, Sep 10, 2009 at 1:50 PM, Prof. John C Nash uottawa.ca> wrote: > | > Subject: Non-GPL packages for R > | > > | > Packages that are not licensed in a way that permits re-distribution > on > | > CRAN are frequently a source of comment and concern on R-help and > other > | > lists. A good example of this problem is the Rdonlp2 package that > has caused > | > a lot of annoyance for a number of optimization users in R. They are > also an > | > issue for efforts like Dirk Eddelbuettel's cran2deb. > | > > | > There are, however, a number of circumstances where non-GPL > equivalent > | > packages may be important to users. This can imply that users need > to > | > both install an R package and one or more dependencies that must be > | > separately obtained and licensed. One such situation is where a new > | > program is still under development and the license is not clear, as > in > | > the recent work we pursued with respect to Mike Powell's BOBYQA. We > | > wanted to verify if this were useful before we considered > distribution, > | > and Powell had been offering copies of his code on request. Thus we > | > could experiment, but not redistribute. Recently Powell's approval > to > | > redistribute has been obtained. > | > > | > We believe that it is important that non-redistributable codes be > | > excluded from CRAN, but that they could be available on a repository > | > such as r-forge. However, we would like to see a clearer indication > of > | > the license status on r-forge. One possibility is an inclusion of a > | > statement and/or icon indicating such status e.g., green for GPL or > | > equivalent, amber for uncertain, red for restricted. Another may be > a > | > division of directories, so that GPL-equivalent packages are kept > | > separate from uncertain or restricted licensed ones. > | > > | > We welcome comments and suggestions on both the concept and the > | > technicalities. > | > > | > John Nash & Ravi Varadhan > | > > | > __ > | > R-devel at r-project.org mailing list > | > https://stat.ethz.ch/mailman/listinfo/r-devel > | > > | > | __ > | R-devel at 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] Non-GPL packages for R
On 10/09/2009 6:57 PM, spencerg wrote: I will offer my opinion as a user and contributer to R packages via R-Forge and CRAN: 1. How difficult would it be to split CRAN into two parts, depending on whether the package carried an acceptable license allowing free distribution? The second might carry a name like RANC (R Archive Network - Commercial), and the first would retain the CRAN name. To this I would say, try it. Don't ask volunteers to do some work that suits you; do it yourself. Duncan Murdoch 2. R-Forge allows public access to the source code, at least for some packages. Moreover, users applying for R-Forge support must specify the license they plan to use. Support may be denied for a project that does not use one of the standard public distribution licenses like GPL. Spencer Dirk Eddelbuettel wrote: On 10 September 2009 at 14:26, Gabor Grothendieck wrote: | The SystemRequirements: field of the DESCRIPTION file normally | lists external dependencies whether free or non-free. Moreover, the (aptly named) field 'License:' in DESCRIPTION is now much more parseable and contains pertinent information. A number of more 'challenging' packages basically pass the buck on with an entry License: file LICENSE which refers to a file in the sources one needs to read to decide. This is e.g. at the basis of Charles' and my decision about what we think we cannot build via cran2deb [1]: non-free, non-distributable, non-commercial or otherwise nasty licenses. There are a couple of packages we exclude for this (or related reasons), and we have been meaning to summarise them with a simple html summary from the database table we use for cran2deb, but have not yet gotten around to it. Just like John and Ravi, I would actually be in favour of somewhat stricter enforcements. If someone decides not to take part in the gift economy that brought him or her R (and many other things, including at least 1880+ CRAN packages with sane licenses) then we may as well decide not to waste our time and resources on his project either and simply exclude it. So consider this as a qualified thumbs-up for John and Ravi's suggestion of a clearer line in the sand. Dirk [1] cran2deb is at http://debian.cran.r-project.org and provides 1800+ Debian 'testing' binaries for amd64 and i386 that are continuously updated as new packages appear on CRAN. With that 'apt-get install r-cran-foo' becomes a reality for almost every value of foo out of the set of CRAN packages. | | On Thu, Sep 10, 2009 at 1:50 PM, Prof. John C Nash wrote: | > Subject: Non-GPL packages for R | > | > Packages that are not licensed in a way that permits re-distribution on | > CRAN are frequently a source of comment and concern on R-help and other | > lists. A good example of this problem is the Rdonlp2 package that has caused | > a lot of annoyance for a number of optimization users in R. They are also an | > issue for efforts like Dirk Eddelbuettel's cran2deb. | > | > There are, however, a number of circumstances where non-GPL equivalent | > packages may be important to users. This can imply that users need to | > both install an R package and one or more dependencies that must be | > separately obtained and licensed. One such situation is where a new | > program is still under development and the license is not clear, as in | > the recent work we pursued with respect to Mike Powell's BOBYQA. We | > wanted to verify if this were useful before we considered distribution, | > and Powell had been offering copies of his code on request. Thus we | > could experiment, but not redistribute. Recently Powell's approval to | > redistribute has been obtained. | > | > We believe that it is important that non-redistributable codes be | > excluded from CRAN, but that they could be available on a repository | > such as r-forge. However, we would like to see a clearer indication of | > the license status on r-forge. One possibility is an inclusion of a | > statement and/or icon indicating such status e.g., green for GPL or | > equivalent, amber for uncertain, red for restricted. Another may be a | > division of directories, so that GPL-equivalent packages are kept | > separate from uncertain or restricted licensed ones. | > | > We welcome comments and suggestions on both the concept and the | > technicalities. | > | > John Nash & Ravi Varadhan | > | > __ | > 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
[Rd] Needless updating of HTML package descriptions
I recently installed a local package which failed because the package was already loaded; however, then it tried to update all the HTML package descriptions needlessly (since they had not changed due to the failure to install). Since updating the HTML package descriptions can be time consuming the processing should skip the update in this case. > utils:::menuInstallLocal() Warning: package 'myPackage' is in use and will not be installed updating HTML package descriptions __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
