[Rd] double-quote tab crashes R (PR#9058)
Hi, This seems to crash my version of R: " where I type a double quote, and then hit the key. I was playing with strsplit, and wanted to give it a vector of characters including newline, tab, space, and so on. I've included the trace info from my macBook Pro (intel macintosh). Date/Time: 2006-07-04 01:07:33.277 -0700 OS Version: 10.4.7 (Build 8J2135a) Report Version: 4 Command: R Path:/Applications/R.app/Contents/MacOS/R Parent: WindowServer [90] Version: 1.16 (3198) PID:1698 Thread: 0 Exception: EXC_BREAKPOINT (0x0006) Code[0]:0x0002 Code[1]:0x Thread 0 Crashed: 0 com.apple.Foundation 0x9275c2d3 _NSRaiseError + 227 1 com.apple.Foundation 0x92782fd7 +[NSException raise:format:] + 57 2 com.apple.Foundation 0x9272c08b -[NSString substringFromIndex:] + 196 3 org.R-project.R 0x000331a4 +[FileCompletion completeAll:cutPrefix:] + 684 (crt.c:305) 4 org.R-project.R 0x00011745 -[RController textView:completions:forPartialWordRange:indexOfSelectedItem:] + 586 (crt.c:305) 5 com.apple.AppKit 0x93808d15 -[NSTextView(NSKeyBindingCommands) completionsForPartialWordRange:indexOfSelectedItem:] + 1002 6 com.apple.AppKit 0x93808202 -[NSTextView(NSKeyBindingCommands) complete:] + 317 7 org.R-project.R 0x00011f8f -[RController textView:doCommandBySelector:] + 1344 (crt.c:305) 8 com.apple.AppKit 0x9346e1bf -[NSTextView doCommandBySelector:] + 182 9 com.apple.AppKit 0x93463965 -[NSKeyBindingManager(NSKeyBindingManager_MultiClients) interpretEventAsCommand:forClient:] + 1932 10 com.apple.AppKit 0x93461ed1 -[NSTSMInputContext interpretKeyEvents:] + 1157 11 com.apple.AppKit 0x93461276 -[NSView interpretKeyEvents:] + 65 12 com.apple.AppKit 0x93461164 -[NSTextView keyDown:] + 1061 13 org.R-project.R 0x0001c2e4 -[RTextView keyDown:] + 150 (crt.c:305) 14 com.apple.AppKit 0x93460ce9 -[NSWindow sendEvent:] + 7377 15 com.apple.AppKit 0x93452524 -[NSApplication sendEvent:] + 5023 16 org.R-project.R 0xdfbe -[RController doProcessEvents:] + 278 (crt.c:305) 17 org.R-project.R 0xb5be -[RController handleReadConsole:] + 84 (crt.c:305) 18 org.R-project.R 0x0002f096 Re_ReadConsole + 423 (crt.c:305) 19 org.R-project.R 0x000355bb run_REngineRmainloop + 516 (crt.c:305) 20 org.R-project.R 0x0002d9f7 -[REngine runREPL] + 49 (crt.c:305) 21 org.R-project.R 0x0001f66d main + 616 (crt.c:305) 22 org.R-project.R 0x200e _start + 228 (crt.c:272) 23 org.R-project.R 0x1f29 start + 41 Thread 1: 0 libSystem.B.dylib0x9000a5c7 mach_msg_trap + 7 1 com.apple.CoreFoundation 0x9082369a CFRunLoopRunSpecific + 2014 2 com.apple.CoreFoundation 0x90822eb5 CFRunLoopRunInMode + 61 3 com.apple.Foundation 0x92778559 -[NSConnection sendInvocation:] + 2126 4 com.apple.Foundation 0x9272f324 -[NSObject(NSForwardInvocation) forward::] + 469 5 libobjc.A.dylib 0x90a51ba1 _objc_msgForward + 49 6 com.apple.Foundation 0x9277798b -[NSDistantObject methodSignatureForSelector:] + 211 7 com.apple.Foundation 0x9272f1b0 -[NSObject(NSForwardInvocation) forward::] + 97 8 libobjc.A.dylib 0x90a51ba1 _objc_msgForward + 49 9 org.R-project.R 0xa596 -[RController readThread:] + 1609 (crt.c:305) 10 com.apple.Foundation 0x927291b0 forkThreadForFunction + 123 11 libSystem.B.dylib0x90024b07 _pthread_body + 84 Thread 2: 0 libSystem.B.dylib0x900251a7 semaphore_wait_signal_trap + 7 1 com.apple.Foundation 0x9277f008 -[NSConditionLock lockWhenCondition:] + 39 2 com.apple.AppKit 0x9345a374 -[NSUIHeartBeat _heartBeatThread:] + 377 3 com.apple.Foundation 0x927291b0 forkThreadForFunction + 123 4 libSystem.B.dylib0x90024b07 _pthread_body + 84 Thread 0 crashed with i386 Thread State: eax: 0x0032c000ebx: 0x9275c1fe ecx:0x90a5b9f8 edx: 0x15c05020 edi: 0x0212f5e0esi: 0x0212f6f0 ebp:0xb528 esp: 0xb4c0 ss: 0x002fefl: 0x0246 eip:0x9275c2d3 cs: 0x0027 ds: 0x002f es: 0x002f fs:0x gs: 0x0037 Binary Images Description: 0x1000 -0x49fff org.R-project.R 1.16 (3198) /Applications/R.app/Contents/MacOS/R 0x65000 -0x6cfff libgcc_s.1.0.dylib /Library/Frameworks/R.framework/Versions/2.3/Resources/lib/libgcc_s.1.0.dylib 0x8c000 -0xa9fff libreadline.5.1.dylib /Library/Frameworks/R.framework/Versions/2.3/Resources/lib/libreadline.5.1.dylib 0x205000 - 0x252fff libgfortran.0.dylib /Library/Frameworks/R.framework/Versions/2.3/Resources/lib/libgfortran.0.dylib 0x1008000 - 0x13d libR.dylib /Library/Frameworks/R.framewor
[Rd] options("quit.with.no.save"), and Windows installer changes
I've just committed a couple of changes to R-devel related to requests
at userR about the Windows installer. The first of these affects all
platforms, but I've only tested it on Windows:
I added an option "quit.with.no.save". If TRUE, then the default
q("ask") prompt will not offer to save the workspace. This is in
response to the observation that new users who are instructed not to
save their workspace, get confused when they accidentally answer Yes to
the prompt to save it.
I'm not sure about the wording of the user prompt question, which is now
"Quit and discard workspace?". The problem with this wording is that
someone who automatically hits "y" will lose their work. I've tried on
Windows to make the dialog box look different enough that they should be
warned.
I haven't made any change to the Mac GUI to support this. On
Unix-alikes, the text prompt should respect this option.
The other change is to the Windows installer, to allow the user to
choose whether to set quit.with.no.save, MDI/SDI display, and help style
at install time. The only (intentional) change to the current behaviour
is to default to CHM help instead of plain text.
These changes will show up in builds based on revision 38480 or later.
Duncan Murdoch
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] options("quit.with.no.save"), and Windows installer changes
> "Duncan" == Duncan Murdoch <[EMAIL PROTECTED]>
> on Tue, 04 Jul 2006 08:32:08 -0400 writes:
Duncan> I've just committed a couple of changes to R-devel related to
requests
Duncan> at userR about the Windows installer. The first of these affects
all
Duncan> platforms, but I've only tested it on Windows:
Duncan> I added an option "quit.with.no.save". If TRUE,
Duncan> then the default q("ask") prompt will not offer to
Duncan> save the workspace. This is in response to the
Duncan> observation that new users who are instructed not to
Duncan> save their workspace, get confused when they
Duncan> accidentally answer Yes to the prompt to save it.
Ok... but I probably misunderstand a bit:
The default has not been q(save = "ask") but q(save = "default"),
and that default has depended on startup.
Even now, "R --no-save" already did have the desired effect,
on Unix at least. For my ESS setup, I have made this an automatic
default many months ago.
Wouldn't it be easier and sufficient to make "--no-save" a
working option on all platforms ?
Or is the point really about changing the quitting dialog?
For me quitting *without* a dialog is the most important thing
which I use (often several times a day).
Duncan> I'm not sure about the wording of the user prompt
Duncan> question, which is now "Quit and discard
Duncan> workspace?". The problem with this wording is that
Duncan> someone who automatically hits "y" will lose their
Duncan> work. I've tried on Windows to make the dialog box
Duncan> look different enough that they should be warned.
good!
Duncan> I haven't made any change to the Mac GUI to support this. On
Duncan> Unix-alikes, the text prompt should respect this option.
Duncan> The other change is to the Windows installer, to
Duncan> allow the user to choose whether to set
Duncan> quit.with.no.save, MDI/SDI display, and help style
Duncan> at install time. The only (intentional) change to
Duncan> the current behaviour is to default to CHM help
Duncan> instead of plain text.
People have asked me in private about this, and I didn't know
the answer:
Is it true that this means that people can no longer commit the
"cheap package install trick" on Windows for R-code-only
packages?
Namely
1) install a source package on a Linux/Unix/MacOSX machine
(where it is often simple to have all the necessary tools available)
2) zip the resulting installed package
3) unzip it on the target Windows machine into the corresponding
library (directory).
Of course, this trick will not provide any *.chm help files.
Will the cheap-installed package still work, using the *.txt (or
*.html) help files?
Duncan> These changes will show up in builds based on
Duncan> revision 38480 or later.
Duncan> Duncan Murdoch
Thanks a lot, Duncan!
Duncan> __
Duncan> R-devel@r-project.org mailing list
Duncan> https://stat.ethz.ch/mailman/listinfo/r-devel
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] problem getting R 2.3.1 svn r38481 to pass make check-all
Hi,
I noticed this problem on my home desktop running FC4 and again on my
laptop running FC5. Both have previously compiled and passed make
check-all on 2.3.1 svn revisions from 10 days ago or so. On both these
machines, make check-all is consistently failing (4 out of 4 attempts on
the FC 4 desktop and 3 out of 3 on the FC 5 laptop) in the
p-r-random-tests tests. This is with both default compiler flags and
extra flags set in config.site.
R is failing make check-all with the following set of messages:
...
make[3]: Entering directory `/home/gavin/R/2.3-patches/build/tests'
running code in '../../tests/p-r-random-tests.R' ... OK
comparing 'p-r-random-tests.Rout' to
'../../tests/p-r-random-tests.Rout.save' ...1a2,16
> R version 2.4.0 Under development (unstable) (2006-06-30 r38463)
> Copyright (C) 2006 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.
254a270,274
> > ## regression test for non-central t bug
> > dkwtest("t", df=20, ncp=3)
> t(df = 20, ncp = 3) PASSED
> [1] TRUE
> >
make[3]: *** [p-r-random-tests.Rout] Error 1
make[3]: Leaving directory `/home/gavin/R/2.3-patches/build/tests'
make[2]: *** [test-Random] Error 2
make[2]: Leaving directory `/home/gavin/R/2.3-patches/build/tests'
make[1]: *** [test-all-devel] Error 1
make[1]: Leaving directory `/home/gavin/R/2.3-patches/build/tests'
make: *** [check-all] Error 2
I looked in ./tests/p-r-random-tests.Rout.fail and couldn't see anything
that indicated a failure - everything had PASSED or TRUE as results of
the tests. I append the contents of this file below.
Anyone see what is wrong?
Thanks in advance,
Gavin
## Contents of p-r-random-tests.Rout.fail ##
R : Copyright 2006, The R Foundation for Statistical Computing
Version 2.3.1 Patched (2006-07-03 r38481)
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.
> ##
> ## RNG tests using DKW inequality for rate of convergence
> ##
> ## P(sup | F_n - F | > t) < 2 exp(-2nt^2)
> ##
> ## The 2 in front of exp() was derived by Massart. It is the best
possible
> ## constant valid uniformly in t,n,F. For large n*t^2 this agrees with
the
> ## large-sample approximation to the Kolmogorov-Smirnov statistic.
> ##
>
>
> superror <- function(rfoo,pfoo,sample.size,...) {
+ x <- rfoo(sample.size,...)
+ tx <- table(x)
+ xi <- as.numeric(names(tx))
+ f <- pfoo(xi,...)
+ fhat <- cumsum(tx)/sample.size
+ max(abs(fhat-f))
+ }
>
> pdkwbound <- function(n,t) 2*exp(-2*n*t*t)
>
> qdkwbound <- function(n,p) sqrt(log(p/2)/(-2*n))
>
> dkwtest <- function(stub = "norm", ...,
+ sample.size = 1, pthreshold = 0.001,
+ print.result = TRUE, print.detail = FALSE,
+ stop.on.failure = TRUE)
+ {
+ rfoo <- eval(as.name(paste("r", stub, sep="")))
+ pfoo <- eval(as.name(paste("p", stub, sep="")))
+ s <- superror(rfoo, pfoo, sample.size, ...)
+ if (print.result || print.detail) {
+ printargs <- substitute(list(...))
+ printargs[[1]] <- as.name(stub)
+ cat(deparse(printargs))
+ if (print.detail)
+ cat("\nsupremum error = ",signif(s,2),
+ " with
p-value=",min(1,round(pdkwbound(sample.size,s),4)),"\n")
+ }
+ rval <- (s < qdkwbound(sample.size,pthreshold))
+ if (print.result)
+ cat(c(" FAILED\n"," PASSED\n",)[rval+1])
+ if (stop.on.failure && !rval)
+ stop("dkwtest failed")
+ rval
+ }
>
> .proctime00 <- proc.time() # start timing
>
>
> dkwtest("binom",size = 1,prob = 0.2)
binom(size = 1, prob = 0.2) PASSED
[1] TRUE
> dkwtest("binom",size = 2,prob = 0.2)
binom(size = 2, prob = 0.2) PASSED
[1] TRUE
> dkwtest("binom",size = 100,prob = 0.2)
binom(size = 100, prob = 0.2) PASSED
[1] TRUE
> dkwtest("binom",size = 1e4,prob = 0.2)
binom(size = 1, prob = 0.2) PASSED
[1] TRUE
> dkwtest("binom",size = 1,prob = 0.8)
binom(size = 1, prob = 0.8) PASSED
[1] TRUE
> dkwtest("binom",size = 100,prob = 0.8)
binom(size = 100, prob = 0.8) PASSED
[1] TRUE
> dkwtest("binom",size = 100,prob = 0.999)
binom(size = 1
Re: [Rd] options("quit.with.no.save"), and Windows installer changes
On 7/4/2006 11:15 AM, Martin Maechler wrote:
>> "Duncan" == Duncan Murdoch <[EMAIL PROTECTED]>
>> on Tue, 04 Jul 2006 08:32:08 -0400 writes:
>
> Duncan> I've just committed a couple of changes to R-devel related to
> requests
> Duncan> at userR about the Windows installer. The first of these affects
> all
> Duncan> platforms, but I've only tested it on Windows:
>
> Duncan> I added an option "quit.with.no.save". If TRUE,
> Duncan> then the default q("ask") prompt will not offer to
> Duncan> save the workspace. This is in response to the
> Duncan> observation that new users who are instructed not to
> Duncan> save their workspace, get confused when they
> Duncan> accidentally answer Yes to the prompt to save it.
>
> Ok... but I probably misunderstand a bit:
>
> The default has not been q(save = "ask") but q(save = "default"),
> and that default has depended on startup.
>
> Even now, "R --no-save" already did have the desired effect,
> on Unix at least. For my ESS setup, I have made this an automatic
> default many months ago.
>
> Wouldn't it be easier and sufficient to make "--no-save" a
> working option on all platforms ?
> Or is the point really about changing the quitting dialog?
> For me quitting *without* a dialog is the most important thing
> which I use (often several times a day).
Yes, that's the point. In the Windows GUI it's pretty easy to quit by
mistake (click on the Close button, which sits right next to the
Maximize button on the window frame). It would not be a good idea if
this resulted in the immediate loss of the workspace, so Windows
programs normally warn if there will be a loss of data when quitting.
>
> Duncan> I'm not sure about the wording of the user prompt
> Duncan> question, which is now "Quit and discard
> Duncan> workspace?". The problem with this wording is that
> Duncan> someone who automatically hits "y" will lose their
> Duncan> work. I've tried on Windows to make the dialog box
> Duncan> look different enough that they should be warned.
>
> good!
>
> Duncan> I haven't made any change to the Mac GUI to support this. On
> Duncan> Unix-alikes, the text prompt should respect this option.
>
> Duncan> The other change is to the Windows installer, to
> Duncan> allow the user to choose whether to set
> Duncan> quit.with.no.save, MDI/SDI display, and help style
> Duncan> at install time. The only (intentional) change to
> Duncan> the current behaviour is to default to CHM help
> Duncan> instead of plain text.
>
> People have asked me in private about this, and I didn't know
> the answer:
> Is it true that this means that people can no longer commit the
> "cheap package install trick" on Windows for R-code-only
> packages?
> Namely
> 1) install a source package on a Linux/Unix/MacOSX machine
> (where it is often simple to have all the necessary tools available)
> 2) zip the resulting installed package
> 3) unzip it on the target Windows machine into the corresponding
> library (directory).
I don't know what currently happens if you do that, but I can't see how
it would work for anyone who sets options(chmhelp=TRUE). People who
build binary packages should use the appropriate tools to do it.
There is something called "chmlib" available for Linux, but I've got no
idea whether it is usable.
> Of course, this trick will not provide any *.chm help files.
> Will the cheap-installed package still work, using the *.txt (or
> *.html) help files?
Show me one and I'll tell you what happens. I think it would be
reasonable behaviour to default to the text help in a case like this,
but I don't know if that would be easy. I do tend to think a patch like
that should come from someone who chooses not to use the tools we
provide for doing proper package builds.
> Duncan> These changes will show up in builds based on
> Duncan> revision 38480 or later.
>
> Duncan> Duncan Murdoch
>
> Thanks a lot, Duncan!
>
>
> Duncan> __
> Duncan> R-devel@r-project.org mailing list
> Duncan> 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] [R] zero.print in print.table after adding margins
> "MM" == Martin Maechler <[EMAIL PROTECTED]>
> on Fri, 30 Jun 2006 17:09:32 +0200 writes:
> "PD" == Peter Dalgaard <[EMAIL PROTECTED]>
> on 29 Jun 2006 12:18:13 +0200 writes:
PD> "BXC (Bendix Carstensen)" <[EMAIL PROTECTED]> writes:
BXC> The function addmargins() adds margins to a table, but returns a
matrix.
BXC> But even after converted to a table the print.zero="." option of
BXC> print.table() does not work:
BXC>
BXC> > x <- sample( 1:7, 20, replace=T )
BXC> > y <- sample( 1:7, 20, replace=T )
BXC> > tt <- table( x, y )
BXC> > tx <- as.table( addmargins( table( x, y ) ) )
BXC> > print( tt, zero.print="." )
BXC>y
BXC> x 1 2 3 4 5 6 7
BXC> 1 1 2 2 . . 1 .
BXC> 2 1 . . 1 . . .
BXC> 3 . . . . . . 2
BXC> 4 1 . . . . 1 .
BXC> 5 1 . 1 . . 1 .
BXC> 6 . 1 . 1 . . .
BXC> 7 . . 1 . 1 1 .
BXC> > print( tx, zero.print="." )
BXC> y
BXC> x 1 2 3 4 5 6 7 Sum
BXC> 11 2 2 0 0 1 0 6
BXC> 21 0 0 1 0 0 0 2
BXC> 30 0 0 0 0 0 2 2
BXC> 41 0 0 0 0 1 0 2
BXC> 51 0 1 0 0 1 0 3
BXC> 60 1 0 1 0 0 0 2
BXC> 70 0 1 0 1 1 0 3
BXC> Sum 4 3 4 2 1 4 2 20
BXC>
BXC> Is this a facility of print.table?
BXC> The attributes() of tt and tx have identical stucture.
PD> It appears to be intentional.
PD>
PD> print.table has
PD>
PD> if (is.integer(x) && zero.print != "0" && any(i0 <- !ina &
PD> x == 0))
PD> xx[i0] <- sub("0", zero.print, xx[i0])
PD>
PD> and of course,
PD>
PD> > storage.mode(tx)
PD> [1] "double"
PD> > storage.mode(tt)
PD> [1] "integer"
PD>
PD> The reason could be that it is not entirely clear what to expect for
PD> values that are zero up to round-off.
PD>
PD> storage.mode(tx) <- "integer" fixes things up.
MM> On the other hand, I'm pretty sure I was the one who added
MM> 'zero.print' and I don't oppose at all to change
MM> is.integer(x) to all(x == round(x))
MM> {and then for efficiency swap the *order* of the tests inside that
if(.)}
MM> which I think would be a bit more convenient and still ok (*)
MM> here.
MM> Martin Maechler, ETH Zurich
MM> (*) yes, one could then construct artificial cases where the
MM> if(.) test would ``conceptually'' be wrong, but I think that
MM> would not matter for all practical cases.
In R-devel,
- addmargins(x, ...) now returns a "table" when 'x' was one.
- print.table(x, zero.print = ch) now also ``zero-prints'' when
'x' is not "integer" but numeric with integer values.
Bendix' original example can now be slightly shortened *and*
works as desired (in R-devel, aka 2.4.0 -- to-be):
> set.seed(1)
> x <- sample( 1:7, 20, replace=TRUE)
> y <- sample( 1:7, 20, replace=TRUE)
> tx <- addmargins( table(x, y) )
> print(tx, zero.print = ".")
y
x 1 2 3 4 5 6 7 Sum
1. . 1 . . . . 1
2. 1 . 1 1 . 1 4
3. 2 . . . 1 . 3
4. . . . 1 . . 1
5. . 1 1 1 . 1 4
6. . 1 . . 2 . 3
73 . 1 . . . . 4
Sum 3 3 4 2 3 3 2 20
>
Hoping, this will be useful..
Martin Maechler, ETH Zurich
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] options("quit.with.no.save"), and Windows installer changes
Martin Maechler wrote:
>> "Duncan" == Duncan Murdoch <[EMAIL PROTECTED]>
>> on Tue, 04 Jul 2006 08:32:08 -0400 writes:
>
> Duncan> I've just committed a couple of changes to R-devel related to
> requests
> Duncan> at userR about the Windows installer. The first of these affects
> all
> Duncan> platforms, but I've only tested it on Windows:
>
> Duncan> I added an option "quit.with.no.save". If TRUE,
> Duncan> then the default q("ask") prompt will not offer to
> Duncan> save the workspace. This is in response to the
> Duncan> observation that new users who are instructed not to
> Duncan> save their workspace, get confused when they
> Duncan> accidentally answer Yes to the prompt to save it.
>
> Ok... but I probably misunderstand a bit:
>
> The default has not been q(save = "ask") but q(save = "default"),
> and that default has depended on startup.
>
> Even now, "R --no-save" already did have the desired effect,
> on Unix at least. For my ESS setup, I have made this an automatic
> default many months ago.
>
> Wouldn't it be easier and sufficient to make "--no-save" a
> working option on all platforms ?
> Or is the point really about changing the quitting dialog?
> For me quitting *without* a dialog is the most important thing
> which I use (often several times a day).
>
> Duncan> I'm not sure about the wording of the user prompt
> Duncan> question, which is now "Quit and discard
> Duncan> workspace?". The problem with this wording is that
> Duncan> someone who automatically hits "y" will lose their
> Duncan> work. I've tried on Windows to make the dialog box
> Duncan> look different enough that they should be warned.
>
> good!
>
> Duncan> I haven't made any change to the Mac GUI to support this. On
> Duncan> Unix-alikes, the text prompt should respect this option.
>
> Duncan> The other change is to the Windows installer, to
> Duncan> allow the user to choose whether to set
> Duncan> quit.with.no.save, MDI/SDI display, and help style
> Duncan> at install time. The only (intentional) change to
> Duncan> the current behaviour is to default to CHM help
> Duncan> instead of plain text.
>
> People have asked me in private about this, and I didn't know
> the answer:
> Is it true that this means that people can no longer commit the
> "cheap package install trick" on Windows for R-code-only
> packages?
> Namely
> 1) install a source package on a Linux/Unix/MacOSX machine
> (where it is often simple to have all the necessary tools available)
> 2) zip the resulting installed package
> 3) unzip it on the target Windows machine into the corresponding
> library (directory).
>
> Of course, this trick will not provide any *.chm help files.
> Will the cheap-installed package still work, using the *.txt (or
> *.html) help files?
Well, the user has to ask
help(topic, chmhelp = FALSE)
in this case, or (s)he get the message:
No CHM help for 'foo' in package 'pkg' is available:
the CHM file for the package is missing
Perhaps it is possible to arrange some fallback to plain text help if
chmhelp is not available: in print.help_files_with_topic call print() on
the "help_files_with_topic" object again, but change attribute "type" to
"help" before that call ...
Uwe Ligges
> Duncan> These changes will show up in builds based on
> Duncan> revision 38480 or later.
>
> Duncan> Duncan Murdoch
>
> Thanks a lot, Duncan!
>
>
> Duncan> __
> Duncan> R-devel@r-project.org mailing list
> Duncan> https://stat.ethz.ch/mailman/listinfo/r-devel
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] options("quit.with.no.save"), and Windows installer changes
On Jul 4, 2006, at 11:15 AM, Martin Maechler wrote:
>> "Duncan" == Duncan Murdoch <[EMAIL PROTECTED]>
>> on Tue, 04 Jul 2006 08:32:08 -0400 writes:
>
> Duncan> I've just committed a couple of changes to R-devel
> related to requests
> Duncan> at userR about the Windows installer. The first of
> these affects all
> Duncan> platforms, but I've only tested it on Windows:
>
> Duncan> I added an option "quit.with.no.save". If TRUE,
> Duncan> then the default q("ask") prompt will not offer to
> Duncan> save the workspace. This is in response to the
> Duncan> observation that new users who are instructed not to
> Duncan> save their workspace, get confused when they
> Duncan> accidentally answer Yes to the prompt to save it.
>
> Ok... but I probably misunderstand a bit:
>
> The default has not been q(save = "ask") but q(save = "default"),
> and that default has depended on startup.
>
> Even now, "R --no-save" already did have the desired effect,
> on Unix at least. For my ESS setup, I have made this an automatic
> default many months ago.
>
> Wouldn't it be easier and sufficient to make "--no-save" a working
> option on all platforms ?
> Or is the point really about changing the quitting dialog?
> For me quitting *without* a dialog is the most important thing
> which I use (often several times a day).
>
I agree - it would be even nicer if there was a way to enable --no-
save with some environment variable ...
However, I think Duncan's approach is a very bad idea, because it
means that with the same answer will give you opposite result. This
is a big UI no-no. (Windows users may may think it's a valid option,
because Microsoft tends to do stupid things like that, but that's
only because they never think about UI).
The correct approach is to change the default button, but definitely
not the dialog box.
Speaking of default buttons - is there a specific reason why hitting
at the prompt is not a valid answer in the console? It would
be nice to have let's say Enter=y, ^D=no, ^C=cancel (the last one
works already).
In the Mac GUI the behavior is well-defined and compatible with all
Mac applications (Enter=Save, Esc=Cancel, Cmd+D=Don's save) - doesn't
Windows define something system-wide like that?
BTW: back to the original issue that Duncan raised - isn't the actual
problem rather the fact that once you saved an image you cannot get
rid of it? Unless you know the "internals", namely that it's a file
named .RData, you can't discard it. There is no way to say "discard
saved workspace". Maybe that's what should be addressed instead...
> Duncan> I'm not sure about the wording of the user prompt
> Duncan> question, which is now "Quit and discard
> Duncan> workspace?". The problem with this wording is that
> Duncan> someone who automatically hits "y" will lose their
> Duncan> work. I've tried on Windows to make the dialog box
> Duncan> look different enough that they should be warned.
>
> good!
>
Since when do people read text in dialog boxes ;)? Especially those
that have been there for ages ;).
Cheers,
Simon
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] options("quit.with.no.save"), and Windows installer changes
On 4 July 2006 at 08:32, Duncan Murdoch wrote: | at install time. The only (intentional) change to the current behaviour | is to default to CHM help instead of plain text. Some people may take offence with the fact that a non-open-source tool is now required to build GNU R on the Windows platform. I liked the old setting where you could use the chm compiler, if installed, but could live quite well without it too. Dirk -- Hell, there are no rules here - we're trying to accomplish something. -- Thomas A. Edison __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Final patch for bug 8141 - rewriting substituteList
Hi, Attached is both the patch and a gzipped version of the patch that is the fix for bug 8141 - rewriting substituteList in coerce.c to use a loop instead of recursion to walk the list. The new version passes all of my tests (make check-all, etc) and I have used it with no negative impact to my work (as verified by comparing before and after tests) so far. The new version fixes the C-stack overflow problem documented in the 8141 bug report. [EMAIL PROTECTED] ~]$ cat test.r dfn <- rep(list(rep(0,2)),30) test <- as.data.frame.list(dfn) which no longer fails on the development tree with this patch in place. I realize it is hard to verify this patch as correct since it converts recursion back into a loop. There has been no official code review as far as I can tell by anyone so far. So perhaps it could be introduced into 2.4.0 with an environment variable switch to allow users to switch back to the old version to add more evidence as to its correctness. As I said, I have used the patch without problems in my day to day work. Also, if there are other annoying low level bugs out there people would like tracked down and fixed, please point me at them. Kevin bug_8141.patch.gz Description: GNU Zip compressed data __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] options("quit.with.no.save"), and Windows installer changes
On 7/4/2006 1:26 PM, Dirk Eddelbuettel wrote: > On 4 July 2006 at 08:32, Duncan Murdoch wrote: > | at install time. The only (intentional) change to the current behaviour > | is to default to CHM help instead of plain text. > > Some people may take offence with the fact that a non-open-source tool is now > required to build GNU R on the Windows platform. I liked the old setting > where you could use the chm compiler, if installed, but could live quite well > without it too. There's no change there. This just gets the installer to set an option in the default Rprofile file. If you don't use the installer, it won't be set, and you'll still default to plain text help. Duncan Murdoch __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] options("quit.with.no.save"), and Windows installer changes
On 7/4/2006 12:02 PM, Simon Urbanek wrote:
> On Jul 4, 2006, at 11:15 AM, Martin Maechler wrote:
>
>>> "Duncan" == Duncan Murdoch <[EMAIL PROTECTED]>
>>> on Tue, 04 Jul 2006 08:32:08 -0400 writes:
>>
>> Duncan> I've just committed a couple of changes to R-devel
>> related to requests
>> Duncan> at userR about the Windows installer. The first of
>> these affects all
>> Duncan> platforms, but I've only tested it on Windows:
>>
>> Duncan> I added an option "quit.with.no.save". If TRUE,
>> Duncan> then the default q("ask") prompt will not offer to
>> Duncan> save the workspace. This is in response to the
>> Duncan> observation that new users who are instructed not to
>> Duncan> save their workspace, get confused when they
>> Duncan> accidentally answer Yes to the prompt to save it.
>>
>> Ok... but I probably misunderstand a bit:
>>
>> The default has not been q(save = "ask") but q(save = "default"),
>> and that default has depended on startup.
>>
>> Even now, "R --no-save" already did have the desired effect,
>> on Unix at least. For my ESS setup, I have made this an automatic
>> default many months ago.
>>
>> Wouldn't it be easier and sufficient to make "--no-save" a working
>> option on all platforms ?
>> Or is the point really about changing the quitting dialog?
>> For me quitting *without* a dialog is the most important thing
>> which I use (often several times a day).
>>
>
> I agree - it would be even nicer if there was a way to enable --no-
> save with some environment variable ...
Environment variables in Windows are a mess. Doing things on the
command line or through option() is a lot easier.
> However, I think Duncan's approach is a very bad idea, because it
> means that with the same answer will give you opposite result. This
> is a big UI no-no. (Windows users may may think it's a valid option,
> because Microsoft tends to do stupid things like that, but that's
> only because they never think about UI).
I agree that that is a problem. However, I don't know a better solution:
- I want to make it hard for the user to accidentally create a saved
workspace. Just changing the default will mean that people who
habitually answer "yes" will still get the wrong result.
- I want to make it hard for the user to accidentally lose a
workspace. Hence --no-save is not an option.
The problem with my solution as it stands is that people who habitually
answer "yes" will sometimes accidentally lose a workspace.
> The correct approach is to change the default button, but definitely
> not the dialog box.
I don't think this is sufficient.
> Speaking of default buttons - is there a specific reason why hitting
> at the prompt is not a valid answer in the console? It would
> be nice to have let's say Enter=y, ^D=no, ^C=cancel (the last one
> works already).
> In the Mac GUI the behavior is well-defined and compatible with all
> Mac applications (Enter=Save, Esc=Cancel, Cmd+D=Don's save) - doesn't
> Windows define something system-wide like that?
>
> BTW: back to the original issue that Duncan raised - isn't the actual
> problem rather the fact that once you saved an image you cannot get
> rid of it? Unless you know the "internals", namely that it's a file
> named .RData, you can't discard it. There is no way to say "discard
> saved workspace". Maybe that's what should be addressed instead...
That's a good idea. Or perhaps instead of quit.with.no.save, we want
start.with.no.load, i.e. something like the --no-restore option.
Duncan Murdoch
>
>
>> Duncan> I'm not sure about the wording of the user prompt
>> Duncan> question, which is now "Quit and discard
>> Duncan> workspace?". The problem with this wording is that
>> Duncan> someone who automatically hits "y" will lose their
>> Duncan> work. I've tried on Windows to make the dialog box
>> Duncan> look different enough that they should be warned.
>>
>> good!
>>
>
> Since when do people read text in dialog boxes ;)? Especially those
> that have been there for ages ;).
>
> Cheers,
> Simon
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] options("quit.with.no.save"), and Windows installer changes
On 4 July 2006 at 15:36, Duncan Murdoch wrote: | On 7/4/2006 1:26 PM, Dirk Eddelbuettel wrote: | > On 4 July 2006 at 08:32, Duncan Murdoch wrote: | > | at install time. The only (intentional) change to the current behaviour | > | is to default to CHM help instead of plain text. | > | > Some people may take offence with the fact that a non-open-source tool is now | > required to build GNU R on the Windows platform. I liked the old setting | > where you could use the chm compiler, if installed, but could live quite well | > without it too. | | There's no change there. This just gets the installer to set an option | in the default Rprofile file. If you don't use the installer, it won't | be set, and you'll still default to plain text help. I am sorry. I misread your original mail as affecting the build process, not the installer. Please ignore my non-applicable complaint. Not enough coffee. Dirk -- Hell, there are no rules here - we're trying to accomplish something. -- Thomas A. Edison __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Classes and methods
Dear all, I have constructed a fairly large package and I wish to improve my code through the used of adapted classes and methods. 1- Is it a good idea to use S4 methods and classes ? e.g.: "setClass", "setMethod" and so forth >From what I have read it seems so! I have ordered J.M. Chambers book "programming with data, 1998" and I have read a very short and well writen document 13p. long entitled : Classes and Methods in the S Language, 2001. These documents are old, but based on R help definition .Rd files are obviously important references! 2- I hope I am still on the wright track... if not please let me know... Unfortunately, it will take two to six weeks before I receive the manual I have ordered. 3- Is there any other relevant and downloadable document out there that I could read meanwhile to improve my R skill using object-oriented techniques. Sincerly Sébastien Durand -- __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] options("quit.with.no.save"), and Windows installer changes
On 7/4/2006 11:57 AM, Uwe Ligges wrote:
> Martin Maechler wrote:
>>> "Duncan" == Duncan Murdoch <[EMAIL PROTECTED]>
>>> on Tue, 04 Jul 2006 08:32:08 -0400 writes:
>> Duncan> I've just committed a couple of changes to R-devel related to
>> requests
>> Duncan> at userR about the Windows installer. The first of these
>> affects all
>> Duncan> platforms, but I've only tested it on Windows:
>>
>> Duncan> I added an option "quit.with.no.save". If TRUE,
>> Duncan> then the default q("ask") prompt will not offer to
>> Duncan> save the workspace. This is in response to the
>> Duncan> observation that new users who are instructed not to
>> Duncan> save their workspace, get confused when they
>> Duncan> accidentally answer Yes to the prompt to save it.
>>
>> Ok... but I probably misunderstand a bit:
>>
>> The default has not been q(save = "ask") but q(save = "default"),
>> and that default has depended on startup.
>>
>> Even now, "R --no-save" already did have the desired effect,
>> on Unix at least. For my ESS setup, I have made this an automatic
>> default many months ago.
>>
>> Wouldn't it be easier and sufficient to make "--no-save" a
>> working option on all platforms ?
>> Or is the point really about changing the quitting dialog?
>> For me quitting *without* a dialog is the most important thing
>> which I use (often several times a day).
>>
>> Duncan> I'm not sure about the wording of the user prompt
>> Duncan> question, which is now "Quit and discard
>> Duncan> workspace?". The problem with this wording is that
>> Duncan> someone who automatically hits "y" will lose their
>> Duncan> work. I've tried on Windows to make the dialog box
>> Duncan> look different enough that they should be warned.
>>
>> good!
>>
>> Duncan> I haven't made any change to the Mac GUI to support this. On
>> Duncan> Unix-alikes, the text prompt should respect this option.
>>
>> Duncan> The other change is to the Windows installer, to
>> Duncan> allow the user to choose whether to set
>> Duncan> quit.with.no.save, MDI/SDI display, and help style
>> Duncan> at install time. The only (intentional) change to
>> Duncan> the current behaviour is to default to CHM help
>> Duncan> instead of plain text.
>>
>> People have asked me in private about this, and I didn't know
>> the answer:
>> Is it true that this means that people can no longer commit the
>> "cheap package install trick" on Windows for R-code-only
>> packages?
>> Namely
>> 1) install a source package on a Linux/Unix/MacOSX machine
>> (where it is often simple to have all the necessary tools available)
>> 2) zip the resulting installed package
>> 3) unzip it on the target Windows machine into the corresponding
>> library (directory).
>>
>> Of course, this trick will not provide any *.chm help files.
>> Will the cheap-installed package still work, using the *.txt (or
>> *.html) help files?
>
>
>
> Well, the user has to ask
> help(topic, chmhelp = FALSE)
> in this case, or (s)he get the message:
>
> No CHM help for 'foo' in package 'pkg' is available:
> the CHM file for the package is missing
>
> Perhaps it is possible to arrange some fallback to plain text help if
> chmhelp is not available: in print.help_files_with_topic call print() on
> the "help_files_with_topic" object again, but change attribute "type" to
> "help" before that call ...
Yes, that seems to work. I'll add that.
Duncan Murdoch
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] options("quit.with.no.save")
On Jul 4, 2006, at 3:38 PM, Duncan Murdoch wrote: >> I agree - it would be even nicer if there was a way to enable -- >> no- save with some environment variable ... > > Environment variables in Windows are a mess. Doing things on the > command line or through option() is a lot easier. > Although I disagree (about the mess), I was thinking mainly about unix here - I'd simply love to put something in my .profile that will prevent the annoying question ;). >> However, I think Duncan's approach is a very bad idea, because it >> means that with the same answer will give you opposite result. >> This is a big UI no-no. (Windows users may may think it's a valid >> option, because Microsoft tends to do stupid things like that, >> but that's only because they never think about UI). > > I agree that that is a problem. However, I don't know a better > solution: > - I want to make it hard for the user to accidentally create a > saved workspace. Just changing the default will mean that people > who habitually answer "yes" will still get the wrong result. I would argue that if someone 'habitually' ignores the default and selects yes, then it's his/her deliberate choice and likely not a new user, because a new user doesn't yet have such a habit - to the contrary, new users are the one most likely influenced by defaults. > - I want to make it hard for the user to accidentally lose a > workspace. Hence --no-save is not an option. > > The problem with my solution as it stands is that people who > habitually answer "yes" will sometimes accidentally lose a workspace. > .. and for the reason you stated I think that's a major problem! >> The correct approach is to change the default button, but >> definitely not the dialog box. > > I don't think this is sufficient. > Your solution may possibly be more efficient in solving the problem you described, but IMHO it causes a much bigger problem. I'd still prefer one save too many that any loss of data. Cheers, Simon __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] double-quote tab crashes R (PR#9058)
On Jul 4, 2006, at 4:26 AM, [EMAIL PROTECTED] wrote: > This seems to crash my version of R: " > Thanks. Now fixed in the GUI rev. 3283. There's still an open issue about the completion of empty names, but I need to dig more to solve that (at least it doesn't crash ;)). Cheers, Simon __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] options("quit.with.no.save")
On 7/4/2006 7:43 PM, Simon Urbanek wrote:
> On Jul 4, 2006, at 3:38 PM, Duncan Murdoch wrote:
>
>>> I agree - it would be even nicer if there was a way to enable --
>>> no- save with some environment variable ...
>> Environment variables in Windows are a mess. Doing things on the
>> command line or through option() is a lot easier.
>>
>
> Although I disagree (about the mess), I was thinking mainly about
> unix here - I'd simply love to put something in my .profile that will
> prevent the annoying question ;).
Put in an alias for R that adds --no-save?
>>> However, I think Duncan's approach is a very bad idea, because it
>>> means that with the same answer will give you opposite result.
>>> This is a big UI no-no. (Windows users may may think it's a valid
>>> option, because Microsoft tends to do stupid things like that,
>>> but that's only because they never think about UI).
>> I agree that that is a problem. However, I don't know a better
>> solution:
>> - I want to make it hard for the user to accidentally create a
>> saved workspace. Just changing the default will mean that people
>> who habitually answer "yes" will still get the wrong result.
>
> I would argue that if someone 'habitually' ignores the default and
> selects yes, then it's his/her deliberate choice and likely not a new
> user, because a new user doesn't yet have such a habit - to the
> contrary, new users are the one most likely influenced by defaults.
>
>
>> - I want to make it hard for the user to accidentally lose a
>> workspace. Hence --no-save is not an option.
>>
>> The problem with my solution as it stands is that people who
>> habitually answer "yes" will sometimes accidentally lose a workspace.
>>
>
> .. and for the reason you stated I think that's a major problem!
>
>
>>> The correct approach is to change the default button, but
>>> definitely not the dialog box.
>> I don't think this is sufficient.
>>
>
>
> Your solution may possibly be more efficient in solving the problem
> you described, but IMHO it causes a much bigger problem. I'd still
> prefer one save too many that any loss of data.
I was actually agreeing with you :-). I'm going to revert the
quit.with.no.save addition. I'm not sure what should go in instead, but
I think it's not just a rewording of the same sort of option.
As you said in your other message, the problem isn't really the
unnecessary save. That wastes a bit of disk space, but provides some
insurance against accidental data loss. The problem is the auto-load on
startup.
I could have the installer put the --no-restore on the Rgui command
line, but it would be cleaner to put something in the default Rprofile
file. Then the user could override it in their private .Rprofile or by
putting something on the command line.
At the same time, I could add an option to hold a default value for the
save parameter of q(), so q() could be q("no") for you.
What do you think of that? What would you name these two options?
Duncan Murdoch
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] attributes of environments
In the code below, e is an environment which we copy to f and then add attributes to e. Now f winds up with the same attributes. In other words it seems that the attributes are a property of the environment itself and not of the variable. Thus it appears we cannot have two environment variables that correspond to the original environment but with different attributes. I can understand if we changed a component of e then f would reflect that too but I am not sure that this is also desirable for attributes as they are not "in" the environment. Is that desirable? Is it a bug? No other class works that way AFAIK. Comments? > e <- new.env() > f <- e > attr(e, "X") <- "Y" # X is an attribute of e > f # f gets the same attribute !!! attr(,"X") [1] "Y" > R.version.string # Windows XP [1] "R version 2.4.0 Under development (unstable) (2006-07-04 r38480)" __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
