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 TclSpinLoop,
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
