Re: [Rd] http://cran.r-project.org/src/base/NEWS.html points to R v2.13.0
On 29.08.2011 21:22, Henrik Bengtsson wrote: FYI, http://cran.r-project.org/src/base/NEWS.html [May 18, 2011] is for R v2.13.0 whereas http://cran.r-project.org/src/base/NEWS [July 8, 2011] is for R v2.13.1. The former is linked to on a few places on http://cran.r-project.org/. Thnaks, probably the automatism that generates the NEWS does not yet generate the NEWS.html for CRAN. CCing CRAN@.. so this won't get lost in the mailing list archives. Uwe /Henrik __ 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] http://cran.r-project.org/src/base/NEWS.html points to R v2.13.0
On Aug 30, 2011, at 11:21 , Uwe Ligges wrote: On 29.08.2011 21:22, Henrik Bengtsson wrote: FYI, http://cran.r-project.org/src/base/NEWS.html [May 18, 2011] is for R v2.13.0 whereas http://cran.r-project.org/src/base/NEWS [July 8, 2011] is for R v2.13.1. The former is linked to on a few places on http://cran.r-project.org/. Thnaks, probably the automatism that generates the NEWS does not yet generate the NEWS.html for CRAN. CCing CRAN@.. so this won't get lost in the mailing list archives. This was already noted by Kurt back in May and I promised to fix the R-build-dist script when I had a clear head after grading exams, which apparently never happened... Done now (incl. CRAN). Uwe /Henrik __ 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 -- Peter Dalgaard, Professor Center for Statistics, Copenhagen Business School Solbjerg Plads 3, 2000 Frederiksberg, Denmark Phone: (+45)38153501 Email: pd@cbs.dk Priv: pda...@gmail.com __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Problem exporting table with many columns to dbf
Hello, I'm newbie in R and I have a problem exporting a table with many columns to a dbf file. I found an error when I open the result DBF file on other software and also importing it on R again. Here a example snippet of the problem (on a GNU/Linux OS): http://pastebin.com/0SMJqqwb Is it a bug? Thank you, Nacho V [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] unexpected behavior of callNextMethod() when passing arguments in methods to generic function
Hi,
there seems to be an unexpected behavior when using callNextMethod() in a method
to a (user defined) generic function so that additional arguments to the ones
defined in the signature of the generic are not passed correctly (i.e., their
value are lost/replaced by the default).
Problem description:
We have two hierarchical classes, foo and subclass bar and a generic
function foobar. There exists methods for foobar for both foo and bar that
have the same signature, which differs from the signature in the generic
function (i.e., there are additional arguments in the methods).There are default
values for the additional arguments in the two methods.The method for bar
contains a callNextMethod() statement.
Now calling foobar for an object of class bar with an additional argument
set to a non-defualt value leads to: in the method for bar, the the additional
argument is equal to the input; in the method for foo (i.e., within the
callNextMethod() statement) the additional argument is equal to the default for
that method (i.e., instead of equal to the user input).
This behavior contrasts with my reading of ?callNextMethod which states:
For a formal argument, sayx, that appears in the original call, there is a
corresponding argument in the next method call equivalent tox = x. In effect,
this means that the next method sees the same actual arguments, but arguments
are evaluated only once.
Therefore I would expect the additional argument be passed on by
callNextMethod() as inputted by the user.
Example:
setClass(foo, representation(x = numeric))
setClass(bar, contains = foo)
setGeneric(foobar, function(object, ...) standardGeneric(foobar))
setMethod(foobar, foo, function(object, another.argument = FALSE, ...) {
print(paste(another.argument in foo-method:, another.argument))
object@x
})
setMethod(foobar, bar, function(object, another.argument = FALSE, ...) {
print(paste(another.argument in bar-method:, another.argument))
callNextMethod()
})
o1 - new(bar, x = 4)
foobar(o1, another.argument = TRUE)
[1] another.argument in bar-method: TRUE
[1] another.argument in foo-method: FALSE
[1] 4
Related Issues:
I already asked this question on stackoverflow
(http://stackoverflow.com/q/7190697/289572) and got a helpful answer with
workarounds from Martin Morgan. However, I have the feeling that this may be of
interest here, too.
This problem may or may not be related to the following similar bug reported on
r-devel:
http://thread.gmane.org/gmane.comp.lang.r.devel/23263/focus=23266
Best,
Henrik
PS:
sessionInfo()
R version 2.13.1 (2011-07-08)
Platform: i386-pc-mingw32/i386 (32-bit)
locale:
[1] LC_COLLATE=English_United Kingdom.1252 LC_CTYPE=English_United
Kingdom.1252 LC_MONETARY=English_United Kingdom.1252
[4] LC_NUMERIC=C LC_TIME=English_United
Kingdom.1252
attached base packages:
[1] stats graphics grDevices utils datasets methods base
other attached packages:
[1] fortunes_1.4-2
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] How to safely using OpenMP pragma inside a .C() function?
I have no R API calls inside the parallelized block. I will work on creating a self-contained example and post it for your review. Thanks! -Alireza -- View this message in context: http://r.789695.n4.nabble.com/How-to-safely-use-OpenMP-pragma-inside-a-C-function-tp3777036p3778482.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] sysdata.rda, namespaces and package dependencies
Bump. Any comments on this? Hadley On Tue, Aug 16, 2011 at 10:53 AM, Hadley Wickham had...@rice.edu wrote: Hi all, I'm struggling with accessing a package dataset (munsell.map, stored in sysdata.rda) when that package is imported, not required. A simple reproducible example is: install.packages(munsell) munsell::mnsl(10B 4/6) # Error in match(col, munsell.map$name) : object 'munsell.map' not found library(munsell) munsell::mnsl(10B 4/6) # Function works correctly Am I doing something wrong, or is this namespace bug? Hadley -- Assistant Professor / Dobelman Family Junior Chair Department of Statistics / Rice University http://had.co.nz/ -- Assistant Professor / Dobelman Family Junior Chair Department of Statistics / Rice University http://had.co.nz/ __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] sysdata.rda, namespaces and package dependencies
I struggled with this for a while too, and I have no idea why this data object is unavailable. Finally I found this can do the trick: data(munsell_map, package = munsell) munsell::mnsl(10B 4/6) ## works But I still cannot understand this. Regards, Yihui -- Yihui Xie xieyi...@gmail.com Phone: 515-294-2465 Web: http://yihui.name Department of Statistics, Iowa State University 2215 Snedecor Hall, Ames, IA On Tue, Aug 30, 2011 at 8:27 AM, Hadley Wickham had...@rice.edu wrote: Bump. Any comments on this? Hadley On Tue, Aug 16, 2011 at 10:53 AM, Hadley Wickham had...@rice.edu wrote: Hi all, I'm struggling with accessing a package dataset (munsell.map, stored in sysdata.rda) when that package is imported, not required. A simple reproducible example is: install.packages(munsell) munsell::mnsl(10B 4/6) # Error in match(col, munsell.map$name) : object 'munsell.map' not found library(munsell) munsell::mnsl(10B 4/6) # Function works correctly Am I doing something wrong, or is this namespace bug? Hadley -- Assistant Professor / Dobelman Family Junior Chair Department of Statistics / Rice University http://had.co.nz/ -- Assistant Professor / Dobelman Family Junior Chair Department of Statistics / Rice University http://had.co.nz/ __ 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] sysdata.rda, namespaces and package dependencies
Your package is doing something weird, so I think it's you: you are loading the munsell.map file via load.r in the top level of the package. That's not a standard thing to do, and it's not being executed in the first case. Put that load statement into one of the files in the R directory and things should be fine. I think that's a red-herring - load.r is for development and is never run during usual package installation. Or are you saying I need to explicit load data stored in sysdata.rda within the package? Hadley -- Assistant Professor / Dobelman Family Junior Chair Department of Statistics / Rice University http://had.co.nz/ __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Problems with r-help
I am getting messages like this whenever I try to post to r-help. The message seems to say that the problem is with on the r-help end (the recipient domain). Delivery to the following recipient failed permanently: r-h...@r-project.org Technical details of permanent failure: Google tried to deliver your message, but it was rejected by the recipient domain. We recommend contacting the other email provider for further information about the cause of this error. The error that the other server returned was: 550 550-Callout verification failed: 550 550 5.7.1 Mail from 129.132.202.242 refused - see http://www.orbitrbl.com/ (state 14). -- Statistics Software Consulting GKX Group, GKX Associates Inc. tel: 1-877-GKX-GROUP email: ggrothendieck at gmail.com __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Problems with r-help
On Tue, Aug 30, 2011 at 11:42 AM, Gabor Grothendieck ggrothendi...@gmail.com wrote: I am getting messages like this whenever I try to post to r-help. The message seems to say that the problem is with on the r-help end (the recipient domain). Delivery to the following recipient failed permanently: r-h...@r-project.org Technical details of permanent failure: Google tried to deliver your message, but it was rejected by the recipient domain. We recommend contacting the other email provider for further information about the cause of this error. The error that the other server returned was: 550 550-Callout verification failed: 550 550 5.7.1 Mail from 129.132.202.242 refused - see http://www.orbitrbl.com/ (state 14). It seems this was temporary since I was just able to post a test message and an actual message to r-help. -- Statistics Software Consulting GKX Group, GKX Associates Inc. tel: 1-877-GKX-GROUP email: ggrothendieck at gmail.com __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] How to safely using OpenMP pragma inside a .C() function?
Simon,
I found that files R-2.13.1/src/library/stats/src/distance.c and
R-2.13.1/src/main/array.c have openmp code (example below). I have couple
questions regarding best practices when using R internals and openmp.
Can we use R-2.13.1/src/library/stats/src/distance.c and
R-2.13.1/src/main/array.c as an example how to interact with R code and R
internals?
What are my other options if I want to work with SEXP structures in my
parallel code?
Thank you
Regards
=
#ifdef HAVE_OPENMP
/* This gives a spurious -Wunused-but-set-variable error */
if (R_num_math_threads 0)
nthreads = R_num_math_threads;
else
nthreads = 1; /* for now */
#pragma omp parallel for num_threads(nthreads) default(none) \
private(j, i, ix, rx) \
firstprivate(x, ans, n, p, type, cnt, sum, \
NaRm, keepNA, R_NaReal, R_NaInt, OP)
#endif
for (j = 0; j p; j++) {
switch (type) {
case REALSXP:
rx = REAL(x) + n*j;
if (keepNA)
for (sum = 0., i = 0; i n; i++) sum += *rx++;
else {
for (cnt = 0, sum = 0., i = 0; i n; i++, rx++)
if (!ISNAN(*rx)) {cnt++; sum += *rx;}
else if (keepNA) {sum = NA_REAL; break;}
}
break;
case INTSXP:
ix = INTEGER(x) + n*j;
for (cnt = 0, sum = 0., i = 0; i n; i++, ix++)
if (*ix != NA_INTEGER) {cnt++; sum += *ix;}
else if (keepNA) {sum = NA_REAL; break;}
break;
case LGLSXP:
ix = LOGICAL(x) + n*j;
for (cnt = 0, sum = 0., i = 0; i n; i++, ix++)
if (*ix != NA_LOGICAL) {cnt++; sum += *ix;}
else if (keepNA) {sum = NA_REAL; break;}
break;
default:
/* we checked the type above, but be sure */
UNIMPLEMENTED_TYPEt(do_colsum, type);
}
if (OP == 1) {
if (cnt 0) sum /= cnt; else sum = NA_REAL;
}
REAL(ans)[j] = sum;
}
--
View this message in context:
http://r.789695.n4.nabble.com/How-to-safely-use-OpenMP-pragma-inside-a-C-function-tp3777036p3779214.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] sysdata.rda, namespaces and package dependencies
On 30/08/2011 11:27 AM, Hadley Wickham wrote: Your package is doing something weird, so I think it's you: you are loading the munsell.map file via load.r in the top level of the package. That's not a standard thing to do, and it's not being executed in the first case. Put that load statement into one of the files in the R directory and things should be fine. I think that's a red-herring - load.r is for development and is never run during usual package installation. Or are you saying I need to explicit load data stored in sysdata.rda within the package? Sorry, I didn't realize you weren't executing that file. (Should it be included in the tar? That's a different issue...) Lazy data is stored in a separate file that is loaded when library(munsell) is called. It appears it isn't being loaded when you only use munsell::mnsl to load it but not attach it. Certainly loading it from one of your .R files would work; I'm not sure if it is intentional that this is necessary or not. Perhaps someone else will comment? Duncan Murdoch __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] sysdata.rda, namespaces and package dependencies
On 30.08.2011 18:59, Duncan Murdoch wrote: On 30/08/2011 11:27 AM, Hadley Wickham wrote: Your package is doing something weird, so I think it's you: you are loading the munsell.map file via load.r in the top level of the package. That's not a standard thing to do, and it's not being executed in the first case. Put that load statement into one of the files in the R directory and things should be fine. I think that's a red-herring - load.r is for development and is never run during usual package installation. Or are you saying I need to explicit load data stored in sysdata.rda within the package? Sorry, I didn't realize you weren't executing that file. (Should it be included in the tar? That's a different issue...) Lazy data is stored in a separate file that is loaded when library(munsell) is called. It appears it isn't being loaded when you only use munsell::mnsl to load it but not attach it. Certainly loading it from one of your .R files would work; I'm not sure if it is intentional that this is necessary or not. Perhaps someone else will comment? This is expected. The data object is not exported from the Namespace and hence not loaded if a reference to the Namespace is made without *attaching* the package. Hence data(..., package=...) is the way to go. Uwe Duncan Murdoch __ 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] Non-GPL C (or R) inside of a package
R-devel,
I am interested in creating a package that requires non-GPL'd (commercial) C
code to work. In essence it is a single .c file with no use of R headers
(all .C callable functions). For example's sake:
1 #include stdio.h
2
3 void test (int *a) {
4 *a = 101;
5 }
The package isn't destined for CRAN, and I realize that this isn't R-legal,
but looking for some expert advice from anyone else who may have encountered
this previously.
The question is whether or not one can distribute code that has multiple
licenses (.c or individual .R files), including some that are not
GPL-compatible, as a tar.gz (or binary) file. i.e., does the packaging
process [R CMD ***] cause everything to become GPL, as we are using R itself
to build the package?
I can of course provide the C libs in this case as a separate install, but
that adds complexity to the overall build and install process.
Thanks,
Jeff
--
Jeffrey Ryan
jeffrey.r...@lemnica.com
www.lemnica.com
www.esotericR.com
[[alternative HTML version deleted]]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] sysdata.rda, namespaces and package dependencies
Lazy data is stored in a separate file that is loaded when library(munsell) is called. It appears it isn't being loaded when you only use munsell::mnsl to load it but not attach it. Certainly loading it from one of your .R files would work; I'm not sure if it is intentional that this is necessary or not. Perhaps someone else will comment? This is expected. The data object is not exported from the Namespace and hence not loaded if a reference to the Namespace is made without *attaching* the package. Hence data(..., package=...) is the way to go. So how should I include package local data? The dataset is only used internally by munsell functions (it's basically a big lookup table) and should not be available to the user - i.e. it should not be exported. This, I thought, was the purpose of sysdata.rda. Hadley -- Assistant Professor / Dobelman Family Junior Chair Department of Statistics / Rice University http://had.co.nz/ __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] sysdata.rda, namespaces and package dependencies
On 30.08.2011 19:52, Hadley Wickham wrote: Lazy data is stored in a separate file that is loaded when library(munsell) is called. It appears it isn't being loaded when you only use munsell::mnsl to load it but not attach it. Certainly loading it from one of your .R files would work; I'm not sure if it is intentional that this is necessary or not. Perhaps someone else will comment? This is expected. The data object is not exported from the Namespace and hence not loaded if a reference to the Namespace is made without *attaching* the package. Hence data(..., package=...) is the way to go. So how should I include package local data? The dataset is only used internally by munsell functions (it's basically a big lookup table) and should not be available to the user - i.e. it should not be exported. This, I thought, was the purpose of sysdata.rda. Hadley A Now I understand you are referring to the special name sysdata.rda that is not to be loaded via data() - I thought you were talking about the regular data including process. That works fine for me as well and then this special data are available when the Namespace is loaded already. Have you put that file into package/R rather than package/data? Which R version? Uwe __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Non-GPL C (or R) inside of a package
On 30/08/2011 1:50 PM, Jeffrey Ryan wrote:
R-devel,
I am interested in creating a package that requires non-GPL'd (commercial) C
code to work. In essence it is a single .c file with no use of R headers
(all .C callable functions). For example's sake:
1 #includestdio.h
2
3 void test (int *a) {
4 *a = 101;
5 }
The package isn't destined for CRAN, and I realize that this isn't R-legal,
but looking for some expert advice from anyone else who may have encountered
this previously.
The question is whether or not one can distribute code that has multiple
licenses (.c or individual .R files), including some that are not
GPL-compatible, as a tar.gz (or binary) file. i.e., does the packaging
process [R CMD ***] cause everything to become GPL, as we are using R itself
to build the package?
I can only say that the answer to the last question is no: the author
gets to choose the license for what s/he wrote. The fact that you used
R to package it is irrelevant. (Some extremists will disagree, and say
that because your package is intended to link to R, it must be
licensed compatibly with the GPL if you distribute it. I don't think
that's true.)
If you are intending to distribute this file you are putting together,
you'll probably want to consult someone who knows the legalities as to
whether you can legally link to the commercial library...
Duncan Murdoch
I can of course provide the C libs in this case as a separate install, but
that adds complexity to the overall build and install process.
Thanks,
Jeff
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Non-GPL C (or R) inside of a package
On Tue, 30 Aug 2011, Duncan Murdoch wrote:
On 30/08/2011 1:50 PM, Jeffrey Ryan wrote:
R-devel,
I am interested in creating a package that requires non-GPL'd
(commercial) C code to work. In essence it is a single .c file
with no use of R headers (all .C callable functions). For
example's sake:
1 #includestdio.h
2
3 void test (int *a) {
4 *a = 101;
5 }
The package isn't destined for CRAN, and I realize that this isn't
R-legal, but looking for some expert advice from anyone else who
may have encountered this previously.
The question is whether or not one can distribute code that has
multiple licenses (.c or individual .R files), including some that
are not GPL-compatible, as a tar.gz (or binary) file. i.e., does
the packaging process [R CMD ***] cause everything to become GPL,
as we are using R itself to build the package?
I can only say that the answer to the last question is no: the author gets
to choose the license for what s/he wrote. The fact that you used R to
package it is irrelevant. (Some extremists will disagree, and say that
because your package is intended to link to R, it must be licensed
compatibly with the GPL if you distribute it. I don't think that's true.)
If no distribution is involved, the conditions under which the tarball
can be distributed is not relevant.
As e.g. GNU tar is itself under GPL, using R to do the packaging is no
different in principle to using GNU tar to do so and I've never heard
anyone argue that using GNU tar affects the licence of the tarball.
I don't think that is the same issue as distributing non-GPLed code
for use with R. In the latter case the issue is what 'link to'
actually entails, and one source of advice is the GPL FAQs. E.g.
http://www.gnu.org/licenses/old-licenses/gpl-2.0-faq.html
http://www.gnu.org/licenses/gpl-faq.html
If you are intending to distribute this file you are putting together, you'll
probably want to consult someone who knows the legalities as to whether you
can legally link to the commercial library...
Duncan Murdoch
I can of course provide the C libs in this case as a separate install, but
that adds complexity to the overall build and install process.
Thanks,
Jeff
__
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
Re: [Rd] Out-of-date manual or small bug in R CMD check?
-Original Message-
From: r-devel-boun...@r-project.org [mailto:r-devel-boun...@r-project.org] On
Behalf Of Duncan Murdoch
Sent: Monday, August 29, 2011 5:30 PM
To: Gabriel Becker
Cc: r-devel@r-project.org
Subject: Re: [Rd] Out-of-date manual or small bug in R CMD check?
On 11-08-29 6:37 PM, Gabriel Becker wrote:
Hey all,
I get a warning about an unsupported file type in the data directory during
R CMD check (for R 2.13.1) if I use the save function to create an Rdata,
but if I save the same object to a .rda file, no warning.
Section 1.1.5 (pg 11 of the pdf) of the Writing R Extensions manual (2.13.1)
appears to say that .Rdata files should be fine:
Data files can have one of three types as indicated by their extension:
plain R code ('.R' or
'.r'), tables ('.tab', '.txt', or '.csv', see ?data for the file formats,
and note that '.csv' is not
the standard14 CSV format), or save() images ('.RData' or '.rda').
Am I misunderstanding some difference between .rda and .Rdata files in terms
of the save calls, or should R CMD check and the extensions manual agree on
this?
.RData and .Rdata aren't the same.
Should that paragraph say that capitalization matters and that the following
file name extensions are recognized
TXT
txt
CSV
csv
tab
r
R
rdata
RData
rda
(and that others that vary only by case, such as TAB, Rdata and Rda, are not)?
Bill Dunlap
Spotfire, TIBCO Software
wdunlap tibco.com
Duncan Murdoch
Thanks for all your hard work.
~G
SessionInfo:
R version 2.13.1 (2011-07-08)
Platform: x86_64-pc-linux-gnu (64-bit)
locale:
[1] LC_CTYPE=en_US.utf8 LC_NUMERIC=C
[3] LC_TIME=en_US.utf8LC_COLLATE=en_US.utf8
[5] LC_MONETARY=C LC_MESSAGES=en_US.utf8
[7] LC_PAPER=en_US.utf8 LC_NAME=C
[9] LC_ADDRESS=C LC_TELEPHONE=C
[11] LC_MEASUREMENT=en_US.utf8 LC_IDENTIFICATION=C
attached base packages:
[1] grid stats graphics grDevices utils datasets methods
[8] base
other attached packages:
[1] gridSVG_0.5-10 ProteinVis_0.4 latticeExtra_0.6-18
[4] RColorBrewer_1.0-2 lattice_0.19-33
__
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] Possible to read R_StringHash from a package?
Is there any way to look at R_StringHash from a package? I've read R-Ints 1.16.1 Hiding C entry points and seen that R_StringHash is declared as extern0 in Defn.h. So it seems the answer is no. Thanks, Matthew __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] sysdata.rda, namespaces and package dependencies
That works fine for me as well and then this special data are available when the Namespace is loaded already. Have you put that file into package/R rather than package/data? Which R version? Yes, sysdata.rda is in package/R - source code available here: https://github.com/cwickham/munsell/tree/master/R I'm running 2.13.1 (on a mac) Hadley -- Assistant Professor / Dobelman Family Junior Chair Department of Statistics / Rice University http://had.co.nz/ __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
