[Rd] Using \u2030 in plot axis label -> stack smashing
Dear List I just noticed the following behaviour in R 2.3.1 Patched (2006-06-13 r38342) and confirmed similar behaviour in R 2.4.0 alpha (2006-09-18 r39383) & R 2.5.0 (2006-09-18 r39383) - which may actually be the same thing?, that trying to plot the unicode character \u2030 (which should be in a ‰ [per mille] sign) in an axis label leads to the following error: *** stack smashing detected ***: /home/gavin/R/R-devel/build/bin/exec/R terminated Aborted The simplest, reproducible example I have tried is: plot(1:10, ylab = "\u2030") This is on a Fedora Core 5 box. Relevant version/session info below. I presume this is how you are supposed to enter Unicode characters for use in stings etc? If so, can anyone else reproduce this - or is this something peculiar to my set-up and/or lack of fonts? Cheers Gav ## R 2.3.1 patched > sessionInfo() Version 2.3.1 Patched (2006-06-13 r38342) i686-pc-linux-gnu attached base packages: [1] "methods" "stats" "graphics" "grDevices" "utils" "datasets" [7] "base" > version _ platform i686-pc-linux-gnu arch i686 os linux-gnu system i686, linux-gnu status Patched major 2 minor 3.1 year 2006 month 06 day13 svn rev38342 language R version.string Version 2.3.1 Patched (2006-06-13 r38342) ## R 2.4.0 > sessionInfo() R version 2.4.0 alpha (2006-09-18 r39383) i686-pc-linux-gnu locale: LC_CTYPE=en_GB.UTF-8;LC_NUMERIC=C;LC_TIME=en_GB.UTF-8;LC_COLLATE=en_GB.UTF-8;LC_MONETARY=en_GB.UTF-8;LC_MESSAGES=en_GB.UTF-8;LC_PAPER=en_GB.UTF-8;LC_NAME=C;LC_ADDRESS=C;LC_TELEPHONE=C;LC_MEASUREMENT=en_GB.UTF-8;LC_IDENTIFICATION=C attached base packages: [1] "methods" "stats" "graphics" "grDevices" "utils" "datasets" [7] "base" > version _ platform i686-pc-linux-gnu arch i686 os linux-gnu system i686, linux-gnu status alpha major 2 minor 4.0 year 2006 month 09 day18 svn rev39383 language R version.string R version 2.4.0 alpha (2006-09-18 r39383) ## R 2.5.0 > sessionInfo() R version 2.5.0 Under development (unstable) (2006-09-18 r39383) i686-pc-linux-gnu locale: LC_CTYPE=en_GB.UTF-8;LC_NUMERIC=C;LC_TIME=en_GB.UTF-8;LC_COLLATE=en_GB.UTF-8;LC_MONETARY=en_GB.UTF-8;LC_MESSAGES=en_GB.UTF-8;LC_PAPER=en_GB.UTF-8;LC_NAME=C;LC_ADDRESS=C;LC_TELEPHONE=C;LC_MEASUREMENT=en_GB.UTF-8;LC_IDENTIFICATION=C attached base packages: [1] "methods" "stats" "graphics" "grDevices" "utils" "datasets" [7] "base" > version _ platform i686-pc-linux-gnu arch i686 os linux-gnu system i686, linux-gnu status Under development (unstable) major 2 minor 5.0 year 2006 month 09 day18 svn rev39383 language R version.string R version 2.5.0 Under development (unstable) (2006-09-18 r39383) -- %~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~% Gavin Simpson [t] +44 (0)20 7679 0522 ECRC & ENSIS, UCL Geography, [f] +44 (0)20 7679 0565 Pearson Building, [e] gavin.simpsonATNOSPAMucl.ac.uk Gower Street, London [w] http://www.ucl.ac.uk/~ucfagls/ UK. WC1E 6BT. [w] http://www.freshwaters.org.uk %~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~% __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Help for methods
Help for help says:
The 'topic' argument may also be a function call, to ask for
documentation on a corresponding method. See the section on
method documentation.
and
The authors of formal ('S4') methods can provide documentation on
specific methods, as well as overall documentation on the methods
of a particular function. The '"?"' operator allows access to
this documentation in three ways.
...
There are two different ways to look for documentation on a
particular method. The first is to supply the 'topic' argument in
the form of a function call, omitting the 'type' argument. The
effect is to look for documentation on the method that would be
used if this function call were actually evaluated. See the
examples below. If the function is not a generic (no S4 methods
are defined for it), the help reverts to documentation on the
function name.
Which doesn't explicitly mention whether this will work for S3 either
way, but the results from:
?summary
?summary(lm(wt ~ mpg, data=mtcars)
?summary(data.frame())
seem to indicate that it doesn't (at least in my R2.3.0, which is out
of date, but I did also search the latest NEWS file for anthing
mentioning help). Would it be possible to extend this method to deal
with S3 classes as well?
Hadley
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] R 2.4.0, methods and rebuild management
With R 2.4.0 around the corner, I intend to resume the usual process of providing beta snapshot packages in Debian unstable. By updating them before they hit 'testing', we give ourselves a nice window in which we can update the packages as needed so that once 2.4.0 comes out for good on October 3, we should be in good shape. But how can I effectively manage this? Running $ apt-cache search ^r-.* | \ grep -v "r-base\|r-doc\|r-gnome\|r-mathlib\|r-recom" | wc -l leads to 80 entries all of which are indeed packages. Is there a way to proactively tell which ones use S4 and the methods package, and need updates? 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
Re: [Rd] R 2.4.0, methods and rebuild management
On Mon, 18 Sep 2006, Dirk Eddelbuettel wrote: > > With R 2.4.0 around the corner, I intend to resume the usual process of > providing beta snapshot packages in Debian unstable. By updating them before > they hit 'testing', we give ourselves a nice window in which we can update > the packages as needed so that once 2.4.0 comes out for good on October 3, we > should be in good shape. > > But how can I effectively manage this? Running > > $ apt-cache search ^r-.* | \ > grep -v "r-base\|r-doc\|r-gnome\|r-mathlib\|r-recom" | wc -l > > leads to 80 entries all of which are indeed packages. Is there a way to > proactively tell which ones use S4 and the methods package, and need updates? Only with some difficulty. Such packages ought to declare 'methods' in the Depends or Imports fields of their DESCRIPTION files, and most do. Exceptions found by 'R CMD check' are Hmisc e1071 gRbase kinship rggobi rstream startupmsg wavelets: the checks used are not exhaustive. -- 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] R 2.4.0, methods and rebuild management
On 18 September 2006 at 17:14, Prof Brian Ripley wrote: | On Mon, 18 Sep 2006, Dirk Eddelbuettel wrote: | | > | > With R 2.4.0 around the corner, I intend to resume the usual process of | > providing beta snapshot packages in Debian unstable. By updating them before | > they hit 'testing', we give ourselves a nice window in which we can update | > the packages as needed so that once 2.4.0 comes out for good on October 3, we | > should be in good shape. | > | > But how can I effectively manage this? Running | > | > $ apt-cache search ^r-.* | \ | >grep -v "r-base\|r-doc\|r-gnome\|r-mathlib\|r-recom" | wc -l | > | > leads to 80 entries all of which are indeed packages. Is there a way to | > proactively tell which ones use S4 and the methods package, and need updates? | | Only with some difficulty. Such packages ought to declare 'methods' in | the Depends or Imports fields of their DESCRIPTION files, and most do. | Exceptions found by 'R CMD check' are Hmisc e1071 gRbase kinship rggobi | rstream startupmsg wavelets: the checks used are not exhaustive. Ok, thanks for this. I guess I should write a quick script to mirror or download all DESCRIPTIONS files. Of those 'exceptional' ones you list above, e1071 is about to enter Debian to I'll talk to the maintainer, and Hmisc + rggobi are among my packages; the rest we don't cover. Thanks, 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
Re: [Rd] Using \u2030 in plot axis label -> stack smashing
Gavin Simpson ucl.ac.uk> writes: > > Dear List > > I just noticed the following behaviour in R 2.3.1 Patched (2006-06-13 > r38342) and confirmed similar behaviour in R 2.4.0 alpha (2006-09-18 > r39383) & R 2.5.0 (2006-09-18 r39383) - which may actually be the same > thing?, that trying to plot the unicode character \u2030 (which should > be in a ‰ [per mille] sign) in an axis label leads to the following > error: > > *** stack smashing detected ***: /home/gavin/R/R-devel/build/bin/exec/R > terminated > Aborted > > The simplest, reproducible example I have tried is: > > plot(1:10, ylab = "\u2030") > I can not reproduce this on my Debian GNU/Linux. I get something like "S for y label under 2.3.1 2006-06-01 and 2.5.0 2006-09-13 r39292 with the following locale [1] "LC_CTYPE=en_GB.UTF-8;LC_NUMERIC=C;LC_TIME=en_GB.UTF-8; LC_COLLATE=en_GB.UTF-8;LC_MONETARY=en_GB.UTF-8;LC_MESSAGES=en_GB.UTF-8; LC_PAPER=C;LC_NAME=C;LC_ADDRESS=C;LC_TELEPHONE=C;LC_MEASUREMENT=C; LC_IDENTIFICATION=C" It does not change if I set everything into en_GB.UTF-8. Is this valid unicode code? Gregor __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Legend frame error (PR#9236)
Hello,
The frame drawn around the legend appears to miscalculate when the
x-axis decreases rather than increases. Pasted below is a simple
testcase. When the x-axis decreases, the width of the legend frame
appears to be calculated based on the length of the first item, rather
than the maximum length of all items.
Thanks,
-TAG
Todd A. Gibson
line1=dpois(seq(0,50), 10)
par(mfcol=c(2,1))
plot(line1, col="blue", type="l")
legend(x=30,y=0.10, legend=c("binding","transcription","Random Genes"),
col=c("red", "blue","black"),lty=c(1,1,2),lwd=c(2,2,1))
plot(line1, col="blue", type="l", xlim=c(50,0))
legend(x=30,y=0.10, legend=c("binding","transcription","Random Genes"),
col=c("red", "blue","black"),lty=c(1,1,2),lwd=c(2,2,1))
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Legend frame error (PR#9236)
[EMAIL PROTECTED] writes:
> Hello,
> The frame drawn around the legend appears to miscalculate when the
> x-axis decreases rather than increases. Pasted below is a simple
> testcase. When the x-axis decreases, the width of the legend frame
> appears to be calculated based on the length of the first item, rather
> than the maximum length of all items.
More likely, it is calculating the maximum of the endpoints, which
will of course be the one furthest to the left if the x axis is
reversed. (As reordering the legends would have shown you.)
The construction
if (is.null(text.width))
text.width <- max(strwidth(legend, units = "user", cex = cex))
else if (!is.numeric(text.width) || text.width < 0)
stop("'text.width' must be numeric, >= 0")
seems to be the culprit. max() should be min() in the reversed case.
And if I'm not mistaken, there's an additional issue: If the x axis is
reversed, an explicit text.width setting should in fact be negative.
--
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] Using \u2030 in plot axis label -> stack smashing
On Mon, 2006-09-18 at 19:02 +, Gregor Gorjanc wrote: > Gavin Simpson ucl.ac.uk> writes: > > > > Dear List > > > > I just noticed the following behaviour in R 2.3.1 Patched (2006-06-13 > > r38342) and confirmed similar behaviour in R 2.4.0 alpha (2006-09-18 > > r39383) & R 2.5.0 (2006-09-18 r39383) - which may actually be the same > > thing?, that trying to plot the unicode character \u2030 (which should > > be in a ‰ [per mille] sign) in an axis label leads to the following > > error: > > > > *** stack smashing detected ***: /home/gavin/R/R-devel/build/bin/exec/R > > terminated > > Aborted > > > > The simplest, reproducible example I have tried is: > > > > plot(1:10, ylab = "\u2030") > > > > I can not reproduce this on my Debian GNU/Linux. I get something like "S > for y label under 2.3.1 2006-06-01 and 2.5.0 2006-09-13 r39292 with the > following locale > > [1] "LC_CTYPE=en_GB.UTF-8;LC_NUMERIC=C;LC_TIME=en_GB.UTF-8; > LC_COLLATE=en_GB.UTF-8;LC_MONETARY=en_GB.UTF-8;LC_MESSAGES=en_GB.UTF-8; > LC_PAPER=C;LC_NAME=C;LC_ADDRESS=C;LC_TELEPHONE=C;LC_MEASUREMENT=C; > LC_IDENTIFICATION=C" > > It does not change if I set everything into en_GB.UTF-8. Is this valid > unicode code? > > Gregor Cheers for the follow up Gregor, I was following advice given by Prof. Ripley in a posting on R-Help about how to get the per mille character: http://finzi.psych.upenn.edu/R/Rhelp02a/archive/48709.html It should look like a "%" character but with two circles at the bottom. I get the same (stack smashing) behaviour on my FC5 laptop with R 2.3.1 patched as below: > sessionInfo() Version 2.3.1 Patched (2006-09-02 r39223) i686-pc-linux-gnu attached base packages: [1] "methods" "stats" "graphics" "grDevices" "utils" "datasets" [7] "base" > version _ platform i686-pc-linux-gnu arch i686 os linux-gnu system i686, linux-gnu status Patched major 2 minor 3.1 year 2006 month 09 day02 svn rev39223 language R version.string Version 2.3.1 Patched (2006-09-02 r39223) G -- %~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~% Gavin Simpson [t] +44 (0)20 7679 0522 ECRC & ENSIS, UCL Geography, [f] +44 (0)20 7679 0565 Pearson Building, [e] gavin.simpsonATNOSPAMucl.ac.uk Gower Street, London [w] http://www.ucl.ac.uk/~ucfagls/cv/ London, UK. WC1E 6BT. [w] http://www.ucl.ac.uk/~ucfagls/ %~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~%~% __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] An update method for lists?
On 9/15/06, Deepayan Sarkar <[EMAIL PROTECTED]> wrote:
> On 9/15/06, Martin Maechler <[EMAIL PROTECTED]> wrote:
> > > "DeepS" == Deepayan Sarkar <[EMAIL PROTECTED]>
> > > on Fri, 15 Sep 2006 12:22:15 -0700 writes:
> >
> > DeepS> Hi, since lattice uses nested lists in various
> > DeepS> situations, it has had an unexported function called
> > DeepS> updateList for a while, which looks like
> >
> > >> > lattice:::updateList
> > >> function (x, val)
> > >> {
> > >> if (is.null(x))
> > >> x <- list()
> > >> if (!is.list(x))
> > >> stop("x must be NULL or a list")
> > >> if (!is.list(val))
> > >> stop("val must be a list")
> > >> xnames <- names(x)
> > >> for (v in names(val)) {
> > >> existing <- v %in% xnames
> > >> if (existing && is.list(x[[v]]) && is.list(val[[v]]))
> > >> x[[v]] <- updateList(x[[v]], val[[v]])
> > >> else x[[v]] <- val[[v]]
> > >> }
> > >> x
> > >> }
> >
> > [I'm not sure I'd allow NULL for 'x'; typing list() instead of
> > NULL is not much more, but when the function name even includes 'list'
> > I'd really require a list for 'x']
>
> Makes sense.
>
> > You could hence collapse the first 6 lines to the single
> >
> >stopifnot(is.list(x), is.list(val))
>
> I'll check if lattice needs some fixes with this.
Actually, I do need to allow NULL, because update.trellis does things like
update.trellis <- function(object, ..., par.strip.text, ...)
{
...
object$par.strip.text <- updateList(object$par.strip.text, par.strip.text)
...
}
where object$par.strip.text may be initially NULL. But I'll do that
inside a lattice wrapper.
> > DeepS> Basically, it recursively replaces elements that have
> > DeepS> been specified in val, leaving the other components
> > DeepS> alone. I'm not aware of any other actual situation
> > DeepS> where this is useful, but it certainly can be, so I
> > DeepS> want to export this functionaliy. At least one other
> > DeepS> person (Gabor) has also asked for that.
> >
> > I've had a similar need only recently:
> > If a list is used to store "defaults" and you want a safe way to
> > change only a few of the values...
> > I presume you use this for manipulating the settings of lattice
> > parts ?
>
> Yes, it's primarily used inside trellis.par.set, but many other places as
> well.
>
> > DeepS> Now, as the name suggests, I think it might be
> > DeepS> reasonable to export this as an update method for
> > DeepS> "list" objects. Depending on what others (in
> > DeepS> particular r-core) think, one of these things might
> > DeepS> happen:
> >
> > DeepS> (1) I export it as updateList (or some other name) in lattice
> > DeepS> (2) I export it as an S3 method update.list in lattice
> > DeepS> (3) It gets added as an S3 method update.list in one of the base
> > packages
> > or
> > (4) it gets added as utility function updateList() to
> > 'utils' {= one of the base packages}
>
> Yes, that a good option too (certainly better than (1))
>
> > which I'd favor momentarily.
> > - update() is typically for updating *models*
> > - it's not clear that this is *the* method for update()ing a list
>
> I agree. Part of the reason I brought this up is because it is not
> clear to me what justifies a new method for an existing generic. An
> argument for is that one doesn't introduce yet another function, which
> (I thought) might be enough if the other choice is to not have any
> method at all.
>
> > I'm also a bit wondering if it wouldn't make sense to change the name to
> > something like assignInList().
>
> I'm open to suggestions for the name. I didn't think too much about it
> since it was unexported anyway.
>
> > DeepS> The default option is (1), and I guess Sept 19 is the deadline
> > for any
> > DeepS> of these to be included in R 2.4.0.
> >
> > Yes, that's true for (3) & (4) are higher if you provide a patch
> > to R-devel (not R-alpha) which includes a man page ... [but
> > don't hurry, I'd like to see other comments]
I have checked in
https://svn.r-project.org/R-packages/trunk/lattice/R/modifyList.R
https://svn.r-project.org/R-packages/trunk/lattice/man/modifyList.Rd
which I'm happy to offer for inclusion in utils or wherever might seem
appropriate. I'll upload a version of lattice which includes these
late tomorrow if I don't see any more comments by then.
I've changed the name because I wasn't sure if assignInList might be
confusing, as the semantics are different from those of assign (assign
is like 'fix', while this is more like 'edit'). However, any name is
fine with me.
Deepayan
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] An update method for lists?
It would be nice if the .Rd file had one or more examples
since its not that easy to otherwise understand what it
does. Regards.
On 9/18/06, Deepayan Sarkar <[EMAIL PROTECTED]> wrote:
> On 9/15/06, Deepayan Sarkar <[EMAIL PROTECTED]> wrote:
> > On 9/15/06, Martin Maechler <[EMAIL PROTECTED]> wrote:
> > > > "DeepS" == Deepayan Sarkar <[EMAIL PROTECTED]>
> > > > on Fri, 15 Sep 2006 12:22:15 -0700 writes:
> > >
> > > DeepS> Hi, since lattice uses nested lists in various
> > > DeepS> situations, it has had an unexported function called
> > > DeepS> updateList for a while, which looks like
> > >
> > > >> > lattice:::updateList
> > > >> function (x, val)
> > > >> {
> > > >> if (is.null(x))
> > > >> x <- list()
> > > >> if (!is.list(x))
> > > >> stop("x must be NULL or a list")
> > > >> if (!is.list(val))
> > > >> stop("val must be a list")
> > > >> xnames <- names(x)
> > > >> for (v in names(val)) {
> > > >> existing <- v %in% xnames
> > > >> if (existing && is.list(x[[v]]) && is.list(val[[v]]))
> > > >> x[[v]] <- updateList(x[[v]], val[[v]])
> > > >> else x[[v]] <- val[[v]]
> > > >> }
> > > >> x
> > > >> }
> > >
> > > [I'm not sure I'd allow NULL for 'x'; typing list() instead of
> > > NULL is not much more, but when the function name even includes 'list'
> > > I'd really require a list for 'x']
> >
> > Makes sense.
> >
> > > You could hence collapse the first 6 lines to the single
> > >
> > >stopifnot(is.list(x), is.list(val))
> >
> > I'll check if lattice needs some fixes with this.
>
> Actually, I do need to allow NULL, because update.trellis does things like
>
> update.trellis <- function(object, ..., par.strip.text, ...)
> {
>...
>object$par.strip.text <- updateList(object$par.strip.text, par.strip.text)
>...
> }
>
> where object$par.strip.text may be initially NULL. But I'll do that
> inside a lattice wrapper.
>
> > > DeepS> Basically, it recursively replaces elements that have
> > > DeepS> been specified in val, leaving the other components
> > > DeepS> alone. I'm not aware of any other actual situation
> > > DeepS> where this is useful, but it certainly can be, so I
> > > DeepS> want to export this functionaliy. At least one other
> > > DeepS> person (Gabor) has also asked for that.
> > >
> > > I've had a similar need only recently:
> > > If a list is used to store "defaults" and you want a safe way to
> > > change only a few of the values...
> > > I presume you use this for manipulating the settings of lattice
> > > parts ?
> >
> > Yes, it's primarily used inside trellis.par.set, but many other places as
> > well.
> >
> > > DeepS> Now, as the name suggests, I think it might be
> > > DeepS> reasonable to export this as an update method for
> > > DeepS> "list" objects. Depending on what others (in
> > > DeepS> particular r-core) think, one of these things might
> > > DeepS> happen:
> > >
> > > DeepS> (1) I export it as updateList (or some other name) in lattice
> > > DeepS> (2) I export it as an S3 method update.list in lattice
> > > DeepS> (3) It gets added as an S3 method update.list in one of the
> > > base packages
> > > or
> > > (4) it gets added as utility function updateList() to
> > > 'utils' {= one of the base packages}
> >
> > Yes, that a good option too (certainly better than (1))
> >
> > > which I'd favor momentarily.
> > > - update() is typically for updating *models*
> > > - it's not clear that this is *the* method for update()ing a list
> >
> > I agree. Part of the reason I brought this up is because it is not
> > clear to me what justifies a new method for an existing generic. An
> > argument for is that one doesn't introduce yet another function, which
> > (I thought) might be enough if the other choice is to not have any
> > method at all.
> >
> > > I'm also a bit wondering if it wouldn't make sense to change the name to
> > > something like assignInList().
> >
> > I'm open to suggestions for the name. I didn't think too much about it
> > since it was unexported anyway.
> >
> > > DeepS> The default option is (1), and I guess Sept 19 is the deadline
> > > for any
> > > DeepS> of these to be included in R 2.4.0.
> > >
> > > Yes, that's true for (3) & (4) are higher if you provide a patch
> > > to R-devel (not R-alpha) which includes a man page ... [but
> > > don't hurry, I'd like to see other comments]
>
> I have checked in
>
> https://svn.r-project.org/R-packages/trunk/lattice/R/modifyList.R
> https://svn.r-project.org/R-packages/trunk/lattice/man/modifyList.Rd
>
> which I'm happy to offer for inclusion in utils or wherever might seem
> appropriate. I'll upload a version of lattice which includes these
> late tomorrow if I don't see any more comments by then.
>
> I've changed the name because I wasn't sure if assignInList might be
> confusing,
Re: [Rd] An update method for lists?
On 9/18/06, Gabor Grothendieck <[EMAIL PROTECTED]> wrote: > It would be nice if the .Rd file had one or more examples > since its not that easy to otherwise understand what it > does. Regards. Added now, although it's not very realistic. Deepayan __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Rgui.exe plot device "Save as" crash (PR#9237)
Full_Name: Michael Toews Version: 2.3.1 OS: WindowsXP Home/Proffesional SP2 Submission from: (NULL) (142.58.206.114) Hi, I have a bug that I can reproduce on two different MS Windows platforms (1:AMD64x2/WinXP SP2 Home; 2:P4/WinXP SP2 Prof.) which is triggered by the "Save as" dialog when saving a plot from a Windows device onto the Desktop. This bug is difficult to reproduce, but here are some instructions to attempt a crash: 1) Start R from Start menu 2) Plot something simple, such as "plot(1:5)" 3) Choose "File > Save as PDF" 4) In the dialog, click the "Save in:" drop-down menu at the top, and select "Desktop" 5) Type "boohoo" in the "File name:" field, and click "Save" 6) Repeat steps 3 and 4, but try to not hover the mouse over any files or window controls, except for "boohoo.pdf" (although this isn't always the case). If you don't crash, repeat steps 3 to 5 again until a crash. 7) *crash*; Windows will display the default crash dialog; Rgui.exe will appear in the Windows Task Manager (ctrl-alt-del in Processes tab) using about 0 of CPU. 8) Click "Don't Send" from the dialog 9) Observe that "Rgui.exe" is now using all available CPU resources for that thread (this is about 50 for Hyper-threading-enabled or dual-core CPUs). It is probably in an infinite loop. 10) Choose "Rgui.exe" from the Processes in Windows Task Manager, and click "End Process". Now your system will be stable, and you can repeat the bug, if you wish. Here are some things that do _not_ affect the outcome: - Presence or absence of a custom .Rprofile in C:\Program Files\R\R-2.3.1, or Rconsole in "My Documents" - The use of a different file name in step 5; I have also tried "tmp" and "rat a tat tat", so spaces don't seem to matter - The complexity of the plot - Active or inactive Windows devices - MDI or SDI modes for GUI Here are some things that _do_ affect the outcome: - No crash if you "Save as" any of the Jpeg options, but crash for all of the other formats (Metafile, Postscript, etc.) - No crash if in other folder, such as "My Documents"; this crash seems to happen only in the Desktop folder when accessed through the drop-down list at the top or the button on the left-hand side (oddly enough, when navigating an absolute path from C:\Documents and Settings\etc..\Desktop, there is no crash) - In the "Save as" dialog, if you navigate to the Desktop folder by selecting the button on the left-hand side of the dialog (rather than in the "Save in:" drop-down field as indicated in step 4), the crash does _not_ trigger the default Microsoft crash dialog, and Rgui.exe silently crashes (disappears), but remains as an active process, using ~ 50% of CPU resources, and requires a manual "End Process". - If "Debug" (if available) or "Send Report [to Microsoft]" are pressed in the crash dialog, the Rgui.exe process ends normally, and no manual "End Process" is required. Sorry if this seems "TooMuchAtOnce", but it is all the same bug with lots of details. My guess is it has something to do with the Tooltip from the Windows system "Save as" dialog, which suggests there is a bug in R's implementation of the system "Save as" dialog. As well, it appears to have problems with the "Desktop" folder when navigated from the convenient "Desktop" links (either from the upper drop-down list or left-hand button) in the "Save" dialog. I don't have access to a pre-compiled Win32 EXE of the the R 2.4.0 alpha releases, otherwise I would try to trigger this bug on the upcoming release. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Rgui.exe plot device "Save as" crash (PR#9237)
On 9/18/2006 8:32 PM, [EMAIL PROTECTED] wrote: > Full_Name: Michael Toews > Version: 2.3.1 > OS: WindowsXP Home/Proffesional SP2 > Submission from: (NULL) (142.58.206.114) > > > Hi, > I have a bug that I can reproduce on two different MS Windows platforms > (1:AMD64x2/WinXP SP2 Home; 2:P4/WinXP SP2 Prof.) which is triggered by the > "Save > as" dialog when saving a plot from a Windows device onto the Desktop. This bug > is difficult to reproduce, but here are some instructions to attempt a crash: > 1) Start R from Start menu > 2) Plot something simple, such as "plot(1:5)" > 3) Choose "File > Save as PDF" > 4) In the dialog, click the "Save in:" drop-down menu at the top, and select > "Desktop" > 5) Type "boohoo" in the "File name:" field, and click "Save" > 6) Repeat steps 3 and 4, but try to not hover the mouse over any files or > window > controls, except for "boohoo.pdf" (although this isn't always the case). If > you > don't crash, repeat steps 3 to 5 again until a crash. > 7) *crash*; Windows will display the default crash dialog; Rgui.exe will > appear > in the Windows Task Manager (ctrl-alt-del in Processes tab) using about 0 of > CPU. Thanks for the detailed instructions. I can reproduce this in 2.3.1, and a fairly recent (but not today's) R-patched build. I'm just building a current Alpha build to test it there. I'm not sure it's something we'll be able to fix: tooltips are very complicated things, involving tons of DLLs outside of R. This could be an Adobe bug (since Acrobat might be involved in producing a tooltip for a PDF), a Windows bug, or something completely unrelated that just happens to be hooked into Explorer. The fact that we can both see it suggests it's either in R or Windows, though. > 8) Click "Don't Send" from the dialog > 9) Observe that "Rgui.exe" is now using all available CPU resources for that > thread (this is about 50 for Hyper-threading-enabled or dual-core CPUs). It is > probably in an infinite loop. > 10) Choose "Rgui.exe" from the Processes in Windows Task Manager, and click > "End > Process". Now your system will be stable, and you can repeat the bug, if you > wish. > > Here are some things that do _not_ affect the outcome: > - Presence or absence of a custom .Rprofile in C:\Program Files\R\R-2.3.1, or > Rconsole in "My Documents" > - The use of a different file name in step 5; I have also tried "tmp" and > "rat a > tat tat", so spaces don't seem to matter > - The complexity of the plot > - Active or inactive Windows devices > - MDI or SDI modes for GUI > > Here are some things that _do_ affect the outcome: > - No crash if you "Save as" any of the Jpeg options, but crash for all of the > other formats (Metafile, Postscript, etc.) > - No crash if in other folder, such as "My Documents"; this crash seems to > happen only in the Desktop folder when accessed through the drop-down list at > the top or the button on the left-hand side (oddly enough, when navigating an > absolute path from C:\Documents and Settings\etc..\Desktop, there is no crash) > - In the "Save as" dialog, if you navigate to the Desktop folder by selecting > the button on the left-hand side of the dialog (rather than in the "Save in:" > drop-down field as indicated in step 4), the crash does _not_ trigger the > default Microsoft crash dialog, and Rgui.exe silently crashes (disappears), > but > remains as an active process, using ~ 50% of CPU resources, and requires a > manual "End Process". > - If "Debug" (if available) or "Send Report [to Microsoft]" are pressed in the > crash dialog, the Rgui.exe process ends normally, and no manual "End Process" > is > required. > > Sorry if this seems "TooMuchAtOnce", but it is all the same bug with lots of > details. My guess is it has something to do with the Tooltip from the Windows > system "Save as" dialog, which suggests there is a bug in R's implementation > of > the system "Save as" dialog. As well, it appears to have problems with the > "Desktop" folder when navigated from the convenient "Desktop" links (either > from > the upper drop-down list or left-hand button) in the "Save" dialog. > > I don't have access to a pre-compiled Win32 EXE of the the R 2.4.0 alpha > releases, otherwise I would try to trigger this bug on the upcoming release. You can download (approximately) daily builds from cran.r-project.org/bin/windows/base/rtest.html. Duncan Murdoch __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Rgui.exe plot device "Save as" crash (PR#9237)
On 9/18/2006 9:39 PM, [EMAIL PROTECTED] wrote: > On 9/18/2006 8:32 PM, [EMAIL PROTECTED] wrote: >> Full_Name: Michael Toews >> Version: 2.3.1 >> OS: WindowsXP Home/Proffesional SP2 >> Submission from: (NULL) (142.58.206.114) >> >> >> Hi, >> I have a bug that I can reproduce on two different MS Windows platforms >> (1:AMD64x2/WinXP SP2 Home; 2:P4/WinXP SP2 Prof.) which is triggered by the >> "Save >> as" dialog when saving a plot from a Windows device onto the Desktop. This >> bug >> is difficult to reproduce, but here are some instructions to attempt a crash: >> 1) Start R from Start menu >> 2) Plot something simple, such as "plot(1:5)" >> 3) Choose "File > Save as PDF" >> 4) In the dialog, click the "Save in:" drop-down menu at the top, and select >> "Desktop" >> 5) Type "boohoo" in the "File name:" field, and click "Save" >> 6) Repeat steps 3 and 4, but try to not hover the mouse over any files or >> window >> controls, except for "boohoo.pdf" (although this isn't always the case). If >> you >> don't crash, repeat steps 3 to 5 again until a crash. >> 7) *crash*; Windows will display the default crash dialog; Rgui.exe will >> appear >> in the Windows Task Manager (ctrl-alt-del in Processes tab) using about 0 of >> CPU. > > Thanks for the detailed instructions. I can reproduce this in 2.3.1, > and a fairly recent (but not today's) R-patched build. I'm just > building a current Alpha build to test it there. I do see the crash in R version 2.4.0 alpha (2006-09-17 r39373), with this stack dump: Call stack: 7CA5158E SHELL32.dll:7CA5158E SHCreateQueryCancelAutoPlayMoniker 7CB2FE26 SHELL32.dll:7CB2FE26 CallCPLEntry16 7CB2FF6A SHELL32.dll:7CB2FF6A CallCPLEntry16 7CB295B5 SHELL32.dll:7CB295B5 Ordinal211 7C9F208D SHELL32.dll:7C9F208D ILFindChild 75F81B9A browseui.dll:75F81B9A Ordinal113 77F69498 SHLWAPI.dll:77F69498 Ordinal120 7C927545 ntdll.dll:7C927545 RtlUpcaseUnicodeString 7C927583 ntdll.dll:7C927583 RtlUpcaseUnicodeString 7C927645 ntdll.dll:7C927645 RtlUpcaseUnicodeString 7C92761C ntdll.dll:7C92761C RtlUpcaseUnicodeString 7C80B683 kernel32.dll:7C80B683 GetModuleFileNameA I really don't know where to go to start looking for this. It would be nice if we had something like valgrind for Windows, but we don't. Duncan Murdoch __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Using \u2030 in plot axis label -> stack smashing
Gavin Simpson wrote: > On Mon, 2006-09-18 at 19:02 +, Gregor Gorjanc wrote: >> Gavin Simpson ucl.ac.uk> writes: >>> Dear List >>> >>> I just noticed the following behaviour in R 2.3.1 Patched (2006-06-13 >>> r38342) and confirmed similar behaviour in R 2.4.0 alpha (2006-09-18 >>> r39383) & R 2.5.0 (2006-09-18 r39383) - which may actually be the same >>> thing?, that trying to plot the unicode character \u2030 (which should >>> be in a ‰ [per mille] sign) in an axis label leads to the following >>> error: >>> >>> *** stack smashing detected ***: /home/gavin/R/R-devel/build/bin/exec/R >>> terminated >>> Aborted >>> >>> The simplest, reproducible example I have tried is: >>> >>> plot(1:10, ylab = "\u2030") >>> >> I can not reproduce this on my Debian GNU/Linux. I get something like "S >> for y label under 2.3.1 2006-06-01 and 2.5.0 2006-09-13 r39292 with the >> following locale >> >> [1] "LC_CTYPE=en_GB.UTF-8;LC_NUMERIC=C;LC_TIME=en_GB.UTF-8; >> LC_COLLATE=en_GB.UTF-8;LC_MONETARY=en_GB.UTF-8;LC_MESSAGES=en_GB.UTF-8; >> LC_PAPER=C;LC_NAME=C;LC_ADDRESS=C;LC_TELEPHONE=C;LC_MEASUREMENT=C; >> LC_IDENTIFICATION=C" >> >> It does not change if I set everything into en_GB.UTF-8. Is this valid >> unicode code? >> >> Gregor > > Cheers for the follow up Gregor, > > I was following advice given by Prof. Ripley in a posting on R-Help > about how to get the per mille character: > > http://finzi.psych.upenn.edu/R/Rhelp02a/archive/48709.html > > It should look like a "%" character but with two circles at the bottom. Perhaps I do not have appropriate font for this character. Gregor __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Using \u2030 in plot axis label -> stack smashing
This seems to be the mine which I contrived. m(_|_)m
--- R-alpha.orig/src/main/gram.y2006-09-04 23:41:33.0 +0900
+++ R-alpha/src/main/gram.y 2006-09-19 13:01:41.0 +0900
@@ -99,11 +99,12 @@
# endif
#endif
#include
+#define MB_BUF 16
static size_t ucstomb(char *s, wchar_t wc, mbstate_t *ps)
{
char tocode[128];
-char buf[16];
+char buf[MB_BUF];
void*cd = NULL ;
wchar_t wcs[2];
char*inbuf = (char *) wcs;
@@ -1709,7 +1710,7 @@
error(_("\\u sequences not supported"));
#else
wint_t val = 0; int i, ext; size_t res;
- char buff[5]; Rboolean delim = FALSE;
+ char buff[MB_BUF]; Rboolean delim = FALSE;
if((c = xxgetc()) == '{') delim = TRUE; else xxungetc(c);
for(i = 0; i < 4; i++) {
c = xxgetc();
@@ -1743,7 +1744,7 @@
#ifdef SUPPORT_MBCS
else {
wint_t val = 0; int i, ext; size_t res;
- char buff[9]; Rboolean delim = FALSE;
+ char buff[MB_BUF]; Rboolean delim = FALSE;
if((c = xxgetc()) == '{') delim = TRUE; else xxungetc(c);
for(i = 0; i < 8; i++) {
c = xxgetc();
2006/9/19, Gregor Gorjanc <[EMAIL PROTECTED]>:
> Gavin Simpson wrote:
> > On Mon, 2006-09-18 at 19:02 +, Gregor Gorjanc wrote:
> >> Gavin Simpson ucl.ac.uk> writes:
> >>> Dear List
> >>>
> >>> I just noticed the following behaviour in R 2.3.1 Patched (2006-06-13
> >>> r38342) and confirmed similar behaviour in R 2.4.0 alpha (2006-09-18
> >>> r39383) & R 2.5.0 (2006-09-18 r39383) - which may actually be the same
> >>> thing?, that trying to plot the unicode character \u2030 (which should
> >>> be in a ‰ [per mille] sign) in an axis label leads to the following
> >>> error:
> >>>
> >>> *** stack smashing detected ***: /home/gavin/R/R-devel/build/bin/exec/R
> >>> terminated
> >>> Aborted
> >>>
> >>> The simplest, reproducible example I have tried is:
> >>>
> >>> plot(1:10, ylab = "\u2030")
> >>>
> >> I can not reproduce this on my Debian GNU/Linux. I get something like "S
> >> for y label under 2.3.1 2006-06-01 and 2.5.0 2006-09-13 r39292 with the
> >> following locale
> >>
> >> [1] "LC_CTYPE=en_GB.UTF-8;LC_NUMERIC=C;LC_TIME=en_GB.UTF-8;
> >> LC_COLLATE=en_GB.UTF-8;LC_MONETARY=en_GB.UTF-8;LC_MESSAGES=en_GB.UTF-8;
> >> LC_PAPER=C;LC_NAME=C;LC_ADDRESS=C;LC_TELEPHONE=C;LC_MEASUREMENT=C;
> >> LC_IDENTIFICATION=C"
> >>
> >> It does not change if I set everything into en_GB.UTF-8. Is this valid
> >> unicode code?
> >>
> >> Gregor
> >
> > Cheers for the follow up Gregor,
> >
> > I was following advice given by Prof. Ripley in a posting on R-Help
> > about how to get the per mille character:
> >
> > http://finzi.psych.upenn.edu/R/Rhelp02a/archive/48709.html
> >
> > It should look like a "%" character but with two circles at the bottom.
>
> Perhaps I do not have appropriate font for this character.
>
> Gregor
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>
--
EI-JI Nakama <[EMAIL PROTECTED]>
"\u4e2d\u9593\u6804\u6cbb" <[EMAIL PROTECTED]>
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
