Re: [Rd] Improved Function Information with Key
On Wed, Oct 7, 2009 at 5:56 AM, Lee Kelvin wrote:
> Hello,
>
> Pressing the key when typing a function into an R terminal does not
> produce the expected output. Currently, R will order all of the available
> function inputs into alphabetical order and present them as options, whereas
> it should display the inputs in the order they appear in the function.
>
> For example:
>
>> test = function(b,a,c){
> print(b)
> a*c
> }
>
>> test(
> a= b= c=
>
> where indicates pressing the Tab key.
>
> It's easy to see that if the function were designed to accept 'b' as a
> string, and 'a' and 'c' as numerics that this function would fail if the
> user made the assumption that the output is in the correct order, and
> input 'a' as a string.
>
> This is a simple example, however I have several functions that I use often
> and each has many possible inputs. It would be useful to not have to
> remember the order the inputs are in for each function, or have to use
> args(function) beforehand. It is also on occasion useful not to have to
> explicitly name each input in your function.
>
> Im using Ubuntu Linux 9.04 and a standard install of R 2.9.2 (unfortunately
> not the polished R.app available on Macs - which coincidentally do display
> function inputs in the correct order).
>
> I welcome any thoughts, disagreements or tips any of you may have,
The sorting is a feature of the readline library that is used as the
backend (there is no sorting on the Windows GUI). Apparently readline
6 allows you to inhibit sorting, so that might turn out to be useful.
-Deepayan
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] (PR#13957) Reading clipboard with read.delim("clipboard") crash
I am having some trouble reproducing this (an example of 3000 rows and
7 columns worked for me, and one of 18000 rows stresses the window
manager so it works slowly if at all).
But AFAICS you are trying to give your window manager too much data,
and the XGetWindowProperty call to determine the size is failing. R
had no code to catch that possibility, and now I've added some I can
no longer provoke a crash: but as expected you get the result
dat <- read.delim('clipboard')
Error in file(file, "r") : cannot open the connection
In addition: Warning message:
In file(file, "r") : clipboard cannot be opened or contains no text
(sometimes after a wait of more than a minute).
So even if it were somehow possible to pass 1Mb of data via an X11
clipboard, it looks as if it would be too slow to be useful.
On Fri, 18 Sep 2009, liam.gret...@leicester.ac.uk wrote:
Full_Name: Liam Gretton
Version: 2.9.2
OS: openSUSE 11.1 (x86_64)
Submission from: (NULL) (143.210.13.77)
Reading a large number of rows of delimited data via the clipboard results in a
segfault or double free error. I've tested copying from various applications,
but gedit will do.
This problem exists in the openSUSE-supplied 2.8.1, I've just built 2.9.2 to see
if it's still there, and it is.
I can provide an example delimited file which demonstrates the problem; it
contains about 18000 rows and 7 columns of data. read.delim("clipboard") tends
to fail when only reading ~1500 rows, though I haven't been able to reproduce
the point at which it fails.
Reading exactly the same data from a file using read.csv("file.csv") is
successful.
Problem reproduced as so:
Data copied to the clipboard in Gnome.
R
R version 2.9.2 (2009-08-24)
[snip]
data <- read.delim("clipboard")
*** caught segfault ***
address 0x18, cause 'memory not mapped'
Traceback:
1: file(file, "r")
2: read.table(file = file, header = header, sep = sep, quote = quote, dec =
dec, fill = fill, comment.char = comment.char, ...)
3: read.delim("clipboard")
Possible actions:
1: abort (with core dump, if enabled)
2: normal R exit
3: exit R without saving workspace
4: exit R saving workspace
On a different (but similar) openSUSE 11.1 system, the command still fails but
reports:
*** glibc detected *** /usr/local/R-2.9.2/lib64/R/bin/exec/R: double free of
corruption (!prev): 0x0097cb70 ***
Details of R build:
./configure --prefix=/usr/local/R-2.9.2 --enable-R-shlib --enable-mbcs
--enable-threads=posix --with-blas --with-lapack --with-system-zlib
--with-system-bzlib --with-system-pcre --with-gnu-ld
No additional packages installed. 'make check' passed.
__
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] compiling packages without Framework and CoreFoundation options on OSX
Jeff,
On Oct 7, 2009, at 18:48 , Jeff Hamann wrote:
I've been trying to get R+PostgreSQL+PL/R to work together on a OSX
machine without the Framework and CoreFoundation options and have
noticed some suspicious switches when compiling packages.
I've installed R (on OSX) with the following ./configure:
./configure \
CC="gcc -arch i386" \
CXX="g++ -arch i386" \
OBJC="gcc -arch i386" \
F77="gfortran -arch i386" \
FC="gfortran -arch i386" \
--enable-R-framework=no \
--enable-R-shlib \
--without-blas \
--x-includes=/usr/X11/include \
--x-libraries=/usr/X11/lib
Notice the
--enable-R-framework=no \
--enable-R-shlib \
No flames please.I'm sure I'm breaking lot's of R purist-isms.
There's a bigger picture here than trying to get R and packages to
build by themselves.
When I build packages, using sudo R, for example:
install.packages(c("rconifers"),
+ lib="/usr/local/lib/R/library",
+ repos="http://cran.r-project.org";,
+ dependencies=TRUE )
the package seems to get built with the "-Wl,-framework -
Wl,CoreFoundation" switches, even when R isn't built with the
framework (and CoreFoundation) options.
You're confusing entirely different things here - "-Wl,-framework -
Wl,CoreFoundation" is simply a safe form of "-framework
CoreFoundation" which means that R uses the CoreFoundation framework
which is part of OS X. It has nothing to do with the --enable-R-
framework option which is about creating *R* as a framework.
For example:
gcc -arch i386 -std=gnu99 -dynamiclib -Wl,-headerpad_max_install_names
-undefined dynamic_lookup -single_module -multiply_defined suppress -
L/
usr/local/lib -o rconifers.so coeffs.o file_io.o grow.o mortality.o
plot.o rconifers.o sample.o smc_coeffs.o smc_model.o stats.o
swo_coeffs.o swo_model.o thin.o -L/usr/local/lib/R/lib -lR -Wl,-
framework -Wl,CoreFoundation
Note the "-lR" which is caused by --enable-R-framework=no, in the
normal R on OS X you'd have seen "-framework R" instead.
I would like to build packages without the "-Wl,-framework -
Wl,CoreFoundation" options because I'm going to install it on other OS
(FreeBSD, Linux, whatever)
If you install it on other OS, you'll get entirely different switches,
of course. CF is needed on OS X for certain OS-specific functionality
such as locales support, Quartz graphics etc.
Clearly, a binary is specific for given OS, so you have to build a
binary of your package for each single OS you want to support in
binary form (with different switches each time).
Does this cause a problem? Will this cause a problem? I'm guessing
the CoreFoundations are an artifact of the XCode compiler.
"XCode compiler" is gcc, so, no.
What's with the -Wl,-framework stuff?
It's roughly the same as -l but it's more powerful as it covers
umbrellas, resources etc. You may want to read more about frameworks:
http://developer.apple.com/mac/library/documentation/MacOSX/Conceptual/BPFrameworks/Frameworks.html
Can I make it stop?
Not really without hacking R.
Will I be okay?
I have the suspicion that you're heading in a very wrong direction
(but you didn't tell us what you're really up to so that's just a
speculation). It should be entirely irrelevant for you what switches
are used, because packages get all necessary switches from R, so they
never need to worry about them. If you do, then it's highly likely
that you're doing something wrong.
Cheers,
Simon
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] [not extremely urgent:] modifiying messages on overriding implicit S4 generics + intended maskings
Hi r-devels,
I am coming with an RFE which is probably not extremely
urgent, dealing with (optionally) modifiying messages
on overriding implicit S4 generics + intended maskings
according to some (optional) pkg-individual files.
Details are shown below.
Any comments welcome,
Best, Peter
=
An aside right away:
For functions with many arguments, would it
be a bad idea to propose to make the implicit
S4 generic dispatch on less arguments (say the
first 2-3)?
=
DETAILS:
%
Overriding default S4 generic
%
In our distr-family of packages, we are about
to write S4 methods for qqplot for several
(mostly distribution-type) signatures.
In order to avoid to have to dispatch on too many
arguments, we would like to use the following generic
setGeneric("qqplot", function(x, y, ...) standardGeneric("qqplot"))
while we would register the original qqplot function from
package stats as
setMethod("qqplot", signature(x="ANY",y="ANY"), function(x, y,
plot.it = TRUE, xlab = deparse(substitute(x)),
ylab = deparse(substitute(y)), ...){
mc <- match.call(call = sys.call(sys.parent(1)))
if(missing(xlab)) mc$xlab <- xlab
if(missing(ylab)) mc$ylab <- ylab
mcl <- as.list(mc)[-1]
return(invisible(
do.call(stats::qqplot, args=mcl)))
})
which should behave exactly the same as the original
stats function when called as usual.
Now doing so, on installing and building our package,
the following message is displayed:
Creating a generic for "qqplot" in package "distr"
(the supplied definition differs from and overrides
the implicit generic in package "stats": Formal
arguments differ: (x, y, ...), (x, y, plot.it,
xlab, ylab, ...))
I would not bother too much about this message
(which /is/ a useful information for the package
developer anyway!), but it might irritate some users
to see this.
%
intended maskings
%
For similar reasons, in our packages we intentionally
mask some (few!) functions from packages stats and base.
In each case, we try to retain their original behaviour
when called as usual (and, AFAICS, they do so), and
also document this masking in corresponding files
MASKING in the inst/ folders.
Again, this masking gets automatically noticed as
a message on attaching the packages
(which again /is/ a useful information, anyway!).
%
proposed solution
%
So, for avoiding/modifying these automatic messages
on building/installing/attaching a package, could we
have optional parsable ASCII files, say
INT_MASKING, INT_OVERR_IMPL_GENERICS
(INT for /int/entional)
or, equally well, something shorter:-) in the inst
folder of a package, which are looked up and then
a correspondingly marked section would be
displayed instead of the original message?
A suggestion for the format of these files could
be:
Two blocks, each braced by some lines beginning
with "###":
+ the first one with a list of intentionally
masked objects / overridden implicit generics,
+ the second one with a corresponding optional
message to be displayed on build/install/attach
instead of the original one (this second block
could be left empty).
The format for the list in the first block could
be: one object a line, in form ::.
In addition lines beginning with ";" would be
ignored (used as comment lines).
Example:
### begin object list
stats::qqplot
stats::df
### end object list
### begin displayed message
We intentionally mask stats functions qqplot and df,
because we have particular methods for them for
distribution-type arguments
### end displayed message
Now, each object mentioned in the first block, would no
longer be displayed within the default message on
build/install/attach (while masked objects / overridden implicit
generics remaining unmatched still do get displayed this
way).
In addition, unless the section in the corresponding
second block is empty, this section would be displayed
after the (again possibly empty) default message,
perhaps prepended by a title like "Intentional Masking"
respectively "Intentionally overridden implicit
generics".
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Improved Function Information with Key
Thanks for the responses,
Im not familiar with the development of readline 6, is it possible to test
this functionality now, or will this be included in a future standard
release of R?
Also, it was suggested that Emacs and the ESS package may be of use. Im not
overly familiar with emacs, but I will give it a go.
Thanks,
Lee Kelvin
2009/10/8 Deepayan Sarkar
> On Wed, Oct 7, 2009 at 5:56 AM, Lee Kelvin wrote:
> > Hello,
> >
> > Pressing the key when typing a function into an R terminal does not
> > produce the expected output. Currently, R will order all of the
> available
> > function inputs into alphabetical order and present them as options,
> whereas
> > it should display the inputs in the order they appear in the function.
> >
> > For example:
> >
> >> test = function(b,a,c){
> > print(b)
> > a*c
> > }
> >
> >> test(
> > a= b= c=
> >
> > where indicates pressing the Tab key.
> >
> > It's easy to see that if the function were designed to accept 'b' as a
> > string, and 'a' and 'c' as numerics that this function would fail if the
> > user made the assumption that the output is in the correct order,
> and
> > input 'a' as a string.
> >
> > This is a simple example, however I have several functions that I use
> often
> > and each has many possible inputs. It would be useful to not have to
> > remember the order the inputs are in for each function, or have to use
> > args(function) beforehand. It is also on occasion useful not to have to
> > explicitly name each input in your function.
> >
> > Im using Ubuntu Linux 9.04 and a standard install of R 2.9.2
> (unfortunately
> > not the polished R.app available on Macs - which coincidentally do
> display
> > function inputs in the correct order).
> >
> > I welcome any thoughts, disagreements or tips any of you may have,
>
> The sorting is a feature of the readline library that is used as the
> backend (there is no sorting on the Windows GUI). Apparently readline
> 6 allows you to inhibit sorting, so that might turn out to be useful.
>
> -Deepayan
>
--
Lee Kelvin
lee.s.kel...@gmail.com
07765431721
[[alternative HTML version deleted]]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] bug inside plot.lm (PR#13989)
The function
getCaption <- function(k) as.graphicsAnnot(unlist(caption[k]))
inside plot.lm in R-2.9.2 and R-2.10.0alpha loses the expression
for caption 6. From a recover() inside the function
Browse[1]> caption[6]
[[1]]
expression("Cook's dist vs Leverage " * h[ii]/(1 - h[ii]))
Browse[1]> caption[[6]]
expression("Cook's dist vs Leverage " * h[ii]/(1 - h[ii]))
Browse[1]> getCaption(6)
[[1]]
"Cook's dist vs Leverage " * h[ii]/(1 - h[ii])
Browse[1]> as.graphicsAnnot(caption[[6]])
expression("Cook's dist vs Leverage " * h[ii]/(1 - h[ii]))
The repair seems to be to redefine getCaption as follows
Browse[1]> getCaption <- function(k) as.graphicsAnnot(caption[[k]])
Browse[1]> getCaption(6)
expression("Cook's dist vs Leverage " * h[ii]/(1 - h[ii]))
Browse[1]>
Rich
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] R_CallMethodDef: 'type' and 'style' fields?
According to Writing R Extensions, the R_CallMethodDef struct has two optional fields for specifying the 'type' and 'style' (where 'style' is said to distinguish in/out/inout). But it gives no details of the possible values of 'style'. And looking in the header file Rdynload.h the definition of R_CallMethodDef does not include these two extra fields at all. (This is the 2.9.2 source) Were these extra fields removed at some point? -- View this message in context: http://www.nabble.com/R_CallMethodDef%3A-%27type%27-and-%27style%27-fields--tp25803271p25803271.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
[Rd] R_CallMethodDef: 'type' and 'style' fields?
In Writing R Extensions it is said that R_CallMethodDef has two optional fields, 'type' and 'style' (where 'style' is said to distinguish in/out/inout arguments). But it doesn't give the possible values for 'style'. Looking at the header Rdynload.h (version 2.9.2) it appears that R_CallMethodDef does not have these extra two fields. Were they removed at some point? If so, what is the best way to call a C function without the overhead of copying the inputs? Thanks -- View this message in context: http://www.nabble.com/R_CallMethodDef%3A-%27type%27-and-%27style%27-fields--tp25803313p25803313.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] Improved Function Information with Key
On Thu, Oct 8, 2009 at 5:33 AM, Lee Kelvin wrote:
> Thanks for the responses,
>
> Im not familiar with the development of readline 6, is it possible to test
> this functionality now, or will this be included in a future standard
> release of R?
I don't think it's possible to test it now (but I can't say for sure
as I don't have readline 6 installed and haven't read the
documentation carefully). In theory, some future release should
include a check for readline>=6 and disable sorting, but I'm not sure
when or if that will happen in practice.
> Also, it was suggested that Emacs and the ESS package may be of use. Im not
> overly familiar with emacs, but I will give it a go.
As far as I can tell, Emacs' completion system also sorts, and I don't
see a way to inhibit that. ESS does show you the results of args()
when you type an open paren after a function name, which should be
useful for you.
-Deepayan
>
> Thanks,
> Lee Kelvin
>
>
> 2009/10/8 Deepayan Sarkar
>>
>> On Wed, Oct 7, 2009 at 5:56 AM, Lee Kelvin wrote:
>> > Hello,
>> >
>> > Pressing the key when typing a function into an R terminal does
>> > not
>> > produce the expected output. Currently, R will order all of the
>> > available
>> > function inputs into alphabetical order and present them as options,
>> > whereas
>> > it should display the inputs in the order they appear in the function.
>> >
>> > For example:
>> >
>> >> test = function(b,a,c){
>> > print(b)
>> > a*c
>> > }
>> >
>> >> test(
>> > a= b= c=
>> >
>> > where indicates pressing the Tab key.
>> >
>> > It's easy to see that if the function were designed to accept 'b' as a
>> > string, and 'a' and 'c' as numerics that this function would fail if the
>> > user made the assumption that the output is in the correct order,
>> > and
>> > input 'a' as a string.
>> >
>> > This is a simple example, however I have several functions that I use
>> > often
>> > and each has many possible inputs. It would be useful to not have to
>> > remember the order the inputs are in for each function, or have to use
>> > args(function) beforehand. It is also on occasion useful not to have to
>> > explicitly name each input in your function.
>> >
>> > Im using Ubuntu Linux 9.04 and a standard install of R 2.9.2
>> > (unfortunately
>> > not the polished R.app available on Macs - which coincidentally do
>> > display
>> > function inputs in the correct order).
>> >
>> > I welcome any thoughts, disagreements or tips any of you may have,
>>
>> The sorting is a feature of the readline library that is used as the
>> backend (there is no sorting on the Windows GUI). Apparently readline
>> 6 allows you to inhibit sorting, so that might turn out to be useful.
>>
>> -Deepayan
>
>
>
> --
> Lee Kelvin
>
> lee.s.kel...@gmail.com
> 07765431721
>
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] R-10 alpha windows() bug?
I have been compiling patched and development versions of R regularly. I started compiling R-10.0 alpha a couple of days ago and I think I discovered a bug in the "windows()" command. Here is what is happening:. 1. Just compiled the latest tarball. Before doing this I updated the R-tools to version 2.10 (includes jpeg-7). 2. Compilation went fine and I successfully built and ran the Windows installer. 3. I also successfully ran "make check-all". 4. I start R GUI and do "plot(1:10)". Here is what I get: 5. When I go to File>Save As>Png... and go through the dialog box (choosing a file name) I get the following GUI error: 6. When, before saving, I resize the graphics window with my mouse even by a very small amount, the plot changes to its normal look (without missing axes of plot.png) and I can save it with no problem. 7. When I do the same thing in just compiled 2.9.2 everything works fine and the plot (plot.png above) looks fine. 8. I suppose, all this is related to the following result of the "windows()" command: Again, resizing this window even slightly, fixes the problem. I am on the Windows XP SP2 machine. Here is the output of R.version: > R.version _ platform i386-pc-mingw32 arch i386 os mingw32 system i386, mingw32 status alpha major 2 minor 10.0 year 2009 month 10 day07 svn rev49971 language R version.string R version 2.10.0 alpha (2009-10-07 r49971) Regards, Andy __ Andy Jaworski 518-1-01 Process Laboratory 3M Corporate Research Laboratory - E-mail: apjawor...@mmm.com Tel: (651) 733-6092 Fax: (651) 736-3122__ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] how to document stuff most users don't want to see
On Mon, Oct 05, 2009 at 02:03:51PM -0400, Duncan Murdoch wrote:
> On 10/5/2009 1:50 PM, Charles Geyer wrote:
> >The functions metrop and temper in the mcmc package have a debug = FALSE
> >argument that when TRUE adds a lot of debugging information to the returned
> >list. This is absolutely necessary to test the functions, because one
> >generally knows nothing about the simulated distribution except what what
> >one learns from MCMC samples. Hence you must expose all details of the
> >simulation to have any hope of checking that it is doing what it is
> >supposed
> >to do. However, this information is of interested mostly (perhaps solely)
> >to developers. So I didn't document it in the Rd files for these
> >functions.
> >
> >But it has ocurred to me that people might be interested in how these
> >functions
> >are validated, and I would like to document the debug output somewhere,
> >but I
> >don't want to clutter up the documentation that ordinary users see. That
> >suggests a separate help page for debugging. Looking at "Writing R
> >Extensions"
> >it doesn't seem like there is a type of Rd file for this purpose. I
> >suppose
> >it could be added in (fairly long) sections titled "Debug Output" in
> >metrop.Rd
> >and temper.Rd or it could be put in a package help page (although that's
> >not
> >what that kind of page is really for). Any other possibilities to
> >consider?
>
> I think writing it up in a vignette would probably be most appropriate.
> You can link directly to a vignette from a man page (though not,
> unfortunately, vice versa). For example, if you look at
> package?grid, you'll see a list that was generated by this code:
>
> Further information is available in the following
> \link{vignettes}:
> \tabular{ll}{
> \code{grid} \tab Introduction to \code{grid} (\url{../doc/grid.pdf})\cr
> \code{displaylist} \tab Display Lists in \code{grid}
> (\url{../doc/displaylist.pdf})\cr
So I decided to follow your advice mcmc_0.7-3.tar.gz just uploaded to CRAN
has such a vignette and such links in the appropriate Rd files.
Thanks
--
Charles Geyer
Professor, School of Statistics
University of Minnesota
char...@stat.umn.edu
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] R-10 alpha windows() bug?
This is my third attempt to send this message. Hopefully this one will go through. If anybody got my previous attempts (one with 3 attached PNG files and one with graph embedded in the message) I apologize for multiple postings. I tried to illustrate this possible bug by including screenshots but it seems that these posts get blocked by something (r-devel-bounce?). Below I try to describe what happens in words. I have been compiling patched and development versions of R regularly. I started compiling R-10.0 alpha a couple of days ago and I think I discovered a bug in the "windows()" command. Here is what is happening:. 1. Just compiled the latest tarball. Before doing this I updated the R-tools to version 2.10 (includes jpeg-7). 2. Compilation went fine and I successfully built and ran the Windows installer. 3. I also successfully ran "make check-all". 4. I start R GUI and do "plot(1:10)". Here is what I get: The plot is missing bottom and right-hand side (both the axis and part of the box). The bottom is missing up to the third dot on the plot, i.e., the x-axis is missing together with the first three points. 5. When I go to File>Save As>Png... and go through the dialog box (choosing a file name) I get the following GUI error: A window pops up saying: "R for Windows GUI has encountered a problem and needs to close. We are sorry for the inconvenience". Closing this window causes R to crash. 6. When, before saving, I resize the graphics window with my mouse even by a very small amount, the plot changes to its normal look (without missing axes of plot.png) and I can save it with no problem. 7. When I do the same thing in just compiled 2.9.2 everything works fine and the plot (plot.png above) looks fine. 8. I suppose, all this is related to the following result of the "windows()" command: I get a window with the upper left chunk of it being dark gray and the remaining part, i.e., the bottom and the right-hand side being white. The white portions correspond to the missing parts of the plot described in 4. Again, resizing this window even slightly, fixes the problem - the whole window becomes dark gray. I am on the Windows XP SP2 machine. Here is the output of R.version: > R.version _ platform i386-pc-mingw32 arch i386 os mingw32 system i386, mingw32 status alpha major 2 minor 10.0 year 2009 month 10 day07 svn rev49971 language R version.string R version 2.10.0 alpha (2009-10-07 r49971) Regards, Andy __ Andy Jaworski 518-1-01 Process Laboratory 3M Corporate Research Laboratory - E-mail: apjawor...@mmm.com Tel: (651) 733-6092 Fax: (651) 736-3122 [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Make error, fails to install base packages (e.g., 'method')
I am trying to build R-2.9.2 from source on a Slax Linux distribution. The only warnings from configure related to the production of the html. However, a series of errors occurs at the end of 'make': --- make[2]: Entering directory `/root/Desktop/Rbin/src/library' mkdir -p -- ../../library make[3]: Entering directory `/root/Desktop/Rbin/src/library/profile' building system startup profile mkdir -p -- ../../../library/base/R make[3]: Leaving directory `/root/Desktop/Rbin/src/library/profile' make[3]: Entering directory `/root/Desktop/Rbin/src/library/base' building package 'base' make[4]: Entering directory `/root/Desktop/Rbin/src/library/base' mkdir -p -- ../../../library/base/demo mkdir -p -- ../../../library/base/po make[4]: *** [mkpo] Error 1 make[4]: Leaving directory `/root/Desktop/Rbin/src/library/base' make[3]: *** [all] Error 2 make[3]: Leaving directory `/root/Desktop/Rbin/src/library/base' make[2]: *** [R] Error 1 make[2]: Leaving directory `/root/Desktop/Rbin/src/library' make[1]: *** [R] Error 1 make[1]: Leaving directory `/root/Desktop/Rbin/src' make: *** [R] Error 1 -- I couldn't find other examples of the errors on a search. Running R produces: --- r...@slax:~/Desktop/Rbin/bin# ./R Error in library(package, lib.loc = lib.loc, character.only = TRUE, logical.return = TRUE, : 'methods' is not a valid installed package R version 2.11.0 Under development (unstable) (2009-10-06 r49948) Copyright (C) 2009 The R Foundation for Statistical Computing ISBN 3-900051-07-0 R is free software and comes with ABSOLUTELY NO WARRANTY. You are welcome to redistribute it under certain conditions. Type 'license()' or 'licence()' for distribution details. R is a collaborative project with many contributors. Type 'contributors()' for more information and 'citation()' on how to cite R or R packages in publications. Type 'demo()' for some demos, 'help()' for on-line help, or 'help.start()' for an HTML browser interface to help. Type 'q()' to quit R. Error in library(package, lib.loc = lib.loc, character.only = TRUE, logical.return = TRUE, : 'datasets' is not a valid installed package --- I am a neophyte, but if someone could point me in the right direction, I would be grateful. Daniel __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R_CallMethodDef: 'type' and 'style' fields?
Steve Jaffe wrote:
> In Writing R Extensions it is said that R_CallMethodDef has two optional
> fields, 'type' and 'style' (where 'style' is said to distinguish
> in/out/inout arguments).
Can you point us to the particular section and line that says
this. I think it is for the R_CMethodDef structure, not the
R_CallMethodDef.
Indeed, in Rdynload.h
typedef enum {R_ARG_IN, R_ARG_OUT, R_ARG_IN_OUT, R_IRRELEVANT} R_NativeArgStyle;
/*
These are very similar to those in unix/dynload.c
but we maintain them separately to give us more freedom to do
some computations on the internal versions that are derived from
these definitions.
*/
typedef struct {
const char *name;
DL_FUNC fun;
int numArgs;
R_NativePrimitiveArgType *types;
R_NativeArgStyle *styles;
} R_CMethodDef;
> But it doesn't give the possible values for
> 'style'.
The enum above does.
The types is described in the help file for .C or .Call, i.e.
?.C
> Looking at the header Rdynload.h (version 2.9.2) it appears that
> R_CallMethodDef does not have these extra two fields.
See above.
>
> Were they removed at some point? If so, what is the best way to call a C
> function without the overhead of copying the inputs?
The .Call() interface does not copy the R objects that it passes to the
C routine which accepts SEXP type objects (and returns a SEXP object also).
D.
>
> Thanks
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
