[Rd] [wishlist, patch] make row() and col() preserve dimnames (PR#13705)
Full_Name: Ben Goodrich Version: 2.9.0 OS: Linux (Debian unstable) Submission from: (NULL) (128.103.220.16) row(x), col(x), and functions that call them like lower.tri(x) and upper.tri(x) do not retain the rownames or colnames of x in the matrix that is returned. Example from R version 2.9.0 : x <- matrix(1:9, nrow = 3, ncol = 3) rownames(x) <- LETTERS[1:3] colnames(x) <- letters[1:3] dimnames(row(x)) # NULL dimnames(col(x)) # NULL Is there anyone for whom the expected behavior is to drop the dimnames of x ? It is not consistent with other functions of matrices. By default, row(x) already returns the row numbers of x (and similarly for col()), so how would seeing integers in the rownames be helpful? Without patch: > row(x) [,1] [,2] [,3] [1,]111 [2,]222 [3,]333 With patch: > row(x) a b c A 1 1 1 B 2 2 2 C 3 3 3 Patch: Index: src/library/base/R/matrix.R === --- src/library/base/R/matrix.R (revision 48553) +++ src/library/base/R/matrix.R (working copy) @@ -104,8 +104,9 @@ labs <- rownames(x, do.NULL=FALSE, prefix="") res <- factor(.Internal(row(dim(x))), labels=labs) dim(res) <- dim(x) -res -} else .Internal(row(dim(x))) +} else res <- .Internal(row(dim(x))) +dimnames(res) <- dimnames(x) +res } col <- function(x, as.factor=FALSE) @@ -114,8 +115,9 @@ labs <- colnames(x, do.NULL=FALSE, prefix="") res <- factor(.Internal(col(dim(x))), labels=labs) dim(res) <- dim(x) -res -} else .Internal(col(dim(x))) +} else res <- .Internal(col(dim(x))) +dimnames(res) <- dimnames(x) +res } crossprod <- function(x, y=NULL) .Internal(crossprod(x,y)) __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] (PR#10500) Bug#454678: followup
[I was overlooked on the CC. Hopefully this message does not create a new bug report.] > Prof Brian Ripley wrote: > I would say this was user error (insisting on editing non-existent > rownames), although the argument is documented. You could argue that > there are implicit rownames, but they would be 1, 2 ... not row1, row2 > And rownames(mat) is NULL. > > For an interactive function the best solution seems to be to throw an > error when the user asks for the impossible. > > I'll fix it for 2.7.0: it certainly isn't 'important' as it has gone > undiscovered for many years, and edit.matrix is itself little used. > > > BTW, 1:dim(names)[1] is dangerous: it could be 1:0. That was the > motivation for seq_len. I would agree that it is a rare user error, but my original mistake was a little more benign than the one that is depicted in the bug report. I just forgot to call rownames()<- before calling edit(); that could have happened to anyone. Perhaps one reason why this issue has not been reported before is that in 2.5.1 at least, it produces an error message rather than crashing (which I noted in the original bug report to Debian but that was a little hard to see by the time it got forwarded to R-bugs). In some ways, I think throwing an error in 2.7.0 would be better than the behavior of edit.data.frame() in this case, which is to add row names of 1, 2, ... . -- Thanks, Ben __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] [wishlist, patch] Removing .bzr/ directory when calling R CMD build (PR#10625)
Full_Name: Ben Goodrich Version: 2.6.1 OS: Debian Submission from: (NULL) (128.103.222.166) bzr is another version control system and adds a .bzr folder to the top-level directory of a package, similar to .svn and .git for subversion and git respectively. However, while R CMD build removes directories called .svn, .git, and some others, it does not remove .bzr . As a result, the .bzr folder is unnecessarily included in the cleanly built package and there are accurate but unnecessary warnings that say certain subdirectories of the .bzr directory are empty. I believe the following patch, which is lightly tested with R-devel, is sufficient to remove the .bzr folder and prevent these warnings. It does not, however, remove the .bzrignore file (if it exists) but perhaps it should be augmented to do so. --- src/scripts/build.in2008-01-23 11:42:47.0 -0500 +++ build.in2008-01-23 11:45:02.0 -0500 @@ -215,6 +215,7 @@ print EXCLUDE "$File::Find::name\n" if(-d $_ && /^\.svn$/); print EXCLUDE "$File::Find::name\n" if(-d $_ && /^\.arch-ids$/); print EXCLUDE "$File::Find::name\n" if(-d $_ && /^\.git$/); + print EXCLUDE "$File::Find::name\n" if(-d $_ && /^\.bzr$/); ## Windows DLL resource file push(@exclude_patterns, "^src/" . $pkgname . "_res\\.rc"); my $filename = $File::Find::name; __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] [wishlist, patch] Removing .bzr/ directory when calling (PR#10628)
Gabor Grothendieck wrote: > If you place an .Rbuildignore file in the top level of > your package with this line single line as its contents: > > [.]bzr$ > > then the .bzr file will not be included. Thank you for the suggestion. In order to remove both the .bzr/ directory and the .bzrignore file, it seems to be necessary to specify [.]bzr$ [.]bzrignore in the .Rbuildignore file before calling R CMD build. This is certainly sufficient in my case, but since the patch is just one line, perhaps it should be considered for inclusion as well. Ben __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Bug in rt() ? (PR#9422)
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
<>
Reproduced on Debian and Windows ...
On 2.4.x if you execute
set.seed(12345)
t.1 <- rt(n = 1000, df = 20)
set.seed(12345)
t.2 <- rt(n = 1000, df = 20, ncp = 0)
all.equal(t.1, t.2) ## Not close to true
This appears to be due to the fact that in 2.4.x rt is now
rt
function (n, df, ncp = 0)
{
if (missing(ncp))
.Internal(rt(n, df))
else rnorm(n, ncp)/sqrt(rchisq(n, df)/df)
}
Whereas in 2.3.1 rt() is verified to work as expected when someone
(redundantly) types ncp = 0
rt
function (n, df, ncp = 0)
{
if (ncp == 0)
.Internal(rt(n, df))
else rnorm(n, ncp)/(rchisq(n, df)/sqrt(df))
}
The only interface difference is missing(ncp) vs. ncp == 0 .
- --please do not edit the information below--
Version:
platform = i486-pc-linux-gnu
arch = i486
os = linux-gnu
system = i486, linux-gnu
status =
major = 2
minor = 4.1
year = 2006
month = 12
day = 18
svn rev = 40228
language = R
version.string = R version 2.4.1 (2006-12-18)
Locale:
LC_CTYPE=en_US.UTF-8;LC_NUMERIC=C;LC_TIME=en_US.UTF-8;LC_COLLATE=en_US.UTF-8;LC_MONETARY=en_US.UTF-8;LC_MESSAGES=en_US.UTF-8;LC_PAPER=en_US.UTF-8;LC_NAME=en_US.UTF-8;LC_ADDRESS=en_US.UTF-8;LC_TELEPHONE=en_US.UTF-8;LC_MEASUREMENT=en_US.UTF-8;LC_IDENTIFICATION=en_US.UTF-8
Search Path:
.GlobalEnv, package:car, package:rkward, package:stats,
package:graphics, package:grDevices, package:utils, package:datasets,
package:methods, Autoloads, package:base
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFFiF09zQDSXIcN85kRAhK4AKCBmPNkGszTzFdALfiGgW1LfNIOTwCfZ8RM
0gZjer8+rnmOPDFKZXBbFQw=
=ff85
-END PGP SIGNATURE-
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Bug in rt() ? (PR#9422)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Prof Brian Ripley wrote: > Why do you consider this might be a bug in R rather than in your > expectations? Your 'expected' is not what others have expected Thank you for this response. I did consider at the time that this unexpected result could be deliberate, but help(rt) on 2.4.1 seemed to confirm my expectations. Martin Maechler noted on the first response to this bug report that help(rt) was not updated to describe the new functionality of rt(). > In 2.4.1 rt(ncp) operates continuously as ncp is varied through 0. > That is different from saying that you want a central t (omitting ncp). I was not expecting random draws from a central t distribution to be the same as random draws from a limiting case of a non-central t distribution. I was expecting that redundantly typing the default arguments of a function would produce the same result as omitting the default arguments. Are there other functions with this discrepancy? In other words, I do not understand why rt() continues to default to ncp = 0, as opposed to no default argument for ncp. It would seem that args(rt) currently implies that the draws are to be taken from a limiting case of non-central t distribution, when this is not accurate if the ncp argument is omitted. Thanks, Ben -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFid58zQDSXIcN85kRAhRVAJ0WNf2fMVcPZk4rfxw8qXO272Bs8ACfdVAt a5OaqyObzqkjL8a5sCooj6w= =/fPt -END PGP SIGNATURE- __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] serialization regression in 2.15.0 beta
Hi,
I am experiencing a problem related to serialization behavior in
2.15.0 beta (binary installed from Debian unstable) and 2.16.0 (from
svn) that is not present in 2.14.2 (binary from Debian testing).
I don't fully understand the problem. Also, I tried but have not yet
been able to create a small, self-contained example that reproduces
the problem. However, I do have a large, not self-contained example,
which requires an alpha version (not yet on CRAN) of the mi package
(the mi package on CRAN would not exhibit this issue). Anyone
interested in reproducing the problem can follow the readme.txt file
in this directory:
http://www.columbia.edu/~bg2382/mi/serialization/
I track r-devel with git-svn and was able to git bisect to svn commit r58219
commit 799102bd9d0266fe89c3120981decf0b1f17ef11
Author: ripley
Date: Sat Jan 28 15:02:34 2012 +
make use of non-xdr serialization;.
although this commit could merely expose the problem rather than cause it.
The problem occurs when the FUN called by mclapply() in the parallel
package returns a S4 object that contains a slot (called X) that is a
large matrix, specifically a "model matrix" similar to that produced
by glm(). Some columns of this matrix get corrupted with wrong values
(usually zero, but sometimes NaN or 10^300ish), which can be seen by
examining X right before FUN returns (to mclapply()'s environment) and
comparing to the "same" X after mclapply() returns to the calling
environment.
Part of svn commit r58219 is this hunk
diff --git a/src/library/parallel/R/unix/mcfork.R
b/src/library/parallel/R/unix/mcfork.R
index 8e27534..4f92193 100644
--- a/src/library/parallel/R/unix/mcfork.R
+++ b/src/library/parallel/R/unix/mcfork.R
@@ -82,7 +82,8 @@ mckill <- function(process, signal = 2L)
## used by mcparallel, mclapply
sendMaster <- function(what)
{
-if (!is.raw(what)) what <- serialize(what, NULL, FALSE)
+# This is talking to the same machine, so no point in using xdr.
+if (!is.raw(what)) what <- serialize(what, NULL, xdr = FALSE)
.Call(C_mc_send_master, what, PACKAGE = "parallel")
}
Contrary to the comment, I have found that if I specify xdr = TRUE, I
get the expected (non-corrupted X slot) behavior in 2.16.0, even
though it is forking locally on my 64bit Debian laptop with a little
endian i7 processor, whose specs are
goodrich@CYBERPOWERPC:/tmp/serialization$ cat /proc/cpuinfo
processor : 0
vendor_id : GenuineIntel
cpu family : 6
model : 42
model name : Intel(R) Core(TM) i7-2630QM CPU @ 2.00GHz
stepping: 7
microcode : 0x17
cpu MHz : 800.000
cache size : 6144 KB
physical id : 0
siblings: 8
core id : 0
cpu cores : 4
apicid : 0
initial apicid : 0
fpu : yes
fpu_exception : yes
cpuid level : 13
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge
mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe
syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl
xtopology nonstop_tsc aperfmperf pni pclmulqdq dtes64 monitor ds_cpl
vmx est tm2 ssse3 cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic popcnt
tsc_deadline_timer xsave avx lahf_lm ida arat epb xsaveopt pln pts dts
tpr_shadow vnmi flexpriority ept vpid
bogomips: 3990.83
clflush size: 64
cache_alignment : 64
address sizes : 36 bits physical, 48 bits virtual
power management:
...
processor : 7
[same as processor 0]
So, to summarize I get the good behavior on R 2.14.2 when using
mclapply(), on 2.15.0 beta when using lapply(), and on 2.16.0 using
mclapply() iff I patch in xdr = TRUE in sendMaster(). I get the bad
behavior on 2.15.0 beta and unpatched 2.16.0 when using mclapply().
My session info:
sessionInfo()
R version 2.15.0 beta (2012-03-16 r58769)
Platform: x86_64-pc-linux-gnu (64-bit)
locale:
[1] LC_CTYPE=en_US.UTF-8 LC_NUMERIC=C
[3] LC_TIME=en_US.UTF-8LC_COLLATE=en_US.UTF-8
[5] LC_MONETARY=en_US.UTF-8LC_MESSAGES=en_US.UTF-8
[7] LC_PAPER=C LC_NAME=C
[9] LC_ADDRESS=C LC_TELEPHONE=C
[11] LC_MEASUREMENT=en_US.UTF-8 LC_IDENTIFICATION=C
attached base packages:
[1] stats4stats graphics grDevices utils datasets methods
[8] base
other attached packages:
[1] mi_0.9-83bigmemory_4.2.11 arm_1.5-03 foreign_0.8-49
[5] abind_1.4-0 R2WinBUGS_2.1-18 coda_0.14-5 lme4_0.999375-42
[9] Matrix_1.0-4 lattice_0.20-0 MASS_7.3-17
loaded via a namespace (and not attached):
[1] grid_2.15.0 nlme_3.1-103
Thanks,
Ben
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] serialization regression in 2.15.0 beta
In case anyone is concerned that this regression will affect them, the
code was reverted to the 2.14.x behavior by
r58842 | ripley | 2012-03-26 08:12:43 -0400 (Mon, 26 Mar 2012) | 1 line
Changed paths:
M /branches/R-2-15-branch/doc/NEWS.Rd
M /branches/R-2-15-branch/src/library/parallel/R/unix/forkCluster.R
M /branches/R-2-15-branch/src/library/parallel/R/unix/mcfork.R
revert to XDR serialization for 2.15.0
Thanks,
Ben
> I am experiencing a problem related to serialization behavior in
> 2.15.0 beta (binary installed from Debian unstable) and 2.16.0 (from
> svn) that is not present in 2.14.2 (binary from Debian testing).
>
> I don't fully understand the problem. Also, I tried but have not yet
> been able to create a small, self-contained example that reproduces
> the problem. However, I do have a large, not self-contained example,
> which requires an alpha version (not yet on CRAN) of the mi package
> (the mi package on CRAN would not exhibit this issue). Anyone
> interested in reproducing the problem can follow the readme.txt file
> in this directory:
>
> http://www.columbia.edu/~bg2382/mi/serialization/
>
> I track r-devel with git-svn and was able to git bisect to svn commit r58219
>
> commit 799102bd9d0266fe89c3120981decf0b1f17ef11
> Author: ripley
> Date: Sat Jan 28 15:02:34 2012 +
>
> make use of non-xdr serialization;.
>
> although this commit could merely expose the problem rather than cause it.
>
> The problem occurs when the FUN called by mclapply() in the parallel
> package returns a S4 object that contains a slot (called X) that is a
> large matrix, specifically a "model matrix" similar to that produced
> by glm(). Some columns of this matrix get corrupted with wrong values
> (usually zero, but sometimes NaN or 10^300ish), which can be seen by
> examining X right before FUN returns (to mclapply()'s environment) and
> comparing to the "same" X after mclapply() returns to the calling
> environment.
>
> Part of svn commit r58219 is this hunk
>
> diff --git a/src/library/parallel/R/unix/mcfork.R
> b/src/library/parallel/R/unix/mcfork.R
> index 8e27534..4f92193 100644
> --- a/src/library/parallel/R/unix/mcfork.R
> +++ b/src/library/parallel/R/unix/mcfork.R
> @@ -82,7 +82,8 @@ mckill <- function(process, signal = 2L)
> ## used by mcparallel, mclapply
> sendMaster <- function(what)
> {
> -if (!is.raw(what)) what <- serialize(what, NULL, FALSE)
> +# This is talking to the same machine, so no point in using xdr.
> +if (!is.raw(what)) what <- serialize(what, NULL, xdr = FALSE)
> .Call(C_mc_send_master, what, PACKAGE = "parallel")
> }
>
> Contrary to the comment, I have found that if I specify xdr = TRUE, I
> get the expected (non-corrupted X slot) behavior in 2.16.0, even
> though it is forking locally on my 64bit Debian laptop with a little
> endian i7 processor, whose specs are
>
> goodrich at CYBERPOWERPC:/tmp/serialization$ cat /proc/cpuinfo
> processor : 0
> vendor_id : GenuineIntel
> cpu family : 6
> model : 42
> model name : Intel(R) Core(TM) i7-2630QM CPU @ 2.00GHz
> stepping: 7
> microcode : 0x17
> cpu MHz : 800.000
> cache size : 6144 KB
> physical id : 0
> siblings: 8
> core id : 0
> cpu cores : 4
> apicid : 0
> initial apicid : 0
> fpu : yes
> fpu_exception : yes
> cpuid level : 13
> wp : yes
> flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge
> mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe
> syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl
> xtopology nonstop_tsc aperfmperf pni pclmulqdq dtes64 monitor ds_cpl
> vmx est tm2 ssse3 cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic popcnt
> tsc_deadline_timer xsave avx lahf_lm ida arat epb xsaveopt pln pts dts
> tpr_shadow vnmi flexpriority ept vpid
> bogomips: 3990.83
> clflush size: 64
> cache_alignment : 64
> address sizes : 36 bits physical, 48 bits virtual
> power management:
>
> ...
>
> processor : 7
> [same as processor 0]
>
> So, to summarize I get the good behavior on R 2.14.2 when using
> mclapply(), on 2.15.0 beta when using lapply(), and on 2.16.0 using
> mclapply() iff I patch in xdr = TRUE in sendMaster(). I get the bad
> behavior on 2.15.0 beta and unpatched 2.16.0 when using mclapply().
>
> My session info:
Re: [Rd] serialization regression in 2.15.0 beta
Quoting Prof Brian Ripley :
On 27/03/2012 22:01, Ben Goodrich wrote:
In case anyone is concerned that this regression will affect them, the
code was reverted to the 2.14.x behavior by
r58842 | ripley | 2012-03-26 08:12:43 -0400 (Mon, 26 Mar 2012) | 1 line
Changed paths:
M /branches/R-2-15-branch/doc/NEWS.Rd
M /branches/R-2-15-branch/src/library/parallel/R/unix/forkCluster.R
M /branches/R-2-15-branch/src/library/parallel/R/unix/mcfork.R
revert to XDR serialization for 2.15.0
But the underlying problem (in non-xdr binary unserialization) is AFAWK
fixed: it was just that at this late stage there was too little time to
test thoroughly before release.
Please test R-devel on your own problem (we haven't: the issue was
found using a different example from elsewhere).
Indeed, the issue seems to be fixed in r-devel for my example.
Thanks,
Ben
I am experiencing a problem related to serialization behavior in
2.15.0 beta (binary installed from Debian unstable) and 2.16.0 (from
svn) that is not present in 2.14.2 (binary from Debian testing).
I don't fully understand the problem. Also, I tried but have not yet
been able to create a small, self-contained example that reproduces
the problem. However, I do have a large, not self-contained example,
which requires an alpha version (not yet on CRAN) of the mi package
(the mi package on CRAN would not exhibit this issue). Anyone
interested in reproducing the problem can follow the readme.txt file
in this directory:
http://www.columbia.edu/~bg2382/mi/serialization/
I track r-devel with git-svn and was able to git bisect to svn
commit r58219
commit 799102bd9d0266fe89c3120981decf0b1f17ef11
Author: ripley
Date: Sat Jan 28 15:02:34 2012 +
make use of non-xdr serialization;.
although this commit could merely expose the problem rather than cause it.
The problem occurs when the FUN called by mclapply() in the parallel
package returns a S4 object that contains a slot (called X) that is a
large matrix, specifically a "model matrix" similar to that produced
by glm(). Some columns of this matrix get corrupted with wrong values
(usually zero, but sometimes NaN or 10^300ish), which can be seen by
examining X right before FUN returns (to mclapply()'s environment) and
comparing to the "same" X after mclapply() returns to the calling
environment.
Part of svn commit r58219 is this hunk
diff --git a/src/library/parallel/R/unix/mcfork.R
b/src/library/parallel/R/unix/mcfork.R
index 8e27534..4f92193 100644
--- a/src/library/parallel/R/unix/mcfork.R
+++ b/src/library/parallel/R/unix/mcfork.R
@@ -82,7 +82,8 @@ mckill<- function(process, signal = 2L)
## used by mcparallel, mclapply
sendMaster<- function(what)
{
-if (!is.raw(what)) what<- serialize(what, NULL, FALSE)
+# This is talking to the same machine, so no point in using xdr.
+if (!is.raw(what)) what<- serialize(what, NULL, xdr = FALSE)
.Call(C_mc_send_master, what, PACKAGE = "parallel")
}
Contrary to the comment, I have found that if I specify xdr = TRUE, I
get the expected (non-corrupted X slot) behavior in 2.16.0, even
though it is forking locally on my 64bit Debian laptop with a little
endian i7 processor, whose specs are
goodrich at CYBERPOWERPC:/tmp/serialization$ cat /proc/cpuinfo
processor : 0
vendor_id : GenuineIntel
cpu family : 6
model : 42
model name : Intel(R) Core(TM) i7-2630QM CPU @ 2.00GHz
stepping: 7
microcode : 0x17
cpu MHz : 800.000
cache size : 6144 KB
physical id : 0
siblings: 8
core id : 0
cpu cores : 4
apicid : 0
initial apicid : 0
fpu : yes
fpu_exception : yes
cpuid level : 13
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge
mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe
syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl
xtopology nonstop_tsc aperfmperf pni pclmulqdq dtes64 monitor ds_cpl
vmx est tm2 ssse3 cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic popcnt
tsc_deadline_timer xsave avx lahf_lm ida arat epb xsaveopt pln pts dts
tpr_shadow vnmi flexpriority ept vpid
bogomips: 3990.83
clflush size: 64
cache_alignment : 64
address sizes : 36 bits physical, 48 bits virtual
power management:
...
processor : 7
[same as processor 0]
So, to summarize I get the good behavior on R 2.14.2 when using
mclapply(), on 2.15.0 beta when using lapply(), and on 2.16.0 using
mclapply() iff I patch in xdr = TRUE in sendMaster(). I get the bad
behavior on 2.15.0 beta and unpatched 2.16.0 when using mclapply().
My session info:
sessionInfo()
R version 2.15.0 beta (2012-03-16 r58769)
Platform: x86_64-pc-linux-gnu (64-bit)
locale:
[1] LC_CTYPE
Re: [Rd] [wishlist, patch] Removing .bzr/ directory when calling R CMD build (PR#10625)
Gabor Grothendieck wrote: > If you place an .Rbuildignore file in the top level of > your package with this line single line as its contents: > > [.]bzr$ > > then the .bzr file will not be included. Thank you for the suggestion. In order to remove both the .bzr/ directory and the .bzrignore file, it seems to be necessary to specify [.]bzr$ [.]bzrignore in the .Rbuildignore file before calling R CMD build. This is certainly sufficient in my case, but since the patch is just one line, perhaps it should be considered for inclusion as well. Ben __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] License status of CRAN packages
Dirk Eddelbuettel debian.org> writes: > As a non-exhautive list with possible misclassifications, cran2deb currently > has these packasges as 'maybe not free' and does not build them: > > BARD,BayesDA,CoCo,ConvCalendar,FAiR,PTAk,RScaLAPACK,Rcsdp,SDDA,SGP, > alphahull,ash,asypow,caMassClass,gpclib,mapproj,matlab,mclust,mclust02, > mlbench,optmatch,rankreg,realized,rngwell19937,rtiff,rwt,scagnostics, > sgeostat,spatialkernel,tlnise,xgobi Small point: FAiR is free. The file LICENSE thing just clarifies that most of the code is AGPL but a couple files can't be included under the AGPL and are plain GPL. As far as I can see, R does not give me the option of saying so in a "standard" way, e.g. putting License: AGPL (>= 3) in the DESCRIPTION file would only be 95% accurate and putting License: AGPL (>= 3) | GPL (>= 3) is misleading. Ben __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] License status of CRAN packages
Gabor Grothendieck wrote: > On Thu, Apr 23, 2009 at 4:59 PM, Ben Goodrich > wrote: >> Dirk Eddelbuettel debian.org> writes: >>> As a non-exhautive list with possible misclassifications, cran2deb currently >>> has these packasges as 'maybe not free' and does not build them: >>> >>> BARD,BayesDA,CoCo,ConvCalendar,FAiR,PTAk,RScaLAPACK,Rcsdp,SDDA,SGP, >>> alphahull,ash,asypow,caMassClass,gpclib,mapproj,matlab,mclust,mclust02, >>> mlbench,optmatch,rankreg,realized,rngwell19937,rtiff,rwt,scagnostics, >>> sgeostat,spatialkernel,tlnise,xgobi >> Small point: FAiR is free. The file LICENSE thing just clarifies that most of >> the code is AGPL but a couple files can't be included under the AGPL and are >> plain GPL. As far as I can see, R does not give me the option of saying so >> in a >> "standard" way, e.g. putting License: AGPL (>= 3) in the DESCRIPTION file >> would >> only be 95% accurate and putting License: AGPL (>= 3) | GPL (>= 3) is >> misleading. > > How about " > > License: AGPL except for 2 GPL files > If that would make anyone's life easier without making anyone else's life harder, I would be happy to put that in the DESCRIPTION file. I have been doing file LICENSE because it parses on http://cran.r-project.org/web/packages/FAiR/index.html and people can click to the LICENSE link to read the details if they are interested. But maybe that is not optimal. Dirk? Ben __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] License status of CRAN packages
Kurt Hornik wrote: > AGPL, unfortunately, allows supplements, and hence cannot fully be > standardized. We've been thinking about extending the current scheme to > indicate a base license plus supplements, but this is still work in > progress. This would be helpful. I would just reemphasize that a package that includes some AGPL code and some GPL3 code is standard as far as the FSF is concerned, e.g. from section 13 of the AGPL: "Notwithstanding any other provision of this License, you have permission to link or combine any covered work with a work licensed under version 3 of the GNU General Public License into a single combined work, and to convey the resulting work. The terms of this License will continue to apply to the part which is the covered work, but the work with which it is combined will remain governed by version 3 of the GNU General Public License." So, I think that CRAN should at least have a canonical spec that covers *this* situation. Other situations may be more complicated to handle elegantly. Thanks, Ben __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] License status of CRAN packages
I don't have a strong opinion about partitioning the repository, but I don't think partitioning based on whether the license is commonly used for R packages is terribly helpful. AGPL and AGPL + GPL3 are not common licensing schemes for R packages currently, but from the perspective of a useR, there is no relevant distinction between these two rare cases and the more common case of GPL3. So why should packages be put in separate repositories based on this non-distinction? A partition based on whether the package is free according to the FSF definition seems more plausible to me. Ben Christophe Dutang wrote: > Hi all, > > I think for the common licences, we should also add BSD licence... for > example my pkg randtoolbox (which is currently with incompatible > licences) will probably be in a near future with the BSD licence. > > Anyway I like the idea of two different repositories for GPL like > licensed pkg and other packages. > > Christophe > > Le 24 avr. 09 à 18:20, Gabor Grothendieck a écrit : > >> On Fri, Apr 24, 2009 at 11:44 AM, Ben Goodrich >> wrote: >>> Kurt Hornik wrote: >>>> AGPL, unfortunately, allows supplements, and hence cannot fully be >>>> standardized. We've been thinking about extending the current >>>> scheme to >>>> indicate a base license plus supplements, but this is still work in >>>> progress. >>> >>> This would be helpful. I would just reemphasize that a package that >>> includes some AGPL code and some GPL3 code is standard as far as the FSF >>> is concerned, e.g. from section 13 of the AGPL: >>> >>> "Notwithstanding any other provision of this License, you have >>> permission to link or combine any covered work with a work licensed >>> under version 3 of the GNU General Public License into a single combined >>> work, and to convey the resulting work. The terms of this License will >>> continue to apply to the part which is the covered work, but the work >>> with which it is combined will remain governed by version 3 of the GNU >>> General Public License." >>> >>> So, I think that CRAN should at least have a canonical spec that covers >>> *this* situation. Other situations may be more complicated to handle >>> elegantly. >> >> Another possibility is to simply standardize the set of licenses that >> CRAN >> supports. GPL licenses (GPl-2, GPL-2.1, GPL-3, LGPL), MIT and >> X11 already cover 98% of all packages on CRAN. If there truly is an >> advantage to the AGPL license perhaps a standard version could be offered >> in the set. Perhaps, for the 2% of packages that want a different >> license >> a second repository could be made available. >> >> __ >> R-devel@r-project.org mailing list >> https://stat.ethz.ch/mailman/listinfo/r-devel > > -- > Christophe Dutang > Ph. D. student at ISFA, Lyon, France > website: http://dutangc.free.fr > > > > __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
