Re: [Rd] RFC: What should ?foo do?
On 30/04/2008 2:44 AM, Martin Maechler wrote:
"DM" == Duncan Murdoch <[EMAIL PROTECTED]>
on Sat, 26 Apr 2008 17:21:06 -0400 writes:
DM> On 25/04/2008 2:47 PM, Prof Brian Ripley wrote:
>> On Fri, 25 Apr 2008, Deepayan Sarkar wrote:
>>
>>> For what it's worth, I use ?foo mostly to look up usage of functions
>>> that I know I want to use, and find it perfect for that (one benefit
>>> over help() is that completion works for ?). The only thing I miss is
>>> the ability to do the equivalent of help("foo", package = "bar");
>>> ?bar::foo gives the help page for "::". Perhaps that would be
>>> something to consider for addition.
>>
>> That fits most naturally with the (somewhat technical) idea that bar::foo
>> becomes a symbol and not a function call. I believe that several of think
>> that is in principle a better idea, but no one has as yet (AFAIK) explored
>> the ramifications.
>>
>> However, 5 mins looking at the sources suggests that it is easy to do.
DM> And you already did. Thanks!
indeed.
DM> I'm going to make the following change soon (in R-devel).
DM> ??foo
DM> will now be like help.search("foo"). This will work with your change,
DM> so ??utils::foo will limit the search to the utils package. This is
DM> also quite easy. A more difficult thing I'd like to do is to broaden
DM> the search to look outside the man pages, but that's a lot harder, and I
DM> haven't started on it.
DM> I will also follow Hadley's suggestion and change the format of the
DM> help.search results, so you can just cut and paste after a question mark
DM> to look up the particular topic, e.g. ??foo gives
DM> utils::citEntry Writing Package CITATION Files
DM> Type '?PKG::FOO' to inspect entry 'PKG::FOO TITLE'.
DM> I haven't touched the case of ?foo failing; I'll want to try it for a
DM> while to decide whether I like it best as is:
>> ?foo
DM> No documentation for 'foo' in specified packages and libraries:
DM> you could try '??foo'
DM> or whether it should just automatically call help.search, or something
DM> in between.
Please the former, at least by default!
[The case of 1500 installed packages was mentioned before...]
Note one thing that hasn't been mentioned before:
help() has had the optional argument
' try.all.packages = getOption("help.try.all.packages") '
for many years now, and I have been involved in its history as
well but don't recall all details. IIRC,
help() {and hence "?"} used to *default* to
'try.all.packages = TRUE' for a while and later it was the
default for me (and our whole statistics departmental unit).
But we found that it *was* inconvenient that a big search was
started, often just because of a typo.
So I think ? should ``answer quickly'' by
default.
Have you tried help.search() lately? It is now very fast. I haven't
checked if help() makes use of the same search mechanism, but presumably
it could do so, if speed is an issue.
So I would say the speed is a solvable or solved problem.
Duncan Murdoch
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] RFC: What should ?foo do?
On Wed, 30 Apr 2008, Duncan Murdoch wrote:
On 30/04/2008 2:44 AM, Martin Maechler wrote:
"DM" == Duncan Murdoch <[EMAIL PROTECTED]>
on Sat, 26 Apr 2008 17:21:06 -0400 writes:
DM> On 25/04/2008 2:47 PM, Prof Brian Ripley wrote:
>> On Fri, 25 Apr 2008, Deepayan Sarkar wrote:
>> >>> For what it's worth, I use ?foo mostly to look up usage of
functions
>>> that I know I want to use, and find it perfect for that (one
benefit
>>> over help() is that completion works for ?). The only thing I miss
is
>>> the ability to do the equivalent of help("foo", package = "bar");
>>> ?bar::foo gives the help page for "::". Perhaps that would be
>>> something to consider for addition.
>> >> That fits most naturally with the (somewhat technical) idea
that bar::foo >> becomes a symbol and not a function call. I believe
that several of think >> that is in principle a better idea, but no one
has as yet (AFAIK) explored >> the ramifications.
>> >> However, 5 mins looking at the sources suggests that it is
easy to do.
DM> And you already did. Thanks!
indeed.
DM> I'm going to make the following change soon (in R-devel).
DM> ??foo
DM> will now be like help.search("foo"). This will work with your
change, DM> so ??utils::foo will limit the search to the utils package.
This is DM> also quite easy. A more difficult thing I'd like to do is
to broaden DM> the search to look outside the man pages, but that's a
lot harder, and I DM> haven't started on it.
DM> I will also follow Hadley's suggestion and change the format of the
DM> help.search results, so you can just cut and paste after a question
mark DM> to look up the particular topic, e.g. ??foo gives
DM> utils::citEntry Writing Package CITATION Files
DM> Type '?PKG::FOO' to inspect entry 'PKG::FOO TITLE'.
DM> I haven't touched the case of ?foo failing; I'll want to try it for
a DM> while to decide whether I like it best as is:
>> ?foo
DM> No documentation for 'foo' in specified packages and libraries:
DM> you could try '??foo'
DM> or whether it should just automatically call help.search, or
something DM> in between.
Please the former, at least by default!
[The case of 1500 installed packages was mentioned before...]
Note one thing that hasn't been mentioned before:
help() has had the optional argument
' try.all.packages = getOption("help.try.all.packages") '
for many years now, and I have been involved in its history as
well but don't recall all details. IIRC,
help() {and hence "?"} used to *default* to 'try.all.packages = TRUE' for
a while and later it was the
default for me (and our whole statistics departmental unit).
But we found that it *was* inconvenient that a big search was
started, often just because of a typo.
So I think ? should ``answer quickly'' by
default.
Have you tried help.search() lately? It is now very fast. I haven't checked
if help() makes use of the same search mechanism, but presumably it could do
so, if speed is an issue.
So I would say the speed is a solvable or solved problem.
There are some possible improvements as yet. Hadley mentioned keeping
binary indices -- we do per-package and could per-library. Just opening
1700 files can be quite slow on some systems -- this is one of the areas
where you see the benefits of Unix-alike file systems.
A lot of the speed ups are generic, e.g. internal file.path. I get
system.time(help("linear", try.all.packages = TRUE))
user system elapsed
10.948 2.620 37.808
system.time(help.search("linear"))
user system elapsed
8.219 0.432 28.358
so there is room for improvement in help(). However, the re-run
system.time(help.search("linear"))
user system elapsed
1.951 0.003 1.960
shows the benefits of caching.
(This is on a not particularly fast machine with all of CRAN and BioC
installed, in UTF-8: and I know of some ways to improve performance in
UTF-8.)
It's all a question of resources and who is prepared to contribute.
I sped help.search() up ca 3x because 100s was too slow for me -- 30s the
first time in a session is OK. (And incidentally disc caching means that
the next session got
system.time(help.search("linear"))
user system elapsed
7.180 0.246 7.627
, so the main issue is disc access.)
--
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
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] [PATCH] Typo in 'help' documentation
---
I think this should be "package is loaded" and not "library is
loaded". At least, I can't see how it can be correct the way it's
currently written.
-roger
src/library/utils/man/help.Rd |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git src/library/utils/man/help.Rd src/library/utils/man/help.Rd
index 5b0ed8e..783b0c2 100644
--- src/library/utils/man/help.Rd
+++ src/library/utils/man/help.Rd
@@ -135,7 +135,7 @@ type?topic
\note{
Unless \code{lib.loc} is specified explicitly, the loaded packages are
searched before those in the specified libraries. This ensures that
- if a library is loaded from a library not in the known library trees,
+ if a package is loaded from a library not in the known library trees,
then the help from the loaded library is used. If \code{lib.loc} is
specified explicitly, the loaded packages are \emph{not} searched.
--
1.5.5.1.99.gf0ec4
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] weighted nonlinear fits: `nls' and `eval'
2 days ago I asked this on r-help, but no luck... since
this is actually a programming question, I post it here
again:
my question concerns the use of `eval' in defining the model
formula for `nls' when performing weighted fits. (I use
version 2.6.2., but according to NEWS there were no changes
to `nls' in 2.7.0, so the problem is still present). in this
scenario their exists a serious problem.
consider the following simple example, where some fixed
model plus data are used to perform both unweighted and
weighted fits. (I intentionally used very uneven weights to
guarantee large differences in the results.)
#CUT===
ln <- 100
x <- 1:ln
y0 <- exp(-.02*x)
y <- rnorm(y0, y0, .01)
wts <- rep(1, ln)
y[30] <- 1.2*y[30]
wts[30] <- 1e3
model <- y ~ exp(-k*x)
xydata <- list(x=x, y=y)
#simple unweighted fit works as expected:
r0 <- nls(model, start = c(k=.01), data = list(x=x, y=y))
#simple weighted fit works as expected:
r1 <- nls(model, start = c(k=.01), data = xydata, weights = wts)
#this actually performs an unweighted fit (issuing a warning):
mdl <- model[[3]]
r2 <- nls(y ~ eval(mdl), start = c(k=.01), data = xydata, weights = wts)
#this, too, actually performs an unweighted fit (issuing a warning):
dv1 <- deriv(model, "k")
r3 <- nls(y ~ eval(dv1), start = c(k=.01), data = xydata, weights = wts)
#weighted fit, works as expected
dv2 <- deriv(model, "k", c("k", "x"))
r4 <- nls(y ~ dv2(k, x), start = c(k=.01), data = xydata, weights = wts)
#CUT===
if you copy this to the R prompt you can see the fits
producing `r2' and `r3' do _not_ do what's intended. looking
at the source code of `nls' I get some ideas where it is
going wrong (in setting up the model frame in `mf') what
exactly is the problem.
moreover, I found out that `r2' and `r3' can be convinced
to do what's intended by modifying `xydata' to
xydata <- list(x=x, y=y, `(weights)` = wts)
i.e. by adding a `(weights)` component to the `data' field.
but that probably is not the way to go ...
while it is clear that my example is artificial, there _are_
circumstances where `eval' constructs for defining the model
formulaoccur quite naturally when writing some
wrappers/drivers for `nls' usage.
questions:
==
1.) is it actually not intended/supported to use `eval' in
defining the model formula argument of `nls'? if so, why
not (it's a legitimate and not that esoteric language
feature)? or what am I missing (e.g. necessity to provide
explicitely an `envir' argument to `eval'. if so, which
one)?
2.) could/should not `nls' be modified to cleanly support
the use of `eval' (remarks along the line of "submit
changes" would not help much, I'm afraid :-))? apart from
the problem described here there are others where `nls'
simply parses `eval' based formulas not as intended
(erroneously) and bails out.
3.) if the policy of the core group is that the current
state of affairs is quite perfect (an assessement which I
would'nt share), should not at least the manpage of `nls'
be augmented to warn people very clearly that any use of
`eval' in the model formula is calling for trouble.
I find the example above especially annoying: the fits
producing `r2' and `r3' run apparently fine, only issuing a
warning, which sure is cryptic for joe user. so, if this
happens in some wrapper function provided to others (which I
do) they very well might believe having performed a weighted
fit when they did not.
thanks,
joerg
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Read/write file locking mechanism using SQL?
Hi, I've got data stored in multiple files on a shared file system. I wish to have multiple processes/hosts read and write to these files simultaneously. When a process wish to write to a file no other processes may write to nor read from the file. If no process is writing to the file, any number of processes may read from it. ...and the solution should be very simple and work automagically in the background (no/minimal setup required by the user). The above can be achieved via file locking mechanism where writers need to require a write lock before writing, and readers need to require a read lock before reading. Any number of read locks can be handed out, but only if no write lock is already in place. Write locks can only be obtained if no other locks (read or write) are handed out. The locking mechanism is per file. I am locking for a cross platform solution in R that works on any file system, i.e. I am not in control of the operating systems of the hosts nor the file system where the data files are stored. I've been suggested to use, for instance, RSQLite database since it provides atomic transactions (and is available on Windows, *nix & OSX). I can image to have a table where each entry is indexed by a file and it keeps track of how many read and write locks are active. Does anyone know of existing solution for this, or has ideas how this could be implemented? I appreciate any references/comments. /Henrik __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] build packages with vignettes in Windows
On 29 Apr 2008, Duncan Murdoch wrote: > Right, you don't need to set the system path for everything, but you do > need to set it in CMD (or other shell) before running Rcmd. For Win 2K/XP/Vista, the system path can be set (through the GUI interface, not sure how to do it with scripts) without restarting, for new CMD processes started afterwards. Michael __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] apply and monthly time series (PR#11352)
Full_Name: Stephen McIntyre
Version: 2.7
OS: Windows XP
Submission from: (NULL) (99.231.2.44)
When I use the apply function to calculate a trend for a matrix of monthly time
series, it yields a different answer than when the trend is calculated one at a
time (by a factor of 12) rather than the identical answer as it should. Here's
an example:
download.file("http://www.climateaudit.org/data/models/monthly.tab","temp.dat",mode="wb";)
load("temp.dat")
trend= function(x) lm(x~c(time(x)))$coef[2]
b= apply(monthly,2,trend)
a= c(trend(monthly[,1]),trend(monthly[,2]),trend(monthly[,3]))
a/b #12 12 12
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] reproducible segmentation fault caused by textConnection()
Dear Bill,
Thanks for having had a look on this bug. I am now using an anonymous
file() connection to store my stuffs instead of textConnection(): it is
much faster and doesn't raise any seg faults.
Regards,
Greg
---
Gregoire Pau
EMBL/EBI Cambridge, UK
http://www.ebi.ac.uk/~gpau
Bill Dunlap wrote:
On Tue, 29 Apr 2008, Gregoire Pau wrote:
Dear all,
It seems that textConnection() can trigger a segmentation fault. The
following script (using two large loops) makes this bug reproducible:
for (i in 1:1) {
z=textConnection(NULL,open='w')
for (j in 1:100) {
write(runif(1)*1e6,file=z)
write('\n',file=z)
}
close(z)
}
The bug could be reproduced on R-2.6.1, R-2.7.0 and on the latest
R-devel 2008-04-29 r45543.
valgrind shows that it uses freed memory after
a garbage collecting episode (after many iterations),
because a Routtextconn's 'data' component was freed:
==24210== Invalid read of size 1
==24210==at 0x810B328: Rf_lengthgets (Rinlinedfuns.h:358)
==24210==by 0x8121C48: text_vfprintf (connections.c:2064)
==24210==by 0x809D0C1: Rvprintf (printutils.c:770)
==24210==by 0x809D105: Rprintf (printutils.c:668)
==24210==by 0x810A984: do_cat (builtin.c:617)
==24210== Address 0x5823CD8 is 0 bytes inside a block of size 1,176 free'd
==24210==at 0x40052A3: free (vg_replace_malloc.c:233)
==24210==by 0x805AC3D: R_gc_internal (memory.c:769)
==24210==by 0x805B873: Rf_cons (memory.c:1757)
==24210==by 0x81571F6: Rf_promiseArgs (eval.c:1633)
(gdb) where 5
#0 Rf_lengthgets (x=0x5823cd8, len=289)
at ../../src/include/Rinlinedfuns.h:358
#1 0x08121c49 in text_vfprintf (con=0x500f280, format=0x81e64d8 "\n",
ap=0xbef18b84 "�\213�") at connections.c:2064
#2 0x0809d0c2 in Rvprintf (format=0x81e64d8 "\n", arg=0xbef18b84 "�\213�")
at printutils.c:770
#3 0x0809d106 in Rprintf (format=0x81e64d8 "\n") at printutils.c:668
#4 0x0810a985 in do_cat (call=0x4ae31f0, op=0x4104eec, args=0x55bb2bc,
rho=0x55baf20) at builtin.c:617
(More stack frames follow...)
(gdb) up
#1 0x08121c49 in text_vfprintf (con=0x500f280, format=0x81e64d8 "\n",
ap=0xbef18b84 "�\213�") at connections.c:2064
2064PROTECT(tmp = lengthgets(this->data, ++this->len));
(gdb) print this->data
$1 = 0x5823cd8
(gdb) whatis this
type = Routtextconn
(gdb) whatis this->data
type = SEXP
(gdb) print *this->data
$2 = {sxpinfo = {type = 16, obj = 0, named = 2, gp = 0, mark = 0, debug = 0,
trace = 0, spare = 0, gcgen = 0, gccls = 7}, attrib = 0x40ae088,
gengc_next_node = 0x8235270, gengc_prev_node = 0x8235270, u = {primsxp = {
offset = 288}, symsxp = {pname = 0x120, value = 0x0,
internal = 0x57685c0}, listsxp = {carval = 0x120, cdrval = 0x0,
tagval = 0x57685c0}, envsxp = {frame = 0x120, enclos = 0x0,
hashtab = 0x57685c0}, closxp = {formals = 0x120, body = 0x0,
env = 0x57685c0}, promsxp = {value = 0x120, expr = 0x0,
env = 0x57685c0}}}
Bill Dunlap
Insightful Corporation
bill at insightful dot com
"All statements in this message represent the opinions of the author and do
not necessarily reflect Insightful Corporation policy or position."
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] apply and monthly time series (PR#11352)
See ?apply
If X is not an array but has a dimension attribute, apply attempts to coerce
it to an array via as.matrix if it is two-dimensional (e.g., data
frames) or via as.array.
So for example, try this noting that time is 1, 2, 3, ...
apply(monthly, 2, time)
Try
lm(monthly ~ time(monthly))
On Wed, Apr 30, 2008 at 9:00 AM, <[EMAIL PROTECTED]> wrote:
> Full_Name: Stephen McIntyre
> Version: 2.7
> OS: Windows XP
> Submission from: (NULL) (99.231.2.44)
>
>
> When I use the apply function to calculate a trend for a matrix of monthly
> time
> series, it yields a different answer than when the trend is calculated one at
> a
> time (by a factor of 12) rather than the identical answer as it should. Here's
> an example:
>
> download.file("http://www.climateaudit.org/data/models/monthly.tab","temp.dat",mode="wb";)
> load("temp.dat")
> trend= function(x) lm(x~c(time(x)))$coef[2]
> b= apply(monthly,2,trend)
> a= c(trend(monthly[,1]),trend(monthly[,2]),trend(monthly[,3]))
> a/b #12 12 12
>
> __
> 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] Quotation marks (PR#11353)
Full_Name: Mitchell Steven Wachtel, MD
Version: 2.7.0 RC
OS: Vista
Submission from: (NULL) (66.230.2.56)
Single (') and double (") quotation marks are not being read as quotation marks
when commands are copied from Word; they produce an error message whenever they
are used. To correct this, one has to retype everything in the R console. I
tried using courier new, as well as the good old fashioned Times New Roman, but
nothing seemed to work.
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] build packages with vignettes in Windows
You can use the Windows batch PATH command. On Wed, Apr 30, 2008 at 11:56 AM, Michael <[EMAIL PROTECTED]> wrote: > On 29 Apr 2008, Duncan Murdoch wrote: > > > Right, you don't need to set the system path for everything, but you do > > need to set it in CMD (or other shell) before running Rcmd. > > For Win 2K/XP/Vista, the system path can be set (through the GUI interface, > not sure how to do it with scripts) without restarting, for new CMD > processes started afterwards. > > Michael > > > __ > 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] Quotation marks (PR#11353)
>
> Single (') and double (") quotation marks are not being read as quotation
> marks
> when commands are copied from Word; they produce an error message whenever
> they
> are used. To correct this, one has to retype everything in the R console. I
> tried using courier new, as well as the good old fashioned Times New Roman,
> but
> nothing seemed to work.
Try turning off smart quotes.
Hadley
--
http://had.co.nz/
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] build packages with vignettes in Windows
On 4/30/2008 11:56 AM, Michael wrote: On 29 Apr 2008, Duncan Murdoch wrote: Right, you don't need to set the system path for everything, but you do need to set it in CMD (or other shell) before running Rcmd. For Win 2K/XP/Vista, the system path can be set (through the GUI interface, not sure how to do it with scripts) without restarting, for new CMD processes started afterwards. Sure, but the installer doesn't know how to do that. It just sets the path in the registry; it doesn't know how to give Explorer a kick to get it to reload from there. As far as I know there's no documented way to do that. Within a shell it's very easy to set the path, but it doesn't propagate to processes started outside that shell. Duncan Murdoch __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] build packages with vignettes in Windows
On Apr 30, 2008, at 2:31 PM, Duncan Murdoch wrote: On 4/30/2008 11:56 AM, Michael wrote: On 29 Apr 2008, Duncan Murdoch wrote: Right, you don't need to set the system path for everything, but you do need to set it in CMD (or other shell) before running Rcmd. For Win 2K/XP/Vista, the system path can be set (through the GUI interface, not sure how to do it with scripts) without restarting, for new CMD processes started afterwards. Sure, but the installer doesn't know how to do that. It just sets the path in the registry; it doesn't know how to give Explorer a kick to get it to reload from there. As far as I know there's no documented way to do that. FWIW the PATH setting is effective immediately (at least on 2k/ XP ...). Any new shell you start (e.g. using Run..) will have the updated PATH already. I was always very skeptical as editing PATH in the installer is concerned (and I have always declined any automated changes), but I really love the feature that allows me to edit the whole PATH interactively in an editor-like window. Also note that the rebooting is optional, you can still safely decline it so I see no reason why that should deter anyone. Cheers, Simon __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] New version of X11, png and jpeg
The now default Cairo results in much prettier graphs, but dense graphs such as plot(rnorm(1e4)) take considerably longer to plot than using X11(type="Xlib"). This has already been mentioned, but I was wondering if we users could expect Cairo speed increases in the near future? >Slower under some circumstances (although on the test systems much faster than packages Cairo and cairoDevice). This will be particularly true for X11() with a slow connection between the machine running R and the X server. Using R 2.7.0 on Ubuntu 8.04 (Pentium 4 1.70 GHz on one machine and Centrino Duo on another) -- View this message in context: http://www.nabble.com/New-version-of-X11%2C-png-and-jpeg-tp15672580p16987759.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] build packages with vignettes in Windows
On 4/30/2008 4:01 PM, Simon Urbanek wrote: On Apr 30, 2008, at 2:31 PM, Duncan Murdoch wrote: On 4/30/2008 11:56 AM, Michael wrote: On 29 Apr 2008, Duncan Murdoch wrote: Right, you don't need to set the system path for everything, but you do need to set it in CMD (or other shell) before running Rcmd. For Win 2K/XP/Vista, the system path can be set (through the GUI interface, not sure how to do it with scripts) without restarting, for new CMD processes started afterwards. Sure, but the installer doesn't know how to do that. It just sets the path in the registry; it doesn't know how to give Explorer a kick to get it to reload from there. As far as I know there's no documented way to do that. FWIW the PATH setting is effective immediately (at least on 2k/ XP ...). Any new shell you start (e.g. using Run..) will have the updated PATH already. Does that happen with the Rtools installer? I didn't know that. I thought explorer only changes the PATH at startup, or when you edit it from the control panel. Duncan I was always very skeptical as editing PATH in the installer is concerned (and I have always declined any automated changes), but I really love the feature that allows me to edit the whole PATH interactively in an editor-like window. Also note that the rebooting is optional, you can still safely decline it so I see no reason why that should deter anyone. Cheers, Simon __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] build packages with vignettes in Windows
On Apr 30, 2008, at 4:29 PM, Duncan Murdoch wrote: On 4/30/2008 4:01 PM, Simon Urbanek wrote: On Apr 30, 2008, at 2:31 PM, Duncan Murdoch wrote: On 4/30/2008 11:56 AM, Michael wrote: On 29 Apr 2008, Duncan Murdoch wrote: Right, you don't need to set the system path for everything, but you do need to set it in CMD (or other shell) before running Rcmd. For Win 2K/XP/Vista, the system path can be set (through the GUI interface, not sure how to do it with scripts) without restarting, for new CMD processes started afterwards. Sure, but the installer doesn't know how to do that. It just sets the path in the registry; it doesn't know how to give Explorer a kick to get it to reload from there. As far as I know there's no documented way to do that. FWIW the PATH setting is effective immediately (at least on 2k/ XP ...). Any new shell you start (e.g. using Run..) will have the updated PATH already. Does that happen with the Rtools installer? I didn't know that. I thought explorer only changes the PATH at startup, or when you edit it from the control panel. Hmm I thought it did, but a subsequent test shows it doesn't. Apparently I must have triggered a change in the Control Panel so PATH was updated even before reboot. Anyway, there are free tools with source that show how to send a broadcast message to make that change active immediately, e.g.: http://www.codeproject.com/KB/applications/SetEnv.aspx?fid=230498&df=90&mpp=25&noise=3&sort=Position&view=Quick&select=1531752&fr=48 BTW: By testing this I found out that the Rtools installer is not as smart as it could be - when you run it a second time it will duplicate the paths. Cheers, Simon I was always very skeptical as editing PATH in the installer is concerned (and I have always declined any automated changes), but I really love the feature that allows me to edit the whole PATH interactively in an editor-like window. Also note that the rebooting is optional, you can still safely decline it so I see no reason why that should deter anyone. Cheers, Simon __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] New version of X11, png and jpeg
On Wed, Apr 30, 2008 at 10:26 AM, Maarten Blaauw <[EMAIL PROTECTED]> wrote: > > The now default Cairo results in much prettier graphs, but dense graphs > such > as plot(rnorm(1e4)) take considerably longer to plot than using > X11(type="Xlib"). This has already been mentioned, but I was wondering if > we > users could expect Cairo speed increases in the near future? > I'm skeptical that the base performance of the Cairo library will improve much, but there has long been talk of a hardware-accelerated backend. Most recently, someone came up with one based on OpenVG (and its ShivaVG implementation using OpenGL and C). It's a long way from being part of base Cairo (or even released on its own). Of course, it would really help to optimize at a higher level (e.g. use caching to avoid re-rendering the same glyph thousands of times). I've also thought about using a vector-based API directly on top of OpenGL, like what Qt (and now the clutter project) has, but that's getting off-topic. > > >Slower under some circumstances (although on the test systems much faster > than packages Cairo and cairoDevice). This will be particularly true for > X11() with a slow connection between the machine running R and the X > server. > > Using R 2.7.0 on Ubuntu 8.04 (Pentium 4 1.70 GHz on one machine and > Centrino > Duo on another) > -- > View this message in context: > http://www.nabble.com/New-version-of-X11%2C-png-and-jpeg-tp15672580p16987759.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 > [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] New version of X11, png and jpeg
On Wed, 30 Apr 2008, Maarten Blaauw wrote: The now default Cairo results in much prettier graphs, but dense graphs such as plot(rnorm(1e4)) take considerably longer to plot than using X11(type="Xlib"). This has already been mentioned, but I was wondering if we users could expect Cairo speed increases in the near future? Some. As Michael Lawrence has already said, cairo speed is an issue and unlilkely to improve any time soon. And anti-aliasing takes some CPU time. What we can do is to reduce the information passing between R and the X server. I already have timer-based double buffering running (the same scheme as on Windows), and that helps a lot in the circumstances mentioned (lots of small symbols). There are some event-loop-interface issues to sort out before it get committed to R-devel. type="nbcairo" is likely to be faster in your example, but not as fast as the buffered device planned for 2.8.0. The X11 server does make quite a difference -- I am running fairly decent Nvidia cards with the Nvidia X server module, and that has much higher performance than the vanilla one that Fedora ships. In the end the reason we offer a choice of types is that there are different needs on the quality vs speed axis. Slower under some circumstances (although on the test systems much faster than packages Cairo and cairoDevice). This will be particularly true for X11() with a slow connection between the machine running R and the X server. Using R 2.7.0 on Ubuntu 8.04 (Pentium 4 1.70 GHz on one machine and Centrino Duo on another) -- View this message in context: http://www.nabble.com/New-version-of-X11%2C-png-and-jpeg-tp15672580p16987759.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 -- 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 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Quotation marks (PR#11353)
On Wed, 30 Apr 2008, hadley wickham wrote:
Single (') and double (") quotation marks are not being read as quotation marks
when commands are copied from Word; they produce an error message whenever they
are used. To correct this, one has to retype everything in the R console. I
tried using courier new, as well as the good old fashioned Times New Roman, but
nothing seemed to work.
Try turning off smart quotes.
(In Word.)
Put another way, what you are pasting are not ASCII quotation marks (as
shown in your message) but unidirectional quotes, and they are not
interpreted as quotation marks by the R parser.
Our students fairly rapidly get out of the habit of preparing R scripts in
Word and use a syntax-aware editor -- usually Emacs+ESS -- because they
see the benefits of e.g. parenthesis matching, automatic indentation etc.
--
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
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
