Re: [Rd] (PR#11537) help (using ?) does not handle trailing whitespace
> "BDR" == Prof Brian Ripley <[EMAIL PROTECTED]>
> on Fri, 30 May 2008 22:34:28 +0100 (BST) writes:
BDR> I think it is ESS that is parsing this as a help
BDR> request (so it can divert it to an ESS buffer).
BDR> Looks like this is an ESS issue, not an R one.
yes, indeed, hence much more belonging the ESS-help mailing
list (or the 'ESS-bugs' e-mail alias).
I'm diverting to that list; please keep follow-ups to this
topic off R-devel.
As most ESS users are aware, ESS is "picking up"
?<...> calls, and indeed then calls help() for these.
In R, '?' has become different from help() more and more,
and it is currently the most urgent open issue in ESS,
that ESS should become much smarter in dealing with '?', the
various 'type ? topic' version and new '??', etc.
Martin Maechler, ETH Zurich
BDR> Using ?"agrep " will fail in R, but that seems correct as there is no
BDR> topic "agrep ".
BDR> On Fri, 30 May 2008, Tim Hesterberg wrote:
>> By whitespace, I mean either a space or tab (preceding the newline).
>>
>> I'm using ESS:
>> ess-version's value is "5.3.6"
>> GNU Emacs 21.4.1 (i486-pc-linux-gnu, X toolkit, Xaw3d scroll bars) of
>> 2007-08-28 on terranova, modified by Debian
>>
>> I have the following in my .emacs:
>> (load "ess-5.3.6/lisp/ess-site")
>> (setq ess-tab-always-indent nil)
>> (setq ess-fancy-comments nil)
>>
>> I have not edited ess-site.el
>>
>>
>> On Fri, May 30, 2008 at 12:26 PM, Prof Brian Ripley
>> <[EMAIL PROTECTED]> wrote:
>>> We don't know how to reproduce this: 'whitespace' is not specific
enough.
>>>
>>> R's tokenizer breaks input at spaces, so a space would never be part of
that
>>> expression. And tabs don't even get to the parser in interactive use,
and
>>> you cannot mean a newline. So exactly what do you mean by 'whitespace'?
>>>
>>> The character in your email as received here is an ASCII space, and
that is
>>> used to end the token on all my systems. That's not to say that you
didn't
>>> type something else that looks like a space (e.g. a nbspace) since email
>>> systems are fickle.
>>>
>>> None of my guesses worked, so we need precise reproduction instructions.
>>>
>>> On Thu, 29 May 2008, [EMAIL PROTECTED] wrote:
>>>
> ?agrep
>
Results in:
No documentation for 'agrep ' in specified packages and libraries:
you could try 'help.search("agrep ")'
There is white space after agrep, that ? doesn't ignore.
--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 = 7.0
year = 2008
month = 04
day = 22
svn rev = 45424
language = R
version.string = R version 2.7.0 (2008-04-22)
Locale:
LC_CTYPE=en_US;LC_NUMERIC=C;LC_TIME=C;LC_COLLATE=C;LC_MONETARY=C;LC_MESSAGES=en_US;LC_PAPER=en_US;LC_NAME=C;LC_ADDRESS=C;LC_TELEPHONE=C;LC_MEASUREMENT=en_US;LC_IDENTIFICATION=C
Search Path:
.GlobalEnv, package:stats, package:graphics, package:grDevices,
package:utils, package:datasets, package:showStructure, package:Rcode,
package:splus2R, package:methods, Autoloads, package:base
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
>>>
>>> --
>>> Brian D. Ripley, [EMAIL PROTECTED]
>>> 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
>>>
>>
BDR> --
BDR> Brian D. Ripley, [EMAIL PROTECTED]
BDR> Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/
BDR> University of Oxford, Tel: +44 1865 272861 (self)
BDR> 1 South Parks Road, +44 1865 272866 (PA)
BDR> Oxford OX1 3TG, UKFax: +44 1865 272595
BDR> __
BDR> R-devel@r-project.org mailing list
BDR> 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] NAMESPACE & methods guidance, please
(Comment near the bottom of the text.)
Seth Falcon wrote:
> * On 2008-06-01 at 11:30 -0400 John Chambers wrote:
>
>> My impression (but just as a user, not an implementer) is that the
>> NAMESPACE mechanism is intended to search for anything, not just for
>> methods, as follows:
>>
>> - look in the namespace itself;
>> - look in the imports, which are in the parent.env of the namespace;
>> - look in the base package's namespace.
>>
>
> As described in the R News article [1], the above describes the static
> component of the search mechanism, but there is a dynamic component
> which adds:
>
> - look in .GlobalEnv
> - look in each package on the search path
> - look (again) in base
>
> [1] http://cran.r-project.org/doc/Rnews/Rnews_2003-1.pdf
>
>
>> Period. This provides a definition of the behavior of functions in the
>> package that is independent of the dynamically changing contents of the
>> search list.
>>
>
> I think the dynamic lookup is important. Consider class Foo and some
> methods, like show, for working with Foo instances defined in pkgA.
> Further, suppose pkgB imports pkgA and contains a function that
> returns a Foo instance.
>
> If a user class library("pkgB") at the prompt, both the developer and
> the user would like for methods for dealing with Foo instances to be
> available.
>
> This has been achieved by adding pkgA to the Depends field of pkgB.
> In this case, library("pkgB") has the side-effect of attaching pkgA to
> the search path and Foo instances behave as desired. This, I believe,
> describes the first part of Martin's example:
>
> Martin Morgan:
>
library(KEGG.db) # Imports, Depends AnnotationDbi; KEGG.db is data-only
head(ls(KEGGPATHID2EXTID))
>>> [1] "hsa00232" "hsa00230" "hsa04514" "hsa04010" "hsa04012" "hsa04150"
>>>
>>>
>
> John Chambers:
>
>> "Depends" may cause the relevant packages to be put on the search list.
>> But a subsequent attach or detach could change what objects were found.
>> So unless this is not the intended interpretation of namespaces, looking
>> in the search list seems a bad idea in principle.
>>
>
> I agree that using the dynamic lookup when the static lookup is
> available is bad programming practice. However, given the flexibility
> of the current tools, it seems not unreasonable to expect that
> picking up a method via the search path would work in a package just
> as it does (should?) interactively.
>
Well, I'm not against that, if it coincides with the general view of
namespaces.
However, it's not required for the methods to be available, AFAICS.
For example, "show" is a generic function associated with the "methods"
package. When a package is loaded with methods for "show", those
methods are merged into the methods table for that generic function.
Any calls to that generic function, from whatever other package, see the
consistent version of the generic, and therefore the new methods.
(That's a description specifically from the r-devel version. If there's
evidence to the contrary, it would likely be a bug.)
The error in Martin's example is in evaluating an argument. Without
more detail, I don't see what that has to do with method selection per se.
John
>
> + seth
>
>
[[alternative HTML version deleted]]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Revised help pages for methods package
A number of the help pages have been revised, so far only on the r-devel version, although the great majority of the revisions apply to 2.7.0 as well. Much of the existing documentation is out of date, some of it badly. Also, a goal of the revision is that readers could start with package?methods and navigate down through some general pages to details. (Not by any means as an introduction to the topic, but for clarifications and for details.) I hope eventually to revise most of the pages, but only a dozen or so have been done at this point (including, however, many of the key topics). Another reason for delay was that the new pages reference the "Software for Data Analysis" book, which was supposed to be out by now, but is not "quite" (questions on that topic have to go to the publisher). However, it seems useful to distribute these revisions now, as the topics come up, for example, in this mailing list fairly often. John __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Request: Documentation of formulae
Mike Prager <[EMAIL PROTECTED]> wrote: > I was at a loss to understand the use of "/" until I looked in > "An Introduction [!] to R," where I found the explanation. > > My request is that more complete material on model formulae be > lifted from "Introduction to R" (or elsewhere) and put into the > main online help files. I also request the R Core consider remaining "An Introduction to R" to something like "R User's Guide." It spans 100 pages and treats many topics far beyond the introductory level. I was surprised at the wealth of information it contains, and I expect that I would have checked it first, not last, among available resources had it been more accurately named. -- Mike Prager, NOAA, Beaufort, NC * Opinions expressed are personal and not represented otherwise. * Any use of tradenames does not constitute a NOAA endorsement. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] benchmarking R installations
Recently I posted to this list with a question about using the Intel 10.1 compilers in building R and one response was basically, "why in the heck would you want to do that?" The answer is that my sysadmin believes that there will be a performance boost with the Intel vs. Gnu compilers on our Linux cluster, of which I am one of many users. Wanting to be a good citizen and use my machine time wisely, I'd of course like to use right tool to build the most efficient installation of R and associated packages. BTW, we got R to compile nicely using the settings at the end of this post. Looking back on previous posts, however, it seems that there is no consensus as to how to benchmark R. I realize such a task is not trivial, nor controversial, but does anyone have a set of time-consuming tasks that can be used to compare R installations? It would seem logical that such a benchmark would include sub-benchmarks on file access, interpreted intensive tasks, C intensive tasks, BLAS intensive tasks, etc. You developers know more about this than I do, but I know enough to realize that there won't be one simple answer. Nevertheless, I'd like to make my usage decisions on something rather than anedotal claims. So, does anyone know of a good benchmarking script or would be willing to contribute one? And here are the settings we used to compile R with Intel 10.1 compilers: ../configure --prefix=/N/u/mkimpel/R_HOME/R-patched/R-build \ --with-system-zlib=/usr/lib64 --with-system-bzlib=/usr/lib64 \ --with-mpi=/N/soft/linux-rhel4-x86_64/openmpi/1.2.5/intel-64 --with-tcltk \ --with-tcl-config=/N/soft/linux-rhel4-x86_64/tcl8.4.16/lib64/tclConfig.sh \ --with-tk-config=/N/soft/linux-rhel4-x86_64/tk8.4.16/lib64/tkConfig.sh \ --without-x --without-readline --without-iconv \ CC="/N/soft/linux-rhel4-x86_64/intel/cce/10.1.013/bin/icc" \ CFLAGS="-O3 -no-prec-div -unroll" \ F77="/N/soft/linux-rhel4-x86_64/intel/fce/10.1.013/bin/ifort" \ FFLAGS="-O3 -no-prec-div -unroll" \ CXX="/N/soft/linux-rhel4-x86_64/intel/cce/10.1.013/bin/icpc" \ CXXFLAGS="-O3 -no-prec-div -unroll" \ FC="/N/soft/linux-rhel4-x86_64/intel/fce/10.1.013/bin/ifort" \ FCFLAGS="-O3 -no-prec-div -unroll" \ OBJC="/N/soft/linux-rhel4-x86_64/intel/cce/10.1.013/bin/icc" \ OBJCFLAGS="-O3 -no-prec-div -unroll" \ --disable-R-profiling --disable-memory-profiling ## make all make install Mark -- Mark W. Kimpel MD ** Neuroinformatics ** Dept. of Psychiatry Indiana University School of Medicine 15032 Hunter Court, Westfield, IN 46074 (317) 490-5129 Work, & Mobile & VoiceMail (317) 663-0513 Home (no voice mail please) ** [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] configure.args from install.packages passed on to subsequent update.packages?
>From the help pages I see that there is a configure.args argument to install.packages, and I am using that successfully. I do not see anything similar for update.packages(). Does each package keep track of the configure.args used to build in initially and pass this on to subsequent updates or I am missing an argument to update.packages? Thanks, Mark -- Mark W. Kimpel MD ** Neuroinformatics ** Dept. of Psychiatry Indiana University School of Medicine 15032 Hunter Court, Westfield, IN 46074 (317) 490-5129 Work, & Mobile & VoiceMail (317) 663-0513 Home (no voice mail please) ** [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] More information on R segfaults, tcltk package, and graphics devices
Dear R-devel -
I have investigated the report I made at
https://stat.ethz.ch/pipermail/r-devel/2008-May/049683.html some more,
and believe I have enough information to warrant an update. My
sessionInfo() immediately after starting R is at the bottom of this message.
I decided to first concentrate on finding out why I sometimes receive a
segfault while closing a graphics window while the window is redrawing
after resizing it, but seemingly only after loading the tcltk package.
I do the following code in a --vanilla R session.
library(grid)
library(tcltk)
for(i in seq(0, 1, by = .1)) {
for(j in seq(0, 1, by = .01)) {
angle <- runif(1, 1, 180)
col <- sample(colors(), 1)
pushViewport(viewport(x = i, y= j, width = .1, height = .1,
angle = angle, gp = gpar(col = col)))
grid.rect()
popViewport()
}
}
I then simply resize the X11 window a bit to force a redraw of the
graphic, and then rapidly hit the 'X' close button on the X11 window
while the rectangles are redrawing. I will often get the behavior that
the window closes and R segfaults.
The gdb backtraces from the core dumps I produced mostly were failing in
GEcheckState from engine.c, but it was not clear to me what was going on
from the backtrace.
After much trial and error, I decided to put a breakpoint in the
removeDevice function from device.c.
I then do what I describe above, and get the following backtrace from
gdb, edited to show what I think is going on.
(gdb) bt
#0 removeDevice (devNum=1, findNext=TRUE) at devices.c:307
#1 0xb7962855 in handleEvent (event=
{type = 33, xany = {type = 33, serial = 15621, send_event = 1,
...(snip)...
, 268686226}})
at devX11.c:627
#2 0xb796296c in R_ProcessX11Events (data=0x0) at devX11.c:665
#3 0x080fd99c in R_runHandlers (handlers=0x8263d28, readMask=0x82cf6a0)
at sys-std.c:363
#4 0xb74e159e in RTcl_eventProc (evPtr=0x97dfbf0, flags=-1) at
tcltk_unix.c:136
#5 0xb749d6a3 in Tcl_ServiceEvent () from /usr/lib/libtcl8.4.so.0
#6 0xb749da32 in Tcl_DoOneEvent () from /usr/lib/libtcl8.4.so.0
#7 0xb74e14ee in TclSpinLoop (data=0x0) at tcltk_unix.c:60
#8 0x0814d4a6 in R_ToplevelExec (fun=0xb74e14d0 ,
data=0x0) at context.c:604
#9 0xb74e14b2 in TclHandler () at tcltk_unix.c:67
#10 0x08184f11 in R_CheckUserInterrupt () at errors.c:125
#11 0x0818d5cc in Rf_eval (e=0x8ab3010, rho=0x858f6f8) at eval.c:370
... (snip)... Many Rf_eval, Rf_applyClosure, etc.
#73 0x08173480 in do_recordGraphics (call=0x8308040, op=0x83223e0,
args=0x91f4c58,
env=0x8308040) at engine.c:2757
#74 0x081730a7 in GEplayDisplayList (dd=0x974f8e0) at engine.c:2547
#75 0xb7962659 in handleEvent (event=
{type = 12, xany = {type = 12, serial = 14493, send_event = 0,
...snip...
#79 0x0805b0ca in Rf_ReplIteration (rho=0x832ac68, savestack=0,
browselevel=0, state=0xbffbbc34)
at main.c:206
#80 0x0805b1ea in R_ReplConsole (rho=0x832ac68, savestack=0,
browselevel=0) at main.c:306
#81 0x0805b4d8 in run_Rmainloop () at main.c:967
#82 0x08058d91 in main (ac=0, av=0x0) at Rmain.c:35
#83 0xb7d61450 in __libc_start_main () from /lib/tls/i686/cmov/libc.so.6
#84 0x08058cc1 in _start ()
What seems to be happening is during the
while (theList != R_NilValue && plotok)
loop in GEplayDisplayList, at some point R_CheckUserInterrupt can be
called, and if the tcltk package has been loaded, its TclHandler is
called, which eventually ends up getting removeDevice called, as the
backtrace above shows. From there, and please excuse my possibly loose
terminology here, the device no longer exists to R, and accessing the
'dd' variable as in GEcheckState can cause a segfault, if something did
not already go wrong while replaying the display list, such as the
strange grid errors such as "Cannot pop top-level viewport" and
"VECTOR_ELT() can only be applied to a 'list', not a 'NULL'" messages I
had been receiving.
Now, I have no idea if there is a fix, or how to go about it at this
point, but I believe that is what is happening, so if anyone wants to
investigate it further, this should be a good starting point. Perhaps
the relevant advice here is "Don't do that".
Please ask if I have not been clear enough or additional information
from gdb is needed.
Best,
Erik Iverson
[EMAIL PROTECTED]
sessionInfo()
R version 2.7.0 (2008-04-22)
i686-pc-linux-gnu
locale:
LC_CTYPE=en_US.UTF-8;LC_NUMERIC=C;LC_TIME=en_US.UTF-8;LC_COLLATE=en_US.UTF-8;LC_MONETARY=C;LC_MESSAGES=en_US.UTF-8;LC_PAPER=en_US.UTF-8;LC_NAME=C;LC_ADDRESS=C;LC_TELEPHONE=C;LC_MEASUREMENT=en_US.UTF-8;LC_IDENTIFICATION=C
attached base packages:
[1] stats graphics grDevices utils datasets methods base
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Request: Documentation of formulae
> "MP" == Mike Prager <[EMAIL PROTECTED]>
> on Mon, 02 Jun 2008 16:29:16 -0400 writes:
MP> Mike Prager <[EMAIL PROTECTED]> wrote:
>> I was at a loss to understand the use of "/" until I looked in
>> "An Introduction [!] to R," where I found the explanation.
>>
>> My request is that more complete material on model formulae be
>> lifted from "Introduction to R" (or elsewhere) and put into the
>> main online help files.
MP> I also request the R Core consider remaining "An Introduction to
MP> R" to something like "R User's Guide." It spans 100 pages and
MP> treats many topics far beyond the introductory level. I was
MP> surprised at the wealth of information it contains, and I expect
MP> that I would have checked it first, not last, among available
MP> resources had it been more accurately named.
Hi Mike, you make very worthy suggestions; but I assume the word
"request" is really putting off almost all of us "R corers".
You *have* heard that R is a volunteer project, that much of its
development has happened in unpaid time of core team mates.
Why are you not using "Suggestion" instead?
Also, since it's a volunteer project, and you are a capable R
user, you could even consider sending patches, e.g. to the
formula.Rd help page.
At last, to the renaming suggestion: I see your point, but
1) in "an Intro" one is allowed to be non-comprehensive
where as a "user's guide" is supposedly touching almost
everything relevant. This is not the case, since R has much
evolved since the "An Intro .." had been compiled, and most
new features are not mentioned in the intro.
2) I don't know your background, but in the math sciences, there
exist quite a few comprehensive textbooks called "An
Introduction to ...".
One example from my bookshelf is
@BOOK{AndT84,
author = {T. W. Anderson},
title ={An Introduction to Multivariate Statistical Analysis},
publisher = Wiley,
address = NY,
year = 1984
}
3) "An Introduction to R" is mentioned in many many pieces of
documentation about R; from instructions to students, to
online guides, to books, etc.
For this reason, a new title should reall still contain the
term.
Maybe simply
"An Introduction to R --- User's guide"
?
Best regards,
Martin Maechler, ETH Zurich
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
