Re: [Rd] Trivial patch for merge.Rd
> Marc Schwartz
> on Wed, 8 Jun 2016 21:13:40 +0200 writes:
>Hi all,
> After replying to r-help earlier today on the merge() related thread, I
> noted a trivial grammatical error in the description for the 'suffixes'
> argument in it's help file.
> A patch against the current SVN trunk version of merge.Rd in
> ..library/base/man is attached and pasted here:
> --- merge1.Rd 2016-06-08 13:34:35.0 -0500
> +++ merge2.Rd 2016-06-08 14:03:34.0 -0500
> @@ -42,7 +42,7 @@
> columns?}
> \item{suffixes}{a character vector of length 2 specifying the
> suffixes
> to be used for making unique the names of columns in the result
> -which not used for merging (appearing in \code{by} etc).}
> +which are not used for merging (appearing in \code{by} etc).}
> \item{incomparables}{values which cannot be matched. See
> \code{\link{match}}. This is intended to be used for merging on
> one
> column, so these are incomparable values of that column.}
> Thanks,
> Marc Schwartz
Thank you, Marc!
Committed to R-devel and R-patched (to be R 3.3.1, in ~ 11 days)
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] cumsum method in Math group
When running
a = runif(10)
class(a) = "foo"
Math.foo = function(x, ...) {
NextMethod(.Generic)
}
signif(a, 3)
cumsum(a)
I don't understand why cumsum strips the class, but signif does not.
Both claim in the documentation that "These are generic functions:
methods can be defined for them individually or via the ‘Math’ group
generic."
--
Edzer Pebesma
Institute for Geoinformatics (ifgi), University of Münster
Heisenbergstraße 2, 48149 Münster, Germany; +49 251 83 33081
Journal of Statistical Software: http://www.jstatsoft.org/
Computers & Geosciences: http://elsevier.com/locate/cageo/
Spatial Statistics Society http://www.spatialstatistics.info
signature.asc
Description: OpenPGP digital signature
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] cumsum method in Math group
On Thu, Jun 9, 2016 at 1:13 AM, Edzer Pebesma
wrote:
> When running
>
> a = runif(10)
> class(a) = "foo"
> Math.foo = function(x, ...) {
> NextMethod(.Generic)
> }
> signif(a, 3)
> cumsum(a)
>
>
> I don't understand why cumsum strips the class, but signif does not.
> Both claim in the documentation that "These are generic functions:
> methods can be defined for them individually or via the ‘Math’ group
> generic."
>
There's no contract that the class be preserved. Only that dispatch
will happen. It's fairly unpredictable when R will preserve
attributes, like class. It's safest to cast the result in your Math
method. In general, who is to say whether the cumsum() of an object is
a valid instance of the same class? This also implies that, while
initially tempting, extending base types, in particular vector types,
will ultimately lead to unpredictable behavior and frustration.
Consider composition instead.
> --
> Edzer Pebesma
> Institute for Geoinformatics (ifgi), University of Münster
> Heisenbergstraße 2, 48149 Münster, Germany; +49 251 83 33081
> Journal of Statistical Software: http://www.jstatsoft.org/
> Computers & Geosciences: http://elsevier.com/locate/cageo/
> Spatial Statistics Society http://www.spatialstatistics.info
>
>
> __
> 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] readlines() truncates text file with Codepage 437 encoding
I can reproduce the issue on Linux (Fedora F22),
R 3.3.0 patched of today.
Here's code for experimenting which allows to reproduce the
issue without the need for an attached file (there's a temporary
file created and removed as part of the function below) :
##---
##' @title write-binary-readLines testing
##' @param i vector of integers in 0:255 to be used as character codes
##' @param file.name optional
##' @param encoding "437" is the one where the problem has been reported
##' @return the readLines() resulting character string with attributes
##' @author Martin Maechler
wb.readL <- function(i, file.name = tempfile("bin"), encoding = "437") {
stopifnot(is.integer(i), 0 <= i, i <= 255,
is.character(file.name))
ff <- file(file.name, "wb")
writeBin(as.raw(i), ff)
close(ff) ; on.exit(unlink(file.name))
## Now read "as codepage" :
ch <- readLines(file(file.name, encoding = encoding))
##- --- typically gives warning
structure(ch,
fSize = file.size(file.name),
nchars = c(b = nchar(ch, "b"),
c = nchar(ch, "c"),
w = nchar(ch, "w")))
}
ii <- c(11:12, 14:255, 10L)
(cc <- wb.readL(ii))
##---
gives
> (cc <- wb.readL(ii))
[1]
"\v\f\016\017\020\021\022\023\024\025\026\027\030\031\032\033\034\035\036\037
!\"#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\\]^_`abcdefghijklmnopqrstuvwxyz{|}~\177ÇüéâäàåçêëèïîìÄÅÉæÆôöòûùÿÖÜ¢£¥₧ƒáíóúñѪº¿⌐¬½¼¡«»░▒▓│┤╡╢╖╕╣║╗╝╜╛┐└┴┬├─┼╞╟╚╔╩╦╠═╬╧╨╤╥╙╘╒╓╫╪┘┌█▄▌▐▀αßΓπΣσµτΦΘΩδ∞φε∩≡±≥≤⌠⌡÷≈°∙·√ⁿ"
attr(,"fSize")
[1] 245
attr(,"nchars")
b c w
427 241 241
Warning message:
In readLines(file(file.name, encoding = encoding)) :
incomplete final line found on '/tmp/RtmpaPyDyp/bin65842896d5f1'
>
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] getGraphicsEvent on X11 and event queuing
Hi Frederik,
>
> on Tue, 7 Jun 2016 15:20:05 -0700 writes:
> ... I just realized that setGraphicsEventHandlers or
> getGraphicsEvent could have an 'onIdle' callback, to be
> called somewhere in the polling loop of gevents.c:163 - I
> think this would solve my problem #2 in a minimally
> disruptive way.
I hope you will get some feedback about this by one of the
graphics/devices experts from within R core.
I'm not among them at all, but they may be busy or travelling
currently.
Also, as you are studying the C code and the issues anyway, it
may be worthwhile to consider (as small as possible!) patches to
the source you could also post to the bugzilla site if you
prefer; attaching as text/plain to R-devel does work fine, too.
Best regards,
Martin
> On Mon, Jun 06, 2016 at 06:38:45PM -0700, frede...@ofb.net
> wrote:
>> Hi R-Devel,
>>
>> I've been working on an oscilloscope project using an
>> Arduino microcontroller board. I found that it's quite
>> easy to get realtime updates, e.g. 30+ frames per second,
>> if I read data from the board in a little Rcpp library. I
>> have to use dev.hold() and dev.flush() to keep the plot
>> from flickering, which restricts me to the "cairo" X11
>> device.
>>
>> I'd like to be able to add interactivity to the
>> oscilloscope display, for instance to bind a key to save
>> the current plot to a file, or to bind keys for adjusting
>> the time scale etc.
>>
>> However, I ran into two problems:
>>
>> (1) setGraphicsEventHandlers only works on the "Xlib" X11
>> device, which doesn't support buffering via dev.hold() -
>> it flickers.
>>
>> (2) getGraphicsEvent and friends lack some interface
>> features which are needed to use the functions in an
>> asynchronous fashion. Typically, event listener library
>> functions have a "timeout" parameter, and the ability to
>> return already-queued events. But getGraphicsEvent() has
>> neither - it waits indefinitely (you can't set a
>> timeout), and it seems to ignore events which occurred
>> before it was called (I can't figure out why, from the
>> code, I guess the normal R event processing grabs events
>> which occur between calls to getGraphicsEvent?).
>>
>> It seems like it should be possible to set a handler for
>> keyboard events and have it execute in between plot
>> updates when the user presses a key - yet without
>> blocking further updates if no key has been pressed.
>>
>> Is anyone interested in fixing (1) and (2)? Or is there
>> some other library or workaround to solve my problems?
>>
>> Here is some code I used to play around with these
>> functions:
>>
>> X11(type="Xlib");
>>
>> keydown = function(key) { cat("Got key: ",key); lastkey <<- key }
>>
>> setGraphicsEventHandlers(onKeybd = keydown);
>>
>> plot(c(0,0)); getGraphicsEvent();
>>
>> Well, I think it's great that getGraphicsEvent exists at
>> all, and want to salute Duncan Murdoch who is listed as
>> the author. I hope I may have helped by describing some
>> new possible uses for these functions.
>>
>> Thank you,
>>
>> Frederick
>>
>> __
>> 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
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
