[Rd] Defaults for postscript()
The defaults for postscript() paper = "default" onefile = TRUE horizontal = TRUE (it seems) date from the days when people used to used this to send plots directly to a postscript printer via print.it=TRUE. I haven't done that for years, and it seems that our current generation of students don't even know the concept. It seems 'horizontal = TRUE' is particularly difficult to grasp. Given that I suspect almost all uses of postscript() are to produce plots to be viewed on-screen or incorporated into another document, a more appropriate set of defaults would be width = 7, height = 7 paper = "special" onefile = FALSE horizontal = FALSE which would have the advantage of using the same default aspect ratio for plots as all (?) other R graphics devices. Does anyone see a reason not to change the defaults? -- 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] Defaults for postscript()
On 12/6/07, Prof Brian Ripley <[EMAIL PROTECTED]> wrote:
> The defaults for postscript()
>
> paper = "default"
> onefile = TRUE
> horizontal = TRUE
>
> (it seems) date from the days when people used to used this to send plots
> directly to a postscript printer via print.it=TRUE. I haven't done that
> for years, and it seems that our current generation of students don't even
> know the concept. It seems 'horizontal = TRUE' is particularly difficult
> to grasp.
>
> Given that I suspect almost all uses of postscript() are to produce plots
> to be viewed on-screen or incorporated into another document, a more
> appropriate set of defaults would be
>
> width = 7, height = 7
> paper = "special"
> onefile = FALSE
> horizontal = FALSE
>
> which would have the advantage of using the same default aspect ratio for
> plots as all (?) other R graphics devices.
>
> Does anyone see a reason not to change the defaults?
I'm not so sure about the 'onefile' change. Scripts with multiple
plots run in batch mode will end up with multiple files; I prefer the
current behaviour. I also have test scripts in packages that go
postscript("something.ps")
dev.off()
Unless I change all these to have onefile=TRUE, I'll end up only with
the last plot available after the tests are run.
-Deepayan
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] [R] color palette from red to blue passing white (shifted from R-help)
Hi, The move to sRGB is nice, is there any interest in adding an interface to lcms, http://www.littlecms.com, to allow gamut matching? I can think of a lot of instances where I would like to render a figure as it would appear on my printer. This is probably best done as a separate package though, at least at first. Nicholas Martin Maechler wrote: >> "Paul" == Paul Murrell >> on Wed, 05 Dec 2007 08:53:10 +1300 writes: > > Paul> Hi > Paul> Achim and I have been looking at tidying up the colorspace package > (see > Paul> http://r-forge.r-project.org/projects/colorspace/) to fix a few > Paul> inaccuracies, PLUS the possibility of declaring R's internal color > space > Paul> to be sRGB. > > Paul> I have started an RFC on the r-developer site > Paul> (http://developer.r-project.org/sRGB-RFC.html) to discuss some > possible > Paul> changes to the core engine and add-on packages. > > Paul> One of the issues will be consolidating some of the double-ups > (e.g., > Paul> hcl() in base and the counterpart in package 'colorspace'; I did > not > Paul> even know about convertColor()!). > > Paul> Ideally, we would have only one copy of the conversions between the > Paul> various colorspaces (probably C code, then the various R-level front > Paul> ends can all just run off the same internal code). > > Paul> A lot of these conversions exist now in 'colorspace', but as Thomas > Paul> pointed out, the S4-ness of 'colorspace' is a problem for making > these > Paul> conversions part of base R. > > Hmm, I think we are currently only required to keep 'base' not > dependent on 'methods'. > Why should 'grDevices' or new "standard R" package not be > dependent on 'methods' ? > Many of us would like to see S4 been used much more widely. Great. I will keep working on the RFC to see if I can propose a way to reconcile all of the color-conversion and palette-selection code based on a single sRGB representation in the R core and only one set of conversion functions. Paul > Martin __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Solve.QP
Hi there, I have a major problem (major for me that is) with solve.QP and I'm new at this. You see, to solve my quadratic program I need to have the lagrange multipliers after each iteration. Solve.QP gives me the solution, the unconstrained solution aswell as the optimal value. Does anybody have an idea for how I could extract the multipliers? Thanx, Serge "Beatus qui prodest quibus potest" - (Lycklig är den som hjälper andra) Dr. Serge de Gosson de Varennes Försäkringskassan Swedish Social Insurance Agency +46-76 11 40 799 [EMAIL PROTECTED] [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] trace() problems (PR#10498)
trace() seems to be broken in 2.6.1 and R-devel:
Try the example from the ?debug man page:
> library(methods)
> trace("plot", browser, exit=browser, signature = c("track",
+ "missing"))
Error in getFunction(what, where = whereF) : no function "plot" found
Okay, it's just an example that doesn't work. Let's try a simpler one,
the first example from the ?trace man page:
> trace(sum)
> hist(stats::rnorm(100)) # shows about 3-4 calls to sum()
> untrace(sum)
No trace! In a clean session without the first error, things are fine:
> trace(sum)
> hist(stats::rnorm(100)) # shows about 3-4 calls to sum()
trace: sum(2^(opts - 2))
trace: sum(2^(opts - 2))
trace: sum(2^(opts - 2))
trace: sum(counts)
trace: sum(2^(opts - 2))
> untrace(sum)
Duncan Murdoch
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Solve.QP
G'day Serge,
On Thu, 6 Dec 2007 13:34:58 +0100
"de Gosson de Varennes Serge (4100)"
<[EMAIL PROTECTED]> wrote:
> I have a major problem (major for me that is) with solve.QP and I'm
> new at this. You see, to solve my quadratic program I need to have
> the lagrange multipliers after each iteration. Solve.QP gives me the
> solution, the unconstrained solution aswell as the optimal value.
> Does anybody have an idea for how I could extract the multipliers?
You could calculate them. For the quadratic program
min 1/2 x'Dx - d'x such that A'x >= b
the KKT conditions are:
( D -A) (x) = (d)
( A' 0) (l) = (b)
plus the complementary conditions. solve.QP tells you the solution x*
and which constraints are active. If A* is the submatrix of A that
contains only those columns of A that correspond to active constraints
at the solution, then the first line in the above set of equations
imply that the corresponding Lagrange multiplier l* fulfill the
equations:
D x* - A* l* = d --> l* = (A*' A*)^{-1} A*'(D x* - d)
all other Lagrange multiplier would be zero.
Thus, using the example from the help page and expanding it, the
following code should calculate the Lagrange multipliers:
Dmat <- matrix(0,3,3)
diag(Dmat) <- 1
dvec <- c(0,5,0)
Amat <- matrix(c(-4,-3,0,2,1,0,0,-2,1),3,3)
bvec <- c(-8,2,0)
res <- solve.QP(Dmat,dvec,Amat,bvec=bvec)
xst <- res$solution
tmp <- Dmat %*% xst -dvec
Ast <- Amat[,res$iact]
ll <- solve(crossprod(Ast,Ast), crossprod(Ast, tmp))
## a small check
cbind(tmp, Ast %*% ll)
lagr <- rep(0, ncol(Amat))
lagrange[res$iact] <- ll
lagrange
[1] 0.000 0.2380952 2.0952381
Alternatively, somewhere down in the FORTRAN code the Lagrange
multipliers are actually calculated. About 4 years ago somebody asked
me about this and he could locate where they are calculated. He
modified the FORTRAN code and the R code such that the Lagrange
multipliers would be returned too. Curiously, he sent the modified
code to me and not to the package maintainer, but I had no time at that
moment to check his modification, so I never passed anything on to the
package maintainer either. But if you are interested in modifying the
FORTRAN and R code and recompile the package yourself, I can see if I
can find that code.
I still think that this package should be worked over by someone with a
better understanding of the kind of fudges that do not come back to
bite and of finite precision arithmetic than the original author's
appreciation of such issues when the code was written. ;-)) Given
Bill's recent comments on r-help, I wonder whether this package is one
of those on his list of downright dangerous packages. LOL.
Hope this helps.
Cheers,
Berwin
=== Full address =
Berwin A TurlachTel.: +65 6516 4416 (secr)
Dept of Statistics and Applied Probability+65 6516 6650 (self)
Faculty of Science FAX : +65 6872 3919
National University of Singapore
6 Science Drive 2, Blk S16, Level 7 e-mail: [EMAIL PROTECTED]
Singapore 117546http://www.stat.nus.edu.sg/~statba
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Defaults for postscript()
On Thu, 2007-12-06 at 00:32 -0800, Deepayan Sarkar wrote:
> On 12/6/07, Prof Brian Ripley <[EMAIL PROTECTED]> wrote:
> > The defaults for postscript()
> >
> > paper = "default"
> > onefile = TRUE
> > horizontal = TRUE
> >
> > (it seems) date from the days when people used to used this to send plots
> > directly to a postscript printer via print.it=TRUE. I haven't done that
> > for years, and it seems that our current generation of students don't even
> > know the concept. It seems 'horizontal = TRUE' is particularly difficult
> > to grasp.
> >
> > Given that I suspect almost all uses of postscript() are to produce plots
> > to be viewed on-screen or incorporated into another document, a more
> > appropriate set of defaults would be
> >
> > width = 7, height = 7
> > paper = "special"
> > onefile = FALSE
> > horizontal = FALSE
> >
> > which would have the advantage of using the same default aspect ratio for
> > plots as all (?) other R graphics devices.
> >
> > Does anyone see a reason not to change the defaults?
>
> I'm not so sure about the 'onefile' change. Scripts with multiple
> plots run in batch mode will end up with multiple files; I prefer the
> current behaviour. I also have test scripts in packages that go
>
>
> postscript("something.ps")
>
> dev.off()
>
>
> Unless I change all these to have onefile=TRUE, I'll end up only with
> the last plot available after the tests are run.
>
> -Deepayan
In a vacuum, I would agree that changing the default values makes sense
given the preponderance of the use for postscript() for creating EPS
files for use in LaTeX and other documents (eg. Office/OO.org). It might
also serve to reduce the frequency of questions on the lists on this
subject.
That being said, I understand Deepayan's concern.
I don't have a sense of how many others would be affected by such a
change.
Pending any other comments on the matter, an incremental approach might
include an initial near term restructuring of the help file for
postscript(), whereby the following content in the Details section:
The postscript produced for a single R plot is EPS (Encapsulated
PostScript) compatible, and can be included into other documents, e.g.,
into LaTeX, using \includegraphics{}. For use in this way you
will probably want to set horizontal = FALSE, onefile = FALSE, paper =
"special". Note that the bounding box is for the device region: if you
find the white space around the plot region excessive, reduce the
margins of the figure region via par(mar=).
is moved to a new Notes section, which could precede the Details
section, given the likely nature of such use. This change could be done
now for R-patched and R-devel.
A separate second comment could be added to the Notes section,
indicating that the defaults will change to those above in version
2.8.0. The longer time frame would give affected package maintainers a
heads up of the pending change and more lead time for implementation of
any changes.
HTH,
Marc
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] R-Cocoa Bridge
I had seen old posts on the list (circa 2002) regarding a Cocoa-R bridge that was under development, but I can't find anything recent about it. Does anyone know if this is available somewhere? If not, does anyone have any experience/pointers calling R functions from Cocoa? Thanks for your time, Lee Falin __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R-Cocoa Bridge
> I had seen old posts on the list (circa 2002) regarding a Cocoa-R bridge > that was under development, but I can't find anything recent about it. > Does anyone know if this is available somewhere? If not, does anyone > have any experience/pointers calling R functions from Cocoa? The R builds on OSX build an R.Framework; you can probably bootstrap off of that without too much trouble. [I haven't done much with it; wish I had time.] --elijah __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R-Cocoa Bridge
On Dec 6, 2007, at 11:58 AM, Lee Falin wrote: > I had seen old posts on the list (circa 2002) regarding a Cocoa-R > bridge that was under development, but I can't find anything recent > about it. Does anyone know if this is available somewhere? If not, > does anyone have any experience/pointers calling R functions from > Cocoa? > R/Cocoa bridge is what the R for Mac OS X GUI is built upon (just grab the sources and look at REngine). However, it's not perfect (its main purpose was to support the GUI - it may need some de-coupling - see also the "stand-alone-REngine" branch) and there is an ongoing project to get write a more general bridge as part of the Mac GUI 2.x initiative. There are also other alternatives, but I'm not sure how public or currently maintained they are these days. Cheers, Simon __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] trace() problems (PR#10498)
The problem is at least as old as 2.5.1. Looks like a line disappeared
from trace(), something like:
on.exit(tracingState(tState))
As a result, if an error occurs in the call to trace(), the tracing
state is left FALSE. The workaround is to turn it on explicitly:
tracingState(TRUE)
after which normal behavior should resume.
[EMAIL PROTECTED] wrote:
> trace() seems to be broken in 2.6.1 and R-devel:
>
> Try the example from the ?debug man page:
>
> > library(methods)
> > trace("plot", browser, exit=browser, signature = c("track",
> + "missing"))
> Error in getFunction(what, where = whereF) : no function "plot" found
>
> Okay, it's just an example that doesn't work. Let's try a simpler one,
> the first example from the ?trace man page:
>
> > trace(sum)
> > hist(stats::rnorm(100)) # shows about 3-4 calls to sum()
> > untrace(sum)
>
> No trace! In a clean session without the first error, things are fine:
>
> > trace(sum)
> > hist(stats::rnorm(100)) # shows about 3-4 calls to sum()
> trace: sum(2^(opts - 2))
> trace: sum(2^(opts - 2))
> trace: sum(2^(opts - 2))
> trace: sum(counts)
> trace: sum(2^(opts - 2))
> > untrace(sum)
>
> Duncan Murdoch
>
> __
> 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] suggested modification to the 'mle' documentation?
Hello: I wish to again express my appreciation to all who have contributed to making R what it is today. At this moment, I'm particularly grateful for whoever modified the 'mle' code so data no longer need be passed via global variables. I remember struggling with this a couple of years ago, and I only today discovered that it is no longer the case. I'd like to suggest that the 'mle' help file be modified to advertise this fact, e.g., by adding one of the two examples appearing below. Best Wishes, Spencer Graves x <- 0:10 y <- c(26, 17, 13, 12, 20, 5, 9, 8, 5, 4, 8) # Pass data via function arguments rather than global variables ll.5 <- function(ymax=15, xhalf=6, x., y.) -sum(stats::dpois(y., lambda=ymax/(1+x./xhalf), log=TRUE)) (fit.5 <- mle(ll.5, start=list(ymax=15, xhalf=6), fixed=list(x.=x, y.=y))) ll3 <- function(lymax=log(15), lxhalf=log(6), x., y.) -sum(stats::dpois(y., lambda=exp(lymax)/(1+x./exp(lxhalf)), log=TRUE)) (fit3 <- mle(ll3, start=list(lymax=0, lxhalf=0), fixed=list(x.=x, y.=y))) __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R-Cocoa Bridge
On Dec 6, 2007, at 12:30 PM, [EMAIL PROTECTED] wrote: >> I had seen old posts on the list (circa 2002) regarding a Cocoa-R >> bridge that was under development, but I can't find anything recent >> about it. Does anyone know if this is available somewhere? If not, >> does anyone have any experience/pointers calling R functions from >> Cocoa? > > The R builds on OSX build an R.Framework; you can probably bootstrap > off of that without too much trouble. [I haven't done much with it; > wish I had time.] > Unfortunately the R/ObjC bridge is not part of the framework yet. We're working on it, but we need some more cleanup of the old code. The current plan is to have it ready for R 2.7.0 (but you never know ...). Cheers, Simon __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Defaults for postscript()
Hi Prof Brian Ripley wrote: > The defaults for postscript() > > paper = "default" > onefile = TRUE > horizontal = TRUE > > (it seems) date from the days when people used to used this to send plots > directly to a postscript printer via print.it=TRUE. I haven't done that > for years, and it seems that our current generation of students don't even > know the concept. It seems 'horizontal = TRUE' is particularly difficult > to grasp. > > Given that I suspect almost all uses of postscript() are to produce plots > to be viewed on-screen or incorporated into another document, a more > appropriate set of defaults would be > > width = 7, height = 7 Wouldn't that be better as width = 6, height = 6 to match pdf() ? Paul > paper = "special" > onefile = FALSE > horizontal = FALSE > > which would have the advantage of using the same default aspect ratio for > plots as all (?) other R graphics devices. > > Does anyone see a reason not to change the defaults? > -- Dr Paul Murrell Department of Statistics The University of Auckland Private Bag 92019 Auckland New Zealand 64 9 3737599 x85392 [EMAIL PROTECTED] http://www.stat.auckland.ac.nz/~paul/ __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] [R] color palette from red to blue passing white (shifted from R-help)
Hi Nicholas Lewin-Koh wrote: > Hi, > The move to sRGB is nice, is there any interest in adding an interface > to lcms, http://www.littlecms.com, > to allow gamut matching? I can think of a lot of instances where I would > like to render a > figure as it would appear on my printer. This is probably best done as a > separate package though, > at least at first. I saw a mention of this when I began looking at Krita the other day (because I had heard that it had good colour support). Screen-to-print would be a great thing to support. Paul > Nicholas > > > Martin Maechler wrote: >>> "Paul" == Paul Murrell >>> on Wed, 05 Dec 2007 08:53:10 +1300 writes: >> Paul> Hi >> Paul> Achim and I have been looking at tidying up the colorspace package >> (see >> Paul> http://r-forge.r-project.org/projects/colorspace/) to fix a few >> Paul> inaccuracies, PLUS the possibility of declaring R's internal color >> space >> Paul> to be sRGB. >> >> Paul> I have started an RFC on the r-developer site >> Paul> (http://developer.r-project.org/sRGB-RFC.html) to discuss some >> possible >> Paul> changes to the core engine and add-on packages. >> >> Paul> One of the issues will be consolidating some of the double-ups >> (e.g., >> Paul> hcl() in base and the counterpart in package 'colorspace'; I did >> not >> Paul> even know about convertColor()!). >> >> Paul> Ideally, we would have only one copy of the conversions between the >> Paul> various colorspaces (probably C code, then the various R-level >> front >> Paul> ends can all just run off the same internal code). >> >> Paul> A lot of these conversions exist now in 'colorspace', but as Thomas >> Paul> pointed out, the S4-ness of 'colorspace' is a problem for making >> these >> Paul> conversions part of base R. >> >> Hmm, I think we are currently only required to keep 'base' not >> dependent on 'methods'. >> Why should 'grDevices' or new "standard R" package not be >> dependent on 'methods' ? >> Many of us would like to see S4 been used much more widely. > > > Great. I will keep working on the RFC to see if I can propose a way to > reconcile all of the color-conversion and palette-selection code based > on a single sRGB representation in the R core and only one set of > conversion functions. > > Paul > > >> Martin > > __ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel -- Dr Paul Murrell Department of Statistics The University of Auckland Private Bag 92019 Auckland New Zealand 64 9 3737599 x85392 [EMAIL PROTECTED] http://www.stat.auckland.ac.nz/~paul/ __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] os x crash using rpanel and tcltk (PR#10495)
I know of gdb but I'm not certain how to use it with Mac OS X's R.app,
do you just do something like "gdb open R.app" in the terminal?.
Interestingly I don't get this crash when I launch the X11 version of
R through the terminal, so this would suggest the bug in question is
to do with the actual Rgui in R.app. Hopefully this information might
help to narrow down the problem. Any advice for using gdb on R.app
would be appreciated, I couldn't find much in the way of guidance when
searching online.
thanks
Aaron
On 05/12/2007, Peter Dalgaard <[EMAIL PROTECTED]> wrote:
> [EMAIL PROTECTED] wrote:
> > Hello,
> > I've recently discovered a persistent issue with rpanel when running
> > R.app (2.6.1) on Mac OS X 10.4.11. tcltk and rpanel load without any
> > apparent error, and the interactive panels appear to work as expected,
> > however upon closing the panels rpanel has created I get catastrophic
> > errors and R crashes completely. For the most part R manages to crash
> > with dignity and work can be saved, but sometimes it will crash
> > straight out. Below is an example of an entire work session (only base
> > packages loaded) with the crash at the end typical of those
> > encountered:
> >
> >
> >> library(tcltk)
> >>
> > Loading Tcl/Tk interface ... done
> >
> >> library(rpanel)
> >>
> > Package `rpanel', version 1.0-4
> > type help(rpanel) for summary information
> >
> >> density.draw <- function(panel) {
> >>
> > + plot(density(panel$x, bw = panel$h))
> > + panel
> > + }
> >
> >> panel <- rp.control(x = rnorm(50))
> >> rp.slider(panel, h, 0.5, 5, log = TRUE, action = density.draw)
> >>
> >
> > *** caught bus error ***
> > address 0x0, cause 'non-existent physical address'
> >
> > Possible actions:
> > 1: abort (with core dump, if enabled)
> > 2: normal R exit
> > 3: exit R without saving workspace
> > 4: exit R saving workspace
> >
> > All packages that are required are up to date, and I can find no
> > evidence of similar issues from searching the mailing lists. Any
> > suggestions would be appreciated.
> >
> >
> Can you run this under gdb? A breakpoint in the error handler and a
> backtrace could be valuable.
>
> > Aaron
> >
> > __
> > R-devel@r-project.org mailing list
> > https://stat.ethz.ch/mailman/listinfo/r-devel
> >
>
>
> --
>O__ Peter Dalgaard Øster Farimagsgade 5, Entr.B
> c/ /'_ --- Dept. of Biostatistics PO Box 2099, 1014 Cph. K
> (*) \(*) -- University of Copenhagen Denmark Ph: (+45) 35327918
> ~~ - ([EMAIL PROTECTED]) FAX: (+45) 35327907
>
>
>
>
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] RGtk2 + tcltk combination problem (PR#10497)
Full_Name: Hans Dieter Version: 2.6.1 OS: windows Submission from: (NULL) (217.93.91.19) Hi all, first I used a TCL/TK GUI, after my work I cloed it and opend an RGTK2 GUI. Now I have the problem, the RGTK2 GUI will not refresh correctly and basic user-commands ( close windows ) dosen't work. Greetings Dieter __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] RGtk2 + tcltk combination problem (PR#10497)
This is likely a result of RGtk2 "piggybacking" on the tcl/tk event loop on Windows. One workaround in your situation is run gtkMain() at the R console to force the GTK+ event loop to run. The downside is that the R console will no longer be responsive. It's tough to keep so many interfaces working at once. Another solution might be to add a tcl/tk timer task that iterates the GTK+ loop (gtkMainIteration()). On Dec 6, 2007 3:40 AM, <[EMAIL PROTECTED]> wrote: > Full_Name: Hans Dieter > Version: 2.6.1 > OS: windows > Submission from: (NULL) (217.93.91.19) > > > Hi all, > first I used a TCL/TK GUI, after my work I cloed it and opend an RGTK2 > GUI. > Now I have the problem, the RGTK2 GUI will not refresh correctly and basic > user-commands ( close windows ) dosen't work. > > Greetings > Dieter > > __ > 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] os x crash using rpanel and tcltk (PR#10495)
On Dec 6, 2007, at 9:26 AM, Aaron Robotham wrote:
> I know of gdb but I'm not certain how to use it with Mac OS X's
> R.app, do you just do something like "gdb open R.app" in the
> terminal?.
>
You can attach it once it's running - just type "attach R" in gdb
while R is runningm then "c", then let it crash and then "bt".
FWIW: I cannot reproduce the problem and I have tried 3 different
machines... (you didn't even tell us what machine type this is ...).
Cheers,
Simon
> Interestingly I don't get this crash when I launch the X11 version of
> R through the terminal, so this would suggest the bug in question is
> to do with the actual Rgui in R.app. Hopefully this information might
> help to narrow down the problem. Any advice for using gdb on R.app
> would be appreciated, I couldn't find much in the way of guidance when
> searching online.
>
> thanks
>
> Aaron
>
> On 05/12/2007, Peter Dalgaard <[EMAIL PROTECTED]> wrote:
>> [EMAIL PROTECTED] wrote:
>>> Hello,
>>> I've recently discovered a persistent issue with rpanel when running
>>> R.app (2.6.1) on Mac OS X 10.4.11. tcltk and rpanel load without any
>>> apparent error, and the interactive panels appear to work as
>>> expected,
>>> however upon closing the panels rpanel has created I get
>>> catastrophic
>>> errors and R crashes completely. For the most part R manages to
>>> crash
>>> with dignity and work can be saved, but sometimes it will crash
>>> straight out. Below is an example of an entire work session (only
>>> base
>>> packages loaded) with the crash at the end typical of those
>>> encountered:
>>>
>>>
library(tcltk)
>>> Loading Tcl/Tk interface ... done
>>>
library(rpanel)
>>> Package `rpanel', version 1.0-4
>>> type help(rpanel) for summary information
>>>
density.draw <- function(panel) {
>>> + plot(density(panel$x, bw = panel$h))
>>> + panel
>>> + }
>>>
panel <- rp.control(x = rnorm(50))
rp.slider(panel, h, 0.5, 5, log = TRUE, action = density.draw)
>>>
>>> *** caught bus error ***
>>> address 0x0, cause 'non-existent physical address'
>>>
>>> Possible actions:
>>> 1: abort (with core dump, if enabled)
>>> 2: normal R exit
>>> 3: exit R without saving workspace
>>> 4: exit R saving workspace
>>>
>>> All packages that are required are up to date, and I can find no
>>> evidence of similar issues from searching the mailing lists. Any
>>> suggestions would be appreciated.
>>>
>>>
>> Can you run this under gdb? A breakpoint in the error handler and a
>> backtrace could be valuable.
>>
>>> Aaron
>>>
>>> __
>>> R-devel@r-project.org mailing list
>>> https://stat.ethz.ch/mailman/listinfo/r-devel
>>>
>>
>>
>> --
>> O__ Peter Dalgaard Øster Farimagsgade 5, Entr.B
>> c/ /'_ --- Dept. of Biostatistics PO Box 2099, 1014 Cph. K
>> (*) \(*) -- University of Copenhagen Denmark Ph: (+45)
>> 35327918
>> ~~ - ([EMAIL PROTECTED]) FAX: (+45)
>> 35327907
>>
>>
>>
>>
>
> __
> 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] os x crash using rpanel and tcltk (PR#10495)
On Dec 6, 2007, at 9:26 AM, Aaron Robotham wrote:
> I know of gdb but I'm not certain how to use it with Mac OS X's =20
> R.app, do you just do something like "gdb open R.app" in the =20
> terminal?.
>
You can attach it once it's running - just type "attach R" in gdb =20
while R is runningm then "c", then let it crash and then "bt".
FWIW: I cannot reproduce the problem and I have tried 3 different =20
machines... (you didn't even tell us what machine type this is ...).
Cheers,
Simon
> Interestingly I don't get this crash when I launch the X11 version of
> R through the terminal, so this would suggest the bug in question is
> to do with the actual Rgui in R.app. Hopefully this information might
> help to narrow down the problem. Any advice for using gdb on R.app
> would be appreciated, I couldn't find much in the way of guidance when
> searching online.
>
> thanks
>
> Aaron
>
> On 05/12/2007, Peter Dalgaard <[EMAIL PROTECTED]> wrote:
>> [EMAIL PROTECTED] wrote:
>>> Hello,
>>> I've recently discovered a persistent issue with rpanel when running
>>> R.app (2.6.1) on Mac OS X 10.4.11. tcltk and rpanel load without any
>>> apparent error, and the interactive panels appear to work as =20
>>> expected,
>>> however upon closing the panels rpanel has created I get =20
>>> catastrophic
>>> errors and R crashes completely. For the most part R manages to =20
>>> crash
>>> with dignity and work can be saved, but sometimes it will crash
>>> straight out. Below is an example of an entire work session (only =20=
>>> base
>>> packages loaded) with the crash at the end typical of those
>>> encountered:
>>>
>>>
library(tcltk)
>>> Loading Tcl/Tk interface ... done
>>>
library(rpanel)
>>> Package `rpanel', version 1.0-4
>>> type help(rpanel) for summary information
>>>
density.draw <- function(panel) {
>>> + plot(density(panel$x, bw =3D panel$h))
>>> + panel
>>> + }
>>>
panel <- rp.control(x =3D rnorm(50))
rp.slider(panel, h, 0.5, 5, log =3D TRUE, action =3D density.draw)
>>>
>>> *** caught bus error ***
>>> address 0x0, cause 'non-existent physical address'
>>>
>>> Possible actions:
>>> 1: abort (with core dump, if enabled)
>>> 2: normal R exit
>>> 3: exit R without saving workspace
>>> 4: exit R saving workspace
>>>
>>> All packages that are required are up to date, and I can find no
>>> evidence of similar issues from searching the mailing lists. Any
>>> suggestions would be appreciated.
>>>
>>>
>> Can you run this under gdb? A breakpoint in the error handler and a
>> backtrace could be valuable.
>>
>>> Aaron
>>>
>>> __
>>> R-devel@r-project.org mailing list
>>> https://stat.ethz.ch/mailman/listinfo/r-devel
>>>
>>
>>
>> --
>> O__ Peter Dalgaard =D8ster Farimagsgade 5, Entr.B
>> c/ /'_ --- Dept. of Biostatistics PO Box 2099, 1014 Cph. K
>> (*) \(*) -- University of Copenhagen Denmark Ph: (+45) =20=
>> 35327918
>> ~~ - ([EMAIL PROTECTED]) FAX: (+45) =20=
>> 35327907
>>
>>
>>
>>
>
> __
> 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] End of whiskers of boxplots are repeated on PDF device (PR#10499)
Full_Name: Michael Toews
Version: 2.61
OS: WinXP SP2
Submission from: (NULL) (142.58.206.114)
Using boxplot on a PDF device with more than one group (or boxes) produces
multiple (and overlain) 1st and 3rd quartile ticks. There are exactly the
multiple of boxplot groups as there are of each 1st and 3rd quartile ticks for
each boxplot (drawn as a horizontal line at the end of each boxplot), which is
(groups^2)x2 tick marks in total drawn for the device region.
For example, a device with 4 boxplots:
dat <- data.frame(f=factor(rep(1:4, 10)), x=rnorm(40))
pdf("test.pdf")
plot(dat)
dev.off()
Since the ticks are overlain, the problem is not apparent when viewed in a PDF
reader, but if one were to open the PDF in either CorelDraw or Adobe
Illustrator[*], it is clear that there are 4 ticks for the 1st and 3rd quartile
marks. This example produces (4^2)x32=64 marks, which is 58 too many. In other
examples that use 86 boxplots, there are (86^2)x2=14792 ticks, of which only
2x86 are needed, the rest are redundant.
[*] I'm not familiar with any OSS capable of editing PDFs, however you can see
the tick marks in the PDF file through any text editor on lines 54-61, 77-84,
100-107, and 123-130. The tick marks alternate from 1st to 3rd each of the four
times, so deleting the bottom 6 lines in each group removes the redundancy.
I have also tested the example using the postscript device, but it seems fine
(the skeleton of the boxplots appear to be compound paths, so are drawn very
differently from a low-level graphics standpoint).
--please do not edit the information below--
Version:
platform = i386-pc-mingw32
arch = i386
os = mingw32
system = i386, mingw32
status =
major = 2
minor = 6.1
year = 2007
month = 11
day = 26
svn rev = 43537
language = R
version.string = R version 2.6.1 (2007-11-26)
Windows XP (build 2600) Service Pack 2.0
Locale:
LC_COLLATE=English_Canada.1252;LC_CTYPE=English_Canada.1252;LC_MONETARY=English_Canada.1252;LC_NUMERIC=C;LC_TIME=English_Canada.1252
Search Path:
.GlobalEnv, package:stats, package:graphics, package:grDevices, package:utils,
package:datasets, package:methods, Autoloads, package:base
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] End of whiskers of boxplots are repeated on PDF device (PR#10499)
As a quick follow up, this problem is apparent in the Postscript device
too (and possibly other vector devices).
For example:
dat <- data.frame(f=factor(rep(1:4, 10)), x=rnorm(40))
postscript("test.ps")
plot(dat)
dev.off()
In Adobe Illustrator, the compound path needs to be "released" to see
the extra outer whisker ticks.
In the "test.ps" file, the first occurrence (for the first boxplot) is
on lines 143-150, and repeats are on lines 151-174.
+mt
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Defaults for postscript()
On Fri, 7 Dec 2007, Paul Murrell wrote: > Hi > > > Prof Brian Ripley wrote: >> The defaults for postscript() >> >> paper = "default" >> onefile = TRUE >> horizontal = TRUE >> >> (it seems) date from the days when people used to used this to send plots >> directly to a postscript printer via print.it=TRUE. I haven't done that >> for years, and it seems that our current generation of students don't even >> know the concept. It seems 'horizontal = TRUE' is particularly difficult >> to grasp. >> >> Given that I suspect almost all uses of postscript() are to produce plots >> to be viewed on-screen or incorporated into another document, a more >> appropriate set of defaults would be >> >> width = 7, height = 7 > > > Wouldn't that be better as width = 6, height = 6 to match pdf() ? Perhaps (but not matching X11 nor windows). Would anyone notice the difference? One argument against is that I now think the default pointsize in pdf() is too large for the default device region. I would have suggested 8x6 (which is what the MASS scripts use) apart from the R preference for square device regions. Thanks to Deepayan & Marc for other comments: I will have some follow-up comments in due course. > > Paul > > >> paper = "special" >> onefile = FALSE >> horizontal = FALSE >> >> which would have the advantage of using the same default aspect ratio for >> plots as all (?) other R graphics devices. >> >> Does anyone see a reason not to change the defaults? >> > > -- 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] suggested modification to the 'mle' documentation?
Spencer Graves wrote:
> Hello:
>
> I wish to again express my appreciation to all who have
> contributed to making R what it is today.
>
> At this moment, I'm particularly grateful for whoever modified the
> 'mle' code so data no longer need be passed via global variables. I
> remember struggling with this a couple of years ago, and I only today
> discovered that it is no longer the case.
>
> I'd like to suggest that the 'mle' help file be modified to
> advertise this fact, e.g., by adding one of the two examples appearing
> below.
>
In a word: No!!! That is not the design. A likelihood function is a
function of its parameters, and the "fixed" argument is for holding some
parameters fixed (e.g. during profiling).
To include data, just make a closure, e.g.
poissonLike <- function(x., y.){
function(ymax=15, xhalf=6)
-sum(stats::dpois(y., lambda=ymax/(1+x./xhalf), log=TRUE))}
mll <- poissonLike(x, y)
mle(ll,
> Best Wishes,
> Spencer Graves
>
> x <- 0:10
> y <- c(26, 17, 13, 12, 20, 5, 9, 8, 5, 4, 8)
> # Pass data via function arguments rather than global variables
> ll.5 <- function(ymax=15, xhalf=6, x., y.)
> -sum(stats::dpois(y., lambda=ymax/(1+x./xhalf), log=TRUE))
> (fit.5 <- mle(ll.5, start=list(ymax=15, xhalf=6),
> fixed=list(x.=x, y.=y)))
>
> ll3 <- function(lymax=log(15), lxhalf=log(6), x., y.)
> -sum(stats::dpois(y.,
> lambda=exp(lymax)/(1+x./exp(lxhalf)), log=TRUE))
> (fit3 <- mle(ll3, start=list(lymax=0, lxhalf=0),
> fixed=list(x.=x, y.=y)))
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>
--
O__ Peter Dalgaard Øster Farimagsgade 5, Entr.B
c/ /'_ --- Dept. of Biostatistics PO Box 2099, 1014 Cph. K
(*) \(*) -- University of Copenhagen Denmark Ph: (+45) 35327918
~~ - ([EMAIL PROTECTED]) FAX: (+45) 35327907
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] suggested modification to the 'mle' documentation?
The closure only works if you are defining the inner function yourself.
If you are not then its yet more work to redefine the environment of
the inner function or other workaround.
On Dec 6, 2007 6:01 PM, Peter Dalgaard <[EMAIL PROTECTED]> wrote:
> Spencer Graves wrote:
> > Hello:
> >
> > I wish to again express my appreciation to all who have
> > contributed to making R what it is today.
> >
> > At this moment, I'm particularly grateful for whoever modified the
> > 'mle' code so data no longer need be passed via global variables. I
> > remember struggling with this a couple of years ago, and I only today
> > discovered that it is no longer the case.
> >
> > I'd like to suggest that the 'mle' help file be modified to
> > advertise this fact, e.g., by adding one of the two examples appearing
> > below.
> >
>
> In a word: No!!! That is not the design. A likelihood function is a
> function of its parameters, and the "fixed" argument is for holding some
> parameters fixed (e.g. during profiling).
>
> To include data, just make a closure, e.g.
>
> poissonLike <- function(x., y.){
>function(ymax=15, xhalf=6)
> -sum(stats::dpois(y., lambda=ymax/(1+x./xhalf), log=TRUE))}
> mll <- poissonLike(x, y)
> mle(ll,
>
>
> > Best Wishes,
> > Spencer Graves
> >
> > x <- 0:10
> > y <- c(26, 17, 13, 12, 20, 5, 9, 8, 5, 4, 8)
> > # Pass data via function arguments rather than global variables
> > ll.5 <- function(ymax=15, xhalf=6, x., y.)
> > -sum(stats::dpois(y., lambda=ymax/(1+x./xhalf), log=TRUE))
> > (fit.5 <- mle(ll.5, start=list(ymax=15, xhalf=6),
> > fixed=list(x.=x, y.=y)))
> >
> > ll3 <- function(lymax=log(15), lxhalf=log(6), x., y.)
> > -sum(stats::dpois(y.,
> > lambda=exp(lymax)/(1+x./exp(lxhalf)), log=TRUE))
> > (fit3 <- mle(ll3, start=list(lymax=0, lxhalf=0),
> > fixed=list(x.=x, y.=y)))
> >
> > __
> > R-devel@r-project.org mailing list
> > https://stat.ethz.ch/mailman/listinfo/r-devel
> >
>
>
> --
> O__ Peter Dalgaard Øster Farimagsgade 5, Entr.B
> c/ /'_ --- Dept. of Biostatistics PO Box 2099, 1014 Cph. K
> (*) \(*) -- University of Copenhagen Denmark Ph: (+45) 35327918
> ~~ - ([EMAIL PROTECTED]) FAX: (+45) 35327907
>
>
> __
> 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] suggested modification to the 'mle' documentation?
Gabor Grothendieck wrote:
>
> The closure only works if you are defining the inner function yourself.
> If you are not then its yet more work to redefine the environment of
> the inner function or other workaround.
>
> On Dec 6, 2007 6:01 PM, Peter Dalgaard <[EMAIL PROTECTED]> wrote:
>> Spencer Graves wrote:
>> > Hello:
>> >
>> > I wish to again express my appreciation to all who have
>> > contributed to making R what it is today.
>> >
>> > At this moment, I'm particularly grateful for whoever modified
>> the
>> > 'mle' code so data no longer need be passed via global variables. I
>> > remember struggling with this a couple of years ago, and I only today
>> > discovered that it is no longer the case.
>> >
>> > I'd like to suggest that the 'mle' help file be modified to
>> > advertise this fact, e.g., by adding one of the two examples appearing
>> > below.
>> >
>>
>> In a word: No!!! That is not the design. A likelihood function is a
>> function of its parameters, and the "fixed" argument is for holding some
>> parameters fixed (e.g. during profiling).
>>
>> To include data, just make a closure, e.g.
>>
>> poissonLike <- function(x., y.){
>>function(ymax=15, xhalf=6)
>> -sum(stats::dpois(y., lambda=ymax/(1+x./xhalf), log=TRUE))}
>> mll <- poissonLike(x, y)
>> mle(ll,
>>
>>
>> > Best Wishes,
>> > Spencer Graves
>> >
>> > x <- 0:10
>> > y <- c(26, 17, 13, 12, 20, 5, 9, 8, 5, 4, 8)
>> > # Pass data via function arguments rather than global variables
>> > ll.5 <- function(ymax=15, xhalf=6, x., y.)
>> > -sum(stats::dpois(y., lambda=ymax/(1+x./xhalf), log=TRUE))
>> > (fit.5 <- mle(ll.5, start=list(ymax=15, xhalf=6),
>> > fixed=list(x.=x, y.=y)))
>> >
>> > ll3 <- function(lymax=log(15), lxhalf=log(6), x., y.)
>> > -sum(stats::dpois(y.,
>> > lambda=exp(lymax)/(1+x./exp(lxhalf)), log=TRUE))
>> > (fit3 <- mle(ll3, start=list(lymax=0, lxhalf=0),
>> > fixed=list(x.=x, y.=y)))
>> >
>> > __
>> > R-devel@r-project.org mailing list
>> > https://stat.ethz.ch/mailman/listinfo/r-devel
>> >
>>
>>
>> --
>> O__ Peter Dalgaard Øster Farimagsgade 5, Entr.B
>> c/ /'_ --- Dept. of Biostatistics PO Box 2099, 1014 Cph. K
>> (*) \(*) -- University of Copenhagen Denmark Ph: (+45)
>> 35327918
>> ~~ - ([EMAIL PROTECTED]) FAX: (+45)
>> 35327907
>>
>>
>> __
>> 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
>
>
At this point I'd just like to advertise the "bbmle" package
(on CRAN) for those who respectfully disagree, as I do, with Peter over
this issue. I have added a data= argument to my version
of the function that allows other variables to be passed
to the objective function. It seems to me that this is perfectly
in line with the way that other modeling functions in R
behave.
(My version also has a cool formula interface and other
bells and whistles, and I would love to get feedback from other
useRs about it.)
cheers
Ben Bolker
--
View this message in context:
http://www.nabble.com/suggested-modification-to-the-%27mle%27-documentation--tf4957508.html#a14206100
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] Bug#454678: r-base-core: Crash when calling edit.matrix with edit.row.names = TRUE when there are no rownames (PR#10500)
Ben,
Thanks for the bug report. I am off two minds about it as discussed below.
But as it does indeed create a crash / segfault, I am passing this on to the
R bug tracker. A suggested two-line patch is below; I tested the patch
against a 'vanilla' 2.6.1 source tree.
On 6 December 2007 at 19:32, Ben Goodrich wrote:
| -BEGIN PGP SIGNED MESSAGE-
| Hash: SHA1
|
| Package: r-base-core
| Version: 2.6.1-1
| Severity: important
|
| Hi Dirk,
|
| My strong hunch is that this bug should just be forwarded upstream but
| it might have something to do with libc6 on Debian. To reproduce it, do
|
| args(utils:::edit.matrix)
| mat <- matrix(rnorm(30), nrow = 10, ncol = 3)
| edit(mat, edit.row.names = TRUE) #crash
I can confirm that it crashes 2.6.0 and 2.6.1. I also spent the last little
while building a (non-stripped) debug version that reveals:
(gdb) where
#0 0xb7b2ef2c in __gconv_transform_utf8_internal () from
/lib/i686/cmov/libc.so.6
#1 0xb7b89f75 in mbrtowc () from /lib/i686/cmov/libc.so.6
#2 0xb7db05e3 in Rstrwid (str=0x8052010 "\020!\005\b\002", slen=134595712,
quote=0) at printutils.c:284
#3 0xb7db0888 in Rstrlen (s=0x8051ff8, quote=0) at printutils.c:377
#4 0xb7d2de24 in Rf_formatString (x=0x873bbb8, n=1, fieldwidth=0xbfd0fc04,
quote=0) at format.c:62
#5 0xb7db12b5 in Rf_EncodeElement (x=0x873ba10, indx=100, quote=0, dec=46 '.')
at printutils.c:576
#6 0xb754ae0d in get_col_width (DE=0xbfd100b0, col=1) at dataentry.c:804
#7 0xb754edb4 in initwin (DE=0xbfd100b0, title=0xb755eed9 "R Data Editor")
at dataentry.c:1986
#8 0xb7549319 in RX11_dataentry (call=0x89b3fe8, op=0x806c970, args=0x8ba40c8,
rho=0x89b4bd0) at dataentry.c:382
#9 0xb7e52771 in do_dataentry (call=0x89b3fe8, op=0x806c970, args=0x8ba40c8,
rho=0x89b4bd0) at X11.c:91
#10 0xb7d6045e in do_internal (call=0x89b4020, op=0x8061fa4, args=0x8ba40c8,
env=0x89b4bd0) at names.c:1120
#11 0xb7d1f352 in Rf_eval (e=0x89b4020, rho=0x89b4bd0) at eval.c:463
#12 0xb7d21d5d in do_set (call=0x89b4074, op=0x8060df0, args=0x89b4058,
rho=0x89b4bd0) at eval.c:1407
#13 0xb7d1f352 in Rf_eval (e=0x89b4074, rho=0x89b4bd0) at eval.c:463
#14 0xb7d212b4 in do_begin (call=0x89b2798, op=0x8062458, args=0x89b4090,
rho=0x89b4bd0) at eval.c:1159
#15 0xb7d1f352 in Rf_eval (e=0x89b2798, rho=0x89b4bd0) at eval.c:463
#16 0xb7d1fb67 in Rf_applyClosure (call=0x89b1c9c, op=0x89b1ba0,
arglist=0x89b1e24, rho=0x89b1d7c, suppliedenv=0x89b1cd4) at eval.c:669
#17 0xb7d60a32 in applyMethod (call=0x89b1c9c, op=0x89b1ba0, args=0x89b1e24,
rho=0x89b1d7c, newrho=0x89b1cd4) at objects.c:126
#18 0xb7d61223 in Rf_usemethod (generic=0x8069af8 "edit", obj=0x8a87868,
call=0x89b1e94, args=0x8052110, rho=0x89b1d7c, callrho=0x8073f9c,
defrho=0x828f2fc, ans=0xbfd10d00) at objects.c:291
#19 0xb7d61776 in do_usemethod (call=0x89b1e94, op=0x80711b8, args=0x89b1e78,
env=0x89b1d7c) at objects.c:399
#20 0xb7d1f352 in Rf_eval (e=0x89b1e94, rho=0x89b1d7c) at eval.c:463
#21 0xb7d1fb67 in Rf_applyClosure (call=0x89b2230, op=0x89b2150,
arglist=0x89b1e24, rho=0x8073f9c, suppliedenv=0x8073fb8) at eval.c:669
#22 0xb7d1f601 in Rf_eval (e=0x89b2230, rho=0x8073f9c) at eval.c:507
#23 0xb7d4a879 in Rf_ReplIteration (rho=0x8073f9c, savestack=0, browselevel=0,
state=0xbfd1116c) at main.c:263
#24 0xb7d4aa61 in R_ReplConsole (rho=0x8073f9c, savestack=0, browselevel=0)
at main.c:312
#25 0xb7d4bec7 in run_Rmainloop () at main.c:975
#26 0xb7d4beee in Rf_mainloop () at main.c:982
#27 0x08048733 in main (ac=0, av=0x0) at Rmain.c:35
#28 0xb7b27450 in __libc_start_main () from /lib/i686/cmov/libc.so.6
#29 0x08048691 in _start ()
(gdb) up
Now, two comments.
Firstly, we all prefer if R would not crash. So this may need some fixing.
Secondly, I think you are rather close to bordering on user error. As your
snippet shows, you need to invoke args on the non-exported edit.matrix to
learn about the edit.row.names argument. Moreover, you also know full well
from looking at this that this will only be true when there actually are
names set --- and you then proceed to call it when there are none. Guess
what: it blows up.
So we could fix this in a number of places. Here is one which I tested; R
Core may opt to apply this, or a better version, or to drop the issue:
[EMAIL PROTECTED]:~/src/debian/R> diff -u
R-2.6.1/src/library/utils/R/edit.R{.orig,}
--- R-2.6.1/src/library/utils/R/edit.R.orig 2007-09-04 17:12:32.0
-0500
+++ R-2.6.1/src/library/utils/R/edit.R 2007-12-06 21:12:32.0 -0600
@@ -166,6 +166,8 @@
else names(datalist) <- paste("col", 1:ncol(name), sep = "")
modes <- as.list(rep.int(mode(name), ncol(name)))
if (edit.row.names) {
+if (is.null(dn[[1]])) ## true if forced edit.row.names as TRUE on null
+dn[[1]] <- paste("row", 1:dim(name)[1], sep="")
datalist <- c(list(row.names = dn[[1]]), datalist)
modes <- c(list(row.names = "character"), modes)
}
This results in
Re: [Rd] Defaults for postscript()
On 06/12/2007, Marc Schwartz <[EMAIL PROTECTED]> wrote:
>
> On Thu, 2007-12-06 at 00:32 -0800, Deepayan Sarkar wrote:
> > On 12/6/07, Prof Brian Ripley <[EMAIL PROTECTED]> wrote:
> > > The defaults for postscript()
> > >
> > > paper = "default"
> > > onefile = TRUE
> > > horizontal = TRUE
> > >
> > > (it seems) date from the days when people used to used this to send plots
> > > directly to a postscript printer via print.it=TRUE. I haven't done that
> > > for years, and it seems that our current generation of students don't even
> > > know the concept. It seems 'horizontal = TRUE' is particularly difficult
> > > to grasp.
> > >
> > > Given that I suspect almost all uses of postscript() are to produce plots
> > > to be viewed on-screen or incorporated into another document, a more
> > > appropriate set of defaults would be
> > >
> > > width = 7, height = 7
> > > paper = "special"
> > > onefile = FALSE
> > > horizontal = FALSE
> > >
> > > which would have the advantage of using the same default aspect ratio for
> > > plots as all (?) other R graphics devices.
> > >
> > > Does anyone see a reason not to change the defaults?
> >
> > I'm not so sure about the 'onefile' change. Scripts with multiple
> > plots run in batch mode will end up with multiple files; I prefer the
> > current behaviour. I also have test scripts in packages that go
> >
> >
> > postscript("something.ps")
> >
> > dev.off()
> >
> >
> > Unless I change all these to have onefile=TRUE, I'll end up only with
> > the last plot available after the tests are run.
> >
> > -Deepayan
>
> In a vacuum, I would agree that changing the default values makes sense
> given the preponderance of the use for postscript() for creating EPS
> files for use in LaTeX and other documents (eg. Office/OO.org). It might
> also serve to reduce the frequency of questions on the lists on this
> subject.
>
> That being said, I understand Deepayan's concern.
>
> I don't have a sense of how many others would be affected by such a
> change.
>
> Pending any other comments on the matter, an incremental approach might
> include an initial near term restructuring of the help file for
> postscript(), whereby the following content in the Details section:
>
>
> The postscript produced for a single R plot is EPS (Encapsulated
> PostScript) compatible, and can be included into other documents, e.g.,
> into LaTeX, using \includegraphics{}. For use in this way you
> will probably want to set horizontal = FALSE, onefile = FALSE, paper =
> "special". Note that the bounding box is for the device region: if you
> find the white space around the plot region excessive, reduce the
> margins of the figure region via par(mar=).
I would like to suggest the following wrapper:
eps <- function(file="Rplot%03d.eps", horizontal=FALSE, paper="special", ...) {
postscript(file=file, onefile=FALSE, horizontal=horizontal, paper=paper, ...);
}
That separates the use case of creating EPS files and "regular"
postscript files allow each of eps() and postscript() to have their
own default values.
/Henrik
>
>
> is moved to a new Notes section, which could precede the Details
> section, given the likely nature of such use. This change could be done
> now for R-patched and R-devel.
>
> A separate second comment could be added to the Notes section,
> indicating that the defaults will change to those above in version
> 2.8.0. The longer time frame would give affected package maintainers a
> heads up of the pending change and more lead time for implementation of
> any changes.
>
> HTH,
>
> Marc
>
> __
> 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] Cross Compiling for ARM
I am trying to cross compile R-2.6.0 for ARM. I have my cross compiling tool chain set up already. I've read the cross compiling guide for WIN # http://cran.r-project.org/doc/contrib/cross-build.pdf # http://cran.r-project.org/doc/contrib/Makefile-rcb Following the same approach, I compiled the native R-2.6.0 version first. Then passed R=R-2.6.0 to ./configure. After that, I hacked makefiles to set R_EXE to the native R binary. I was able to compile through until R packages in /src/library, where the following command was issued $R_EXE --vanilla --slave -f /src/library/base/makebasedb.R | Error in eval(expr, envir, enclos) : | may already be using lazy loading on base | Calls: local -> eval.parent -> eval -> eval -> eval -> eval | Execution halted Seems the error was caused by lazy loading mechanism of the native R binary on the host. AFAIK --vanilla should suppress loading any package upon startup, however, seems there is no way to get around lazy loading. My questions are why cross compiling for WIN don't hit this error (maybe some special setting I'm not aware of was set in the makefile for WIN). Second, how could I get around this lazy loading issue, if my approach is not completely off? Thanks Gordon __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
