Re: [Rd] Call R function from Java

2010-08-08 Thread bytecode

RCaller is another way for calling r from java without JNI.
You can try and develop RCaller with GPL license.
http://www.mhsatman.com/rcaller

-- 
View this message in context: 
http://r.789695.n4.nabble.com/Call-R-function-from-Java-tp911738p2317844.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] readline operate-and-get-next

2010-08-08 Thread Rafael Laboissiere
Okay, I could not refrain myself and implemented the change in
src/unix/sys-std.c.  The patch is attached below.  I tested it in the
2.11.1 source and it worked fine.  At any rate, the patch applies cleanly
to the SVN source.

Three notes about this patch:

1. The code is taken from the bash source (bashline.c) with minimal
   changes.
   
2. The changes are put inside #ifdef HAVE_READLINE_HISTORY_H, because
   it uses history related functions.
   
3. In the call to rl_add_defun, the operate-and-get-next function is
   bound to C-o.  This is not the behavior of Bash and Octave, which
   depends on the user to define the key binding in ~/.inputrc.  To
   mimic this behavior, the code should be rather:

   rl_add_defun ("operate-and-get-next", operate_and_get_next, -1);


Best regards,

Rafael Laboissiere

* Rafael Laboissiere  [2010-08-07 13:07]:

> Both Bash and Octave have a nifty addition to the readline library called
> "operate-and-get-next", bound to "C-o".  This function accepts the
> current line for execution and fetch the next line relative to the
> current line from the history for editing (see
> http://www.faqs.org/docs/bashman/bashref_101.html).
> 
> This feature has a huge impact in my productivity using Bash and Octave
> interactively, since it avoids those numerous arrow key strokes in order
> to rerun a previous block of commands. 
> 
> I looked at the Bash sources and it does not seem too complicate to
> implement.  Octave has borrowed practically the same code from Bash.
> Before I start looking at the R code, I would like to know whether the R
> developers had already planned to include the operate-and-get-next
> feature into R.
> 
> Best regards,
> 
> Rafael Laboissiere
--- a/src/unix/sys-std.c
+++ b/src/unix/sys-std.c
@@ -596,6 +596,54 @@
 onintr();
 }
 
+
+#ifdef HAVE_READLINE_HISTORY_H
+/* 
+   Add a function that accepts the current line for execution and
+   fetch the next line relative to the current line from the history for
+   editing.
+
+   The code below is taken almost as is from the Bash source (bashline.c).
+*/
+
+static rl_hook_func_t *old_rl_startup_hook = (rl_hook_func_t *)NULL;
+
+static int saved_history_line_to_use = -1;
+
+static int
+set_saved_history ()
+{
+  if (saved_history_line_to_use >= 0)
+rl_get_previous_history (history_length - saved_history_line_to_use, 0);
+  saved_history_line_to_use = -1;
+  rl_startup_hook = old_rl_startup_hook;
+  return (0);
+}
+
+static int
+operate_and_get_next(int count, int c)
+{
+  int where;
+
+  /* Accept the current line. */
+  rl_newline (1, c);
+
+  /* Find the current line, and find the next line to use. */
+  where = where_history ();
+
+  if ((history_is_stifled () && (history_length >= history_max_entries)) ||
+  (where >= history_length - 1))
+saved_history_line_to_use = where;
+  else
+saved_history_line_to_use = where + 1;
+
+  old_rl_startup_hook = rl_startup_hook;
+  rl_startup_hook = set_saved_history;
+
+  return 0;
+}
+#endif
+
 #ifdef HAVE_RL_COMPLETION_MATCHES
 /* 
function-completion interface formerly in package rcompletion by
@@ -893,6 +941,10 @@
 #ifdef HAVE_RL_COMPLETION_MATCHES
 	initialize_rlcompletion();
 #endif
+#ifdef HAVE_READLINE_HISTORY_H
+rl_add_defun ("operate-and-get-next", operate_and_get_next,
+  CTRL ('O'));
+#endif
 	}
 	else
 #endif /* HAVE_LIBREADLINE */
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel


Re: [Rd] gpar fill and transparency on devices

2010-08-08 Thread Paul Murrell

Hi

On 6/08/2010 5:34 p.m., baptiste auguie wrote:

Hi,

Thanks for pointing this out. I do have the book, unfortunately I left
it abroad this year. I would think that such brief mention in ?gpar
could be useful (because that's where one first looks for gpar()
defaults --- which are not listed).


Righto.  I've added a mention in ?gpar

Paul


Best regards,

baptiste


On 6 August 2010 00:54, Paul Murrell  wrote:

Hi

The help page for "Working with Viewports" (e.g., pushViewport()) has a
brief mention when talking about the ROOT viewport ...

"The viewport tree always has a single root viewport (created by the system)
which corresponds to the entire device (and default graphical parameter
settings)."

... which is a reasonable place for it because this is a feature of the gpar
of the ROOT viewport, not of gpars in general.  That mention might be a bit
hard to find, but a very similar statement is also made in the Section on
Viewports in the R Graphics book.  That in turn might be hard to find if you
don't have the book, but that chapter is also available online
(http://www.stat.auckland.ac.nz/~paul/RGraphics/chapter5.pdf)

It might be worth adding something more explicit about this sort of gotcha
...

"Some devices have different default graphics parameter settings, so it is
not safe to assume that the ROOT viewport will be identical on different
devices."

... ?

Paul

On 5/08/2010 8:14 a.m., baptiste auguie wrote:


Dear list,

I'm puzzled by the graphical output in the following example,

library(grid)

foo<- function(){
   grid.rect(gp=gpar(fill="black"))
   print(get.gpar()$fill)
   grid.rect(width=0.2,height=0.2)
}

png("test.png", bg = "transparent")
foo()
dev.off()

png("test1.png", bg = "white")
foo()
dev.off()


It seems that the default value of gpar()$fill is set according to the
device background. I couldn't find this documented in ?gpar or in
?png, and it caused a rather puzzling bug in my code (the pdf() output
was OK, whilst the png output (default bg to white) was seemingly
empty because covered by a white rectangle.)

Best regards,

baptiste

__
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
p...@stat.auckland.ac.nz
http://www.stat.auckland.ac.nz/~paul/







--
Dr Paul Murrell
Department of Statistics
The University of Auckland
Private Bag 92019
Auckland
New Zealand
64 9 3737599 x85392
p...@stat.auckland.ac.nz
http://www.stat.auckland.ac.nz/~paul/

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel