Re: [Rd] Command completion of the R binary / Ubuntu
Am 11.01.2012 19:53, schrieb Sharpie: > The bash completion script is also used by the Homebrew package manager on > OS X. There we go... good to know. -- Claudia Beleites Spectroscopy/Imaging Institute of Photonic Technology Albert-Einstein-Str. 9 07745 Jena Germany email: claudia.belei...@ipht-jena.de phone: +49 3641 206-133 fax: +49 2641 206-399 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] parse( connection) and source-keeping
On 11/01/2012 8:36 PM, Duncan Murdoch wrote:
On 12-01-11 3:54 PM, mark.braving...@csiro.au wrote:
> In R<= 2.13.x, calling 'parse( con)' where 'con' is a connection, 'options(
keep.source)' is TRUE, and default 'srcfile' would preserve the source. In R>=
2.14.1, it doesn't.
Actually, it preserved the "source" attribute of the function if it
could, but didn't add a srcref. Sometimes it would fail, giving a
message like
Error in parse(textConnection(texto)) :
function is too long to keep source (at line 8812)
>
>> tf<- tempfile()
>> options( keep.source=TRUE)
>> texto<- c( 'function() { # comment', '}')
>> parse( text=texto)
> expression(function() { # comment
> })
>> cat( texto, file=tf, sep='\n')
>> parse( file=tf)
> expression(function() { # comment
> })
>> parse( file( tf))
> expression(function() {
> })
>> parse( textConnection( texto))
> expression(function() {
> })
>
> and yes I didn't bother closing any connections.
>
> My suspicion is that this change is unintentional, and it seems to me that
the best option would be for 'connection' to work like 'text' does here, ie to
attach a 'srcfilecopy' containing the contents.
Yes, that does sound like a good idea.
I've taken a look, and this doesn't look like something I'll fix for
2.15.0. Here's why:
The entry points to the parser are really quite a mess, and need to be
cleaned up: working around this problem without that cleanup would make
them messier, and I don't have time for the cleanup before 2.15.0.
Part of the problem is that connections are so flexible: the parser
doesn't know whether the connection passed to it is at the beginning, or
whether you've already read some lines from it; it might not even have a
beginning (e.g. stdin()).
There is a relatively easy workaround if you really need this: you can
make the srcfilecopy yourself, and pass it as the "srcfile" argument to
parse. (This won't work on the stdin() connection, but if you're the
one creating the connection, you can perhaps work around that. By the
time parse() is called, it's too late.)
The parser does manage to handle input coming from the console, because
that case uses a different entry point to the parser, and it keeps a
buffer of all input. (It needs to do this because you might not be
finished typing yet, and it will start over again when you enter the
next line.) So connections (even stdin()) could be handled in the same
way, and when I do the big cleanup, that's probably what will happen.
If you have a particular use case in mind and the workaround above isn't
sufficient, let me know.
Duncan Murdoch
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] How to modify the start-up message
Hi all, I got a custom R package in .zip (i.e. meant only for Windows installation). When I load that package, there are some start-up messages, probably loading through .onLoad() function. However I want to modify those messages. Please note that I do not have any other version of that package like .tar.gz fomat etc. Having only the .zip version, is there any possibility to modify those start-up functionalities of that package? Thanks for your help. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Inconsistencies in device_Raster when axes are reflected
Paul Murrell wrote
>
> I think the problem is that I just failed to anticipate this situation
> (i.e., the current documentation and behaviour both assume xlim[1] <
> xlim[2] and ylim[1] < ylim[2]).
>
> Will take a look at where to apply a fix (EITHER allow the API to be
> more flexible [allow negative 'width' and 'height' and 'x' and 'y' to be
> other than left-bottom], which will require complicating the code in
> some devices OR keep the API fixed and complicate the graphics engine
> code instead). The rotation argument adds an interesting twist ...
>
> Thanks for the report!
>
> Paul
>
Thanks for the reply Paul!
This isn't too hard to handle at the device level. For example, all I had to
do to the tikzDevice was add a loop and some logic that re-ordered the
raster vector and re-positioned the coordinate anchor:
int i, j, index, target, row_offset = 0, col_offset = 0, row_trans = 1,
col_trans = 1;
if ( height < 0 ) {
/* Using these parameters, one can cause a loop to "count backwards" */
row_trans = -1;
row_offset = h - 1;
/*
* If a dimension is negative, the (x,y) coordinate no longer references
* the lower left corner of the image. We correct for this and then make
* sure the dimension is positive.
*/
y += height;
height = fabs(height);
}
if ( width < 0 ) {
col_trans = -1;
col_offset = w - 1;
x += width;
width = fabs(width);
}
for ( i = 0; i < h; ++i ) {
for ( j = 0; j < w; ++j ) {
target = i*w + j;
index = (row_trans*i + row_offset)*w + (col_trans*j + col_offset);
INTEGER(red_vec)[target] = R_RED(raster[index]);
INTEGER(green_vec)[target] = R_BLUE(raster[index]);
INTEGER(blue_vec)[target] = R_GREEN(raster[index]);
INTEGER(alpha_vec)[target] = R_ALPHA(raster[index]);
}
}
This gives the device the same behavior as the PDF device. So, the behavior
isn't too difficult to correct on the device end---I was just concerned by
the difference between documentation and behavior and wanted to make sure
the graphics engine was not expecting something different.
-Charlie
-
Charlie Sharpsteen
Undergraduate-- Environmental Resources Engineering
Humboldt State University
--
View this message in context:
http://r.789695.n4.nabble.com/Inconsistencies-in-device-Raster-when-axes-are-reflected-tp4286320p4289713.html
Sent from the R devel mailing list archive at Nabble.com.
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Silently loading and Depends: versus NAMESPACE imports
Hi Dirk,
On 01/11/2012 11:42 AM, Dirk Eddelbuettel wrote:
R CMD check really hates it when my .onLoad() function contains
suppressMessages(library(foo))
Note that you can always fool 'R CMD check' by doing something like:
sillyname <- library
suppressMessages(sillyname("foo"))
Also isn't suppressPackageStartupMessages() more appropriate?
However, _and for non-public packages not going to CRAN_ I prefer doing this
over using explicit Depends or import statements in the NAMESPACE file as the
latter do not give me an ability to make the loading less verbose. With the
R universe of packages being as vast as at is, a simple (non-public) package
I have loads about five or six other packages explicitly, each of which loads
even more. The net result is totally intimidating _sixty lines full_ of
verbose noise that is meaningful to me as an R programmer, but not for the
colleagues expected to use the packages. It looks rather uninviting, frankly.
How do I use imports via NAMESPACE, and yet keep the noise level down to zero?
If you only need to import foo (i.e. and actually don't need to attach
it to the search path) then putting foo in Imports and using import
statements in NAMESPACE will keep the noise level down to zero.
So I guess your question is: how do we suppress package startup messages
for packages listed in Depends?
Cheers,
H.
Dirk
--
Hervé Pagès
Program in Computational Biology
Division of Public Health Sciences
Fred Hutchinson Cancer Research Center
1100 Fairview Ave. N, M1-B514
P.O. Box 19024
Seattle, WA 98109-1024
E-mail: hpa...@fhcrc.org
Phone: (206) 667-5791
Fax:(206) 667-1319
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] WISHLIST: Be able to timeout readline()/stdin via setTimeLimit in all consoles
Hi.
WISHLIST:
Regardless on console, I'd like to be able to timeout a call to
readline()/file("stdin", blocking=TRUE) via setTimeLimit.
OBSERVATION:
On Windows Rterm as well as plain R on Linux, setTimeLimit() does not
momentarily interrupt from stdin, but only after hitting RETURN. A
few examples:
timeout00 <- function() {
setTimeLimit(elapsed=5);
Sys.sleep(10);
}
timeout01 <- function() {
setTimeLimit(elapsed=5);
readline();
}
timeout02 <- function() {
setTimeLimit(elapsed=5);
con <- file("stdin", blocking=TRUE);
on.exit(close(con));
readChar(con, nchars=1);
}
timeout03 <- function() {
setTimeLimit(elapsed=5);
con <- socketConnection(port=6011, blocking=TRUE);
on.exit(close(con));
readChar(con, nchars=1);
}
# Times out after 5 second
> timeout00()
Error in Sys.sleep(10) : reached elapsed time limit
# Times out only after pressing ENTER
> timeout01()
foo
[1] "foo"
Error: reached elapsed time limit
# Times out only after pressing ENTER
> timeout02()
bar
[1] "b"
Error: reached elapsed time limit
# Times out after 5 second
> timeout03()
Error in socketConnection(port = 6011, blocking = TRUE)
reached elapsed time limit
Note also, that it is possible to interrupted timeout01() and
timeout02() via Ctrl+C as well as by sending SIGINT to the R process
(at least on a Linux system).
Doing the same in Rgui, the timeout will indeed timeout:
# Times out after 5 second
> timeout01()
Error in readline() : reached elapsed time limit
# Times out after 5 second (but somehow returns immediately)
> timeout02()
character(0)
Error: reached elapsed time limit
DOCUMENTATION:
The help("setTimeLimit", package="base") documentation says:
"Time limits are checked whenever a user interrupt could occur. This
will happen frequently in R code and during Sys.sleep, but only at
points in compiled C and Fortran code identified by the code author."
Maybe one could clarify/examplify(?) by adding: "Depending on the type
of console, timeouts when reading from stdio (e.g. via readline()) may
not be effective until a line is completed (i.e. ENTER is pressed).
HOW UPDATING SOURCE CODE TO SUPPORT INTERRUPTS?
I'm not sure where this "behavior" is originating from, and whether it
is possible to obtain a cross-platform solution or not. I located the
following native do_readln() function in src/main/scan.c that is
called by readline():
SEXP attribute_hidden do_readln(SEXP call, SEXP op, SEXP args, SEXP rho)
{
...
while ((c = ConsoleGetchar())!= '\n' && c != R_EOF) {
if (bufp >= &buffer[MAXELTSIZE - 2]) continue;
*bufp++ = c;
}
...
}
with ConsoleGetchar():
/* used by readline() and menu() */
static int ConsoleGetchar(void)
{
if (--ConsoleBufCnt < 0) {
ConsoleBuf[CONSOLE_BUFFER_SIZE] = '\0';
if (R_ReadConsole(ConsolePrompt, ConsoleBuf,
CONSOLE_BUFFER_SIZE, 0) == 0) {
R_ClearerrConsole();
return R_EOF;
}
ConsoleBufp = ConsoleBuf;
ConsoleBufCnt = strlen((char *)ConsoleBuf);
ConsoleBufCnt--;
}
/* at this point we need to use unsigned char or similar */
return (int) *ConsoleBufp++;
}
where in turn R_ReadConsole() appears to be specific to platform and
console, e.g. from src/gnuwin32/system.c:
* R_ReadConsole calls TrueReadConsole which points to:
* case 1: GuiReadConsole
* case 2 and 3: ThreadedReadConsole
* case 4: FileReadConsole
* ThreadedReadConsole wake up our 'reader thread' and wait until
* a new line of input is available. The 'reader thread' uses
* InThreadReadConsole to get it. InThreadReadConsole points to:
* case 2: CharReadConsole
* case 3: FileReadConsole
Here I get a bit lost, but there is:
/*2: from character console with getline (only used as InThreadReadConsole)*/
static int
CharReadConsole(const char *prompt, char *buf, int len, int addtohistory)
{
int res = getline(prompt, buf, len);
if (addtohistory) gl_histadd(buf);
return !res;
}
and, AFAIU, getline() is from the GNU getline library. Is it possible
to timeout getline()? At least it appears to be responding to SIGINT.
/Henrik
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
