[Rd] CRAN: No MacOS X binary builds since January 7
FYI,
no MacOS X binaries have been built for CRAN since 2010-01-07:
> url <- "http://cran.r-project.org/bin/macosx/universal/contrib/r-release/";;
> x <- readLines(url);
pattern <- ".*([0-9]{2}-[A-Za-z]{3}-[0-9]{4}) ([0-9]{2}:[0-9]{2}).*";
y <- grep(pattern, x, value=TRUE);
y <- grep("PACKAGE", y, invert=TRUE, value=TRUE);
z <- gsub(pattern, "\\1", y);
z <- unique(z);
z <- as.Date(z, "%d-%b-%Y");
z <- sort(z);
print(z);
> pattern <- ".*([0-9]{2}-[A-Za-z]{3}-[0-9]{4}) ([0-9]{2}:[0-9]{2}).*";
> y <- grep(pattern, x, value=TRUE);
> y <- grep("PACKAGE", y, invert=TRUE, value=TRUE);
> z <- gsub(pattern, "\\1", y);
> z <- unique(z);
> z <- as.Date(z, "%d-%b-%Y");
> z <- sort(z);
> print(z);
[1] "2009-07-18" "2009-07-19" "2009-10-02" "2009-10-16" "2009-10-27"
[6] "2009-10-28" "2009-10-29" "2009-10-30" "2009-10-31" "2009-11-02"
[11] "2009-11-04" "2009-11-05" "2009-11-06" "2009-11-07" "2009-11-09"
[16] "2009-11-10" "2009-11-11" "2009-11-12" "2009-11-13" "2009-11-14"
[21] "2009-11-16" "2009-11-17" "2009-11-18" "2009-11-19" "2009-11-20"
[26] "2009-11-21" "2009-11-23" "2009-11-24" "2009-11-25" "2009-11-26"
[31] "2009-11-27" "2009-11-28" "2009-11-30" "2009-12-01" "2009-12-02"
[36] "2009-12-03" "2009-12-04" "2009-12-07" "2009-12-08" "2009-12-10"
[41] "2009-12-11" "2009-12-12" "2009-12-14" "2009-12-15" "2009-12-16"
[46] "2009-12-17" "2009-12-18" "2009-12-19" "2009-12-21" "2009-12-22"
[51] "2009-12-23" "2009-12-24" "2009-12-25" "2009-12-27" "2009-12-29"
[56] "2009-12-30" "2009-12-31" "2010-01-02" "2010-01-03" "2010-01-04"
[61] "2010-01-05" "2010-01-06" "2010-01-07"
> print(table(diff(z)));
1 2 3 11 14 75
46 12 1 1 1 1
/Henrik
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] CRAN: No MacOS X binary builds since January 7
Not an issue for *this* list!
Please report to the maintainer and perhaps cc R-sig-mac. Note that
you are looking at the (old) Tiger binaries and not the more current
Leopard ones, which were last updated yesterday,
In any case, binary packages are a privilege and you can always
install from the sources (in the vast majority of cases with no extra
tools other than Xcode).
On Sun, 17 Jan 2010, Henrik Bengtsson wrote:
FYI,
no MacOS X binaries have been built for CRAN since 2010-01-07:
url <- "http://cran.r-project.org/bin/macosx/universal/contrib/r-release/";;
x <- readLines(url);
pattern <- ".*([0-9]{2}-[A-Za-z]{3}-[0-9]{4}) ([0-9]{2}:[0-9]{2}).*";
y <- grep(pattern, x, value=TRUE);
y <- grep("PACKAGE", y, invert=TRUE, value=TRUE);
z <- gsub(pattern, "\\1", y);
z <- unique(z);
z <- as.Date(z, "%d-%b-%Y");
z <- sort(z);
print(z);
pattern <- ".*([0-9]{2}-[A-Za-z]{3}-[0-9]{4}) ([0-9]{2}:[0-9]{2}).*";
y <- grep(pattern, x, value=TRUE);
y <- grep("PACKAGE", y, invert=TRUE, value=TRUE);
z <- gsub(pattern, "\\1", y);
z <- unique(z);
z <- as.Date(z, "%d-%b-%Y");
z <- sort(z);
print(z);
[1] "2009-07-18" "2009-07-19" "2009-10-02" "2009-10-16" "2009-10-27"
[6] "2009-10-28" "2009-10-29" "2009-10-30" "2009-10-31" "2009-11-02"
[11] "2009-11-04" "2009-11-05" "2009-11-06" "2009-11-07" "2009-11-09"
[16] "2009-11-10" "2009-11-11" "2009-11-12" "2009-11-13" "2009-11-14"
[21] "2009-11-16" "2009-11-17" "2009-11-18" "2009-11-19" "2009-11-20"
[26] "2009-11-21" "2009-11-23" "2009-11-24" "2009-11-25" "2009-11-26"
[31] "2009-11-27" "2009-11-28" "2009-11-30" "2009-12-01" "2009-12-02"
[36] "2009-12-03" "2009-12-04" "2009-12-07" "2009-12-08" "2009-12-10"
[41] "2009-12-11" "2009-12-12" "2009-12-14" "2009-12-15" "2009-12-16"
[46] "2009-12-17" "2009-12-18" "2009-12-19" "2009-12-21" "2009-12-22"
[51] "2009-12-23" "2009-12-24" "2009-12-25" "2009-12-27" "2009-12-29"
[56] "2009-12-30" "2009-12-31" "2010-01-02" "2010-01-03" "2010-01-04"
[61] "2010-01-05" "2010-01-06" "2010-01-07"
print(table(diff(z)));
1 2 3 11 14 75
46 12 1 1 1 1
/Henrik
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
--
Brian D. Ripley, rip...@stats.ox.ac.uk
Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/
University of Oxford, Tel: +44 1865 272861 (self)
1 South Parks Road, +44 1865 272866 (PA)
Oxford OX1 3TG, UKFax: +44 1865 272595
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Build R-2.10.0 on HP-UX ia64 server
Hi All, I want to build R-2.10.0 on HP-UX, but I got following error message: ld: Unsatisfied symbol "zgemm" in file CHOLMOD.a[cholmod_l_super_numeric.o] ld: Unsatisfied symbol "zgemv" in file CHOLMOD.a[cholmod_l_super_solve.o] ld: Unsatisfied symbol "zherk" in file CHOLMOD.a[cholmod_l_super_numeric.o] ld: Unsatisfied symbol "ztrsm" in file CHOLMOD.a[cholmod_l_super_numeric.o] ld: Unsatisfied symbol "ztrsv" in file CHOLMOD.a[cholmod_l_super_solve.o] ld: Unsatisfied symbol "dgemm" in file CHOLMOD.a[cholmod_l_super_numeric.o] ld: Unsatisfied symbol "dgemv" in file CHOLMOD.a[cholmod_l_super_solve.o] ld: Unsatisfied symbol "main" in file ld: Unsatisfied symbol "alloca" in file CHMfactor.o ld: Unsatisfied symbol "dpotrf" in file CHOLMOD.a[cholmod_l_super_numeric.o] ld: Unsatisfied symbol "zpotrf" in file CHOLMOD.a[cholmod_l_super_numeric.o] ld: Unsatisfied symbol "dsyrk" in file CHOLMOD.a[cholmod_l_super_numeric.o] ld: Unsatisfied symbol "dtrsm" in file CHOLMOD.a[cholmod_l_super_numeric.o] ld: Unsatisfied symbol "dtrsv" in file CHOLMOD.a[cholmod_l_super_solve.o] 14 errors. gmake[3]: *** [Matrix.sl] Error 1 gmake[3]: Leaving directory `/rnd/homes/jixu/tmp/R-2.10.1/src/library/Recommended/Matrix/src' ERROR: compilation failed for package 'Matrix' * removing '/rnd/homes/jixu/tmp/R-2.10.1/library/Matrix' gmake[2]: *** [Matrix.ts] Error 1 gmake[2]: Leaving directory `/rnd/homes/jixu/tmp/R-2.10.1/src/library/Recommended' gmake[1]: *** [recommended-packages] Error 2 gmake[1]: Leaving directory `/rnd/homes/jixu/tmp/R-2.10.1/src/library/Recommended' gmake: *** [stamp-recommended] Error 2 Any help or suggestions would be appreciated. In addition I use below parameter: export CC="cc" export CFLAGS="-AC99 +DD64" export CXX="aCC" export CXXFLAGS="-b +DD64" export F77="f90" export FFLAGS="+DD64" export LDFLAGS="-L/opt/fortran90/lib -L/usr/lib/hpux64" ./configure --prefix=$/usr/homes/myrhome --enable-R-shlib --with-x --with-readline=no In addition to the R-2.10.1 still can reproduce this issue with above parameter. Thanks in advance, Xu Jin _ [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Fix for bug in match()
Hello all,
I posted the following bug last week:
# These calls work correctly:
match(c("A", "B", "C"), c("A","C"), incomparables=NA) # okay
match(c("A", "B", "C"), "A") # okay
match("A", c("A", "B"), incomparables=NA) # okay
# This one causes R to hang:
match(c("A", "B", "C"), "A", incomparables=NA)
I found the reason in the hash table implementation in unique.c. Values
in the table argument of match are stored in a hash table. Incomparables
are then removed by (potentially multiple) calls to removeEntry():
static void removeEntry(SEXP table, SEXP x, int indx, HashData *d)
{
int i, *h;
h = INTEGER(d->HashTable);
i = d->hash(x, indx, d);
while (h[i] != NIL) {
if (d->equal(table, h[i], x, indx)) {
h[i] = NA_INTEGER; /* < 0, only index values are inserted */
return;
}
i = (i + 1) % d->M;
}
h[i] = NA_INTEGER;
}
Removing a value x sets the corresponding cell to NA_INTEGER. If x is
not element of the table, the cell where it would have been is set from
NIL (-1) to NA_INTEGER. Therefore, subsequent calls to removeEntry()
with values that are not element of the table can remove all initial NIL
values from the table cells. Another call of removeEntry() or Lookup()
then leads to an infinte loop because the condition
while (h[i] != NIL)
is never false.
As a fix, I propose to reset cells to NIL when removing values, which
leads to the following definition:
static void removeEntry(SEXP table, SEXP x, int indx, HashData *d)
{
int i, *h;
h = INTEGER(d->HashTable);
i = d->hash(x, indx, d);
while (h[i] != NIL) {
if (d->equal(table, h[i], x, indx)) {
h[i] = NIL; /* < 0, only index values are inserted */
return;
}
i = (i + 1) % d->M;
}
}
I would have submitted a patch file, but I couldn't checkout from the
svn repository.
Cheers,
Andreas
--
Andreas Borg
Medizinische Informatik
UNIVERSITÄTSMEDIZIN
der Johannes Gutenberg-Universität
Institut für Medizinische Biometrie, Epidemiologie und Informatik
Obere Zahlbacher Straße 69, 55131 Mainz
www.imbei.uni-mainz.de
Telefon +49 (0) 6131 175062
E-Mail: b...@imbei.uni-mainz.de
Diese E-Mail enthält vertrauliche und/oder rechtlich geschützte Informationen.
Wenn Sie nicht der
richtige Adressat sind oder diese E-Mail irrtümlich erhalten haben, informieren
Sie bitte sofort den
Absender und löschen Sie diese Mail. Das unerlaubte Kopieren sowie die
unbefugte Weitergabe
dieser Mail und der darin enthaltenen Informationen ist nicht gestattet.
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] CRAN: No MacOS X binary builds since January 7
On Mon, Jan 18, 2010 at 1:36 AM, Prof Brian Ripley
wrote:
> Not an issue for *this* list!
I used this list to share this with package developers - not
particularly MacOS X users. As a package provider I'd like to know
when packages are not available on all platforms. It seems like a
errors, because the records show that packages are typically built
every day.
>
> Please report to the maintainer and perhaps cc R-sig-mac.
Maintainer has been notified repeatably without response (==don't know
if my messages even gets through).
> Note that you are
> looking at the (old) Tiger binaries and not the more current Leopard ones,
> which were last updated yesterday,
Thanks for this note. As a non-OSX user, I wasn't aware of this. It
made me find:
http://cran.r-project.org/bin/macosx/leopard/contrib/r-release/
This is not the directory that are used for the MacOS X links when
going to package pages under http://cran.r-project.org/web/packages/,
e.g.
http://cran.r-project.org/web/packages/aroma.core/
The MacOS X links is:
http://cran.r-project.org/bin/macosx/universal/contrib/r-release/aroma.core_1.3.1.tgz
Another example is here:
http://cran.r-project.org/web/packages/biglars/
Then, do the MacOS X links on the CRAN package pages need to be
updated/complemented?
If this is already well known, that is all I need to hear. (I
understand that install.packages() takes care of the installation).
/Henrik
>
> In any case, binary packages are a privilege and you can always install from
> the sources (in the vast majority of cases with no extra tools other than
> Xcode).
>
> On Sun, 17 Jan 2010, Henrik Bengtsson wrote:
>
>> FYI,
>>
>> no MacOS X binaries have been built for CRAN since 2010-01-07:
>>
>>> url <-
>>> "http://cran.r-project.org/bin/macosx/universal/contrib/r-release/";;
>>> x <- readLines(url);
>>
>> pattern <- ".*([0-9]{2}-[A-Za-z]{3}-[0-9]{4}) ([0-9]{2}:[0-9]{2}).*";
>> y <- grep(pattern, x, value=TRUE);
>> y <- grep("PACKAGE", y, invert=TRUE, value=TRUE);
>> z <- gsub(pattern, "\\1", y);
>> z <- unique(z);
>> z <- as.Date(z, "%d-%b-%Y");
>> z <- sort(z);
>> print(z);
>>>
>>> pattern <- ".*([0-9]{2}-[A-Za-z]{3}-[0-9]{4}) ([0-9]{2}:[0-9]{2}).*";
>>> y <- grep(pattern, x, value=TRUE);
>>> y <- grep("PACKAGE", y, invert=TRUE, value=TRUE);
>>> z <- gsub(pattern, "\\1", y);
>>> z <- unique(z);
>>> z <- as.Date(z, "%d-%b-%Y");
>>> z <- sort(z);
>>> print(z);
>>
>> [1] "2009-07-18" "2009-07-19" "2009-10-02" "2009-10-16" "2009-10-27"
>> [6] "2009-10-28" "2009-10-29" "2009-10-30" "2009-10-31" "2009-11-02"
>> [11] "2009-11-04" "2009-11-05" "2009-11-06" "2009-11-07" "2009-11-09"
>> [16] "2009-11-10" "2009-11-11" "2009-11-12" "2009-11-13" "2009-11-14"
>> [21] "2009-11-16" "2009-11-17" "2009-11-18" "2009-11-19" "2009-11-20"
>> [26] "2009-11-21" "2009-11-23" "2009-11-24" "2009-11-25" "2009-11-26"
>> [31] "2009-11-27" "2009-11-28" "2009-11-30" "2009-12-01" "2009-12-02"
>> [36] "2009-12-03" "2009-12-04" "2009-12-07" "2009-12-08" "2009-12-10"
>> [41] "2009-12-11" "2009-12-12" "2009-12-14" "2009-12-15" "2009-12-16"
>> [46] "2009-12-17" "2009-12-18" "2009-12-19" "2009-12-21" "2009-12-22"
>> [51] "2009-12-23" "2009-12-24" "2009-12-25" "2009-12-27" "2009-12-29"
>> [56] "2009-12-30" "2009-12-31" "2010-01-02" "2010-01-03" "2010-01-04"
>> [61] "2010-01-05" "2010-01-06" "2010-01-07"
>>>
>>> print(table(diff(z)));
>>
>> 1 2 3 11 14 75
>> 46 12 1 1 1 1
>>
>> /Henrik
>>
>> __
>> R-devel@r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-devel
>>
>
> --
> Brian D. Ripley, rip...@stats.ox.ac.uk
> Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/
> University of Oxford, Tel: +44 1865 272861 (self)
> 1 South Parks Road, +44 1865 272866 (PA)
> Oxford OX1 3TG, UK Fax: +44 1865 272595
>
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] CRAN: No MacOS X binary builds since January 7
On Jan 18, 2010, at 7:53 , Henrik Bengtsson wrote:
On Mon, Jan 18, 2010 at 1:36 AM, Prof Brian Ripley
wrote:
Not an issue for *this* list!
I used this list to share this with package developers - not
particularly MacOS X users. As a package provider I'd like to know
when packages are not available on all platforms. It seems like a
errors, because the records show that packages are typically built
every day.
Please report to the maintainer and perhaps cc R-sig-mac.
Maintainer has been notified repeatably without response (==don't know
if my messages even gets through).
I wonder where you were sending your notifications -- quite apparently
not to the right place as I didn't get any ...
Anyway, now that it reached me (through suboptimal channels as Brian
pointed out) it should be fixed for the next run.
Note that you are
looking at the (old) Tiger binaries and not the more current
Leopard ones,
which were last updated yesterday,
Thanks for this note. As a non-OSX user, I wasn't aware of this. It
made me find:
http://cran.r-project.org/bin/macosx/leopard/contrib/r-release/
This is not the directory that are used for the MacOS X links when
going to package pages under http://cran.r-project.org/web/packages/,
e.g.
http://cran.r-project.org/web/packages/aroma.core/
The MacOS X links is:
http://cran.r-project.org/bin/macosx/universal/contrib/r-release/aroma.core_1.3.1.tgz
Another example is here:
http://cran.r-project.org/web/packages/biglars/
Then, do the MacOS X links on the CRAN package pages need to be
updated/complemented?
I think so -- there is currently a discrepancy - the checks show
Leopard builds but that link is to the Tiger build -- Kurt, can you,
please, check?
If this is already well known, that is all I need to hear. (I
understand that install.packages() takes care of the installation).
/Henrik
In any case, binary packages are a privilege and you can always
install from
the sources (in the vast majority of cases with no extra tools
other than
Xcode).
On Sun, 17 Jan 2010, Henrik Bengtsson wrote:
FYI,
no MacOS X binaries have been built for CRAN since 2010-01-07:
url <-
"http://cran.r-project.org/bin/macosx/universal/contrib/r-
release/";
x <- readLines(url);
pattern <- ".*([0-9]{2}-[A-Za-z]{3}-[0-9]{4}) ([0-9]{2}:[0-9]
{2}).*";
y <- grep(pattern, x, value=TRUE);
y <- grep("PACKAGE", y, invert=TRUE, value=TRUE);
z <- gsub(pattern, "\\1", y);
z <- unique(z);
z <- as.Date(z, "%d-%b-%Y");
z <- sort(z);
print(z);
pattern <- ".*([0-9]{2}-[A-Za-z]{3}-[0-9]{4}) ([0-9]{2}:[0-9]
{2}).*";
y <- grep(pattern, x, value=TRUE);
y <- grep("PACKAGE", y, invert=TRUE, value=TRUE);
z <- gsub(pattern, "\\1", y);
z <- unique(z);
z <- as.Date(z, "%d-%b-%Y");
z <- sort(z);
print(z);
[1] "2009-07-18" "2009-07-19" "2009-10-02" "2009-10-16" "2009-10-27"
[6] "2009-10-28" "2009-10-29" "2009-10-30" "2009-10-31" "2009-11-02"
[11] "2009-11-04" "2009-11-05" "2009-11-06" "2009-11-07"
"2009-11-09"
[16] "2009-11-10" "2009-11-11" "2009-11-12" "2009-11-13"
"2009-11-14"
[21] "2009-11-16" "2009-11-17" "2009-11-18" "2009-11-19"
"2009-11-20"
[26] "2009-11-21" "2009-11-23" "2009-11-24" "2009-11-25"
"2009-11-26"
[31] "2009-11-27" "2009-11-28" "2009-11-30" "2009-12-01"
"2009-12-02"
[36] "2009-12-03" "2009-12-04" "2009-12-07" "2009-12-08"
"2009-12-10"
[41] "2009-12-11" "2009-12-12" "2009-12-14" "2009-12-15"
"2009-12-16"
[46] "2009-12-17" "2009-12-18" "2009-12-19" "2009-12-21"
"2009-12-22"
[51] "2009-12-23" "2009-12-24" "2009-12-25" "2009-12-27"
"2009-12-29"
[56] "2009-12-30" "2009-12-31" "2010-01-02" "2010-01-03"
"2010-01-04"
[61] "2010-01-05" "2010-01-06" "2010-01-07"
print(table(diff(z)));
1 2 3 11 14 75
46 12 1 1 1 1
/Henrik
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
--
Brian D. Ripley, rip...@stats.ox.ac.uk
Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/
University of Oxford, Tel: +44 1865 272861 (self)
1 South Parks Road, +44 1865 272866 (PA)
Oxford OX1 3TG, UKFax: +44 1865 272595
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] order() fails on a chr object of class "AsIs" with "\265" in it
Prof. Ripley,
Thank you for the explanation. I appreciate both understanding what's
happening, and having several options for fixing my scripts.
-Don
At 7:17 AM + 1/16/10, Prof Brian Ripley wrote:
On Fri, 15 Jan 2010, Don MacQueen wrote:
Here's an example (session info at the end).
tmpv <- c('\265g/L','Bq/L')
order(tmpv)
[1] 2 1
tmpv <- I(tmpv)
order(tmpv)
Error in if (xi > xj) 1L else -1L : missing value where TRUE/FALSE needed
foov <- gsub('\265','',tmpv)
order(foov)
[1] 2 1
str(tmpv)
Class 'AsIs' chr [1:2] "\265g/L" "Bq/L"
str(foov)
Class 'AsIs' chr [1:2] "g/L" "Bq/L"
I can easily work around this in my scripts, but shouldn't order()
succeed with such an object?
Not in the C locale. There is no pre-defined ordering for non-ASCII
characters in that locale and the string is invalid in a strict C
locale.
(I suppose this could be Mac-specific, but I'm assuming it's not...)
No, but the handling of invalid strings in C is OS-specific.
For context:
The character "\265" causes the Greek letter mu to be displayed in
various output devices. For example, the character vector
eventually gets written to an html file, which when displayed in
Firefox (Mac) is displayed as Greek mu. Also in Excel 2004 (Mac).
I first wrote these scripts 6 years ago, when "\265" was a way I
could find to display the Greek mu in output text files of various
kinds. They worked as recently as 3 months ago. Maybe there's a
better way now to display a mu in text-based contexts?
Use UTF-8 and Unicode \u03BC (http://*www.*alanwood.net/unicode/greek.html).
The issue is that you need a xtfrm method for 'AsIs': it falls back
to comparisons via .gt and those (correctly) fail.
xtfrm.AsIs <- function(x) xtfrm(unclass(x))
would keep get you going until you fix the scripts.
sessionInfo()
R version 2.10.1 (2009-12-14)
i386-apple-darwin8.11.1
locale:
[1] C
attached base packages:
[1] stats graphics grDevices utils datasets methods base
Thanks
-Don
--
--
Don MacQueen
Environmental Protection Department
Lawrence Livermore National Laboratory
Livermore, CA, USA
925-423-1062
__
R-devel@r-project.org mailing list
https://*stat.ethz.ch/mailman/listinfo/r-devel
--
Brian D. Ripley, rip...@stats.ox.ac.uk
Professor of Applied Statistics, http://*www.*stats.ox.ac.uk/~ripley/
University of Oxford, Tel: +44 1865 272861 (self)
1 South Parks Road, +44 1865 272866 (PA)
Oxford OX1 3TG, UKFax: +44 1865 272595
--
--
Don MacQueen
Environmental Protection Department
Lawrence Livermore National Laboratory
Livermore, CA, USA
925-423-1062
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] compiler specific flags : -std=c++0x
Hello, We'd like to use the flag -std=c++0x to take advantage of features of the forthcoming C++0x standard that is already partly implemented by the GCC >= 4.3 R CMD check warns about the flag because it is non portable. Is there a way to turn the warning off, considering that we do test that the compiler is indeed GCC >= 4.3 as part of our configure script and we only add the flag in that case. Romain -- Romain Francois Professional R Enthusiast +33(0) 6 28 91 30 30 http://romainfrancois.blog.free.fr |- http://tr.im/KfKn : Rcpp 0.7.2 |- http://tr.im/JOlc : External pointers with Rcpp `- http://tr.im/JFqa : R Journal, Volume 1/2, December 2009 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Model frame when LHS is cbind (PR#14189)
The model frame shows the response and predictors in a data frame with
nicely labelled columns:
fm <- lm(wt~qsec+log(hp)+sqrt(disp), data=mtcars)
model.frame(fm) # ok
When the left hand side consists of more than one response, those response
variables still look good, inside a matrix:
fm <- lm(cbind(qsec,hp,disp)~wt, data=mtcars)
model.frame(fm)[[1]] # ok
A problem arises when some of the response variables are transformed:
fm <- lm(cbind(qsec,log(hp),sqrt(disp))~wt, data=mtcars)
model.frame(fm)[[1]] # ugh, missing column names
The model frame is useful for many things, even more so when all column
names are legible. Therefore I propose adding two new lines to
model.frame.default() between lines 371 and 372 in
R-patched_2010-01-12/src/library/stats/R/models.R:
varnames <- sapply(vars, deparse, width.cutoff = 500)[-1L]
variables <- eval(predvars, data, env)
NEW if (is.matrix(variables[[1L]]))
NEW colnames(variables[[1L]]) <- as.character(formula[[2L]])[-1L]
if (is.null(rownames) && (resp <- attr(formula, "response")) >
0L) {
With this fix, the above example returns legible column names:
fm <- lm(cbind(qsec,log(hp),sqrt(disp))~wt, data=mtcars)
model.frame(fm)[[1]] # nice column names
I hope the R development team can either commit this fix or improve it.
Thanks,
Arni
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Copyright versus Licenses
My company recently started using a R library from RCRAN that is licensed under the LGPL Version 2 or greater per the DESCRIPTION file, but contains no copy of the LGPL notice, or any copyright notice. I've grown accustomed to paying attention to copyright and licensing as a Debian package maintainer, and sent the author of the package an email expressing my concern. The author believed that assigning themselves copyright was incompatible with licensing the library under the terms of the LGPL. I disagree, and further contend that without copyright notice, the [copyright] license loses a certain degree of applicability, as it becomes inconclusive as to who is licensing the software under the terms of the LGPL. Not knowing who I was, the library author asked me to start a discussion of the subject on this list, presumably so they could see the opinions of others that they trust. The LGPL itself [1], in the final section entitled "How to Apply These Terms to Your New Libraries", the license provides a template for adding to the top of each source code file that contains a copyright line, a general notice regarding the lack of warranty, and information on where to obtain a full copy of the license. The GPL HOWTO [2] expresses similar instructions for the inclusion of a copyright line with the license. I know that R distributes copies of common licenses under 'share/licenses' in the R source. Debian does as well in '/usr/share/common-licenses/' for the purpose of not having to include the full LICENSE and/or COPYING file with every package that uses a common open source license, allowing the use of verbage such as "The Debian packaging is © 2010 [author] and is licensed under the Apache License version 2.0. On debian and derived systems, see `/usr/share/common-licenses/Apache-2.0' for the complete text." The R manual for writing extensions suggests a similar approach to avoiding duplication in Section 1.1 [3]. The R manual for writing extensions also mentions [4] in Section 1.1.1 the optional use of a Copyright field in the DESCRIPTION file, separate from the License field. As this section implies that the DESCRIPTION file format is based on the debian control file format, I assume the goal is to keep these lines simple, generally under 80 characters do to average terminal width. As such, I don't assume this field is recommended for complete copyright information for a library with multiple contributors. The aforementioned article does not specify where a developer should alternately put copyright information, perhaps assuming one would add it to each source code file as is recommended by GNU. In closing, do the R developers believe that including a Copyright notice is imperative with a Copyright License? If so, what advice do they have for those writing and contributing open source R libraries as to where this notice should go? Should that information perhaps be added to the R manual for extensions? Bryan McLellan [1] http://www.gnu.org/licenses/lgpl-2.1.txt [2] http://www.gnu.org/licenses/gpl-howto.html [3] http://cran.r-project.org/doc/manuals/R-exts.html#Package-structure [4] http://cran.r-project.org/doc/manuals/R-exts.html#The-DESCRIPTION-file __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
